Your password expires in five days.
You change it. Again.
Maybe you replace the number at the end, move the special character, or update the season and year. The system accepts it, the compliance report turns green, and everyone moves on for another 60 or 90 days.
That may look like security. It usually is not.
If your organization still forces employees to change their passwords on a fixed schedule simply because the calendar says so, it is time to revisit the policy. The National Institute of Standards and Technology (NIST) has advised against arbitrary periodic password changes since 2017. Its current guidance is even more direct:
NIST’s current instruction is straightforward: organizations following the guidance shall not require periodic password changes and shall force a change when there is evidence of compromise.
That is not permission to ignore passwords. It is a direction to replace a low-value ritual with controls that address how accounts are actually compromised.
The Guidance Changed Years Ago
Periodic password expiration did not appear out of nowhere. It was a reasonable response to an older problem: if a password was stolen and nobody knew, eventually expiring it could shorten the time an attacker was able to use it.
The weakness in that approach is that password age is not evidence of password compromise. A password stolen the day after a mandatory reset may remain useful for nearly the entire rotation period. A strong, unique password that has not been exposed does not become weak on day 91.
As password research improved and large breach datasets showed how people actually behave, the guidance changed.
2016: NIST Signals a Different Direction
In 2016, NIST previewed a rewrite of its digital identity guidance. The agency described password rotation and complicated composition rules as requirements that looked helpful on paper but often caused people to create predictable passwords, reuse them, or store them insecurely.
That preview was an early public signal that the familiar password playbook was being reconsidered.
June 2017: NIST Says “Should Not”
NIST finalized Special Publication 800-63-3 and its companion authentication guidance, SP 800-63B, on June 22, 2017. The new guidance said verifiers should not require passwords—then called “memorized secrets”—to be changed arbitrarily or periodically. It also said a change shall be forced when there is evidence of compromise.
This was the important break from calendar-based expiration. NIST paired it with a broader shift toward longer passwords, screening out known weak or compromised values, allowing password managers, rate-limiting guesses, and using multi-factor authentication.
2019: Microsoft Removes Expiration From Its Baseline
The change was not limited to NIST. In 2019, Microsoft removed periodic password-expiration policies from its Windows 10 and Windows Server security baseline. Microsoft called periodic expiration an old mitigation of very low value and pointed organizations toward banned-password lists and MFA instead.
That did not make password expiration impossible to configure. It meant Microsoft no longer considered a fixed expiration period a broadly applicable security baseline.
2025: NIST Strengthens “Should Not” to “Shall Not”
NIST finalized Revision 4 of its Digital Identity Guidelines on July 31, 2025, and identified August 1 as the date the revision superseded the 2017 guidance.
The current SP 800-63B-4 strengthens the language. Periodic password changes moved from SHOULD NOT, a strong recommendation, to SHALL NOT, a requirement for systems claiming conformance with that guidance.
The exception remains the same: force a password change when there is evidence that it has been compromised.
Why Forced Rotation Can Make Security Worse
The problem is not that changing a compromised password is bad. The problem is requiring a change without a security reason.
People Make Predictable Changes
When employees know they must invent a new password every few months, they adapt. A password ending in 1! becomes 2!. A month, season, or year changes while the rest stays the same. Attackers know these patterns, too.
NIST’s password-expiration FAQ explains that users often choose weaker passwords when they know another change is coming. When forced to change, they commonly apply predictable transformations to the old password. If an attacker knows a previous password, those transformations are easy to test.
The system records a new value. The person and the attacker may see almost the same password.
Rotation Does Not Stop Common Password Attacks
A scheduled change does little to prevent:
- Phishing that captures the current password
- Password spraying against common passwords
- Credential stuffing with passwords reused from another breach
- Malware or keylogging on an endpoint
- Session-cookie theft that bypasses the password entirely
- Social engineering of a help desk or account-recovery process
The password may be new and still be phished this afternoon.
It Encourages Workarounds
Frequent expiration creates a memory problem at scale. Employees respond by choosing easier patterns, reusing passwords, writing them down in exposed places, or making the smallest change the system will accept.
It also creates lockouts, support tickets, and interruptions. Those costs might be worthwhile for a control that materially reduces risk. They are harder to justify for a ritual that often produces weaker password behavior.
The Calendar Is a Poor Security Signal
A password’s age tells you when it was set. It does not tell you whether it appeared in a breach, was entered into a fake login page, was shared, or was used from an unusual location.
Modern identity security should respond to evidence and risk signals, not birthdays.
What Current Best Practice Looks Like
Ending routine expiration is only one part of a modern password policy. If an organization disables the 90-day timer and changes nothing else, it has not finished the job.
Change Passwords When There Is a Reason
Require an immediate change when:
- The password appears in a known breach or compromised-password dataset
- The user reports entering it into a suspected phishing site
- Suspicious activity suggests the account or credential was used by someone else
- Malware capable of stealing credentials is found on the user’s device
- A temporary or default password is still in use
- An administrator resets the account or the user requests a change
The response may also need to revoke active sessions, review MFA methods and recovery information, investigate activity, and address the cause of the compromise. Changing the password alone may not remove an attacker who already has a valid session.
Prefer Long, Unique Passwords
Current NIST guidance requires at least 15 characters when a password is used as the only authentication factor. When the password is used as part of MFA, NIST permits a minimum of eight characters. Systems should support passwords up to at least 64 characters.
The practical goal is a long, unique password for every account. A password generated by a password manager is ideal. When a person must remember the password, a long passphrase can be easier to use than a short string built to satisfy several composition rules.
NIST also says systems shall not impose additional composition rules such as requiring a mixture of uppercase letters, lowercase letters, numbers, and symbols. Those rules tend to produce predictable substitutions rather than meaningful strength.
Use a Password Manager
People cannot reliably create and remember a different strong password for every business and personal account. A password manager can generate and store unique credentials, reduce reuse, and make long random passwords practical.
NIST now says verifiers shall allow password managers and autofill and should permit pasting into password fields. Blocking paste is not a security feature; it makes secure credential handling harder.
Block Known-Bad Passwords
When a password is created or changed, compare the full value against a blocklist of commonly used, expected, or compromised passwords. That list should also account for context-specific choices such as the organization’s name, the service name, and the username.
This addresses the passwords attackers are likely to guess before rate limits stop them. It is more useful than demanding a symbol that turns Password1 into Password1!.
Require MFA—and Prefer Phishing-Resistant Methods
NIST is explicit that passwords are not phishing-resistant. A strong password is still a reusable secret that can be stolen.
Require MFA for email, remote access, administrators, financial systems, cloud services, and other important accounts. When the platform supports it, prefer phishing-resistant authentication such as FIDO/WebAuthn security keys or passkeys. CISA recommends that organizations plan toward phishing-resistant MFA because it can prevent a credential entered at an impostor site from being replayed at the legitimate one.
Protect the Authentication System
The organization and its technology providers still have work to do behind the login screen:
- Rate-limit failed authentication attempts
- Store passwords with an appropriate salted, computationally expensive password-hashing scheme
- Monitor for suspicious authentication and account-recovery activity
- Alert users and administrators to meaningful identity events
- Protect privileged accounts more strongly than ordinary user accounts
- Maintain a tested, abuse-resistant recovery process
- Revoke sessions and tokens during a credential-related incident
This places more of the security burden on systems designed to handle it instead of asking employees to defeat modern attacks with better memory.
Old Policy vs. Better Policy
| Old approach | Better approach |
|---|---|
| Expire every password every 60 or 90 days | Change a password when compromise is suspected or confirmed |
| Require short passwords with several character classes | Prefer long, unique passwords and support lengths of at least 64 characters |
| Accept any password that satisfies the format | Block common, expected, and compromised passwords |
| Make users memorize many changing passwords | Allow password managers, autofill, and paste |
| Treat the password as the primary defense | Require MFA and prefer phishing-resistant authentication |
| Measure compliance by password age | Monitor compromise signals, risky activity, and control coverage |
This Guidance Is About Human Passwords
“Stop routine password rotation” is easy to overgeneralize.
NIST’s guidance here applies to centrally verified passwords used by people. It does not mean every secret in a technology environment should live forever.
Different handling may be appropriate for:
- Default and temporary passwords
- Shared credentials that cannot yet be eliminated
- Break-glass and emergency-access accounts
- Privileged credentials managed by a vault
- Service-account passwords and application secrets
- API keys, certificates, encryption keys, and other machine credentials
- Credentials subject to a specific legal, regulatory, contractual, or insurance requirement
Many of these secrets should be replaced with managed identities, certificates, short-lived credentials, or automated vault rotation rather than handled like an employee’s password. The right lifecycle depends on how the secret is used, how compromise can be detected, and what requirement applies.
How to Retire a 90-Day Password Policy Safely
Do not begin by simply turning off expiration everywhere. Begin by understanding what the existing policy covers and what will replace it.
- Inventory the accounts. Separate ordinary employee accounts from privileged, emergency, shared, service, and machine credentials.
- Confirm the safeguards. Verify MFA coverage, compromised-password screening, rate limiting, logging, alerting, secure password storage, and recovery controls.
- Check obligations. Determine whether a law, contract, customer requirement, cyber-insurance condition, or adopted standard still requires a particular change interval.
- Update the written policy. State the events that require a password change and who can initiate one.
- Change the technical settings. Remove arbitrary expiration only for the account populations covered by the new policy.
- Explain the change. Employees should hear that passwords are becoming longer, unique, manager-supported, and protected by MFA—not that password security no longer matters.
- Measure the result. Track MFA coverage, compromised credentials, suspicious sign-ins, reset events, lockouts, and help-desk volume.
The goal is not fewer controls. The goal is better controls.
Change Passwords Because Something Happened
A password should change because it was exposed, may have been exposed, is temporary or shared inappropriately, or no longer fits the way the account should be protected.
It should not change merely because Tuesday arrived and a counter reached 90.
The guidance has been clear since 2017 and is stronger today. Long, unique passwords; password managers; compromised-password screening; rate limiting; MFA; secure storage; monitoring; and event-driven resets provide a better defense than predictable changes on a calendar.
If your password policy still measures security by how often employees invent a new variation of the same password, it is overdue for a review.
Sources
- NIST: Ideas Whose Time Has Come (and Gone), v. 2017 (December 20, 2016)
- NIST SP 800-63-3 final publication announcement (June 22, 2017)
- NIST SP 800-63B (2017), archived password requirements
- NIST SP 800-63B-4 (2025), current password requirements
- NIST FAQ: Is password expiration no longer recommended?
- NIST: Easy Ways to Build a Better Password (2017)
- Microsoft Windows security baseline removing password-expiration policies (2019)
- CISA: More Than a Password
Is Your Password Policy Solving the Right Problem?
MN Risk & Cybersecurity Advisory helps small and mid-sized businesses review identity controls, align policies with current guidance, and replace checkbox security with practical risk reduction.