A calendar reminder is not evidence that a password has been compromised.
The original article argued against forcing a new password every ninety days. Its strongest point was practical: changing a suffix can satisfy an expiry policy without addressing how the account is actually attacked.
That example is not a measurement of every user, and it is not a reason to ignore a real compromise. The question is what should trigger a reset, and what other protections the sign-in system needs.
01 / FIELD NOTESWhat the guidance says
Guidance check — September 29, 2026: NIST SP 800-63B-4 says verifiers must not require periodic password changes and must force a change when there is evidence of compromise. It also addresses blocklists, password-manager support, and phishing-resistant authentication.
Those requirements have a defined scope. Reviewing them is not the same as establishing every contractual, sector-specific, or organizational requirement that applies to a particular system. Check that context before changing an enforced policy.
02 / FIELD NOTESSeparate the scenarios
Different events need different responses.
Select a scenario to see the boundary. This is explanatory guidance, not a policy engine.
A date passes.
No evidence of compromise is established by the date alone.
Calendar event ≠ exposed authenticator.
The cited NIST guidance rejects periodic changes. Review the applicable system requirements before adjusting policy.
Read the figure without interaction
An expiry date alone does not establish compromise. Confirmed exposure needs a response. An unusual sign-in needs investigation. Authentication methods differ in phishing resistance. This illustration does not override applicable requirements or configure a provider.
The figure is an explanation, not a policy engine. It does not check a password, query a breach service, or change an account.
An ordinary expiry date, a known exposed credential, an unusual sign-in, and an authenticator upgrade are different situations. A suspicious signal needs investigation; it is not automatically conclusive evidence about one particular password.
03 / FIELD NOTESWhat belongs beside the reset rule
The original article pairs longer passwords and password-manager support with breach screening and multifactor authentication. They address different weaknesses, so the replacement should not be reduced to a single “never expire” checkbox.
Technical clarification: a one-time code from an authenticator app is not the same as phishing-resistant authentication. NIST explains that manually entered OTPs can be relayed; the authenticator guidance distinguishes them from protocols that bind authentication to the verifier.
Use that distinction when comparing options. Calling every second factor “phishing resistant” hides an important part of the choice.
04 / FIELD NOTESBreach screening is not a plaintext-password collection task
The original article mentions Pwned Passwords. Its documented range API uses the first five characters of a password hash to return candidate suffixes for local comparison, rather than requiring a plaintext password to be sent.
That does not mean a maintainer can take arbitrary stored password-verifier hashes and directly compare them with that dataset. A system needs an appropriate point in the credential-setting or authentication flow and a careful implementation. This page collects no password and implements no screening service.
05 / FIELD NOTESPlan the policy change, not just the toggle
The original closing presented this as mostly a quick configuration change. That may describe some systems, but it is not established for an unknown identity provider or custom application.
Review the current authentication setup, recovery process, blocklist behavior, MFA options, exception handling, and applicable requirements. Explain the change to users. Retain a response process for exposed credentials and test recovery before relying on it.
The aim is not fewer settings for their own sake. It is a policy in which each requirement has a clear job—and a reset happens for a meaningful reason.
Source, dates, and what this page verifies
Based on the complete supplied project/article account. Original publication dates and source URLs are retained. This is an edited reference, not a published update or a new audit of the original application.
Official technical clarifications checked September 29, 2026 are explicitly marked and linked beside the relevant passages. They are distinct from the original author's historical claims. The jq and Docker excerpts remain unchanged and carry their source limitations.
New interactive examples are bounded local teaching tools; they do not scan a website, process credentials, contact AWS, build an image or report a production measurement. No repository, staff account, service terms, résumé, price or live backend was changed.
See docs/batch-6/SOURCE-REVIEW.md for the separation of source-derived claims, external documentation and authored illustrations.