When should organisations use passkeys instead of push approvals?

When passkeys are the better default than push approvals

Passkeys are the better default when the sign-in step itself is the security decision you most want to harden. They raise the bar against phishing, adversary-in-the-middle interception, password reuse, and push fatigue, while also removing the recurring human prompt that users can be conditioned to approve. That makes them a stronger primary factor for everyday workforce access.

Push approvals still have a place, but they are better treated as a fallback or recovery path than as the main trust mechanism. If a user can authenticate with a passkey, there is usually little reason to keep asking them to approve routine logins through a channel that can be spammed, social-engineered, or confused with a real request.

What changes in the authentication model

Passkeys shift authentication from knowledge or approval to cryptographic possession plus device or platform binding. That matters because the attacker can no longer win by stealing a reusable secret or by pushing the user into clicking “accept” on a familiar prompt. For organisations that already rely on SSO, passkeys fit naturally as a stronger authenticator for the entry point into the identity stack.

Push approvals, by contrast, assume the user can reliably distinguish a legitimate prompt from an attack. In practice, that assumption weakens under fatigue, distraction, and repeated prompts. A push is not inherently wrong, but it is a weaker trust signal when the user is under pressure or when the attacker can generate enough noise to make approval feel routine.

Where each method fits in a real rollout

Use passkeys first for employee populations that face phishing pressure, remote access, executive accounts, helpdesk-heavy environments, and users who sign in often enough that prompt fatigue becomes a real operational problem. They are especially attractive where organisations want both lower friction and stronger resistance to account takeover.

Keep push approvals for edge cases: older devices, partial rollout periods, break-glass access patterns, or as a temporary step-up option while passkey adoption is still incomplete. The key judgement is not whether push is “secure enough” in isolation, but whether it is still the best default once passkeys are available for the same population.

Risk and Threat Considerations

Push approvals create a standing social-engineering surface because the attacker only needs one accidental approval or one rushed user interaction. That risk rises sharply when users receive repeated prompts, are conditioned by MFA fatigue, or are targeted with real-time phishing that mirrors the login flow.

Failure mechanism: The user accepts a malicious or spurious approval, or the attacker relays the session through a phishing page that makes the push look routine rather than exceptional.

Impact: The account is authenticated despite the attacker never knowing the password, which can lead directly to mailbox access, SaaS takeover, lateral movement, or token theft.

Practitioner Guidance

What to prioritise: Move the most exposed and most frequently used workforce applications to passkeys first, especially where password theft or push bombing has already been observed. Treat the remaining push path as a controlled exception rather than an equal option.

What to verify: Check that the passkey implementation supports your actual estate, including browser, device, recovery, and helpdesk flows. A stronger authenticator can still fail operationally if account recovery quietly reintroduces a weaker path.

Common mistake: Keeping push approvals as the default because they are familiar. Familiarity is not the same as assurance, and at scale the easiest prompt for users to understand is often the one attackers know how to abuse.

Practitioner takeaway: If passkeys are available for the user population and use case, make them the default sign-in method and reserve push for fallback, exception handling, or transitional coverage only.

Related resources from NHI Mgmt Group

• Should organisations use SSH certificates instead of long-lived keys?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?
• When should organisations block an AI agent instead of letting teams use it?
• Should organisations use HITRUST instead of HIPAA?