Password Policy Requirements: ISO 27001, NIST and PCI DSS Compared

By Compyl Research · Last reviewed September 2026

A compliant password policy in 2026 needs a minimum length of 12 to 15 characters, screening against known-breached passwords, and MFA on anything sensitive. What it no longer needs — under NIST, and increasingly in practice — is forced complexity rules or scheduled 90-day expiry. ISO 27001, NIST SP 800-63B and PCI DSS do not agree on that last point, and this guide reconciles them into one policy.

Key takeaways

• The frameworks genuinely conflict. NIST SP 800-63B rev 4 says you shall not force periodic password changes or composition rules. PCI DSS still requires 90-day rotation unless you meet a specific alternative. ISO 27001 prescribes neither and asks you to justify whatever you choose.
• Length is the settled part. NIST sets 8 characters as the floor and 15 as the recommendation; PCI DSS requires 12; CISA advises 16. A 15-character minimum satisfies all three at once.
• Blocklist screening is the highest-value control and the one most policies are missing — checking new passwords against known-breached credentials does more than any complexity rule ever did.
• You can write one policy for all three frameworks. Set the strictest length, screen against a blocklist, require MFA, and handle rotation as a scoped exception for the cardholder data environment rather than a company-wide rule.

What every framework agrees on

Before the disagreements, the common ground — and it is most of the policy:

• Length beats complexity. Every current standard has moved toward longer minimums and away from character-composition rules.
• Multi-factor authentication is expected on remote access, administrative access, and anything touching sensitive data. This is no longer a maturity signal; it is a baseline.
• Credentials must be stored hashed and salted, never in plaintext or reversible encryption.
• Default credentials must be changed before a system goes into service.
• Failed login attempts must be limited with lockout after a defined threshold.
• Password reuse must be constrained, whether by history depth or by blocklist.
• Users must be able to use a password manager. Blocking paste in password fields is now treated as an anti-pattern rather than a hardening measure.

Where the frameworks disagree: rotation and complexity

This is the question most password policies get wrong, because the answer changed and not every framework changed with it.

NIST SP 800-63B revision 4, finalised in August 2025, is explicit: verifiers shall not impose composition rules — no “one uppercase, one number, one symbol” — and shall not require passwords to be changed on a schedule. Passwords change when there is evidence of compromise. NIST strengthened both from “should not” in revision 3 to “shall not” in revision 4, which is as firm as the language gets. The reasoning is behavioral: forced rotation produces Summer2026! becoming Autumn2026!, and composition rules produce predictable substitutions that attackers model easily.

PCI DSS v4.0.1 has not followed. It still requires passwords of at least 12 characters containing both numeric and alphabetic characters, and it still requires a change every 90 days — with one alternative: if you dynamically analyze the security posture of accounts and respond in real time to anomalous access, you may forgo the fixed interval. Most organizations do not meet that bar, so for the cardholder data environment, 90-day rotation usually still applies.

ISO 27001:2022 takes neither side. Annex A control 5.17 covers authentication information and A.8.5 covers secure authentication, but the standard prescribes no specific length, no rotation interval and no complexity formula. It requires that you have a documented policy, that the policy is risk-based, that it is communicated, and that you can show it operating. An auditor will ask why you chose what you chose — a defensible answer citing NIST is entirely acceptable.

The practical resolution: follow NIST as your default and treat PCI rotation as a scoped exception. Apply the modern policy — long minimum, no forced complexity, no scheduled expiry, blocklist screening — across the organization, and carve out the accounts in scope for PCI DSS where 90-day rotation still applies. One policy document, one documented exception, both auditors satisfied.

Password requirements by framework, compared

Read down the middle column and you have a policy that satisfies the left one automatically. Read the right column and you have the exceptions to scope.

What ISO 27001 actually requires

ISO/IEC 27001:2022 handles passwords through Annex A control 5.17, authentication information, supported by 5.15 on access control and 8.5 on secure authentication. None of them contains a number. What the control requires is that authentication information is allocated and managed through a defined process, that users are told their obligations, that default credentials are changed, and that the whole thing is documented and reviewed.

What an auditor tests, in practice:

• A written password or authentication policy exists, is approved, and is dated.
• Employees have acknowledged it, and you can produce the attestation records.
• The technical configuration matches what the policy claims — this is where most findings arise, because the document says twelve characters and the identity provider is set to eight.
• Defaults were changed on new systems, evidenced by configuration records.
• The policy has been reviewed within your stated review period.

The freedom ISO gives you is real, and it means the reasoning matters more than the number. “We follow NIST SP 800-63B rev 4, which prohibits forced rotation, and we compensate with breached-credential screening and MFA” is a stronger answer to an auditor than “we rotate every 90 days” with nothing behind it.

What NIST SP 800-63B revision 4 requires

Revision 4 became final in August 2025 and is the reference most other frameworks are converging on. The substantive requirements:

• Length: a minimum of 8 characters is mandatory; 15 is recommended where a password is the sole authenticator. At least 64 characters must be accepted, so passphrases work.
• Character set: all printable ASCII, spaces, and Unicode should be accepted. Truncating or stripping characters is not permitted.
• No composition rules. Do not require mixed case, digits or symbols.
• No scheduled expiry. Force a change only on evidence of compromise.
• Blocklist screening is mandatory. Every new or changed password must be checked against known-breached credentials, dictionary words, repetitive strings, and context-specific terms such as the company or product name. Rejected users must be told why and prompted to choose again.
• No hints, no knowledge-based questions. “Mother’s maiden name” is out.
• Password managers must work, including paste into the password field.

The blocklist requirement is the one to act on first. It is the control that replaced complexity rules, it is more effective than anything it replaced, and in most organizations it is simply absent — the identity provider supports it and nobody enabled it.

What PCI DSS v4.0.1 requires

PCI is the prescriptive one, and it applies only to systems in scope for the cardholder data environment:

• Minimum 12 characters, with both numeric and alphabetic characters. Where a system genuinely cannot support 12, 8 is the floor.
• Change at least every 90 days — or demonstrate that you dynamically analyze account security posture and respond to anomalous access in real time, which is the alternative most organizations cannot evidence.
• New passwords cannot match any of the previous four.
• Lock the account after no more than 10 failed attempts, for at least 30 minutes or until an administrator releases it.
• MFA for all access into the cardholder data environment, and for all remote access, with the factors independent of one another.
• Vendor defaults changed before deployment, and application and system accounts managed with their own controls.

How to write one policy that satisfies all three

1. Set a 15-character minimum organization-wide. It clears NIST’s recommendation, exceeds PCI’s 12, and gives ISO a defensible number. Accept at least 64 characters and every printable character.
2. Drop composition requirements everywhere. They are prohibited by NIST and provide no benefit at 15 characters. PCI’s alphanumeric requirement is satisfied incidentally by almost any 15-character password, but if you want certainty, apply the alphanumeric check only to in-scope accounts.
3. Turn on breached-password screening. Every major identity provider supports it. This is the single change with the largest security return.
4. Remove scheduled expiry — except in the cardholder data environment. Document the exception, name the systems it covers, and cite the PCI requirement that drives it.
5. Require MFA on remote access, administrative access and anything in a regulated scope. Prefer phishing-resistant factors where you can.
6. Set lockout at 10 attempts and 30 minutes — PCI’s number, which satisfies everyone else.
7. Permit and provide a password manager, and stop blocking paste.
8. Write down why. One paragraph explaining that the policy follows NIST SP 800-63B rev 4 with a scoped PCI exception is what turns a configuration into a defensible control.

Password hygiene: the habits that actually matter

Policy sets the floor; behavior determines the real posture. The practices worth training on, in order of impact:

• Unique credentials per service. Reuse is the mechanism by which one breach becomes several. A password manager makes this achievable; exhortation does not.
• Passphrases over passwords. Four unrelated words beat a mangled dictionary word at the same length, and people remember them.
• MFA on personal accounts too, particularly personal email, which is the recovery channel for everything else.
• Change on suspicion, immediately — and make reporting a suspected compromise blameless, because hesitation is what turns an incident into a breach.
• Never share credentials, and give teams a shared vault so they do not have to.

How to evidence this for an auditor

The policy document is the smallest part of what you will be asked for. Expect to produce:

The finding that recurs most often is not a weak policy. It is a good policy that does not match the identity provider’s actual configuration — the document says one thing, the tenant says another, and nobody compared them since the policy was written.

Common failure points

• The policy and the configuration have drifted. Check them against each other before an audit, not during one.
• Rotation left switched on everywhere because nobody scoped the PCI exception, which degrades password quality across the whole organization to satisfy a requirement that applies to a fraction of it.
• Blocklist screening available but not enabled. The most common gap, and the cheapest to close.
• MFA on employees but not on service and application accounts, which are where privilege actually concentrates.
• Contractors and third parties outside the policy’s scope while holding access inside it.
• Legacy systems that cannot meet the minimum, undocumented — an exception you have recorded is a finding avoided; one you have not is a finding waiting.

Where Compyl fits

A password policy is one control that has to prove itself against several frameworks at once — which is the problem Compyl is built for. One control library maps a single authentication control to ISO 27001 A.5.17, the NIST requirements and PCI DSS requirement 8 simultaneously, so it is written once, tested once, and satisfies all three. Identity provider configuration is pulled automatically as evidence rather than screenshotted each cycle, scoped exceptions like PCI rotation live in an exception register with an owner and a review date, and policy attestation is tracked without chasing.

See how one authentication control satisfies ISO 27001, PCI DSS and SOC 2 at the same time in a 20-minute walkthrough — request a demo, or read the control mapping guide first.

Frequently asked questions

What is the minimum password length for compliance in 2026?

Fifteen characters satisfies every current framework at once. NIST SP 800-63B rev 4 requires 8 and recommends 15; PCI DSS v4.0.1 requires 12; CISA advises 16. ISO 27001 prescribes no number and expects you to justify the one you pick.

Does ISO 27001 require password expiration?

No. ISO/IEC 27001:2022 does not specify a rotation interval anywhere in Annex A. Control 5.17 requires a documented, risk-based authentication policy. Choosing not to expire passwords is fully compliant provided the decision is documented and compensated for with breached-password screening and MFA.

Should we still force password changes every 90 days?

Not as a general rule. NIST SP 800-63B rev 4 states that verifiers shall not require periodic changes, because forced rotation produces weaker, more predictable passwords. The exception is the cardholder data environment: PCI DSS v4.0.1 still requires 90-day rotation unless you can evidence dynamic analysis of account posture. Scope that exception rather than applying it everywhere.

What are the NIST password guidelines?

NIST SP 800-63B revision 4, final since August 2025, requires a minimum of 8 characters with 15 recommended, acceptance of at least 64 characters, no composition rules, no scheduled expiry, mandatory screening against a blocklist of breached and dictionary passwords, no password hints or security questions, and support for password managers.

What is the PCI DSS password requirement?

PCI DSS v4.0.1 requires at least 12 characters containing numeric and alphabetic characters, a change every 90 days unless account posture is dynamically analyzed, no reuse of the previous four passwords, lockout after no more than 10 failed attempts for at least 30 minutes, and MFA for all access into the cardholder data environment.

Are complexity requirements still recommended?

No. NIST rev 4 prohibits imposing composition rules, strengthening the language from “should not” in revision 3. Length and blocklist screening deliver more security than character requirements, which mainly produce predictable substitutions. PCI DSS still requires alphanumeric characters for in-scope systems.

What is password blocklist screening and do we need it?

It checks each new or changed password against known-breached credentials, dictionary words and context-specific terms such as your company name, and rejects matches. NIST requires it, and it is the control that replaced complexity rules. Most identity providers support it natively and it is frequently left switched off — usually the largest single gap in an otherwise sound policy.

How do we prove our password policy to an auditor?

Produce the approved policy with a version and date, employee attestation records, an identity provider configuration export showing the settings match the policy, evidence that blocklist screening and MFA are enabled, the lockout threshold, a register entry for any scoped exception such as PCI rotation, and a record of the last policy review. The most common finding is a policy that no longer matches the identity provider’s actual configuration.

Sources: ISO/IEC 27001:2022 Annex A controls 5.15, 5.17 and 8.5; NIST SP 800-63B revision 4 (final, August 2025); PCI DSS v4.0.1 requirement 8; CISA password guidance. Verify current requirements against the published standards before relying on them for an audit.