5 Billion Passkeys and Still Phishable: The MFA Fallback That Undoes Your Whole Rollout

Five billion passkeys are now in active use worldwide, and 68% of organizations are deploying, piloting, or rolling them out for employee sign-ins, according to the FIDO Alliance’s 2026 report. That’s meaningful progress, but adoption figures alone don’t tell you whether your organization is actually protected from phishing.

The critical question is what happens when someone can’t use a passkey. If a sign-in policy still accepts a phishable fallback, an attacker may simply choose that weaker route instead.

Phishing resistance is only as strong as the methods your policies still allow. A successful passkey rollout requires more than enabling a new credential. It takes deliberate enforcement, secure recovery, and a plan for the systems that aren’t ready to modernize.


WHY PASSKEYS STOP RELAY PHISHING

Passwords and one-time codes can be captured and relayed. An attacker-in-the-middle (AiTM) phishing site, for example, can sit between a user and a real sign-in page, collecting credentials and sometimes session information as the user interacts with what appears to be a legitimate login.

Passkeys work differently. They use public-key cryptography, and the authentication response is bound to the legitimate website’s origin. The specific domain the user is visiting. A credential created for the real sign-in domain won’t authenticate on an attacker’s lookalike domain. That origin binding blocks the credential-relay step that makes many AiTM attacks work.

That protection is powerful, but it applies when the user authenticates with the passkey. If a policy also accepts SMS codes, voice calls, authenticator codes, or an approval prompt that can be manipulated, an attacker may try the alternative instead. Those options are not all equally risky, but they do not provide the same origin-bound protection as passkeys.

A phishing-resistant method is not a phishing-resistant policy if users can bypass it with a weaker method.

THE 2026 DEADLINE MAKES THIS OPERATIONAL

Microsoft Entra ID’s move toward passkeys is already underway. Starting September 1, 2026, users enabled for Microsoft-provided SMS or voice authentication are automatically enabled for passkeys and prompted to register when they next complete MFA. Microsoft’s documentation says the registration prompt is a nudge; it does not mean that every user has completed enrollment.

Starting February 1, 2027, Microsoft-provided SMS and voice authentication is scheduled to retire for most users. Global Administrators and external users have a later retirement date of July 1, 2027; internal guest users remain in the February group. Organizations that continue to need telephony authentication must plan for a supported provider. Review Microsoft’s SMS and voice retirement timeline and don’t assume automatic passkey enablement means your users are ready.

There’s also growing compliance and insurance pressure. For HIPAA-regulated organizations, the current Security Rule requires procedures to verify the identity of people seeking access to electronic protected health information. It does not establish a new, blanket MFA mandate effective in 2026. However, a documented risk analysis may show that stronger authentication is necessary for particular systems or access paths. See the current HIPAA technical safeguards and HHS guidance on MFA and risk analysis.

Cyber insurers also commonly ask organizations to demonstrate that MFA is enforced for important access, such as administrator accounts and remote access. Requirements differ by carrier and policy. A simple statement that “MFA is enabled” may not show which users, applications, or exceptions are covered. Be ready to document enforcement scope and any approved gaps.


BUILD A PHASED ROLLOUT, AND ENFORCE THE STRONGER METHOD

A phased approach helps protect high-impact accounts first while giving users and support teams time to adapt.

  1. Inventory authentication before changing policy. Identify users who rely on SMS or voice, privileged roles, sensitive applications, legacy systems, shared workstations, service accounts, and recovery processes. Find out which users have registered phishing-resistant credentials, and where a fallback can still be used.
  2. Enable FIDO2/passkeys with identity-based groups. In Microsoft Entra ID, configure the authentication methods your organization supports and group users by role and readiness. Follow Microsoft’s phishing-resistant authentication deployment guidance to plan pilots, credential registration, Conditional Access enforcement, and user communications.
  3. Protect administrators and sensitive access first. Use Conditional Access authentication strengths to require phishing-resistant MFA for privileged roles and high-impact applications. Test the policy in report-only mode, review which sign-ins would be blocked, remediate readiness issues, then enforce it for a pilot group before widening coverage.
  4. Match credentials to the work. Hardware FIDO2 keys are a practical choice for administrators, highly regulated users, and shared workstations. For general staff on individually assigned devices, platform authenticators such as Windows Hello for Business and Touch ID can make secure sign-in straightforward. Users should have a second suitable method available in case a device is lost or unavailable.
  5. Make recovery secure before removing old options. Establish identity verification and a controlled recovery process before deprecating passwords or phishable factors. In Entra, an administrator-issued Temporary Access Pass (TAP) can be used to bootstrap a replacement credential. Restrict who can issue one, verify the requestor through a separate trusted channel, set an appropriate lifetime, and audit issuance and use.

Then remove SMS, voice, and other phishable methods from the sign-in paths where phishing-resistant MFA is required. Don’t keep an old method active “just in case” without determining whether a user can select it to bypass the intended control. If temporary exceptions are necessary, document the business reason, limit the scope, add compensating controls, and set an owner and review date.

HANDLE LEGACY SYSTEMS AND BREAK-GLASS ACCOUNTS DELIBERATELY

Some older applications, protocols, or infrastructure may not support modern authentication. Treat each as a specific technical exception, not as a reason to weaken the identity policy for everyone.

First, identify the application and its users. Then assess whether it can be upgraded, replaced, or placed behind a modern identity-aware access layer. Where that isn’t immediately possible, isolate access through a controlled network path or managed jump host, restrict accounts and permissions, monitor activity, and create a dated migration plan. Compensating controls reduce exposure; they do not make the legacy system phishing-resistant.

Break-glass administrator accounts also need special handling. Maintain only the emergency accounts needed for recovery, protect their credentials separately, tightly restrict access, and alert on every use. Test them on a planned schedule so they work during an outage, but don’t exempt them from monitoring or allow routine use. Review who can access the credentials, where they are stored, and how the organization will investigate an emergency sign-in.

KEEP WATCHING AFTER ENROLLMENT

Passkeys make credential phishing much harder. They don’t eliminate every identity risk. Attackers may still target session tokens, steal credentials from compromised devices, exploit weak recovery procedures, or use suspicious access patterns to conceal unauthorized activity.

Monitor authentication and identity events for unusual sign-in locations, repeated failures, unexpected method changes, risky sign-ins, suspicious session behavior, and activity involving privileged accounts. Where available, use controls such as Conditional Access token protection to help reduce token replay risk. Keep sign-in logs available for investigation, and make sure someone is responsible for reviewing and escalating meaningful anomalies.

Cenova Cyber’s 24/7 security monitoring combines security telemetry, alert investigation, and analyst-led response to help organizations detect and investigate authentication anomalies and possible session token theft. Our vCISO services can help build an identity roadmap that aligns rollout priorities, policy enforcement, recovery, exceptions, and evidence with your business and compliance needs.

CLOSE THE FALLBACK GAP

Passkeys are a major step forward, but deploying them is only the beginning. Review what your sign-in policies accept, secure recovery before removing older methods, and make exceptions visible, limited, and temporary.

Contact Cenova Cyber for a free identity security assessment. We’ll help you identify where phishable methods remain, prioritize your rollout, and map practical next steps for stronger identity protection. Talk with our team.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top