Password and MFA policy that matches the guidance, not the folklore

Password policy is where the gap between published guidance and deployed reality is widest, and where testers most often repeat folklore back to clients because it is what the last report said.

The headline: complexity rules and routine expiry make things worse, both the NCSC and NIST withdrew them years ago, and the replacement is length, screening against known-breached passwords, and rate limiting.

What the current guidance actually says

Folklore	Current position
Require upper, lower, number and symbol	Drop composition rules. They push people toward 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 sets. That does more than any rule about punctuation.
Limit length to 16 or 20	Allow long passphrases 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.

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.

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.

How to report this 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. Give them the ammunition rather than the criticism.