- Offer a second factor to everyone and require it for staff and admins; an authenticator app is a sound baseline and passkeys are the strongest common option.
- Treat SMS and phone codes as a fallback: NIST lists them as a restricted authenticator, and email should not be used as a second factor.
- Company customers expect single sign-on through their identity provider, using SAML or OpenID Connect, and often automatic user provisioning.
- Plan account recovery before launch: recovery should never be easier to abuse than the sign-in it replaces.
- For most products, an identity service is safer and faster than building sign-in, MFA and SSO from scratch.
Which sign-in options should a business app offer?
Offer every user a second factor and require it for staff and admins. An authenticator app is a sound baseline, passkeys are the strongest option most people can use, and SMS codes belong at the bottom as a fallback. If you sell to companies, add single sign-on (SSO) so their staff sign in with their work accounts, and plan account recovery before launch rather than after the first locked-out customer.
The right mix depends on who signs in. Staff with access to every customer record need stronger rules than a customer checking an invoice, and company customers bring their own identity systems and expectations.
Which second factors are strongest, and which are weakest?
| Option | How it works | Main weakness |
|---|---|---|
| Passkeys and security keys | A cryptographic key on the phone, computer or hardware key, confirmed with a PIN or biometric | Recovery and new-device sign-in need planning |
| Authenticator app codes | A six-digit code that changes every few seconds | Codes can still be phished on a fake sign-in page |
| Push approval | The user approves the sign-in in an app | "Push bombing" if the prompt can be approved blindly |
| SMS or voice codes | A code sent by text or phone call | SIM swaps, number porting and interception |
| Email codes | A code sent to the email address | Only as safe as the email account |
The US standard for digital identity, NIST SP 800-63B (revision 4), lists phone-delivered codes (SMS or voice) as a restricted authenticator and says email shall not be used for out-of-band authentication. It also requires services at its AAL2 level to offer at least one phishing-resistant option. Those rules are written for US federal systems, but they are a useful benchmark for any business app.
If you offer push approval, OWASP's MFA cheat sheet recommends a challenge such as number matching, so users cannot approve a prompt they did not start.
Should you add passkeys now?
Passkeys are sign-in credentials built on FIDO standards that can be stored on a phone, a computer or a hardware security key, according to the FIDO Alliance. They resist phishing because the key only works on the real site, and people confirm them with the same face, fingerprint or PIN they use for their device.
Many passkeys sync through the platform's cloud account to the user's other devices. NIST's revision 4 includes an appendix on these syncable authenticators and accepts them for broad public-facing use. When you add passkeys, follow the OWASP advice to require user verification and check the user-verification flag on the server.
A practical rollout keeps the existing sign-in, offers "Add a passkey" after a successful sign-in and shows the passkey option first for people who have one.
When do customers expect single sign-on?
Once you sell to companies with an IT team, expect requests to sign in through their identity provider, such as Microsoft Entra ID, Google Workspace or Okta. Staff then use their work account and company security rules, and access ends when someone leaves.
- Protocols: support SAML 2.0 and OpenID Connect. OpenID Connect is an authentication protocol built on the OAuth 2.0 framework, as the OpenID Foundation explains, and it is usually simpler for new integrations.
- Provisioning: larger customers often want users created, updated and removed automatically. SCIM, defined in RFC 7644, is the HTTP-based standard for that.
- Per-customer setup: each company connects its own identity provider, so you need an admin screen or a support process for it, plus rules for domains and default roles.
Many products put SSO in their business plans. If that is your model, plan it with your billing; our guide to SaaS billing plans, seats and trials covers how plans and features fit together.
How should account recovery work?
Most account takeovers that get past a second factor do so through a weak recovery route. Plan it with the same care as sign-in, whether you build custom software or configure an identity service:
- Two ways in. NIST suggests encouraging users to keep at least two separate means of authentication, such as a passkey and an authenticator app.
- Recovery codes shown once during setup, for users to store safely.
- Alerts by email or push whenever a factor is added, removed or changed, as OWASP recommends.
- No security questions. OWASP notes they are no longer recognised as an acceptable factor.
- A support process with identity checks for the rare cases where everything is lost, written down so agents do not improvise.
Should staff and customers follow the same rules?
No. Require a second factor for every staff and admin account, preferably passkeys or security keys, because those accounts can see and change everyone's data. For customers, offer it, encourage it during setup and require it for the riskiest actions. This "step-up" check asks for a second factor again before sensitive actions such as changing bank details, exporting data or adding users, even within a signed-in session.
Should you build sign-in yourself or use an identity service?
For most products, an identity service such as Auth0, Clerk, Amazon Cognito, Firebase Authentication or Microsoft Entra External ID is the safer start. These services handle passwords, MFA, passkeys and SSO connections, and they keep up with security changes for you. You pay per user or per sign-in, so check the pricing at the size you expect next year.
Building it yourself makes sense when you have unusual rules, strict data location needs or a security team to maintain it. In our SaaS and MVP projects we usually start with a service and keep the option to move later. Either way, sign-in is one part of the back end; our mobile app back-end checklist and client portal guide cover the parts around it.
Frequently asked questions
Is SMS two-factor still better than nothing?
For most accounts, yes: a code by text message stops many attacks that only use a stolen password. But it can be intercepted or redirected through SIM swaps, and OWASP notes that each message costs money, so you need limits against attackers who request messages in bulk. Offer SMS as a fallback and steer people to an authenticator app or passkey.
Do passkeys replace passwords completely?
They can for people who set them up, and many apps let passkey users skip the password entirely. In practice you still need a way to sign in on a new device, a recovery route and support for users who have not adopted passkeys yet. Most products add passkeys alongside existing sign-in first and grow from there.
How do we make two-factor login mandatory for existing users?
Start with admins and staff, then roll out to customers in stages. Announce the change, give a grace period with reminders at sign-in, show recovery codes during setup and make sure support knows the recovery process. Track how many accounts have enrolled before the deadline so you can extend it if needed.
Should single sign-on be included in every plan?
That is a pricing decision. Many business apps include SSO in their business or enterprise plans, because the customers who need it are larger companies with security reviews. Whatever you choose, keep a local sign-in option for your own support staff and for emergencies when the customer's identity provider is down.
Does adding two-factor login make us compliant with SOC 2 or GDPR?
Not on its own. Strong sign-in is one control among many, alongside access reviews, logging, encryption and incident handling. It is often expected in security questionnaires and audits, so having it ready helps, but ask your auditor or legal adviser which controls apply to your product.
Last updated