Resources · 24
Deploy phishing-resistant authentication with safe recovery
Use factors bound to the genuine service and protect enrollment, loss and revocation.
· 8 min
What this guide helps achieve
- Map access paths
- Select a resistant protocol
- Protect enrollment
- Rehearse recovery
Quick check
- Which accounts reach critical data or functions?
- Is the factor cryptographically bound to the genuine service?
- Who authorises a new authenticator?
- How is a lost device revoked?
- Do exceptions have an owner and end date?
Step-by-step method
- 01
Inventory access paths
List applications, federation, administrators, emergency accounts and current methods. Identify sign-ins that still accept manually entered codes.
Deliverable: account, application and factor matrix.
- 02
Select the required resistance
Evaluate cryptographic protocols bound to a channel or verifier name, such as WebAuthn/FIDO2 where the application supports it. NIST does not treat manually entered OTPs as phishing-resistant because a false site can relay them.
Deliverable: method choice and known limitations.
- 03
Pilot sensitive accounts
Test browsers, devices, delegation, possible offline use and accessibility with a representative group. Provide more than one authorised path without accumulating dormant access.
Deliverable: pilot scenarios and success criteria.
- 04
Protect enrollment
Verify identity and session before adding a key, notify the user and record the event. Test rejection of an enrollment request from suspicious context.
Deliverable: enrollment procedure and event record.
- 05
Plan loss and revocation
Document reporting, disablement, recovery and identity checks for a lost authenticator. Test the journey without bypassing protection through a weaker channel.
Deliverable: recovery and revocation exercise.
- 06
Expand and monitor
Roll out by group, measure coverage, follow failures and exceptions, then retire legacy methods once the tested recovery process permits it.
Deliverable: migration dashboard and exception register.
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Coverage | Sensitive accounts on resistant methods | Extend rollout |
| Enrollment | Additions with checks and notification | Fix weak paths |
| Recovery | Simulated losses resolved without bypass | Repeat the exercise |
| Exceptions | Remaining access with owner and expiry | Retire legacy factors |
Common pitfalls
- Calling every MFA method phishing-resistant
- Securing sign-in but leaving weak enrollment
- Missing administrators and emergency accounts
- Retiring a legacy method before recovery works
Frequently asked questions
Is a one-time code sufficient?
NIST explains that a manually entered code can be relayed by an impostor service and is not phishing-resistant.
Does everyone need a hardware key?
The choice depends on assurance and context; some syncable WebAuthn authenticators may suit some uses with appropriate recovery choices.
What follows device loss?
Revoke the affected authenticator, follow the verified recovery process and notify the user according to service policy.
Identity: factors, sessions and recovery
An authentication method must be assessed alongside enrolment, recovery and the sessions it opens. A passkey label, a phone or a biometric sensor does not by itself establish the assurance level of the entire service.
References use NIST SP 800-63B-4, finalised in July 2025, and WebAuthn Level 3, a W3C Recommendation since 25 August 2026. AALs describe authentication transactions rather than product scores or certifications earned by ticking this table. Application depends on service scope and risk assessment.
Sources consulted on .
Compare eight methods without confusing their guarantees
| Method and reference | Property and conditions | Recovery and dependencies | Evidence to request |
|---|---|---|---|
| Entered password | Knowledge factor; a false site can relay or capture the secret. | Depends on the password manager and the password replacement path. | Length policy, compromised-secret blocking and a tested replacement journey. |
| Manually entered TOTP | Possession of a shared secret; manual entry does not bind the output to the legitimate session. | Plan for loss of the generator and protection of seeds or provider backups. | Authorised enrolment, secret protection and revocation; do not call every OTP phishing-resistant. |
| SMS or voice code | PSTN out-of-band channel, restricted in the NIST framework; manual codes are not phishing-resistant. | The number, carrier and SIM or line changes are dependencies. | Channel justification, risk signals, alternatives and number-change procedure. |
| Simple push approval | Approval without cryptographic verifier-name or channel binding does not establish phishing resistance. | Lost phones and application re-enrolment require handling. | Actual protocol, user intent and enrolment controls; the push label alone is insufficient. |
| Syncable WebAuthn with UV | Cryptographic binding to the service; user verification (UV) must be requested and checked when required. Syncable keys are exportable in NIST terminology. | The sync account, its devices and its recovery enter the trust boundary. | Sync and UV requirements. Syncable methods do not fit AAL3, which prohibits key export. |
| Device-bound WebAuthn with UV | Service binding and user verification. Device-bound alone does not establish non-exportable hardware protection. | Device loss requires another authorised method or controlled recovery. | Storage properties, UV, proof of non-exportability when needed and tests of actual clients. |
| WebAuthn key without UV | Service binding, but possession alone in this case. A touch or user presence (UP) flag is not proof of user verification (UV). | Plan a second authorised method and lost-key revocation. | UP/UV checks and the factor combination required by the service; hardware form alone does not establish MFA. |
| Biometrics considered alone | In the NIST framework, biometrics accompany a physical authenticator in MFA; they are neither secrets nor sufficient standalone mechanisms. | Provide a non-biometric alternative and protect biometric information appropriately. | Comparison location, activation role and accessible alternative; distinguish biometric comparison from cryptographic proof. |
No method matches the filters.
Three AALs: distinguish requirements and recommendations
| Level and factors | Resistance and key export | Overall reauthentication timeout | Inactivity |
|---|---|---|---|
| AAL1 One factor can suffice at this level. | Phishing resistance not imposed by this level; key export permitted. | At most 30 days: SHOULD recommendation. | No numeric ceiling in this reference; define the service policy. |
| AAL2 Two distinct factors. | A phishing-resistant option must be offered; key export permitted under applicable conditions. | At most 24 hours: SHOULD recommendation; establishing a definite overall limit remains mandatory. | At most 1 hour: SHOULD recommendation. |
| AAL3 Cryptographic authenticator and additional or activation factor. | Phishing resistance and a non-exportable private key required. | At most 12 hours: SHALL requirement. | At most 15 minutes: SHOULD recommendation. |
These values are not cookie lifetimes to copy blindly. NIST distinguishes overall and inactivity limits and then defines reauthentication rules. Applications may choose shorter periods based on risk. IAL concerns identity proofing and FAL federation: AAL does not replace either dimension. NIST §2 →
Passwords: seven precise NIST reference points
- Single factor
- Minimum 15 characters required.
- Within MFA
- Minimum 8 characters required when the password is used only in a multifactor process.
- Accepted length
- Allowing a maximum length of at least 64 characters is recommended.
- Composition
- No imposed mixture of character types.
- Replacement
- No arbitrary periodic changes; force a change when there is evidence of compromise.
- Secrets to reject
- Compare against commonly used, expected or compromised passwords.
- Entry assistance
- Allow password managers and autofill; permitting paste is recommended.
Recovery: four classes and their conditions
- Previously saved code
- At least 64 random bits in the NIST framework; offline subscriber storage, hashed server storage and invalidation after use.
- Code issued on demand
- Codes sent by text or voice are valid for at most 10 minutes; email codes for at most 24 hours. Verify addresses and apply the target level’s conditions.
- Recovery contact
- Organise contact addresses and associated checks; a personal relationship does not replace technical recovery requirements.
- Repeated identity proofing
- An option for previously identity-proofed accounts. Without prior identity proofing, do not claim to re-verify an unknown identity.
Replacing a forgotten password through another still-valid authenticator is binding a new authenticator rather than necessarily account recovery. Document notifications, delays, revocations and responsibilities so support does not become a bypass. NIST §4 →
Connect authentication, sessions and incidents
| Stage | Proposed practical check | Observable evidence |
|---|---|---|
| Enrol | Check who authorises a new authenticator and notify the subscriber through a known path. | Record of binding, associated method and authorisation basis. |
| Authenticate | Check the protocol, expected domain and required factors before granting access. | Results on chosen clients, with presence and verification indicators separated. |
| Manage the session | Define overall expiry, inactivity, reauthentication for sensitive actions and logout invalidation. | Expired-session, logout and post-revocation access tests. |
| Report loss | Identify the affected authenticator, preserve useful evidence and decide invalidation based on suspected compromise. | Report timeline and observed access result after handling. |
| Recover | Follow a documented path, notify and prevent an old session from adding a new method without appropriate checks. | Successful recovery case and refused bypass case. |
| Leave the service | Remove obsolete authenticators and access; address relevant sessions, devices and sync authorisations too. | Revoked methods, removed access and remaining dependencies. |
WebAuthn: verify the response at the service
The server must correlate the challenge, authorised origin, RP ID hash and signature with the expected ceremony and check required flags. UP signals presence; UV signals user verification. BE and BS describe credential backup eligibility and state without independently certifying the sync system. Use a maintained library and the complete procedures in specification sections 7.1 and 7.2. WebAuthn Level 3 →
Include people who use a different journey
WCAG 2.2 criterion 3.3.8, level AA, addresses cognitive tests during authentication with specific exceptions and assistance mechanisms. Test password managers, paste, labels, keyboard, cancellation and fallback in practice. NIST requires a non-biometric alternative; making it usable is part of design. WCAG 2.2 · 3.3.8 →
Continue with identity governance →
Primary references and scope
Publication and consultation dates are distinct. Proposed tests and evidence are editorial; linked normative texts govern. Vendor documentation describes its own product and does not establish your application’s AAL.
- NIST SP 800-63B-4 · final publication · Publication :
- NIST · Authentication Assurance Levels · Publication :
§2.1–2.3 - NIST · Authenticators and password requirements · Publication :
§3.1.1; §3.2.3; §3.2.5 - NIST · Authenticator Event Management · Publication :
§4.1; §4.2; §4.6 - NIST · Session Management · Publication :
§5 - NIST · Syncable Authenticators · Publication :
Appendix B - W3C · WebAuthn Level 3 · Publication : · W3C Recommendation
§6.1; §7.1–7.2 - W3C · Accessible Authentication (Minimum) · Publication :
WCAG 2.2 · 3.3.8 · AA
Forms: criteria, errors and contrast
Authenticate without avoidable cognitive effort
SC 3.3.8 addresses cognitive tests at each authentication step, with specific alternatives, assistance mechanisms and exceptions. Verify security and usability together.
- Try password managers and paste where relevant.
- Examine recovery mechanisms in the actual journey.
- Do not infer screen accessibility from the chosen authentication technology alone.
Open the WCAG review grid and contrast calculator →
W3C WAI · Understanding SC 3.3.8 · Accessible Authentication (Minimum) · Informative explanation · consulted 2026-10-23
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
- NIST SP 800-63B-4 — phishing resistance and authenticator lifecycle
- CISA — Cross-Sector Cybersecurity Performance Goals
- NIST SP 800-63B-4 · final publication
- NIST · Authentication Assurance Levels
- NIST · Authenticators and password requirements
- NIST · Authenticator Event Management
- NIST · Session Management
- NIST · Syncable Authenticators
- W3C · WebAuthn Level 3
- W3C · Accessible Authentication (Minimum)
- W3C · Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI · Understanding SC 3.3.8 · Accessible Authentication (Minimum)
Continue exploring
Related analysis
