If you’ve been following the news lately, the narrative around AI suggests swarms of agents are finding and exploiting new vulnerabilities at record speeds. However, real-world data from the frontlines of identity security tells a different story. While AI is used broadly enough that we assume some level of augmentation in every observed attack, AI is not the catalyst for identity attacks—it’s the accelerant.
Threat actors are primarily using AI to increase the speed and scale of well-known attack methods, like phishing, rather than inventing brand-new ones. Because the underlying conditions for initial access have not fundamentally changed, the architectural principles that secure organizations against human-led attacks remain just as effective against AI-augmented threats.
To withstand modern attacks, security fundamentals matter more than ever. Security teams should focus on reducing their overall attack surface—and governing their organization’s use of AI—rather than trying to outrun attackers’ use of AI. By putting a few key controls in place, our research shows security leaders can better protect against these AI-driven threats.
A small number of controls can prevent most breaches
In 2024, computer scientist Niels Provos introduced the concept of security invariants—automated, machine-enforceable policies that systematically reduce an organization's attack surface without requiring individual employees to make security decisions.
Provos’s analysis of public data breaches revealed that a small set of consistently enforced controls—such as mandatory hardware second factors, egress restrictions, and app allowlisting—could collectively prevent up to 65% of recorded breaches.
Niels Provos found that 65% of breaches could be prevented with just three controls. The analysis is detailed in a Security Blueprints blog post.
Because an invariant operates automatically across computing infrastructure, it helps remove the security burden from the end user, so they don’t need to constantly worry about taking actions such as creating stronger passwords or spotting sophisticated phishing attempts.
We put phishing resistance to the test
Using Provos's study as a framework, Okta Threat Intelligence conducted research to test our hypothesis that a small number of security invariants could help prevent identity attacks. To gauge the efficacy of phishing-resistant factors and policies in the wild, we analyzed approximately 6,000 real-world social engineering events from an internal dataset of over 10,000 campaigns.
We evaluated target configurations, policy settings, and session outcomes during account takeover (ATO) attempts, which we defined as any compromised IdP session—even if the attacker did not gain access to protected resources. We excluded attacks where:
The user device was already compromised
The primary method of initial access was tricking a user into downloading malicious software or RMM tools
The primary method of initial access was tricking a user into authorizing an attacker-controlled app in a downstream SaaS application
These wouldn’t have any bearing on the effectiveness of phishing-resistant authentication.
The initial observations confirmed standard industry assumptions about the weakness of passwords: 87% of ATO sessions involved passwords, while 58% satisfied push notifications, 36% completed app-based one-time passwords (OTP), and 22% used SMS OTPs. The most frequent factor pairings were password + push (47%) and password + app-based OTP (27%)—none of which are phishing resistant.
How the security invariants performed
Next, we examined whether our phishing-resistant security invariants prevented the ATO. When measuring the direct impact of phishing-resistant authenticators, the numbers revealed clear protection layers:
Mandatory enrollment: Requiring users to enroll in phishing-resistant factors stopped 88% of account takeover attempts.
App sign-in enforcement: Requiring phishing resistance within app sign-in policies closed most of the remaining gap, elevating protection to 99.75%.
App sign-in policies define how a user must authenticate to gain access to an app, and setting these is a necessary step to help ensure users can only authenticate with a phishing-resistant factor, not a weaker factor. Enforcing phishing resistance in app sign-in policies is important because MFA downgrade has long been a part of the social engineer’s playbook. Threat actors will go to great lengths to convince users not to choose a phishing-resistant factor.
Even with mandatory enrollment and strict app sign-in policies enforced, 0.25% of social engineering events in the study still resulted in a compromised session.
This residual risk comes from the challenge of account bootstrapping, the process of securely enrolling a new user or device. Organizations face a chicken-or-the-egg conundrum: how can they verify a user's identity securely before allowing them to enroll in a strong, phishing-resistant authenticator? If this initial verification relies on weaker factors like passwords, OTP, or push notifications, the account remains exposed to MFA downgrade attacks before the stronger protection is ever applied. If an attacker successfully logs in with the weaker MFA factor, they can use their access to self-provision their own attacker-controlled phishing-resistant factor, effectively locking in persistent access.
To reach ~100% protection against social engineering attacks, phishing-resistance requirements must extend to Account Management Policies (AMPs). By locking down how factors are added, modified, or deleted, organizations prevent attackers from self-serving their way into accounts. AMPs can accomplish this protection by requiring:
A user to verify their identity using phishing-resistant factors before a new factor is added (to accomplish this, new user accounts could be bootstrapped using pre-registered physical security keys)
The requesting party to be on a managed device
The use of a third-party IdV service
The requesting party to be on a trusted network
If you can’t outrun AI, limit its attack paths
Attempting to outpace AI-driven exploitation with reactive defense is a losing battle. As Provos noted in follow-up work on AI threats, security teams should focus on using security invariants to limit attack paths rather than trying to defend at machine speed.
By combining mandatory user enrollment with strict phishing-resistance policies across both app sign-in and account management flows, organizations create an architectural barrier that holds firm regardless of how fast or automated an attacker's tools become.
This content is for informational purposes only, does not constitute professional advice, and is provided without warranties or liability; please consult your own advisors for implementation decisions.
