Resources · 24
Deploy phishing-resistant authentication with safe recovery
Use factors bound to the genuine service and protect enrollment, loss and revocation.
· 17 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.
Official references
Continue exploring
Related analysis
