Phishing-Resistant MFA with Entra Passkeys: Retiring App-Based Approvals

Multi-factor authentication has become a baseline expectation across Australian government, aged care, and enterprise environments, yet not all methods carry equal weight against determined adversaries. Push-based approvals delivered through a mobile authenticator represented a meaningful improvement over passwords alone, and many organisations deployed them widely to satisfy earlier maturity requirements. As attacker techniques have advanced, however, these prompt-based approvals now sit at the weaker end of the authentication spectrum, and they no longer meet the strongest tier of controls expected for privileged access.

The Essential Eight Maturity Model draws a clear line between MFA that resists phishing and MFA that does not. For organisations targeting Maturity Level Three, particularly for administrator accounts, the direction of travel is towards phishing-resistant methods bound to a physical device. Microsoft Entra passkeys offer a practical, Microsoft-native way to make that transition, and understanding the migration path helps technical teams plan the change without disrupting their user base.

Why push-based approvals no longer meet the strongest tier

A push notification sent to Microsoft Authenticator asks a person to approve or deny a sign-in attempt, and this design depends on the user making a correct decision under pressure. Adversaries exploit this human dependency through techniques such as MFA fatigue, where they trigger repeated prompts until a tired or distracted user eventually approves one. Real-time phishing proxies present a further problem, because they can relay a legitimate credential and approval through an attacker-controlled site, capturing the resulting session even when the second factor appears to function normally.

Number matching and additional context in Microsoft Authenticator have reduced some of these risks by requiring the user to type a value shown on the sign-in screen. These improvements raise the difficulty of blind approvals, but they do not change the underlying architecture, because the authentication is not cryptographically bound to the origin of the request. For accounts that hold elevated privileges, this residual exposure is the reason assessors increasingly expect a method that removes the possibility of relayed or coerced approval altogether.

How Entra passkeys deliver phishing resistance

Passkeys in Microsoft Entra ID are built on the FIDO2 and WebAuthn standards, and they replace the shared secret model with public-key cryptography. During registration the authenticator generates a key pair, retaining the private key on the device and registering only the public key with Entra. When the user signs in, the device proves possession of the private key without ever transmitting it, and the browser enforces that the credential can only be used with the legitimate service origin.

This origin binding is what makes the method phishing-resistant, because a credential registered for a genuine tenant will not respond to a fraudulent look-alike domain operated by an attacker. Entra supports passkeys in several forms, including device-bound passkeys held on a hardware security key and passkeys stored within Microsoft Authenticator on a registered mobile device. For the highest assurance on administrator accounts, many organisations favour hardware security keys, because the private key remains isolated on dedicated tamper-resistant hardware and cannot be exported or synchronised elsewhere.

Planning the migration path

A considered migration begins with visibility rather than immediate enforcement, so teams should first review which accounts currently rely on push approvals and which of those hold privileged roles. Administrator accounts, break-glass accounts, and service management identities warrant priority, because they present the greatest impact if compromised and are the specific focus of the strongest maturity expectations. Documenting existing authentication methods per account, along with the devices in use, provides the baseline needed to plan registration and to identify users who will require hardware security keys.

With that picture established, the practical work involves enabling passkey methods in the Entra authentication methods policy and defining who may register them. Conditional Access then becomes the mechanism that raises the bar, because authentication strength policies can require a phishing-resistant method for sensitive applications and for privileged role activation through Privileged Identity Management. A phased approach that enrols administrators first, verifies the experience, and only then extends enforcement to broader groups reduces the risk of lockout and gives the service desk time to prepare.

Operational considerations for a durable rollout

Registration logistics deserve early attention, particularly where staff work across multiple sites or in field settings common to aged care and government service delivery. Distributing and enrolling hardware security keys requires a repeatable process, and organisations should plan for spares, replacement procedures, and a clear owner for the inventory. Retaining a small number of securely stored break-glass accounts with their own phishing-resistant credentials protects against the scenario where a policy change or directory issue blocks normal administrative access.

Retiring push approvals should follow, not precede, confirmation that passkeys are working reliably for the relevant population. Once phishing-resistant methods are enforced and adopted, teams can tighten the authentication methods policy to remove weaker options for privileged accounts, and monitoring sign-in logs helps confirm that legacy methods are no longer in active use. Treating the change as an ongoing programme rather than a single project supports the continuous improvement that maturity uplift demands, and it keeps administrator authentication aligned with evolving guidance.

References

• ACSC Essential Eight Maturity Model
• Microsoft Entra passwordless authentication overview
• Enable passkeys (FIDO2) for Microsoft Entra ID