Many organisations report "MFA everywhere" while their most important logins can still be phished with a fake page, approved by a tired user tapping a push prompt, or reset by a convincing phone call to the help desk. Authentication maturity is not the number of factors; it is how resistant each login is to the attacks that actually happen, how much of the estate that resistance covers, and how well recovery and sessions are protected. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to score authentication across seven capability areas, from passwords to MFA to phishing-resistant and passwordless sign-in, with NIST SP 800-63B-4 as the technical yardstick. It is for IAM leads, security architects and CISOs who need to score where they are and plan the next step. Passkey deployment itself is covered in the Passwordless and Passkeys Guide; this page is about staged maturity.
Key takeaways
- The five levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately across seven capability areas.
- Phishing resistance is the dividing line. Codes you type, including authenticator app codes and SMS, are not phishing-resistant under NIST SP 800-63B-4; only authenticators with channel binding or verifier name binding, such as FIDO2 and WebAuthn passkeys or smart cards, are.
- Level 3 is the first sensible target: MFA enforced on every interactive login, legacy protocols blocked, NIST-aligned password rules and phishing-resistant MFA for administrators.
- Recovery sets your real level. A passkey-only login with a help desk reset that accepts a name and date of birth is as weak as the reset.
- Do not forget machines. Service accounts and API clients that log in with static passwords or keys need their own track towards federated, short-lived credentials.
The five levels
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | Passwords are the main or only factor. Complexity and 90-day rotation rules push users to predictable patterns. MFA exists for a few applications, often by SMS. Legacy protocols (basic authentication, POP, IMAP, NTLM) are open, and many applications have their own local logins. |
| 2 | Developing | Single sign-on covers the main SaaS applications and MFA is enforced for remote access and email, mostly by push or one-time codes. Exceptions are many and undocumented. Administrators use the same methods as everyone else. Help desk resets rely on knowledge questions. |
| 3 | Defined | An authentication standard sets required assurance per application. MFA is enforced on every interactive login through the identity provider, legacy authentication is blocked, password rules follow SP 800-63B-4 (length, blocklist, no forced rotation), push prompts use number matching, and administrators use phishing-resistant MFA. Recovery requires identity verification. |
| 4 | Managed | Phishing-resistant authenticators are the default for the workforce, with passkeys or smart cards issued at onboarding. Conditional access uses device compliance and risk signals. Session lifetimes are set per assurance level, token theft is monitored, and authentication metrics are reported monthly. |
| 5 | Optimised | Passwordless is the norm and passwords are removed from accounts where the platform allows. High-assurance roles use non-exportable, device-bound keys. Recovery is phishing-resistant end to end, and workloads authenticate with federated, short-lived credentials instead of stored secrets. |
Capability areas
Score each area separately.
| Capability area | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Password policy | Composition rules, forced rotation, short minimums | SP 800-63B-4 rules: minimum 15 characters when the password is the only factor and 8 within MFA, maximum of at least 64 allowed, blocklist check, no composition rules or periodic change, password managers and paste allowed | Passwords removed from most accounts; where they remain, they are a second factor |
| MFA coverage | Some applications, SMS | Every interactive login through the identity provider; exceptions documented with expiry | No interactive login without strong authentication, including local and break-glass accounts with controlled procedures |
| Authenticator strength | SMS and voice codes | App-based push with number matching or TOTP for users; phishing-resistant MFA for administrators | Phishing-resistant for all users; non-exportable keys for privileged and high-assurance roles |
| Legacy protocols and local logins | Basic authentication, NTLM and per-app passwords open | Legacy authentication blocked at the identity provider; applications federated via SAML or OIDC | No application outside federation; NTLM and shared credentials retired |
| Recovery and enrolment | Knowledge questions, email links | Identity verification for resets; recovery codes or a second registered authenticator | Recovery uses another phishing-resistant authenticator or in-person or verified identity proofing |
| Sessions and tokens | Long-lived sessions, no reauthentication | Session lifetimes set per application risk; reauthentication for sensitive actions | Token binding to devices where supported; token theft detection and automatic revocation |
| Machine authentication | Static passwords and shared keys for services | Inventory of service accounts and keys with owners and rotation | Workload identity federation, certificates or short-lived tokens; no static secrets for workloads |
Authenticators by level
This table places common authenticators against SP 800-63B-4 and against the level at which they are acceptable as the main method.
| Authenticator | Phishing-resistant under SP 800-63B-4? | Highest AAL | Acceptable as main method from |
|---|---|---|---|
| Password only | No | AAL1 | Not acceptable for workforce at Level 3 and above |
| SMS or voice code | No; PSTN delivery is a restricted authenticator | AAL2 with restrictions | Fallback only at Level 3; removed at Level 4 |
| TOTP app or push with number matching | No (manually entered or approved output) | AAL2 | Level 2 to 3 for general users |
| Synced passkey | Yes (verifier name binding) | AAL2 (syncable authenticators shall not be used at AAL3) | Level 4 for the workforce and customers |
| Device-bound passkey or security key | Yes | AAL3 with non-exportable keys | Level 4 to 5, required for privileged roles |
| Smart card (PIV or CAC) | Yes (channel binding through TLS client authentication) | AAL3 | Level 4 to 5 where the infrastructure exists |
SP 800-63B-4 was published as final on 31 July 2025. It requires verifiers at AAL2 to offer at least one phishing-resistant option and sets session limits by level: AAL2 reauthentication should be no more than 24 hours overall and 1 hour of inactivity, and AAL3 shall be no more than 12 hours overall. Details are in the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
Mapping to frameworks
| Framework | Control | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-2, IA-2(1), IA-2(2) | Identification and authentication of organisational users; MFA for privileged and non-privileged accounts |
| NIST SP 800-53 Rev. 5 | IA-2(8) | Replay-resistant authentication |
| NIST SP 800-53 Rev. 5 | IA-5, IA-5(1) | Authenticator management; password-based authentication |
| NIST SP 800-53 Rev. 5 | AC-12, IA-11 | Session termination; reauthentication |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03 | Identities and credentials managed; users, services and hardware authenticated |
| CIS Controls v8.1 | 6.3, 6.4, 6.5 | MFA for externally exposed applications, remote network access and administrative access |
| MITRE ATT&CK | T1110, T1621, T1539 | Brute Force, Multi-Factor Authentication Request Generation and Steal Web Session Cookie, the techniques each level closes |
Self-assessment questions
Answer for the workforce first, then repeat for customers and for machine identities. A control that covers a fraction of logins scores Level 2.
- Coverage: what share of interactive logins goes through the identity provider with MFA enforced, and how many applications still have local passwords?
- Remote access: does every VPN, VDI and remote access portal require MFA? At Change Healthcare, a Citrix remote access portal without MFA was the entry point, and the company later put the number of people affected at 192.7 million (Change Healthcare breach).
- Strength: what share of users and of administrators authenticate with a phishing-resistant method?
- Push abuse: do push prompts require number matching, and would you detect repeated denied prompts? In the Uber breach, an attacker with a contractor's password triggered repeated MFA prompts until one was accepted.
- Legacy protocols: are basic authentication, POP, IMAP and NTLM blocked, and how do you know?
- Passwords: do you still force periodic changes or composition rules, and do you check new passwords against a blocklist of compromised values?
- Recovery: what does the help desk need to reset MFA for an administrator? The MGM Resorts breach began, by the attackers' account, with a call to the IT help desk impersonating an employee.
- Sessions: how long do sessions and refresh tokens last for your most sensitive applications, and would you notice a session cookie replayed from a new device?
- Service accounts: how many service accounts log in with passwords that never change, and are they excluded from MFA policies by broad exceptions?
Evidence that supports each score
Ask for reports, not assurances. These are the artefacts an assessor should see before accepting a score of 3 or 4.
| Capability area | Evidence for Level 3 | Evidence for Level 4 |
|---|---|---|
| Password policy | Identity provider password settings showing length, blocklist and no expiry | Count of accounts with no password set, trending up |
| MFA coverage | Conditional access policy export and sign-in report showing MFA on all interactive sign-ins; exception list with expiry dates | Monthly coverage report by application, including non-federated systems |
| Authenticator strength | Registered methods report showing phishing-resistant methods for every administrator | Same report showing phishing-resistant methods as the default for the workforce |
| Legacy protocols | Policy blocking legacy authentication and a sign-in report showing zero successful legacy sign-ins | NTLM usage audit with a retirement plan per remaining system |
| Recovery | Written help desk verification procedure and reset logs showing the verification used | Results of help desk social engineering tests |
| Sessions and tokens | Session lifetime settings per application tier | Alerts for token replay and their response times |
| Machine authentication | Service account inventory with owners | Share of workloads using federation or certificates |
Worked example
A professional services firm scores itself: password policy 3, MFA coverage 3, authenticator strength 2 (push for everyone, including administrators), legacy protocols 3, recovery 1 (resets by phone with name and employee number), sessions 2 and machine authentication 1. Its profile, not its average of 2.1, decides the plan: recovery and administrator authenticators come first, because an attacker who calls the help desk or phishes an administrator's push prompt bypasses every other control the firm has built.
Moving up: roadmap
From Ad hoc to Developing
- Put remote access, email and the identity provider itself behind MFA first, because they are the commonest entry points.
- Connect the main SaaS applications to single sign-on so MFA is enforced in one place.
- Remove forced rotation and composition rules and add a compromised password blocklist. See the Password Policy Guide (NIST-aligned).
From Developing to Defined
- Publish an authentication standard with required assurance per application class. Use the Authentication and MFA Policy Template.
- Block legacy authentication: run sign-in reports in audit mode for 30 days to find users and devices still depending on it, migrate them, then enforce, keeping a time-limited exception group as rollback. See the Legacy Authentication and ROPC Retirement Guide.
- Turn on number matching for push, remove SMS as a default and keep it only as a documented fallback.
- Issue phishing-resistant authenticators to all administrators and enforce them with conditional access.
- Require identity verification for MFA resets. See the Account Recovery and Help Desk Security Guide.
From Defined to Managed
- Roll out passkeys or security keys to the workforce in rings: IT and security first, then a pilot business unit, then everyone, measuring help desk volume at each ring. See the Phishing-Resistant MFA Guide.
- Add device compliance and sign-in risk to conditional access for sensitive applications.
- Set session lifetimes per assurance level and alert on token replay from unfamiliar devices. See the Session Hijacking and Cookie Theft Guide.
- Inventory service accounts and remove them from broad MFA exclusions by moving them to non-interactive credentials.
From Managed to Optimised
- Remove passwords from accounts where the identity provider supports passwordless-only sign-in, keeping a controlled break-glass process.
- Require device-bound, non-exportable keys for privileged roles to meet AAL3.
- Replace workload passwords and keys with federation, certificates or short-lived tokens. See the NHI Authentication Guide.
Metrics that show movement: share of interactive logins with MFA enforced; share of users and of administrators using phishing-resistant methods; legacy authentication sign-ins per week (target zero); MFA reset requests and how they were verified; median session lifetime for sensitive applications; service accounts with static passwords.
What changes with organisation size
- Small organisations on one cloud identity provider can reach Level 3 quickly by using its built-in conditional access and passkey support, and should start with administrators and email.
- Large organisations are held back by legacy applications and on-premises protocols; score business units and application tiers separately and fund federation work for the long tail.
- Customer identity follows the same levels but with different constraints: synced passkeys, risk-based step-up and account recovery matter more than device-bound keys. See the Risk-Based and Adaptive Authentication Guide.
Common failure patterns
- MFA with holes: a remote access portal, VPN or legacy protocol left outside the MFA policy becomes the route in, as at Change Healthcare.
- Counting factors, not resistance: TOTP and push are still phished by adversary-in-the-middle kits that relay codes and steal session cookies. See the AiTM Phishing Guide.
- Strong login, weak recovery: MFA resets by phone without verification undo phishing-resistant enrolment.
- Broad exclusions: service accounts and "VIP" groups excluded from MFA policies grow over time and are rarely reviewed.
- Old password rules kept: forced 90-day rotation and complexity rules still in place produce predictable passwords and contradict SP 800-63B-4.
- Break-glass accounts forgotten: emergency accounts excluded from conditional access with long, unmonitored passwords are a standing backdoor. Protect them with phishing-resistant keys held in a safe, and alert on every use.
- Ignoring sessions: a perfect login followed by a 90-day refresh token gives attackers who steal the token everything the login protected.
Practitioner checklist
- Score all seven capability areas for workforce, customers and machine identities separately.
- Enforce MFA on every remote access path and the identity provider before anything else.
- Block legacy authentication after an audit-mode period, with a time-limited exception group.
- Align password rules to SP 800-63B-4: length, blocklist, no forced rotation, no composition rules.
- Issue phishing-resistant authenticators to every administrator now, and plan workforce rollout in rings.
- Require identity verification for every MFA reset and test the help desk with exercises.
- Set session and token lifetimes per assurance level and monitor for token replay.
- Protect break-glass accounts with phishing-resistant keys held offline and alert on every use.
- Re-score every six months and report the six metrics monthly.
Standards and references
- NIST: SP 800-63B-4, Authentication and Authenticator Management
- NIST: SP 800-63B-4 Appendix B, Syncable Authenticators
- CISA: Implementing Phishing-Resistant MFA
- W3C: Web Authentication Level 3
- FIDO Alliance: Passkeys
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Authentication Guide · MFA Guide · Identity Security Maturity Model · MFA Fatigue and Bypass Guide