Why passkeys aren't enough, and how to secure MFA reset and recovery

With push-based multifactor authentication (MFA), attackers could purchase or phish your password and one-time passcode (OTP), then spam you with push prompts until you finally approve one to make them stop. The MITRE ATT&CK® Matrix for Enterprise framework lists examples of MFA fatigue attacks from well-known cybercriminal groups, including Scattered Spider and LAPSUS$.

With passkeys, there’s no password or OTP to enter, nor a generic push to approve. Indeed, many organizations have adopted phishing-resistant authentication like passkeys, but these are just part of the solution.

This article will walk through those remaining vulnerabilities, why they exist, and how you can prevent them.

Passkeys: What they fix and what they don’t

Passkeys allow you to log in without passwords, using a public key stored with the website and a private key that stays on your device or in your password manager. When the website asks you to prove it’s really you, your device prompts you to unlock access to the passkey with your fingerprint, face, or PIN. It then sends a signature to the website as evidence of your verified identity.

There are advantages to this approach. You never type a password, removing the risk of attackers capturing it at the point of entry or in transit. The secret key never leaves your device, as the device uses the private key to sign the challenge without sending the key itself.

But as the adoption of passkeys grows, attackers are finding ways around passkey-based authentication to break into organizations and take over victims’ accounts.

Four entry points that attackers exploit to get around passkey authentication

Passkey-based authentication is often so secure that attackers have shifted the fight from stealing credentials to manipulating exception handling. Four of the primary exception paths are social engineering vulnerabilities during MFA changes, account recoveries, new device enrollments, and help desk calls. Here’s a closer look at how each one could open you up to an attack.

MFA changes

Attackers may add, remove, or modify users’ backup MFA methods. Examples include changing the phone number, swapping authenticators, or disabling an old authentication factor associated with the account.

If attackers can get the help desk to change an account’s MFA selection, they completely bypass the existing MFA requirement. The risk is especially high for privileged accounts, where a fraudulent MFA reset or reenrollment can give an attacker access to sensitive systems and administrative privileges.

Because the attacker controls the session and device during reenrollment, they can set up a new authenticator, or even a passkey, and authenticate legitimately.

Account recovery

Attackers may exploit account-recovery flows when users cannot log in or remember credentials. Recovery flows are usually designed to allow users to gain access quickly, but should be at least as strong as normal login flows and designed to gather proof that the user is who they say they are.

New device enrollment

Attackers may attempt to enroll a device they control as an authenticator, creating a path into the account. Often, this starts with a claim that the original device was lost, stolen, or broken.

Many organizations treat the addition of a new device as a routine, low-risk occurrence rather than a security-sensitive event. But organizations should require proof that ties the person to the account before allowing a new device to bind as an authenticator. For high-risk roles, consider dual-control or independent approval for new authenticators.

Help desk social engineering

Attackers exploit help desks’ prioritization of speed and customer satisfaction. They pose as executives, lower-level employees, or contractors and emphasize the urgency of a request to bypass routine identity-related checks.

Any support action that touches MFA, passkeys, recovery, or privileged access should be viewed through a security lens. Help desk staff should receive training on social engineering techniques and be empowered to slow down or escalate a request instead of approving it based on the user’s title.

How has AI changed attack techniques?

Passkeys make it difficult to phish or fatigue users at the login page, but attackers are now using AI to impersonate employees and talk their way around controls. With its ability to scale, adapt, and mimic companies’ writing style and jargon, generative AI makes social engineering help desks easier. Attackers can also use it for voice modulation, video overlays, and deepfakes.

However, even when powered by generative AI, hackers don’t automatically control what happens when users need to change their MFA, get logged out of the system, or lose their phone.

So while passkeys secure the front door, attackers are now breaking in through the side. With more robust identity verification processes, organizations can better secure these high-risk touchpoints.

How can identity proofing stop MFA fatigue attacks?

Identity proofing doesn’t stop MFA fatigue, and it can’t keep an attacker who gains access from your systems from doing damage. But it can reduce the risk of account takeovers by requiring a high-assurance check when attackers try to skirt around passkey-based MFA requests.

Using identity verification as a step-up check before high-risk actions or requests can also help keep attackers who get an initial foothold from dealing serious damage.

In a nutshell, MFA fatigue allows an attacker through the front door. Identity proofing helps prevent them from sneaking in through a less-secure side door. And identity verification can keep them from getting into the safe in the basement.

Persona helps automate and secure account recovery

Persona helps organizations like Twilio, Cisco, Ro, and Legora keep their systems secure with strong identity checks during hiring, onboarding, and account recovery.

For example, many organizations use an ID and selfie check to automate identity verification before employees or contractors can reset MFA, enroll a new authenticator, or regain access to their account. Behind the scenes, Persona evaluates a variety of signals, such as geolocation inconsistency and device telemetry, to help verify that the person is who they claim to be.

Book a demo to see how Persona can help strengthen your IAM policies and automate high-assurance checks during critical moments.