SaaS MFA and passkeys: a secure account setup checklist
Plan multi-factor authentication and passkeys for SaaS accounts, including enrollment, recovery, administrator protection and accessible rollout.
In this guide
What MFA should a SaaS product offer?
Multi-factor authentication (MFA) asks a person to prove control of two distinct authentication factors. A passkey or security key can provide phishing-resistant authentication; an authenticator app can add a second factor to a password. No single option fits every device, user or risk, so give people clear choices and design recovery with the same care as sign-in. NIST SP 800-63B-4 is a technical reference, not a blanket legal requirement for every commercial SaaS product.
Offer passkeys or security keys for strong sign-in
Passkeys use public-key authentication tied to a website's domain, which helps resist look-alike phishing pages. Support a second authenticator or a carefully designed recovery path because a user may lose a device. Explain whether a passkey can sync through the user's platform account and let the user review and remove registered authenticators.
Provide an authenticator-app option where it fits
Time-based one-time passwords can serve as a second factor when hardware-backed sign-in is not available. Show the setup secret only during enrollment, ask for a valid code before binding the device and give recovery codes once. One-time codes are useful but are not phishing-resistant; avoid describing every MFA method as equally strong.
Treat text-message codes as a risk-based fallback
A code sent by SMS can be exposed through number takeover, message interception or social engineering, and a person can type it into a convincing fake site. Consider a stronger default for administrators and high-impact actions. If SMS remains available, explain its limits and provide a supported way to change a number without weakening account recovery.
| Account group / action | Primary MFA option | Fallback and recovery | Enrollment test | Owner / review date |
|---|---|---|---|---|
| Workspace administrators | ||||
| Standard members | ||||
| Billing or data export |
How should a SaaS team enroll and recover authenticators?
Verify the signed-in account before binding a new device
Require an authenticated session and appropriate reauthentication before adding, replacing or removing an authenticator. Notify the account through an established channel and record the event. If the user is already locked out, follow a separately secured recovery process rather than a weaker version of normal enrollment.
Make recovery codes usable but hard to misuse
Generate high-entropy, one-time codes; display them after enrollment and explain how to store them safely. Invalidate each code after use and let a user replace the full set after confirming a current authenticator. Do not email reusable codes or allow support staff to read them back.
Protect recovery without excluding people
Offer more than one safe authenticator where practical and make recovery instructions understandable to people using assistive technology or shared devices. Do not make an inaccessible phone or a single lost security key the only way into an account. For a high-risk recovery, use a documented check with clear limits and audit the decision.
How do you roll out MFA without locking out customers?
Protect high-impact accounts and actions first
Start with internal administrators, customer workspace owners and actions such as changing payment details, exporting sensitive data or creating credentials. Set the requirement and recovery path before enforcement. Use a staged rollout with clear notice, test accounts and a support plan for people who cannot enroll immediately.
Use step-up checks for sensitive changes
A recently authenticated session may still be inappropriate for an irreversible or high-impact action. Ask for a fresh authenticator check before changing MFA, adding a privileged user, changing recovery information or exporting especially sensitive data. Keep the prompt tied to the specific action and avoid repeated prompts that train people to approve automatically.
Test lost-device, replacement and incident paths
Exercise a lost phone, stolen laptop, expired session, unavailable email, suspected account takeover and employee departure. Confirm how to revoke a lost authenticator, end active sessions, restore access and review account activity. Track failed enrollment and lockout rates so the team can fix usability problems without weakening the control.
SaaS MFA and passkey questions
Are passkeys phishing-resistant?
WebAuthn-based passkeys bind authentication to the relying party's domain, which helps prevent a fake domain from reusing the authentication response. Device, sync-provider, account-recovery and implementation choices still matter; passkeys reduce important risks but do not make the whole account or service invulnerable.
Is SMS MFA better than a password alone?
It can add a barrier to some attacks, but SMS has risks such as number takeover and phishing. Offer stronger methods where possible, especially for privileged accounts, and do not present text-message codes as equivalent to phishing-resistant authenticators.
Can an authenticator be shared across several accounts?
A person may use a compatible authenticator for more than one account, but each SaaS account should bind and manage its own credential relationship. Let the user see which authenticators are registered and remove a lost or unwanted one without exposing other accounts.
Should every customer be forced to enroll on day one?
The right rollout depends on product risk, customer commitments and support capacity. Protect high-impact accounts first, communicate a deadline when enforcement is needed and provide an accessible recovery route before requiring enrollment across a whole customer base.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- NIST SP 800-63B-4: Authentication and Authenticator ManagementNational Institute of Standards and Technology
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- OWASP Cheat Sheet: LoggingOWASP Foundation