When should organisations combine passkeys with other identity verification checks?

When passkeys are enough, and when they are not

Passkeys are strongest as a phishing-resistant sign in method, not as a universal proof that every subsequent action is safe. They reduce credential theft and replay, but they do not answer questions like whether the user is new, whether the account was recently recovered, or whether the requested change has high fraud impact. For those situations, organisations should treat passkeys as one assurance signal in a broader identity decision.

That distinction matters because a passkey confirms possession of a bound authenticator, not necessarily the legitimacy of the transaction. A low-risk login can often rely on the passkey itself, while a high-impact workflow should add step-up checks that reflect the sensitivity of the action, the account history, and the business consequences if the request is fraudulent.

For teams rolling out passwordless authentication, the practical question is not “Does the user have a passkey?” but “What risk is created by letting this authenticated user proceed?” The strongest design keeps passkeys at the centre of sign in, then layers additional checks only where the action changes recovery, payout, contact, or entitlement state.

Which workflows justify extra verification?

Additional verification is usually warranted when the workflow materially changes trust, money, or access. Common examples include account recovery, adding a new device, changing payout instructions, changing the email or phone number used for recovery, or modifying access entitlements. These are precisely the moments when an attacker who has gained partial access can convert a good sign in into a durable takeover or financial loss.

New users and newly established accounts also deserve more scrutiny because there is less behavioural history to compare against. A passkey can still authenticate the user, but the organisation may not yet have enough confidence in the relationship to rely on a single factor for high-value actions. That is especially true where onboarding, identity proofing, and transaction history are still thin.

Passkeys also need reinforcement when the organisation allows delegated or assisted flows, such as help desk recovery, payout changes requested through support, or an admin action that affects privileges. In those cases, the risk is often not the login itself but the transition from authenticating a person to authorising a consequential change.

How to apply layered assurance without overcomplicating the user journey

Good practice is to match the second check to the risk of the action, not to use the same challenge everywhere. A routine login may only need the passkey, while a sensitive change may require a fresh device check, a verified recovery channel, or a stronger identity proofing step. That keeps friction proportionate and avoids training users to expect friction on every action.

Organisations should also separate authentication from decisioning. A passkey proves the user can authenticate, but the business rule decides whether the requested action should be allowed immediately, delayed, reviewed, or stepped up. That separation helps security teams avoid the common mistake of equating strong sign in with full transaction trust.

For NIST SP 800-63 Digital Identity Guidelines, the key idea is assurance: stronger authenticators support stronger sign in, but different transactions can still require different assurance outcomes. Organisations that want a practical rollout model can also use the OWASP ASVS view of authentication, session, and access control as separate concerns rather than one control. The same pattern appears in Passwordless and Passkeys Guide, which covers phishing-resistant sign in and the need to design recovery carefully.

Risk and Threat Considerations

Passkeys materially reduce phishing and credential replay, but they do not stop social engineering, account recovery abuse, or fraud in high-value workflows. The main residual risk is that an attacker or impostor who gets past initial authentication can still use a trusted session, a weak recovery process, or a poorly protected change request to move the account toward takeover or monetisation.

Failure mechanism: The control fails when organisations treat passkey authentication as sufficient proof for every action, including recovery and entitlement changes. Attackers then target the weakest downstream step, such as support-assisted reset, contact detail update, or payout redirection, instead of trying to defeat the passkey itself.

Impact: The result can be account takeover, fraudulent payouts, privilege escalation, or loss of recovery control. The larger the business consequence of the action, the more important it is to add a second, context-aware verification step.

Practitioner Guidance

What to verify: Check whether the user is performing a routine sign in or a sensitive state change. If the action changes recovery, money movement, or entitlements, require a stronger step than the passkey alone and make the approval path explicit.

Decision rule: Use the passkey as the primary authenticator, then step up when the requested action increases blast radius. If the transaction would be hard to reverse, hard to observe, or costly to dispute, do not rely on sign in strength alone.

Common mistake: Teams often hard-code one policy for all authenticated users. That is usually too weak for recovery and payout flows, and too burdensome for ordinary access, so the result is either unnecessary friction or preventable fraud.

Practitioner takeaway: The right design is layered assurance, with passkeys protecting authentication and a separate risk decision protecting the transaction.

Related resources from NHI Mgmt Group

• How should organisations combine identity verification and AML checks in fast-growing payments or fintech environments?
• How do organisations decide when to add database verification, custom checks, or face authentication in identity verification?
• How should organisations implement document-free identity verification without weakening fraud controls or compliance checks?
• How should security teams combine bank-based verification with identity document checks for onboarding at scale?