Passkeys and security keys
Use FIDO-based authenticators where supported to reduce shared-secret and phishing risk. Decide whether syncable or device-bound authenticators fit the account, recovery model, and assurance requirement.
Reviewed September 2026NIST 800-63-4 informed
Treat authentication as a lifecycle, not a login checkbox.
Strong authentication depends on enrollment, authenticator strength, phishing resistance, device and session context, recovery, help-desk procedures, privileged access, monitoring, and revocation. Passwordless methods can reduce password risk, but they still need disciplined lifecycle controls.
NIST SP 800-63B-4, finalized in July 2025, defines requirements for authenticator assurance levels and integrates modern authenticator guidance. Current NIST materials recognize syncable authenticators such as passkeys while emphasizing assurance, lifecycle, and risk considerations.
Authentication risk
Prioritize accounts by consequence and attack path.
Start with administrators, remote access, email, cloud control planes, source control, finance workflows, identity administrators, production systems, and accounts that can reset other credentials. Require stronger authentication and tighter recovery for identities with greater blast radius.
Do not assume every second factor provides the same protection. SMS and one-time codes may improve security over passwords alone, while phishing-resistant cryptographic authenticators provide stronger protection against adversary-in-the-middle and credential replay attacks.
Authenticator choices
Match the method to the required assurance and user population.
Authenticator apps
Push and time-based one-time passwords can be useful transitional controls. Protect against approval fatigue, enrollment abuse, and weak recovery.
Passwords
When passwords remain, use modern password policy, block known-compromised values where practical, avoid unnecessary composition rules, and protect reset workflows.
Certificates and smart cards
High-assurance or regulated environments may require hardware-backed or certificate-based authentication. Treat key issuance, renewal, revocation, and recovery as security-critical operations.
Phishing resistance
Move the highest-value accounts away from reusable secrets and approval prompts.
Prioritize phishing-resistant authentication for administrators and high-impact remote or cloud access. Where legacy applications prevent immediate adoption, isolate those applications, reduce exposed entry points, monitor authentication closely, and create an explicit migration plan rather than allowing weaker methods to persist indefinitely.
Enrollment
Strong authenticators are only as trustworthy as the enrollment path.
Verify the user before adding a new authenticator. Require stronger checks when enrolling an authenticator remotely, adding a new device, changing a recovery method, or replacing an administrator’s credential. Alert users and security teams to high-risk enrollment events and retain enough evidence to investigate suspicious changes.
Recovery
Do not let help-desk recovery become the weakest authenticator.
Recovery channels
Minimize recovery methods that rely only on easily discovered personal information or a single weak factor. Use step-up verification and independent notification for important changes.
Lost devices
Provide a documented process for lost, stolen, replaced, or inaccessible devices. Revoke old authenticators promptly and confirm recovery does not silently preserve attacker access.
Privileged identities
Use separate administrative identities and stronger authentication.
Keep everyday productivity accounts separate from highly privileged administration where practical. Require phishing-resistant authentication, restrict the devices and networks used for sensitive administration, minimize standing privilege, and monitor authentication, enrollment, and recovery events involving privileged identities.
Measure protection
Track strength, coverage, and failure modes.
- Percentage of workforce and privileged identities protected by MFA.
- Percentage of high-risk accounts using phishing-resistant authenticators.
- Legacy protocols or applications bypassing strong authentication.
- Authenticator enrollment and recovery events requiring investigation.
- Stale or duplicate authenticators after device replacement.
- Help-desk resets, failed recovery attempts, and suspected social-engineering events.
90-day implementation
Protect high-impact identities first, then expand.
Days 1–30
Inventory authentication methods, privileged accounts, legacy bypasses, enrollment processes, and recovery channels. Enforce MFA on the highest-risk access paths.
Days 31–60
Pilot phishing-resistant authentication, tighten enrollment and recovery, separate admin identities, and instrument authentication logs and alerts.
Days 61–90
Expand passkeys or hardware-backed methods where appropriate, retire weak bypasses, measure adoption and exceptions, and test recovery with real users.
Passkey deployment
Design passwordless adoption around account recovery and device reality.
Choose syncable versus device-bound use deliberately
Syncable passkeys can reduce user friction across a person’s devices, while device-bound authenticators can provide tighter control for high-assurance administrative scenarios. The right choice depends on the account’s consequence, managed-device posture, recovery model, user population, and required assurance. Document which authenticator classes are allowed for workforce, administrator, customer, and service-facing use cases.
Inventory application compatibility
Before broad rollout, identify applications that rely on legacy protocols, embedded browsers, unsupported identity libraries, shared accounts, or separate local credentials. Segment them into immediate migration, compensating-control, and retirement tracks. A passwordless program stalls when the organization discovers critical exceptions only after disabling the old sign-in path.
Enroll more than one recoverable authenticator
Where policy and assurance requirements allow, give users a controlled way to maintain a second valid authenticator so a lost device does not automatically become a help-desk identity-proofing event. Notify the user when authenticators are added or removed, and make the account’s enrolled methods visible enough that unexpected changes can be reported quickly.
Test actual phishing resistance
Do not label an experience phishing-resistant solely because the user never types a password. Validate that the authentication ceremony is bound to the legitimate relying party and cannot be replayed through an attacker-controlled intermediary. Keep fallback methods from silently reducing the effective protection of a high-value account.
Non-human and emergency access
Keep service identities and break-glass accounts out of the user-MFA blind spot.
Workload and service identities often cannot complete interactive MFA, but they still require strong authentication and lifecycle control. Prefer short-lived workload identity, managed identity, certificates, or other platform-native mechanisms over static secrets where supported. Assign an owner, purpose, permitted resources, rotation or renewal method, and retirement condition to every non-human identity.
Emergency accounts should be rare, monitored, and tested. Store recovery material using a controlled mechanism, limit the account’s privileges to the intended recovery purpose, alert on every use, and review the account after exercises or incidents. An emergency identity that has never been tested can fail when the primary identity provider or MFA service is unavailable.
Help-desk procedures deserve the same threat modeling as login. Define what support staff may change, which verification steps are required, when a second approver is necessary, how high-risk resets are logged, and how the user is notified. Attackers frequently target support processes precisely because technical authentication controls are stronger.
Measure exception debt. Track accounts still using weaker factors, applications that cannot support the target method, temporary bypasses, users without a viable recovery path, and privileged identities that have not migrated. Every exception should have an owner and review date so “temporary” does not become the permanent authentication architecture.
Primary sources
Use current digital identity guidance.
Continue learning
Related guides after MFA & Passwordless Authentication
Follow the next implementation topic without returning to search.
Identity & Access Management Program
Govern identity lifecycle, authentication, federation, privileged access, service identities, access review, and identity evidence
Continue readingPrivileged Access Management Program
Reduce standing privilege and govern privileged identities, elevation, service accounts, emergency access, monitoring, and review
Continue readingSecurity Awareness & Phishing Resilience
Build role-based security learning, phishing resilience, fast reporting, behavior change, and continuous improvement
Continue reading
Put this guide to work
Turn MFA & Passwordless Authentication Guide | Zeph Tech into a decision-ready next step.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.