Password and MFA Policy That Matches the Guidance, Not the Folklore

A password and MFA policy that matches current guidance drops composition rules and routine expiry, sets a length floor, screens new passwords against known-breached lists, throttles guessing, and asks which second factor is used and when it is checked rather than whether MFA exists at all. Both the NCSC and NIST moved away from complexity rules and forced rotation years ago, yet this is where testers most often repeat folklore back to clients because it is what the last report said.

What the current guidance actually says

Folklore	Current position
Require upper, lower, number and symbol	Drop composition rules. They push people towards predictable substitutions and reduce real entropy.
Expire every 90 days	Change on evidence of compromise, not on a calendar. Rotation drives incrementing suffixes and cross-system reuse.
Ban dictionary words	Screen the whole password against known-breached and commonly used sets. That does more than any rule about punctuation.
Eight characters is enough	NIST now asks for 15 characters where the password stands alone, and eight only where it is one factor of several.
Limit length to 16 or 20	Allow long passphrases (at least 64 characters) and allow paste, because blocking paste breaks password managers, which are the single most effective thing a user can adopt.
Lock the account after 5 failures	Throttle with backoff. A hard lockout hands an attacker denial of service against a named user.

The NIST position is no longer a recommendation you can argue with. SP 800-63B, published in June 2017, said verifiers should not impose composition rules or periodic changes. Its fourth revision, SP 800-63B-4, published on 31 July 2025, turns both into prohibitions, requires blocklist screening, rules out password hints and security questions, and requires verifiers to allow password managers. The NCSC's own guidance says plainly that regular password changing harms rather than improves security, and that throttling is preferred to lockout.

Storage: the part that is genuinely non-negotiable

A memory-hard function with a per-user salt. Argon2id where the platform supports it, scrypt or bcrypt where it does not, with parameters tuned to current hardware rather than to the defaults in a decade-old tutorial. Plain hashes, unsalted hashes and general-purpose fast hashes are findings regardless of what surrounds them.

MFA: presence is the wrong question

"Do you have MFA" is answered yes by almost everybody and tells you almost nothing. The useful questions are narrower, and they are the ones a serious supplier assessment now asks, as answering a security questionnaire about your pentest platform shows from the other side.

1. Which factors? Phishing-resistant factors built on WebAuthn (passkeys and hardware keys) are a different security proposition from time-based codes, which are a different proposition again from SMS.
2. Enforced or optional? An MFA feature nobody has enrolled in is a marketing claim, not a control. Ask for the enrolment percentage.
3. What bypasses it? Legacy protocols, API tokens, recovery codes emailed on request, and support staff who can disable it on a phone call are all more common than the vendor documentation suggests.
4. What does enrolling a new factor require? If a hijacked session can add one, the second factor protects nothing after the first compromise.
5. How long does a session stay trusted? Enrolment is a property of the account. Freshness is a property of the session, and only one of those is a meaningful control at the moment data is read.

Enrolment answers "did this person once own a phone". Freshness answers "is this session, right now, held by that person".

Reset flows are where authentication is usually broken

Everything above can be right and undone by the reset path, which is written once, early, by whoever was available.

• Tokens are random, single use and short lived.
• Tokens are stored hashed, so read access to the database does not become account takeover.
• The response is identical for a known and an unknown address.
• Existing sessions are invalidated on a successful reset.
• The link travels somewhere that does not end up in logs and referrer headers.
• Requesting a reset does not itself lock the account, which would be a denial of service by design.

What to test, not just what to recommend

Policy advice is easy to write and easy for a client to file. Findings come from the behaviour, and the behaviour is frequently at odds with the policy document. The same weaknesses turn up often enough to appear among the common penetration test findings.

• Whether throttling survives distribution: attempts spread across source addresses, and across many accounts rather than one.
• Whether a password change invalidates other live sessions. Very often it does not, which makes a reset useless after a session theft.
• Whether the reset token is single use, expiring, and unguessable, and whether requesting a reset reveals which addresses are registered.
• Whether enrolling a new second factor requires proving an existing one. If a hijacked session can add a factor, the factor protects nothing after the first compromise.
• What the recovery path is, and who can trigger it. Support staff who can disable MFA on a phone call are a control that exists on paper only.

Reporting old rules without starting a fight

Clients running composition rules and 90-day expiry are usually doing it because an old audit told them to, and somebody there will have to defend a change to somebody else. Telling them their policy is folklore lands badly and changes nothing. Give them the ammunition rather than the criticism: state the guidance, name the specific effect in their environment, and give them the sentence they need for whoever asked for the rule.

"Rotation is driving predictable suffixes, which we demonstrated in the credentials recovered during this test" is a finding. "NIST withdrew this in 2017" is a fact they will accept and still not act on. The difference is the same one that separates remediation a developer will action from advice that gets filed.

Applying the same standard to your own firm

It is worth turning this list on yourself before you send it to a client, because a testing firm holds a concentration of other organisations' most sensitive material and increasingly gets assessed on exactly these questions.

• Phishing-resistant factors for staff, not just any second factor.
• Data access gated on a recent second-factor check rather than on enrolment months ago.
• Enrolling a new factor requires control of an existing one, so a hijacked session cannot enrol its own.
• Sessions listed per device and revocable immediately, not at the next token expiry.
• Reset flows that cannot be turned into account takeover by read access to a database.
• An offboarding process that is a process, not a memory.