Retiring the 90-Day Password Reset Under PCI DSS 4.0
Why the 90-Day Reset Persists
Forced periodic password change is a control that outlived its own evidence base. We keep rotating passwords every 90 days because a standard once told us to, not because the practice still reduces meaningful risk.
It persisted for a simple reason: it was trivial to audit. An assessor could pull a configuration screenshot, confirm the expiry interval, and check the box. PCI DSS 3.2.1 prescribed a change at least every 90 days, so the control had the weight of an explicit requirement behind it. A requirement that is cheap to verify and explicitly mandated becomes reflex, and reflexes are hard to retire even after the reasoning behind them collapses.
The reasoning did collapse. Forced rotation pushes people toward predictable, incrementally-changed passwords (Password1 becomes Password2 becomes Password3), and toward writing the new value on a sticky note because they can no longer remember it. The control degrades the very behavior it was meant to strengthen. That is why NIST stopped recommending it. NIST SP 800-63B-4 (Section 3.1.1.2) states, "Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
Treat this as a risk-management decision, because that is what it is. Rotation carries a real cost (degraded user behavior, weaker passwords, more reset friction) and returns very little risk reduction in exchange. NIST says stop. PCI historically said rotate. PCI DSS 4.0 resolves the conflict by giving you two legitimate ways out, and the first one is far easier than most teams expect.
The Simple Win: MFA Removes the Rotation Rule
Read Req 8.3.9 carefully and the escape hatch is right there in the conditional. The rotation rule applies only when a password is the sole authentication factor. The text reads, "If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either: Passwords/passphrases are changed at least once every 90 days, OR The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly." The standard then states it plainly: "This requirement does not apply to in-scope system components where MFA is used."
That sentence is the whole game. Enforce compliant MFA on the in-scope accounts and 8.3.9's rotation mandate no longer applies to them, with no targeted risk analysis and no customized approach to write. The MFA requirements that get you there are already in the standard: 8.4.1 (MFA for administrative non-console access into the CDE), 8.4.2 (MFA for all non-console access into the CDE), and 8.4.3 (MFA for all remote access from outside the network that could affect the CDE). Req 8.4.2 was future-dated when 4.0 published, but it has been mandatory since 31 March 2025, so for any 2026 assessment it is simply in force. There is no transition period left to lean on.
The catch is that the MFA has to be real. It must satisfy Req 8.5.1: at least two different factor types, not susceptible to replay, not bypassable except where documented and time-limited with management authorization, and all factors required before access is granted. A weak or partial MFA implementation does not earn the exemption, and a QSA will check the mechanism, not just the label.
If every in-scope account can sit behind MFA that meets 8.5.1, this is the entire job. Stop here. Do not build a customized approach you do not need; it is real work and a real maintenance burden, and an exemption you already have for free does not justify it. When we confirmed full MFA coverage with our QSA, the 90-day rotation finding simply fell away for those accounts.
When MFA Alone Isn't Enough
The defined-approach exemption does not reach every account. Two situations leave you exposed. The first is password-only access that cannot take a second factor: service accounts, system accounts, application accounts, and legacy interfaces that authenticate with a credential and have nowhere to plug in MFA. The second is strategic rather than technical. You may want one unified, formally validated, NIST-aligned password standard applied consistently across the estate, instead of a patchwork of account-by-account MFA exemptions that each have to be argued and re-evidenced at every assessment.
For those cases, the customized approach is the second legitimate way out, and it is where the cost shows up. A customized approach is not free. It requires a targeted risk analysis, a controls matrix that maps your alternative controls to the stated objective of the requirement, annual review of that analysis, and a negotiation with your QSA who has to agree the approach meets the objective. That is genuine, recurring work.
So apply a clear decision rule. Build the customized approach when it removes recurring friction across many accounts, or when it covers a password-only gap that MFA simply cannot reach. If it would only spare you from rotating one or two passwords that could take MFA instead, it is not worth the overhead. The customized approach earns its cost at scale or at a hard technical boundary, and not much in between.
When the answer is yes, the work is mechanical if you do it in the right order. Here is how to build one that survives review.
The Customized Approach, Step by Step
Start From the Objective
A customized approach meets the requirement's Customized Approach Objective, not the prescribed control. For 8.3.9 that objective reads, "An undetected compromised password/passphrase cannot be used indefinitely." Translate it plainly: an account must not stay accessible forever through a single, static, potentially-compromised password. Every control you design has to defend that one sentence, and your evidence has to show it does.
Run the Targeted Risk Analysis
A customized-approach control is documented under Req 12.3.2: a controls matrix plus a targeted risk analysis, prepared per Appendix D and using the Appendix E sample templates. That is where your 8.3.9 evidence lives.
Do not confuse 12.3.2 with 12.3.1. The 12.3.1 targeted risk analysis is a different instrument: it governs the defined-approach requirements that let the entity set its own frequency for an activity, and it has nothing to do with meeting a requirement's objective a different way. Getting that distinction right is the difference between an assessor trusting your paperwork and an assessor reading the rest of it twice.
A rigorous targeted risk analysis documents the assets being protected, the threats the requirement defends against, the factors driving likelihood and impact, a justified analysis of how your approach minimizes both, and a review at least once every 12 months. The table below is the core of that analysis for password compromise.
| Threat scenario | Likelihood | Impact | Mitigating controls | Residual risk |
|---|---|---|---|---|
| Online guessing / brute force | Low | High | 15-char minimum (exceeds 8.3.6), lockout after <=10 attempts (8.3.4), rate limiting, MFA (8.4.x) | Low |
| Credential stuffing (reused breach creds) | Medium | High | Compromised-password screening at set and change, continuous credential-breach monitoring with forced reset on new exposure, MFA | Low |
| Phishing / real-time interception | Medium | High | Phishing-resistant or app-based MFA per 8.5.1, user awareness | Low to Medium |
| Undetected long-lived credential compromise | Low to Medium | High | MFA (a stolen password alone cannot authenticate), behavioral monitoring, forced reset on indicators of compromise | Low |
That last row is the one forced rotation was ever meant to cover, which is exactly why the control set below can replace it.
Design the Control Set
Your controls have to meet the objective at least as well as rotation did. The risk-management argument is short: rotation only ever addressed that last threat row, and it addressed it weakly, capping exposure at roughly 90 days rather than detecting the compromise. MFA, breach screening, and monitoring address the same threat continuously. The sharpest of the three is continuous breach monitoring: when one of your accounts turns up in a new breach corpus, you force a reset on detection, which is the evidence-driven version of what the 90-day timer was only guessing at. Here is the NIST-aligned control set that does it.
- Minimum length 15 characters for all in-scope accounts. This exceeds PCI's 12-character floor (8.3.6) and meets the single-factor minimum in NIST SP 800-63B-4. Allow at least 64 characters, with no low maximum.
- No composition or complexity rules. Do not force character classes; allow all printable characters, spaces, and long passphrases.
- No scheduled expiration. Force a change only on evidence or reasonable suspicion of compromise.
- Screen at set and change against a maintained known-compromised-password blocklist, and reject matches.
- Monitor for breached credentials continuously (for example, with Have I Been Pwned's Domain Search or a commercial credential-monitoring service), and force a reset when one of your accounts appears in a new breach. This is the evidence-driven replacement for periodic rotation.
- Throttle and lock out: rate-limit failed attempts and lock after no more than 10 invalid attempts for at least 30 minutes or until identity is confirmed (8.3.4).
- Allow password managers and paste, with a reveal toggle.
- MFA on every covered access path (8.4.x), implemented to satisfy 8.5.1 (two distinct factor types, anti-replay, non-bypassable, all factors required).
On the length numbers: PCI's floor is 12 characters, current NIST recommends a minimum of 15 for single-factor passwords, so standardizing on 15 satisfies both at once and spares you from maintaining two policies.
Document the Controls Matrix and Evidence
The Appendix E controls matrix is where you map the objective to the controls you implemented and to the testing the assessor will perform. The targeted risk analysis sits behind it as the justification for why those controls are sufficient. The matrix for 8.3.9 looks like this.
| Controls matrix field | Entry |
|---|---|
| Requirement | 8.3.9 |
| Customized approach objective | An undetected compromised password/passphrase cannot be used indefinitely. |
| Implemented controls | MFA on covered access (8.4.x / 8.5.1); 15-character minimum; known-compromised-password screening; continuous credential-breach monitoring with forced reset on new exposure; lockout and rate limiting (8.3.4); behavioral monitoring with forced reset on indicators of compromise |
| How the controls meet the objective | MFA makes a compromised password insufficient to authenticate; screening blocks known-bad passwords at the point of choice; credential-breach monitoring detects a password that becomes compromised later and forces a reset, which is what directly satisfies "cannot be used indefinitely"; lockout and length defeat guessing; together they replace the 90-day exposure cap with continuous detection |
| Testing the assessor performs | Inspect policy and configuration; observe MFA enforcement scope; test the lockout threshold; verify screening is active; review the targeted risk analysis and the annual review record |
Have the supporting evidence assembled before the assessor asks for it.
- A signed, dated customized-approach targeted risk analysis (Req 12.3.2) with a named approver and the next annual review date.
- The customized-approach controls matrix (Appendix E).
- A password policy document reflecting the control set above.
- Configuration evidence: minimum length, expiry disabled, screening enabled, lockout threshold, and MFA enforcement scope.
- MFA design evidence mapped to 8.5.1 (factor independence, anti-replay, non-bypassable).
- Records of the annual targeted-risk-analysis review and any compromise-triggered resets.
Validate With the QSA Before You Build
A customized approach only works if your assessor agrees the controls meet the objective, and that agreement is worth nothing if you secure it the week of the audit. Engage the QSA during planning. As I learned leading our PCI DSS 4.0 migration, the conversation you want is the one where the QSA signs off on the design before you build it, not the one where they reject your evidence after you have. Bring them the objective, the targeted risk analysis, and the proposed control set, and get the agreement on record first.
Pitfalls That Sink a Customized Approach
Four mistakes turn a defensible customized approach into a finding. I have watched all four happen.
- Over-engineering. The most common one is building a customized approach, with its full targeted risk analysis and controls matrix, when compliant MFA had already removed 8.3.9 under the defined approach for those same accounts. That is recurring paperwork to re-prove an exemption you held for free. The decision rule has not changed: if the accounts can take MFA that meets 8.5.1, just do that and stop.
- Forgetting the annual obligation. A customized-approach targeted risk analysis under Req 12.3.2 must be reviewed at least once every 12 months. It is a standing commitment, not a one-time artifact you file and forget. Treat it as a program, not a project: assign an owner, calendar the review, and keep the dated approval current. A lapsed analysis is a finding even when the controls underneath it still work.
- MFA that fails 8.5.1. A single factor type dressed up as two (a password plus a security question), a flow that can be bypassed without documented and time-limited authorization, or an OTP delivery susceptible to replay all fail 8.5.1. That voids both the defined-approach exemption and the MFA control inside your customized-approach control set. The assessor tests the mechanism, not the label on it.
- Assuming PCI's 12 is already "NIST-aligned." PCI's single-factor floor is 12 characters (8.3.6), but current NIST SP 800-63B-4 recommends a minimum of 15 for single-factor passwords. A policy that stops at 12 and calls itself NIST-aligned is not. Standardize on 15, and adopt the stricter of the two requirements on every parameter. On length that is now NIST's number, not PCI's.
The Bottom Line
PCI DSS 4.0 lets you replace a calendar-driven control with an evidence-driven one. That is the whole shift, and it is a risk-management win: you stop spending user goodwill on a 90-day ritual that NIST abandoned, and you start spending it on controls that actually detect compromise.
For most teams the path is short. Compliant MFA on the in-scope accounts removes the rotation rule outright, with no targeted risk analysis and no customized approach to write. Confirm the coverage, prove the MFA meets 8.5.1, and the finding falls away. The customized approach is there for the residual cases (the password-only accounts that cannot take a second factor) and for teams that want one NIST-aligned standard they can defend across the whole estate.
Either way, the move is the same. You stop rotating passwords on a schedule and start proving, continuously, that a compromised password cannot be used.