How should security teams decide whether QR-based passkey flows are acceptable?

Where QR-based passkey flows fit, and where they do not

QR-based cross-device passkey flows are a usability pattern, not a security guarantee. They are usually acceptable when the organisation is comfortable with a second device approving the sign-in and with the residual risk that the user may be lured into approving a legitimate prompt at the wrong moment. The decision should be driven by assurance requirements and by how much trust you place in the user’s ability to recognise context.

In practice, the key distinction is whether the QR flow is the primary path or merely a convenience path. For consumer or employee sign-in where phishing resistance is the main goal, the underlying passkey standard still matters, but the user journey can change the attack surface if the browser, device, or site context is weak. NIST SP 800-63 Digital Identity Guidelines helps teams tie that choice back to authenticator assurance and phishing resistance rather than to product defaults. NIST SP 800-63 Digital Identity Guidelines

For teams rolling out passkeys more broadly, it helps to think of QR handoff as an approval ceremony. If the ceremony is easy to understand, device-bound, and tied to a known origin, it can be a reasonable UX trade-off. If it becomes a generic “approve this on another device” habit, the assurance gap grows and the flow can become a social-engineering target rather than a strengthening control.

What makes QR passkey approval safer or riskier

The security question is not whether QR is inherently bad, but whether the approval step preserves the properties you are trying to achieve with passkeys in the first place. Device-bound registration and strong origin binding reduce the chances that a remote attacker can turn a user’s convenience flow into delegated access. Where the environment allows synced passkeys, shared devices, or fallback methods, the practical assurance level may be lower than the headline “passkey” label suggests.

Teams should also separate authentication strength from recovery and fallback design. A QR passkey flow can be reasonable while recovery is weak, but the overall account security is only as strong as the weakest path into the account. That is why the rollout view in Passwordless and Passkeys Guide is useful for practitioners deciding between platform passkeys, synced passkeys, and device-bound options.

One practical rule is to treat any flow that allows an approval on a second device as higher-friction, higher-context security. That extra context is helpful when users are attentive, but it also means the control depends on the user recognising the request as legitimate. If your users are exposed to phishing, help-desk abuse, or session theft pressure, that dependence becomes a real control consideration rather than a minor UX detail.

How to choose an acceptable passkey pattern

Decide by the assurance you need, the adversary you are defending against, and the fallback paths you are willing to support. If the environment can tolerate a usability-first approach, QR-based cross-device sign-in may be acceptable as part of a well-instrumented passkey rollout. If you need higher assurance, prefer device-bound registration and avoid hybrid fallback unless you can constrain it tightly and monitor it carefully.

A useful design check is whether the flow still works if the user is under mild deception. If the answer is yes, but the action remains bound to the intended device and origin, the flow is usually defensible. If the answer is yes because the user can be tricked into approving a nearby QR-driven request from a malicious site or link, the flow is too dependent on user judgement to be your highest-assurance option. The broader passkey guidance in Workforce Identity Security Guide is a useful reference when the question is how sign-in ergonomics affects phishing resistance at scale.

When the question is sensitive authentication rather than general convenience, teams should compare the QR flow against the stronger baseline, not against passwords or SMS. That comparison keeps the conversation focused on whether the added approval path is genuinely necessary, or whether it is simply a legacy UX compromise that weakens the assurance story.

Practitioner Guidance

What to verify: Confirm that the QR flow is still bound to the right origin, that the second-device approval cannot be reused outside the intended session, and that recovery does not silently reintroduce a weaker path. If any of those conditions fail, the flow is not just a usability choice, it is an assurance downgrade.

Decision rule: If the account or action needs high assurance, use device-bound passkeys and minimise fallback. If the business accepts a moderated assurance level for better adoption, allow QR-based cross-device flows only as a controlled convenience path, not as the only mature path in the stack.

Common mistake: Treating “passkey” as a single security state. In reality, cross-device flows, synced passkeys, and recovery choices can produce very different risk profiles even when the same passkey label appears in the UI.

Practitioner takeaway: QR-based passkey flows are acceptable when the threat model allows an extra user approval step, but they should be rejected where assurance depends on removing that human judgement from the attack path.

Related resources from NHI Mgmt Group

• How do security teams decide whether cookie-based auth is acceptable for a web app?
• How should security teams decide whether to keep a legacy SEG or move to an API-based email security model?
• How do security teams decide whether a self-service lifecycle flow is acceptable?
• How should security teams decide whether a trust service is acceptable for EU business?