Use passkeys when phishing resistance and user experience both matter, especially for workforce access that is frequently targeted by password theft and push spam. Passkeys remove password reuse from the equation and reduce prompt dependency. Push approvals should become a fallback method, not the default trust mechanism, where stronger options are available.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys and phishing-resistant auth are central to authenticator assurance decisions. |
| Recommendation — Use phishing-resistant authenticators and align assurance to the access risk. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question is about choosing a stronger workforce login authenticator. |
| IA-5 — Authenticator Management | Passkey rollout changes authenticator lifecycle, recovery, and fallback handling. | |
| IA-9 — Service Identification and Authentication | Passkey-style phishing-resistant authentication also informs machine and service auth design. | |
| Recommendation — Require stronger authenticators for workforce sign-in and reduce reliance on push-only approval. Manage authenticator issuance, recovery, rotation, and retirement with tighter controls. Apply stronger cryptographic authentication where systems or services must prove identity. | ||
| CIS Controls v8 | CIS-5 — Account Management | The choice affects how accounts are accessed and how unsafe defaults are phased out. |
| Recommendation — Prioritise phishing-resistant account access and remove weak default approvals where possible. | ||
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.