This article explores strategies to safeguard your organization against identity threats, such as account takeovers (ATO) and the evaluation of MFA vulnerability.

• Security
• Account Takeover

Your users are your most important asset —that's why it's critical to provide secure access to apps for both your workforce and customers. Smart organizations have already implemented multi-factor authentication to prevent account takeover. However, not all factors and authenticators provide the same level of security assurance. The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication:

• Knowledge: Something you know (for example, a password)
• Possession: Something you have (for example, an ID badge or a cryptographic key)
• Inherence: Something you inherently are (for example, a fingerprint or other biometric data) 

In general, knowledge-based factors are considered weaker than possession or inherence-based ones.

Assurance level	Authenticator	Pros	Cons
Low	Password	Provides baseline security at a low cost Easy to use and deploy Users are familiar with the process of signing in with a password	Vulnerable to data breaches due to users' poor password management habits (use of common passwords, writing passwords down, reusing passwords, etc.)  Major risks from social engineering and phishing Vulnerable to credential stuffing and password spray attacks Users tend to forget passwords when password requirements are too complex Difficult to type on mobile devices
Low	Security Question	Provides baseline security at a low cost  Users are familiar with the process of answering a security question during login	Users often forget their answers Many questions are weak, making answers easy to guess or discover Subject to social engineering and phishing
Low	SMS, Voice, Email One-time Password (OTP)	Familiar experience for users, as many consumer apps already use OTP as a form of account/identity verification Easy to deploy, as most individuals have a phone	Relies on phone/internet service provider for securing the systems used to transmit authentication material; Subject to social engineering (e.g., SIM swapping) May require using a personal device, which cannot be enforced in some regions Opens the door to SIM swapping and toll fraud attacks against implementers. Limited DMARC standard implementation means that detecting email-based spoofing is difficult
Low	Mobile/Desktop One-time Password (OTP) apps Examples: Okta Verify OTP, Google Authenticator, Authy	Low cost, many users are able to install an app on a laptop or phone Algorithmically generated Crypto-based security Does not require internet/data service to use (i.e., airplanes, international travel)	Biometric verification can be set intrinsic to authentication Limited protection against a stolen device May require using a personal device, which cannot be enforced in some regions Subject to real-time adversary-in-the-middle attacks
Medium	Mobile app push notifications  Examples: Okta Verify with Push	Low cost, many users are able to install an app on a laptop or phone Algorithmically generated, not delivered over insecure channels Some apps support biometrics User-friendly Creates additional signal for defenders (initiating and verifying client available in logs)	May require using a personal mobile device. Users may have privacy concerns, and cannot be enforced in some regions Subject to man-in-the-middle and phishing attacks Subject to brute force manipulation or social engineering.
Medium	Physical token One-time Password (OTP) Examples: YubiKey in OTP mode, Symantec VIP	Algorithmically generated Does not require internet/data service to use Does not require a personal phone/device	Subject to loss and may require a separate recovery option Higher deployment and provisioning costs, orgs may not deploy to all users Many OTP tokens do not support biometrics
High	Personal Identity Verification (PIV)/ Common Access Card (CAC) smart cards	Mature technology Strong authentication level Phishing-resistant inbuilt MFA (required PIN to access)	Needs an insert-based, contact-based reader, not contactless Can be easily lost or stolen Not widely supported on mobile platforms PIN resets can be painful Certificate management
High	FIDO2.0 / WebAuthn and CTAP2 Examples: Mac Touch ID, Android fingerprint, Windows Hello, YubiKey	Phishing resistant Support for both on-device biometrics and security keys Seamless end-user experience Puts organizations on a path to passwordless Can reduce IT and support costs for factor enrollment and reset	Only applies to web-based authentication
High	Okta FastPass	Phishing-resistant for all managed devices and for MacOS, Windows, and Android on unmanaged devices Seamless end-user experience Leverages the device context signals (some collected by Okta Verify itself and others through integration partners such as CrowdStrike and Tanium) to help administrators make policy decisions based on the device posture Can reduce IT and support costs for factor enrollment and reset	Only applies to web-based authentication

Advice on better securing against account takeover

1. Phishing-resistant factors

Consider transitioning to more secure authentication methods, initially with number challenge. The end game would be phishing-resistant methods, like Okta FastPass.

A first step is transitioning from push notification to number challenge. Security analysis has shown that compared to push challenge, number challenges account takeovers rarely happen. Initially, you can enable it for "high risk" challenges and afterwards transition to "all push challenges".

Resource: What Triggers Number Challenge in Okta Verify

Afterwards, when moving to phishing-resistant factors, you can start testing with a small group and gradually expand, especially for applications with sensitive data. A gradual roll-out is recommended to ensure a clear understanding of the effects and impact it will have on your users. In some scenarios, we can discuss device limitations that cannot use FastPass. Here, we can consider YubiKey as an alternative.

Resource: Phishing-resistant authentication

2. Network Zone configuration

A first step here would be to block Anonymizing proxies. An active block ensures that any request incoming from an anonymizing proxy will translate into a 403 Forbidden result to any endpoint of your organization. Please be aware that this will also block legitimate users if they are using an anonymizing proxy to access your tenant. An example is Apple devices with Private Relay enabled, where users will need to disable Private Relay when accessing your organization. You can allowlist certain anonymizers with enhanced dynamic zones.

We also highly recommend blocking countries and ASNs. A country block from regions where you do not have active users will greatly limit possible malicious actor attempts. We suggest leveraging the "Enhanced Dynamic Zone" that offers better granularity compared to "Dynamic Zone".

Resource: Enhanced dynamic zones

Even when specific blocklists are in place, if you have users traveling abroad to a zone that you have in a blocklist, you can still allow those users access by adding their IPs to the Exempt Zone. The default IP Exempt Zone bypasses any blocklist that you have in place.

Resource: How to Allowlist an IP Blocked by Network Zones

3. Identity Threat Protection

Consider adopting ITP (Identity Threat Protection) for the Okta Threat Intelligence and other detections, and enabling Universal Logout. This feature is highly efficient at detecting session hijacking, and "Universal Logout" ensures that your users are logged out of Okta and third-party apps that are linked to Okta.

Resource: Identity Threat Protection

4. Automations for your own threat detection tool

First, you will need to create your log streaming service from Okta. Afterwards, review the Okta detections repository and create automations in your SIEM to notify your SecOps team to investigate suspicious behavior.

Resources:

• Log Streaming 
• Add Splunk Log Stream
• Okta Customer Detection Repository:  GitHub - okta/customer-
• Auth0 Customer Detection Catalog: GitHub - auth0/auth0-customer-detections