ASVS V6.2.10 requires that a user's password stays valid until it is discovered to be compromised or the user chooses to change it. The application must not require periodic rotation. It is a Level 2 requirement.
This requirement removes a habit rather than adding a feature. The reasoning is simple: change a password when you have a reason, not on a schedule.
Why it matters
Forced rotation produces Summer2026! followed by Autumn2026!. Attackers who know one password can guess the next. Meanwhile users spend effort on a ritual that does not stop real attacks.
Scheduled expiry does not reduce risk in the way people assume. If an attacker steals a hash today, they will crack it before the next rotation date in many cases, and users who are forced to change often choose small variations that are easy to predict. Expiry also drives helpdesk tickets and sticky notes.
Meanwhile, the events that really matter are not calendar dates: a breach at another service, malware on a device, a phishing click. Those are the triggers to design for.
How to implement it
Remove expiry from the data model and the policy. Replace it with event driven changes:
- Force a reset when the password appears in a breach corpus (V6.2.12).
- Force a reset after confirmed account compromise.
- Let users change whenever they choose.
# do this
def must_reset(user):
return user.flagged_compromised or is_breached(user.password_fingerprint)
# not this
def must_reset_old(user):
return (now() - user.password_set_at).days > 90
Update your written policy as well, because auditors read it.
Make the change in three steps. First, remove the expiry field and any scheduled job that reads it. Second, build the replacement signals: breach checks on sign in or in the background against your hash fingerprint set, alerts from the identity provider, and an admin action to flag a user as compromised. Third, show users a clear option to change their password at any time. If you operate in a regulated sector that still mandates rotation, document the rationale, because the requirement allows deviation only with a clear justification.
How to test it
Set a test account's password change date to two years ago. Sign in. No expiry prompt should appear. Then mark the account compromised and confirm a reset is required.
Review the identity provider, the directory and any VPN or legacy portal behind the same accounts. A single expiry setting in one of them contradicts the requirement for the user even if your code is clean.
Common mistakes
-
Leaving a 90 day job in the identity provider while the app is clean.
-
Keeping an expiry because an old compliance document says so.
-
Not offering a way to detect compromise, which leaves rotation as the only lever.
-
Forgetting directory services or SSO products that carry their own expiry setting.
-
Dropping expiry without adding any compromise detection, leaving no way to force a reset.
Quick check
What replaces scheduled rotation?
Rotation on evidence of compromise, plus a user initiated change at any time.
