Password and MFA policy: what changed, and what auditors still expect

The password rules most organisations still enforce were shown to be counterproductive years ago, by the same institutions that popularised them. Updating your policy is one of the few security changes that simultaneously improves security and makes people's lives easier - which is exactly why it is worth doing properly rather than quietly.

What modern guidance actually says

NIST SP 800-63B and the UK NCSC broadly converge on the following:

• Length over complexity. A long passphrase beats a short string of substituted characters. Minimums around 12 characters for user accounts, higher for privileged ones.
• Do not force periodic rotation without cause. Routine expiry drives predictable patterns - the same password with an incrementing digit - which weakens rather than strengthens. Rotate on evidence of compromise instead.
• Drop composition rules. Mandatory character-class requirements push users toward predictable substitutions that attackers model well.
• Screen against known-breached lists. Blocking passwords that appear in breach corpora is worth more than every complexity rule combined.
• Allow paste and password managers. Blocking paste actively prevents good behaviour.
• Drop knowledge-based "security questions" - the answers are usually public.
• Rate-limit and lock out rather than relying on password strength alone.

Expect resistance: rotation feels like diligence. The counter-argument that lands is that rotation was introduced when password databases leaked slowly and undetected - modern breach monitoring and MFA address that risk far more directly, and rotation's cost is now measurably negative.

Not all MFA is equal

"MFA is enabled" has become a checkbox that conceals a wide range of actual protection. Roughly in ascending order:

• SMS and voice - vulnerable to SIM swap and interception. Better than nothing; no longer considered adequate for privileged access, and some regulators say so explicitly.
• Email codes - only as strong as the email account, which is often the thing being protected.
• Time-based codes (TOTP) in an authenticator app - solid against credential theft, still phishable in real time via a proxy.
• Push notifications - convenient, but vulnerable to MFA fatigue, where an attacker sends repeated prompts until someone approves one. Number matching mitigates it substantially.
• Phishing-resistant: FIDO2 security keys and passkeys - cryptographically bound to the legitimate domain, so a proxy phishing site cannot relay the authentication. This is the meaningful step change.

A realistic target: phishing-resistant MFA for administrators, developers, finance and executives; strong MFA everywhere else; SMS retired or reserved as a fallback with additional monitoring.

The gaps that survive an MFA rollout

Almost every organisation that has "MFA everywhere" still has some of these:

• Legacy authentication protocols that bypass MFA entirely - the single most exploited gap after a rollout. Disable them explicitly and verify.
• Service accounts and API keys, which cannot use interactive MFA and need their own controls: rotation, scoping, and vaulting.
• Break-glass accounts, deliberately exempt - which is correct, but they need alerting on use and periodic review.
• Systems outside SSO, typically older internal applications and anything procured on a departmental card.
• Enrolment and recovery. If a helpdesk can reset MFA on a phone call with a name and date of birth, the recovery path is the weakest link - and it is the one attackers actually use.

Justifying the policy change to an assessor

Auditors test against your stated policy, not against a fixed rulebook - so a modern policy is entirely auditable provided you can show it is deliberate. What makes it defensible:

• Reference the standard you are following, explicitly, in the policy itself.
• Show the compensating measures: breached-password screening, MFA coverage, lockout thresholds, monitoring for anomalous sign-ins.
• Record the decision - a management review minute noting the rationale is usually enough.
• Check your obligations first. Some regulators and customer contracts still mandate rotation; where a specific rule binds you, comply and document the conflict rather than arguing with the requirement.

Key takeaways

• Length plus breached-password screening beats complexity rules and forced rotation.
• MFA strength varies enormously - phishing-resistant methods are a genuine step change.
• Legacy protocols, service accounts and helpdesk recovery are where MFA rollouts leak.
• A modern policy is auditable if you cite the guidance and record the decision.