10 Step Phishing Resistance Success Factors

By definition, a phishing-resistant method of authentication is one in which a cryptographic relationship is established between a user authenticator and the service provider during enrollment. This prevents the disclosure of sensitive authentication data to fake apps or websites, because there is no shared secret for an attacker to intercept or trick a user into disclosing. Even if an attacker knows a user's password, they cannot log in without physical access to that user's trusted device or security key.

There are three types of phishing-resistant authentication methods supported in Okta:

• Okta FastPass
• Passkeys (following the FIDO2 WebAuthn standard)
• Smart Cards (PIV cards)

Many other factors are not phishing-resistant because they can be intercepted or approved by a deceived user – these include SMS, email, one-time passwords (OTPs) and even push requests.

Phishing resistance does not have a single "on" switch. Okta recommends following this 10-step framework to improve phishing resistance and reduce risk.

1. Upgrade to Okta Identity Engine (OIE)

Okta Identity Engine is a foundational prerequisite for phishing resistance. The advanced authentication policies and features required to enforce phishing resistance (such as FastPass) are only available on OIE. If your organization is on Okta Classic Engine, review the Upgrade to Okta Identity Engine documentation and initiate your migration.

2. Ensure entitlements for phishing-resistant factors

Your Okta organization must be entitled to use phishing-resistant factors. Verify that your Okta tenant has the necessary licensing and SKUs active for Okta FastPass, passkeys (FIDO2 WebAuthn) passkeys, and/or Smart Cards.

3. Enable phishing-resistant factors in Authenticators

Before users can enroll, the authenticators must be active in your organization. In the Okta Admin Console, navigate to Security > Authenticators. Ensure that Okta FastPass, passkey (FIDO2 (WebAuthn), and/or Smart Card IdP are added and active.

4. Require high-security enrollment methods in Okta Verify

Attackers often target account onboarding and self-service flows to register their own authenticators in a compromised user account. Protecting this process requires strong MFA enrollment policies and account management policies: 

• Enforce High-Security Okta Verify Registration: Ensure Okta Verify enrollment relies only on secure registration channels (such as managed device flows or pre-authenticated sessions) rather than weak fallbacks like unauthenticated QR codes or SMS links.

• Configure Okta Account Management Policy (OAMP): Use OAMP rules to apply specific conditions to when users can enroll or disable authenticators. We recommend requiring verification using an existing phishing-resistant factor or an identity verification flow to enroll any new factor, preventing adversaries with compromised weak credentials from adding rogue authenticators to an account.

5. Enforce phishing-resistant sign-in policy for the Okta Admin Console

It is an absolute necessity to require a phishing-resistant method for signing in to the Okta Admin Console. To do this, a specific app sign-in policy must be created. Navigate to Security > Authentication Policies and select the policy protecting the Okta Admin Console app. Update the sign-in rules to explicitly require phishing-resistance as a constraint.

6. Enforce phishing-resistant sign-in policies for commonly targeted apps

We recommend taking a threat-informed approach to prioritize locking down access to the applications most targeted by threat actors. Okta Threat Intelligence has identified a list of applications presented below that are most targeted by social engineering actors. We nonetheless encourage every customer to perform their own risk evaluation to come up with a priority list.

Navigate to Security > Authentication Policies and select the policy protecting the highly targeted app(s). Update the sign-in rules to explicitly require phishing-resistance as a constraint. An alternative approach is to only allow phishing-resistant factors, but note that if the phishing resistance constraint is not checked in a policy rule, Okta Identity Engine will only consider passkey (FIDO2 WebAuthn) and Smart Card authenticators as phishing resistant. If exceptions must be made for legacy applications, apply compensating controls specific to your environment and operating model to reduce exposure (i.e. managed device requirement + ITP for session protection, alerting and monitoring by Security Operations, network zone blocks of malicious proxies, etc).

7. Drive phishing-resistant factor usage past 50%

Monitoring the enrollment status of your users helps to inform when you can apply phishing resistance to more applications with the least friction.

Use the MFA Enrollment by User and Authentication Activity reports to identify users already signing in with phishing-resistant methods. Use policy branches to monitor the user impact of introducing phishing resistance to an application or group of applications. 

8. Require phishing-resistant factors in all enrollment policies

Phishing resistant factors must be mandatory when users enroll. If they remain optional, threat actors can easily socially engineer users to sign in using weaker methods in MFA downgrade attacks. In the Okta Admin Console, navigate to Security > Authenticators > Enrollment. Ensure that your MFA enrollment policies list at least one phishing-resistant factor (FastPass, WebAuthn, or Smart Card) as Required. Restrict enrollment in weaker factors to only the specific user groups that absolutely require them, and implement compensating controls for those users.

9. Enforce phishing-resistant sign-in policies across all applications

Expand the app sign-in policies you established in Steps 5 and 6 to cover all of your applications. This ensures that an attacker who compromises a credential cannot access any protected resource without presenting a phishing-resistant factor.

10. Disable non-phishing-resistant authenticators

The final step is to eliminate all fallback options in order to protect users against MFA downgrade attacks. Once all applications and policies mandate phishing resistance, navigate to Security > Authenticators in the Okta Admin Console and disable non-phishing-resistant authenticators globally.