Capability

Phishing-resistant MFA

What it does: Attackers cannot use a password, code or approval they trick a user into giving away.

WICCIC

In short

Phishing-resistant MFA signs users in with a key stored on their own device. The key only works on the real site. A fake site gets nothing it can reuse.12

Book a callHow Okta and Auth0 do it ↓
5
attack types it helps against

What it is, and the attacks it stops

Most MFA still asks the user to hand something over. That can be a password, a six-digit code or a tap on a push notification. An attacker can trick the user into giving up any of these.

Phishing-resistant MFA works differently. The proof of identity stays on the user's device. The device only sends it to the real site it was registered with.12

That one change stops attacks such as:

1

Credential phishing

A fake login page collects the password. With this MFA, the user has no password to type. The fake page gets nothing it can replay.

2

Adversary-in-the-middle proxies

A proxy passes the real login through and steals the session after MFA. The authenticator checks which site is asking. It does not answer a lookalike domain.

3

Vishing and "read me the code" calls

A caller poses as IT and asks for a one-time code. There is no code to read out.

4

Push fatigue (repeated approval requests)

The attacker sends requests until someone taps yes. This type of sign-in does not rely on a blind tap.

5

Stolen or reused passwords

A password from another breach is no longer enough on its own, even if an attacker also phished the password.

Before and after rollout

Without
With
WithoutA phished password opens the account.
WithA phished password is not enough. The attacker also needs the user's device or key.12
WithoutA one-time code can be read out on a call or passed on by a proxy.
WithThere is no code to read out or pass on.
WithoutA fake site looks the same as the real one. The user cannot tell.
WithThe authenticator answers only the real site.12
WithoutEvery sign-in depends on the user spotting the trick.
WithThe device does the check - the user does not have to spot anything.

How Okta and Auth0 do it

Okta offers two ways to get phishing-resistant MFA. You can use them together.

1

The user opens a sign-in

The user signs in to an app protected by Okta.

2

The authenticator checks the site

Okta Verify (FastPass) or a FIDO2 key confirms that the request comes from the real Okta domain.12

3

The device confirms the user is present

The key on the device signs the request. The user confirms on the device, for example with a biometric or PIN.12

4

Policy decides what is allowed

Okta delivers FIDO2 (WebAuthn) and Okta FastPass, both phishing-resistant. Okta Adaptive MFA can require stronger factors when sign-in risk is higher. Require those, and strive to retire the weaker factors.35

Fake site

UserFake site✕ Result

Real Okta sign-in

UserOkta✓ Result
WIC
Who it protectsStaff, contractors, admins
Okta FastPassA passwordless sign-in through the Okta Verify app on the user's device. App sign-in policies decide when FastPass is offered. It is designed to resist phishing.1
FIDO2 (WebAuthn) and passkeysYou can set up FIDO2 (WebAuthn) authenticators, including passkeys, as Okta authenticators.28
Phishing-resistant authenticatorsCurrently, FIDO2 (WebAuthn) and Okta FastPass are Okta’s available phishing-resistant MFA factors.3
MFA enrollment policiesThese policies, configured in Okta, dictate which MFA factors the user must enroll in, depending on the group they are assigned.4
CIC
Who it protectsYour app's users
PasskeysAuth0 database connections support passkeys. Customers sign in with a passkey instead of a password they could reuse. Some passkeys sync through the customer's cloud account.6
WebAuthn security keys as MFAYou can turn on security keys as an MFA factor for customer sign-ins.7
Adaptive MFAAuth0 Adaptive MFA asks for stronger factors when customer sign-in risk is higher. It is available on Auth0 Enterprise plans as an add-on.9

How Zelto implements it

The technology behind Okta is the ready and proven half - Zelto maps your accounts, devices and exceptions. We plan rollouts in groups to minimize risk/impact. We start with the accounts attackers want most. We also keep a recovery path that attackers cannot talk their way into.

Typical rollout

  1. Map who signs in, how and from what

    We list your apps, authenticators and devices.

  2. Choose the authenticators

    For maximum phishing resistance, we use FastPass where devices can run Okta Verify. We use FIDO2 keys for shared, kiosk and high-risk accounts. We use passkeys for customers.

  3. Pilot with admins and IT

    We start with the highest-value accounts. Before any policy becomes required, we agree on an owner on your side. We also agree when to switch over and when to roll back.

  4. Roll out one group at a time

    We don't switch everyone over on the same day. Each group gets its own MFA enrollment policy in Okta. Your help desk gets a script for that group's questions. Each group has a fixed switch-over date.

  5. Tighten and retire

    We remove passwords and weaker factors for the covered apps as much as possible. We review exceptions on a schedule.

Pitfalls we plan for

A user's key or FastPass fails at sign-in.

−Let them sign in with SMS, a phone call or a push instead. Attackers know this and ask for the weaker method.

+Block the sign-in and send the user to a recovery process that checks who they are.

A user locks themselves out and calls the help desk.

−The help desk resets the password or adds a new factor after a few questions on the phone.

+The help desk checks the caller's identity first. The user gets back in only by enrolling a new phishing-resistant factor.

Contractors and shared accounts need access.

−Give them the same setup as staff, or leave them out, without checking who actually uses each account.

+Check who uses each account. Give every contractor their own account. Put FIDO2 keys on shared and kiosk accounts.

Teams share one FIDO2 key between several people.

−Pass one security key around the team, so nobody can tell who used it and a lost key affects everyone.

+Give each person their own FIDO2 key. Use dedicated keys registered to shared or kiosk accounts, not a personal key copied between users.

People sign in from personal phones and laptops, and phones and keys get lost or replaced.

−Let anyone register a key on any device, with no backup and no plan for a lost phone. Locked-out users end up back on passwords or SMS.

+Decide which devices can hold a key. Give each user a backup key or a second device. Agree how a lost or new device gets replaced before the rollout starts.

Want phishing-resistant sign-in without a rollout that stalls?

We review how your staff and customers sign in today. Then we tell you what to change first.

Book a call30 minutes, no slides. We look at how your users sign in today.

Related blog posts

Hands-on notes from rollouts

Phishing-resistant MFA and FIDO rolloutRead on the blog →Implement phishing-resistant MFA with Okta: a practical guideRead on the blog →F is for FIDO2Read on the blog →

Sources

Official Okta and Auth0 documentation and primary legal sources.

  1. 1Okta Verify and Okta FastPassOkta Help Center
  2. 2Configure passkeys (FIDO2 WebAuthn) authenticatorOkta Help Center
  3. 3Phishing-resistant authenticationOkta Help Center
  4. 4About MFA enrollment policiesOkta Help Center
  5. 5Okta Adaptive MFAokta.com product page
  6. 6Passkeys in Auth0 database connectionsAuth0 Docs
  7. 7Configure WebAuthn security keys as an MFA factorAuth0 Docs
  8. 8Okta developer guide: FIDO2 WebAuthn authenticatordeveloper.okta.com
  9. 9Adaptive MFAAuth0 Docs