Your Compliance Framework Still Requires 90-Day Rotation. Now What?

You won the argument. It took two quarters, a written proposal, and a meeting where you walked the security team through the research: rotation trains users to increment a digit, it drives helpdesk volume, it conditions people to comply with unexpected "change your password now" prompts. NIST agrees with you. Microsoft agrees with you. The NCSC agrees with you. Expiry got turned off. Support ticket volume dropped about eleven percent in the following month and nobody complained.

Six weeks later, procurement forwards a security questionnaire from a prospect worth more than your last two years of new ARR combined. Question 47: Are user passwords required to be changed at least every 90 days? (Yes/No)

There is no comment box.

That gap — between what the field concluded and what the paperwork enforces — is where most security engineers actually live. The case against rotation is settled; I've made it at length elsewhere and I'm not going to relitigate it here. This article assumes you already agree and are nonetheless contractually obligated. That's a different problem, and it's an engineering and negotiation problem rather than a research one.

Why the gap exists, and why it will persist

It's tempting to attribute the lag to ignorance. It's mostly structure.

Frameworks revise on multi-year cycles, and their consumers revise slower. PCI DSS v4.0 landed in 2022 with a transition period running into 2025. ISO 27001 was revised in 2022 and organizations were still transitioning certificates through 2025. NIST SP 800-53 Rev 5 shipped in 2020; FedRAMP's Rev 5 baselines arrived in 2023 and providers spent well over a year transitioning. Each hop adds latency, and the guidance a framework cites was current when the drafting committee froze scope, not when you read it.

Auditors test the written control, not the control objective. This is the single most important structural fact in the whole subject and I'll come back to it. An auditor's job is to obtain evidence that a stated control operated as described. If the description says "passwords expire every 90 days" and your configuration says otherwise, that is an exception, full stop. It doesn't matter that your actual posture is better. The auditor is not evaluating your security; they're evaluating conformance to a description. Confusing those two is the reason most of these conversations go badly.

Questionnaires are copied, not written. The vendor security questionnaire you just received was very likely assembled from a template that was itself assembled from an earlier template. I have answered questionnaires in the last two years that asked about antivirus definition update frequency and whether we ran quarterly "war dialing." The 90-day question survives in these documents for the same reason vestigial code survives in a repo: removing it requires someone to take responsibility for removing it.

And the incentive is asymmetric. Nobody has ever been disciplined for requiring password rotation. The failure mode of over-requiring is diffuse annoyance spread across thousands of people; the failure mode of under-requiring, in the mind of the person signing off, is being the one who removed a control before a breach. That asymmetry is stable regardless of evidence, which is why "the research says" is a weaker argument in that room than you expect.

What the current guidance actually binds

Be precise here, because imprecision is how you lose credibility with a compliance function.

NIST SP 800-63B — the authenticator half of the Digital Identity Guidelines — is the document everyone cites. Revision 3 (2017) advised against arbitrary periodic expiration; the finalized Revision 4 (2025) states it in stronger normative language: verifiers and credential service providers shall not require periodic change of memorized secrets, and shall force a change when there is evidence of compromise. It pairs that with requirements that go the other direction on strictness — screening candidate secrets against lists of commonly used and compromised values, minimum lengths, no composition rules, no knowledge-based recovery questions.

Two scoping points people get wrong.

First, 800-63 is guidance for U.S. federal agencies and the credential service providers serving them. It is not a law that applies to your SaaS company. It has enormous influence because other frameworks and regulators adopt it by reference or converge on it independently, but "NIST says so" is not a compliance argument on its own. It's an argument that your chosen control is defensible against contemporary practice, which is a different and more useful claim.

Second, the prohibition is on arbitrary periodic change. It is not a prohibition on rotation. Evidence-driven change is required. That distinction matters when you're writing replacement control language, because it gives you something affirmative to promise rather than merely an absence.

The version dependence is real and worth stating out loud when you cite it: 800-63B Rev 3 and Rev 4 differ in force and in surrounding requirements, and the framework mapping documents your auditor holds may still reference Rev 3. Cite the revision. If someone paraphrases without one, treat the paraphrase as unverified.

Where 90 days genuinely still lives

Not everywhere people think, and the map matters because you should only fight the battles that exist.

PCI DSS is the most-cited and the most misread. In v4.x, requirement 8.3.9 applies only where a password is the sole authentication factor for user access, and even then it offers two options: change at least every 90 days, or dynamically analyze the security posture of accounts and determine access in real time accordingly. Requirement 8.3.10.1 imposes the parallel obligation on service providers for customer-user passwords. Meanwhile 8.4.2 requires MFA for all access into the cardholder data environment, effective March 2025.

Follow the logic: if you've satisfied 8.4.2, password-only access to the CDE largely shouldn't exist, and the condition that triggers 8.3.9 stops being met for those accounts. A large number of organizations are still rotating passwords in the name of a requirement whose predicate they no longer satisfy. And 8.6.3, covering application and system account passwords, doesn't specify an interval at all — it requires a frequency justified by a targeted risk analysis under 12.3.1.

Also: PCI scope is the cardholder data environment and connected systems. It is not your entire corporate directory. Scope creep from "PCI requires this" to "we rotate everyone's password" is extremely common and is nobody's requirement but your own.

FedRAMP is where you have the least room. Baselines are prescriptive, control parameters are set for you, and the Rev 5 IA-5 family moved closer to 800-63 in substance — compromised-credential screening, approved key derivation, long user-chosen passwords — but you are implementing whatever the baseline text and the PMO's guidance say, at the revision in force for your authorization. Argue at parameter level with your 3PAO, and expect the room to be narrow.

ISO 27001 almost never requires it, and this surprises people. Annex A 5.17 in the 2022 revision concerns the management of authentication information; the standard does not specify an expiry interval. What you're actually being audited against is your own Statement of Applicability and the policy you wrote to satisfy the control. If your password policy says 90 days, ISO now requires 90 days — of you, because you said so. The 2013 version's implementation guidance leaned toward periodic change, and plenty of policies still carry that language forward untouched from a decade ago.

HIPAA specifies nothing about intervals. § 164.308(a)(5)(ii)(D) is an addressable implementation specification requiring procedures for creating, changing, and safeguarding passwords. The 90-day number in healthcare comes from derived checklists, HITRUST, and payer contracts — not from the Security Rule. (Watch the proposed rulemaking here; the direction of travel is toward more prescription, not less.)

And then there's the contract, which outranks every standard on this list. A customer can require anything they can get you to sign, and a Master Services Agreement with a security exhibit specifying quarterly password expiry is binding no matter what NIST publishes. This is not a compliance problem you can reason your way out of. It's a commercial term.

The insight most teams miss: SOC 2 requires whatever you said it does

If you take one thing from this article, take this one, because it's the most common and most expensive misunderstanding in the whole space.

SOC 2 has no password requirements. None. Not 90 days, not 12 characters, not complexity. The Trust Services Criteria are outcome-based. CC6.1 asks that the entity implement logical access security measures to protect information assets; it says nothing about expiry intervals. There is no clause you can point to because there is no clause.

What gets audited in a SOC 2 examination is management's description of the system — a document you write — and the controls you stated in it. The auditor obtains evidence that your stated controls were suitably designed and, for a Type 2, operated effectively over the period. So when someone on your team says "SOC 2 requires 90-day rotation," what is nearly always true is one of:

• Somebody wrote it into your control matrix during the first audit, probably in year one, probably by copying a template or accepting an auditor's suggested control language.
• Your auditor's readiness checklist proposed it and nobody pushed back, because pushing back in year one costs time you didn't have.
• A compliance automation platform seeded your control set from a default library and the default included it.

All three are your control, not the standard's.

The consequence is liberating and underused: you can change it. Not by arguing with the standard, which has no opinion, but by amending your own description of the system and demonstrating that the revised control still satisfies the criterion. Nothing in the framework prevents this. What prevents it in practice is timing — you cannot rewrite a control halfway through a Type 2 observation period without creating an exception for the portion of the period where the old control didn't operate. You have to do it at scoping, before the period begins, with the auditor's agreement on record.

The same reasoning applies to ISO 27001 and its Statement of Applicability, and partially to HIPAA's addressable specifications, which explicitly contemplate an alternative measure that accomplishes the same purpose plus documentation of why. Three of the frameworks most often cited as requiring rotation actually require you to have decided something and be able to evidence it. That's a much better position than it sounds, and most teams never notice they're in it.

The compensating-control argument, made properly

The move that works is never "rotation is bad." It's: here is the risk the rotation control addresses, here is the control we substitute, here is the evidence it operates. Frame it as control objective preserved, mechanism improved.

A note on the mechanics of the first row: checking passwords against a breach corpus without disclosing them to anyone is a solved problem, and worth understanding properly rather than approximating — the login-time check in particular is the only moment you ever hold the plaintext of a password set years ago, and it's where the substitute control does its real work.

Now the honest part, and you should say it out loud in the room rather than let the auditor find it.

Rotation does address one thing the substitutes don't fully cover: an undetected, long-lived compromise where the attacker is quiet. No breach-corpus hit, because the password was never published. No anomaly, because the attacker logs in from a plausible location at plausible hours and behaves like the user. Rotation puts a hard deadline on that credential regardless of whether anyone ever noticed. That is a genuine property and pretending otherwise weakens everything else you say.

What actually covers it is not a single control but a set: MFA, which means the stolen password alone is insufficient; session and token lifetimes bounded so persistence requires repeated re-authentication; and the ability to force a reset across an entire population in minutes when you do get a signal. The last one is the piece most organizations that abolished expiry never built, which is a bad trade — they removed the scheduled reset and never acquired the emergency one. If you're going to make this argument, build that capability first, and be prepared to show a timestamped record of the last time you exercised it.

How to have the conversation

Do it at scoping, not at fieldwork. During fieldwork the auditor is collecting evidence against a fixed control set. A change proposed then is an exception with extra steps. At scoping — before the observation period opens — you're jointly defining what will be tested, and auditors are far more flexible about control language they haven't yet committed to testing.

Bring the replacement text drafted. Not a concern, not a question, not a link to a NIST publication. A specific paragraph you propose to put in the description of the system, in the same register as the control it replaces. Something along the lines of: user passwords do not expire on a fixed schedule; candidate passwords are screened against a compromised-credential corpus at set time and at authentication; a password change is forced upon corpus match, anomalous authentication, or confirmed compromise; MFA is enforced for all interactive access. Then the artifact list for each clause. You are handing the auditor their own workpaper, which is a favour and lands as one.

Argue the objective, never the standard. "The control objective under CC6.1 is that logical access is restricted to authorized users; here is how we meet it" is a conversation. "NIST says rotation is counterproductive" is a challenge to the framework the auditor is paid to apply, and it puts them in a position where agreeing with you means going off-script for your benefit. Auditors have professional exposure. Give them a defensible file, not a debate.

Map old to new explicitly, control ID to control ID, with the risk each addresses. Compliance functions think in mappings. A document that says "control AC-07 is superseded by AC-07a and AC-07b, addressing the same risk, evidenced by X and Y" is a document someone can approve.

Things that do not work, and I've watched all of them fail:

Sending research papers. Nobody in the audit chain is empowered to act on them.

Changing the configuration and hoping the sample doesn't catch it. It will, and now you have an integrity problem instead of a policy disagreement.

Escalating over the auditor to a partner. It works occasionally and costs you the working relationship for every subsequent finding, which you will need.

Arguing during a customer's audit of you. Wrong venue, wrong stakes, and the customer's auditor has no authority to amend your controls anyway.

The questionnaire version

Different game, because the reader is usually a procurement analyst clearing a checklist, not a security engineer.

For a free-text field, answer the objective and be specific: Passwords do not expire on a fixed interval. Password changes are forced on evidence of compromise, on a match against breached-credential corpora (checked at set time and at login), and on anomalous authentication. MFA is enforced for all interactive access. This follows NIST SP 800-63B-4, which prohibits arbitrary periodic expiry for memorized secrets. That answer clears most reviews, because it reads as considered rather than deficient.

For a hard Yes/No with no comment box: answer honestly and attach the explanation wherever the form allows attachment — a cover note, the follow-up email, your standard security overview. A "No" with an adjacent paragraph almost never fails on its own. A "Yes" that is untrue is a misrepresentation in a document that may be incorporated into a contract, and it is genuinely not worth it. I've seen a team answer yes on the theory that it was aspirational; the clause landed in the security exhibit and became a real obligation with a real audit right.

Get ahead of it: publish a security overview or trust page that addresses this specific question, and reference it in every response. Half the value of a trust page is that it lets you answer a question once rather than forty times a year.

And sometimes: just comply. If the deal is large, the buyer is inflexible, and the requirement is narrow — say, rotation only for the accounts touching their tenant — take the requirement. You're trading a modest amount of user friction for revenue. The engineering discipline is to scope it as tightly as the contract allows and to keep it out of your global default, which is the next section.

If you have to ship it, ship it so it does the least harm

Assume you lose, or lose partially. The implementation choices still matter a great deal.

Make expiry a per-tenant or per-population policy from the first line of code. This is the whole ballgame, and it's the thing teams get wrong by building rotation as a global feature flag. You will have one customer who requires it and forty who don't. If expiry lives in a policy object attached to a tenant — or to a group within a tenant — the contractual requirement becomes a configuration, which is exactly what it is. If it lives in a global setting, every future negotiation is an engineering project.

Take the longest interval permitted and stop treating the number as a security dial. Where a framework offers a range or a risk-analysis-derived frequency, do the risk analysis properly and document it; that document is the artifact that makes the number defensible.

Exempt MFA-enrolled users where the framework allows it. PCI's structure practically invites this, since 8.3.9 is conditioned on the password being the only factor. Building the exemption as a first-class policy condition rather than a manual carve-out also gives users a visible reason to enrol in MFA, which is the outcome you wanted anyway.

Drop composition rules at the same time. They are rarely mandated as tightly as rotation and they interact badly with it: forced change plus character-class requirements is precisely the combination that produces Summer2026! → Autumn2026!. If you must keep the calendar, at least stop constraining the space users pick from.

Warn early and in-app, never by email with a link. An emailed "your password expires in 3 days, click here" is a phishing template you are sending to your own users on a schedule. Put the notice in the product, behind an authenticated session.

Never expire a password during an active session in a way that produces a mid-workflow interception, and never lock out on expiry — allow authentication and interrupt with a mandatory change, the same pattern that works for breach-corpus hits at login.

And keep non-human credentials in a separate conversation entirely. Service accounts, API keys, and client secrets have a genuinely different threat model — no human memory to burden, no phishing surface of the usual kind, no behavioural baseline, often no individual owner. Rotation there is defensible, sometimes necessary, and only workable if the mechanism supports overlapping validity rather than a hard cutover. Letting a debate about human password expiry contaminate your machine-credential policy — in either direction — is how you end up with both a rotation policy nobody follows and a client secret last changed in 2021.

The line worth keeping

The instinct behind this whole subject is to want a single correct answer that you can implement once and defend everywhere. You are not going to get one. Different customers operate under different frameworks at different revisions, with different auditors interpreting them, and some of them will have signed contracts with each other that reference documents from 2014.

So the durable engineering position isn't "we don't do rotation." It's that expiry is a policy attribute of a population, not a property of the system — configurable, defaulted off, evidenced when on, and never something you have to redeploy to change. Teams that hold "rotation is bad" as a belief end up rebuilding it under deadline for a customer who wouldn't budge. Teams that hold it as a default end up flipping a field.

Meanwhile, build the controls that actually work, and make them legible: breach screening at set and at login, MFA coverage you can report as a percentage, revocation latency you have measured, and a mass-reset path you have exercised recently enough to name the date. That last list is what makes the auditor conversation winnable, and it's worth having even in the years you lose it.