QR Code Authentication: How It Works, Benefits, and Best Practices

What Is QR Code Authentication?

QR code authentication is a passwordless sign-in pattern where a website or application displays a unique, time-limited QR code and the user confirms the login on a trusted device, typically their phone, by scanning the code and approving the request. The QR itself is not a password; it is a one-time, short-lived challenge that binds the device you scan with to the browser session in front of you. In plain English: the site shows a code, you scan it with an app you already trust, you approve with biometrics or a PIN on your phone, and a secure session is established on the browser that showed the code. This flow removes the need to type usernames and passwords and dramatically reduces exposure to phishing and credential stuffing because nothing reusable crosses the network.

There are two dominant models in practice. The first is app-mediated QR login, commonly used when you want to log in on a desktop or kiosk. The desktop page renders a dynamic QR that encodes an ephemeral session identifier or challenge. You scan it with a mobile authenticator, such as the WWPass Key App, and approve locally (e.g., Face ID, fingerprint, or a PIN). The authenticator cryptographically signs the challenge and sends the response to the server, which validates it and upgrades the browser session to “authenticated.” The QR expires quickly, can be used only once, and carries no sensitive personal data by design.

The second is passkey-based cross-device sign-in, which relies on WWPass/WebAuthn passkeys and a proximity signal (often Bluetooth) to bootstrap an authentication ceremony across devices. In this model, you initiate sign-in on the laptop, it displays a QR to “handshake” with your phone, and your phone’s platform authenticator (secured by biometrics or PIN) performs a WebAuthn assertion for the site. This is the pattern standardized as hybrid transport (sometimes called caBLE) in WebAuthn, and it’s the foundation of modern “use your phone to sign in on this computer” experiences. WWPass supports cross-device, QR-bootstrapped login via its WWPass Key App, using an origin-bound one-time challenge that your phone signs to complete authentication.

If you’re evaluating solutions, it’s worth understanding how a provider designs the QR. For example, in WWPass’s approach the QR only contains a random, server-side session ticket, never personally identifying information, so scanning it does not leak secrets and the code is worthless after it expires. This is an important design choice for phishing resistance and privacy. For a concrete overview of WWPass’s user flow and recovery model, see the [WWPass Key App] page and the implementation notes in their developer documentation.

How QR Code Authentication Works

In an app-mediated flow, the desktop browser requests an authentication challenge. The server creates a unique, unpredictable token and ties it to a pending session, encoding only that token in a QR displayed on the page. The user opens the trusted mobile authenticator and scans the QR. The mobile app resolves the token back to the server origin, displays a human-verifiable prompt (“Sign in to example.com?”), and requires user presence and user verification, for example, a biometric or PIN. The authenticator then produces a signed response binding the one-time token to the correct relying party and sends it to the server over a mutually authenticated channel from the app. The server validates the signature, ensures the token is unused and unexpired, and flips the desktop session to authenticated. Because the token is one-time-use and short-lived, replay fails; because the approval happens in a trusted app tied to the origin, just pointing a camera at a code on a malicious site does not grant access. WWPass documents this pattern clearly: the QR is a dynamic session ticket, cryptographic operations happen on the user’s device, and no reusable credentials are transmitted. [Tired of passwords? A QR is the easiest way to log in] explains the user journey, while the [WWPass FAQ] clarifies the security properties of the QR payload.

In a passkey cross-device flow (for instance, when you choose “Use a phone” on a laptop that lacks a built-in authenticator), the relying party initiates a WebAuthn ceremony. The laptop displays a QR that helps establish a secure association with your phone. Your phone and laptop use Bluetooth proximity to prove the devices are near each other; your phone performs the WebAuthn assertion using a passkey scoped to the site’s relying party ID (the registrable domain). The assertion is origin-bound, signs a server-provided challenge, and returns attested public-key data to the website. This hybrid transport pattern is captured in WebAuthn’s evolving specifications and explained in developer resources; it exists specifically to make cross-device sign-in seamless without copying secrets between devices. Yubico’s technical notes describe how security keys complement hybrid flows, while reference articles detail how QR and Bluetooth cooperate to maintain phishing resistance.

Many users encounter QR authentication daily without noticing it. When you “link a device” in WhatsApp Web, you scan a QR from your phone to authorize the desktop. WhatsApp’s documentation emphasizes that you scan a QR displayed on the desktop and confirm on your primary phone, after which the desktop becomes a linked device for your account. This is a textbook example of app-mediated pairing through QR: the QR bootstraps trust, your phone approves, and the desktop session is granted access based on that approval.

A practical detail for architects: expiration windows for QR challenges should be tight, and servers must enforce one-time semantics. The QR content must never include secrets that can be replayed elsewhere, and any authentication assertion must be bound to the intended RP origin. The WebAuthn specifications codify the RP ID and origin rules precisely so an assertion made for login.example.com cannot be replayed at attacker.example.net. These guardrails matter because QR patterns are visually simple and familiar; the security comes from the cryptographic ceremony behind the scenes rather than the barcode itself.

Security Posture: Strengths, Risks & Mitigations

The chief strength of QR code authentication is that it eliminates passwords and SMS codes from the visible user journey. No passwords means no password reuse, no credential stuffing, and a vastly smaller phishing surface. When implemented with passkeys/WebAuthn, the authentication is phishing-resistant by design: the authenticator signs a challenge scoped to the site’s RP ID, which is useless on a look-alike domain. This architectural shift is why the industry is rapidly standardizing on passkeys. Google, for instance, made passkeys the default option for personal accounts, highlighting both usability and resistance to phishing compared with passwords and OTPs. These moves reflect a broader transition away from passwords and from fragile second factors like SMS.

The risk profile of QR authentication is different from passwords. The most cited threat is QRLJacking, a social-engineering attack where an adversary tricks a user into scanning a malicious QR that actually authorizes the attacker’s session. Like all phishing, it relies on confusing origin and context. If the QR contains a valid session ticket for the attacker’s browser and the user scans it and approves without noticing the mismatch, a hijack can occur. This is not a flaw of QR codes per se; it’s a failure to bind the scan/approval to the correct origin and to make the human approval step meaningful. OWASP’s discussion of QRLJacking highlights that applications must treat “login with QR” as a privileged flow that deserves careful UX and protocol design, not just a convenience add-on.

Mitigations map directly to phishing-resistant principles. First, enforce origin binding so that an approval in the app is always shown with the relying party name and only results in an assertion for that origin; WebAuthn does this intrinsically by scoping credentials to RP IDs. Second, use signed, one-time challenges and short expirations so any captured token has no value. Third, require explicit user presence and verification, a biometric or PIN in the app, so a background scan cannot auto-approve. Fourth, bind approvals to the displayed session by reflecting context in the app (“Sign in to example.com on Chrome for Windows?”) and, when feasible, proximity via Bluetooth so remote abuse is harder. Fifth, prefer device-bound credentials (hardware keys or platform passkeys) to remove the risks associated with shared secrets. Finally, ensure that push confirmations in the app are sparse, high-signal, and resistant to “MFA fatigue” (e.g., include a code or tap-to-match). Together, these controls elevate QR login from “scanning a barcode” to phishing-resistant multi-factor authentication.

Another important strength is resilience against SIM-swap and SMS redirection attacks. Because modern QR and passkey flows do not rely on text messages, they avoid a whole class of telephony-layer exploits. Investigations have shown how attackers can redirect SMS one-time codes with business messaging services, bypassing user awareness. Moving away from SMS-based second factors is a clear security win, which is why standards bodies and major platforms now recommend phishing-resistant methods.

Vendors that implement QR authentication thoughtfully will design the QR to be data-minimal. WWPass, for example, states that its login QR carries only a random session ticket, never personal data, and all cryptographic operations happen on the user device. This sharply limits the blast radius of QR capture and aligns with privacy-by-design principles. Pair that with short timeouts and one-time semantics and you mitigate the most realistic abuse scenarios while preserving the delightful “scan and go” user experience. [Not all authentication QR codes are created equal] breaks down why the contents of a QR matter.

Compliance & Standards Alignment

From a compliance standpoint, the north star is NIST SP 800-63B. At AAL2 and above, verifiers must offer a phishing-resistant authenticator option. WebAuthn passkeys meet this bar because they use public-key cryptography scoped to a relying party, with user presence and verification. AAL3 raises the assurance further by requiring a non-exportable key and phishing-resistant authenticator, which hardware security keys and certain platform authenticators fulfill. For enterprises mapping QR flows to NIST, the most robust posture is to deploy passkey-backed, origin-bound QR ceremonies that achieve at least AAL2 with phishing resistance, and to use AAL3 where the risk profile requires it. Microsoft’s Entra guidance mirrors this interpretation in practical deployments: aim for AAL2 + phishing resistance at minimum.

It’s also worth noting how the WebAuthn standards ensure trust. Credentials are RP-scoped; assertions include the challenge, RP ID, and origin; and authenticators enforce user presence/verification. Those design elements are why passkeys are considered phishing-resistant by default in government and industry guidance. When QR is used purely to bootstrap a WebAuthn ceremony across devices, you inherit these guarantees while keeping the flow familiar to users.

If your use case involves regulated environments or frameworks beyond NIST, financial services, public sector, or UK Cyber Essentials, the same pattern applies: prefer passkeys/WebAuthn or cryptographic, device-bound authenticators over SMS and OTP. For organizations prioritizing audit-friendly implementations, vendors that publish developer docs, protocol details, and recovery processes provide better trust signals for security due diligence. WWPass maintains public documentation and product pages explaining how QR login, MFA, and SSO operate without passwords; linking to those materials in internal runbooks makes audits smoother. [WWPass Multi-Factor Authentication] and [WWPass for Developers] are good starting points to evaluate fit and controls.

Business & Consumer Use Cases

Workforce SSO and kiosks. QR authentication shines anywhere users can’t or shouldn’t type passwords. In frontline, warehouse, point-of-sale, or shared workstation scenarios, a desktop or kiosk can present a QR, the employee scans with their phone, approves once, and lands in an SSO-backed portal. Because the login is phishing-resistant, you reduce both credential theft and help-desk resets. Vendors like WWPass offer passwordless SSO for web and mobile with support for standards (OIDC/SAML), making it easier to retrofit existing apps without rewrites. If you’re planning such a rollout, evaluate the end-to-end user journey, recovery, and how guest/contractor access is handled. [Passwordless SSO for Web & Mobile Apps] describes one approach to integrating passkeys and QR into enterprise SSO.

Shared and guest devices. In hospitals, labs, libraries, and conference venues, the device in front of you is not “yours.” QR flows allow account portability without leaving secrets on the shared machine. Because the approval happens on your personal device, you can authenticate quickly, and when the session ends there’s nothing to steal. A well-designed QR scheme with short expirations and app-mediated approval is ideal for such transient access.

Retail and PoS. Sales associates often need to authenticate frequently on terminals. Removing typed credentials reduces shoulder surfing and speeds throughput. A QR flow that pairs with a personal authenticator app meets both goals while providing audit trails tied to user presence.

Banking and fintech. These sectors are moving away from SMS and phone-centric OTPs due to SIM-swap and redirection risks. A passkey-backed QR login checks both boxes: strong cryptography and a familiar user gesture. Given regulatory pressure to demonstrate phishing resistance and strong customer authentication, this pattern helps satisfy both security and compliance teams. Industry coverage and platform updates over the last two years underscore the momentum behind passkeys for sensitive accounts.

Messaging apps. A canonical example of app-mediated QR login is WhatsApp Web. The desktop displays a QR; your primary phone scans and authorizes; the desktop is added as a linked device. Users love the convenience because no typing is required, and the mobile app is the authoritative place where you approve access. Engineers love it because the QR carries only the information necessary to pair the session with the account, and approvals remain under the user’s control. If you’re designing a similar pattern, study WhatsApp’s link a device documentation to see how they communicate the steps and manage linked device lifecycle (including automatic disconnect after inactivity).

Bring-your-own-authenticator and vendor choice. Some enterprises prefer an authenticator app from an identity vendor; others adopt platform passkeys to lean on built-in OS support. Many do both. QR can serve as the unifying front door: the code on the desktop starts the ceremony, and the user’s chosen authenticator completes it. WWPass, for instance, emphasizes that the QR should be dynamic and data-minimal and that cryptographic operations happen on the user device. If you favor this model, evaluate the WWPass Key App for workforce logins, SSO, and recovery flows, and ensure your policies cover lost device scenarios as described in vendor docs. [WWPass Key App] provides an overview you can hand to pilot users.

Recovery and continuity. A recurring objection to passwordless is “What if someone loses their phone?” Modern implementations address this through secure recovery, backup authenticators, or roaming security keys as break-glass options. In cross-device passkey ecosystems, passkeys can sync across user devices with end-to-end encryption or be stored in hardware keys; hybrid transport then lets any of those authenticators sign in via QR on a new computer. For proprietary authenticators, evaluate the provider’s recovery design, WWPass documents its recovery setup and replacement flows for the Key App so that a lost phone does not become a business outage.

User experience and adoption. The magic of QR authentication is that it feels instant without sacrificing assurance. Users already know how to scan QR codes; the difference here is that scanning triggers a high-assurance cryptographic ceremony instead of just opening a link. As platform vendors have elevated passkeys, including defaults and large-scale rollouts, the friction to adopt phishing-resistant login has dropped dramatically, and the QR-plus-phone pattern gives organizations a simple migration path that avoids retraining users to type new credentials.

Implementation Patterns

Pattern A: App-Mediated QR Login

Design the desktop experience so that every browser tab that requests “Sign in with QR” receives a fresh, per-session and per-browser QR. Under the hood, your backend should mint a high-entropy, single-use nonce, wrap it in a server-side state object that stores the pending session, the intended relying-party origin, and the browser context, and then encode only the opaque reference to that state, never secrets, into the QR. Treat the QR as a pointer rather than a payload. When the page renders, start a short expiration timer and rotate the QR on view and on interval so the code always represents a live, unique challenge. This “pointer, not payload” principle is now common practice in cross-device authentication write-ups and passkey literature because it neutralizes code scraping: even if someone photographs a QR, without the bound state and a valid approval it is worthless.

On the mobile side, mutual trust between the app and your backend is essential. Don’t rely on anonymous calls from the scanner; instead, make the mobile authenticator establish a secure channel to your origin (for example, with certificate pinning and strong token binding) and fetch the pending challenge referenced by the QR. The app should render a human-verifiable prompt that names the relying party and the device context, “Sign in to example.com on Chrome for Windows?”, and require user presence and user verification with a biometric or PIN before producing any cryptographic response. When you approve, the app signs the one-time challenge and sends the signed result back to the backend over the authenticated channel. The server verifies the signature, enforces one-time use and short TTL semantics, confirms that the origin and browser context match what was displayed, and then upgrades the waiting desktop session to authenticated. What never appears inside the QR are reusable credentials, keys, or PII; the QR is simply the rendezvous for a cryptographic ceremony that lives in your app and on your server. This is exactly the security posture championed by modern passkey and cross-device flows, where the origin binding and the signed challenge do the heavy lifting, not the visible code itself.

In practical deployments, teams also bind the approval to the specific browser instance that displayed the QR. Do this by associating the pending state with a browser-local context, such as a just-in-time session seed minted in the page and transmitted to your backend at QR render, so that only the tab that requested the login can be upgraded. That context should be non-identifying and ephemeral to preserve privacy, but binding the approval to it hardens against races and relay abuse. Finally, when the server issues the authenticated session to the browser, it should do so by setting the secure session cookie or token only over the HTTPS channel that belongs to that tab; never attempt to “return” a session through the QR path or to the mobile device. This is the pattern you see in mature implementations that explicitly advise to never expose secrets in the QR and to let the server, not the QR, own session issuance and replay defenses.

Where you want a turnkey example to study or pilot, WWPass Multi-Factor Authentication and the WWPass Key App show an app-mediated QR login: the desktop shows a code, the app confirms with a biometric or PIN, and the site upgrades the session with no username or password in the flow. WWPass’s own docs emphasize QR as a short-lived ticket and keep the cryptography on the user device and server side, which is why this pattern is amenable to passwordless SSO and step-up scenarios without adding brittleness. If you need developer specifics, the WWPass for Developers quick start walks through registering a site, generating tickets, and integrating the scan-to-sign-in journey.

Pattern B: Passkey (WWPass) Cross-Device

When your product wants the best of both worlds, passkey-grade phishing resistance and the familiarity of scanning, you can run the WebAuthn ceremony across devices and use the QR to bootstrap proximity and association. The desktop initiates a standard WebAuthn challenge and displays a QR that encodes the information needed to discover and pair with the phone. The phone’s platform authenticator then performs the passkey assertion bound to your relying-party ID and origin and sends the signed result back to your backend; the backend verifies RP ID, challenge, and the user presence/user verification flags and finalizes the desktop session. Modern implementations leverage hybrid transport, often called caBLE or CDA, to combine QR and Bluetooth proximity so that the phone can prove it’s near the desktop, thereby raising confidence that the approval is for the intended session. This workflow is the essence of the WWPass Cross-Device Authentication pattern and is documented in standards and vendor guidance.

WWPass and WebAuthn materials clarify why this is phishing-resistant: the credential is RP-scoped; assertions include the server-provided challenge and the origin; and authenticators require explicit user interaction. You can frame this pattern to stakeholders as “use your phone’s passkey to sign in on your computer,” which matches the mental model users already have from consumer experiences, and then layer enterprise requirements like attestation and audit. The upshot for engineering is that your risk engine can treat a successful cross-device passkey assertion the same way it does any WebAuthn success, while your UX team can present the same “scan and approve” surface users find frictionless. WWPass deploys this idea in its ecosystem to deliver passwordless flows that are both friendly and verifiably strong; the Passwordless SSO for Web & Mobile Apps overview shows how QR-bootstrapped sign-in and passkeys coexist in real systems.

UX Best Practices

Treat the QR screen as a high-conversion, high-risk touchpoint. Begin with a concise, unambiguous call to action, “Scan with your company app”, and keep the hover help and a direct fallback close at hand: “No phone? Use a security key” or “Sign in with a passkey on this device.” Always include a visible countdown and an automatic refresh so users understand the code is live and short-lived; this both reassures them and conditions them that a stale code cannot be used. After a successful scan, show a post-scan confirmation on the desktop that reiterates the origin and device just approved the login, along with a dismissible reminder that only on-site codes should be scanned. This small education step meaningfully reduces susceptibility to quishing. Coverage across 2024–2025 documents a marked rise in QR-based phishing that capitalizes on users’ habituation; surfacing safety cues at the moment of scanning is a low-cost way to bend that curve.

Keep your error states and fallbacks humane. If Bluetooth or network conditions block a hybrid passkey flow, prompt users to try the QR scan again, switch to a roaming key, or move to a same-device passkey option if available. If your mobile app is the authenticator, render the approval prompt with the site’s verified name and domain and require a biometric or device PIN; back on desktop, clarify what just happened with a “Signed in on example.com from iPhone” toast. By anchoring approvals to explicit origins and mirroring context between the two screens, you blunt the very social-engineering tricks that QRLJacking relies on. OWASP’s summary of this attack class is simple: if you scan the attacker’s QR and approve it, they get your session. Your UX’s job is to make it obvious what you are approving, for which site, and where.

Finally, educate without slowing down. A single sentence beneath the code, “Scan only codes shown on this page; do not scan codes emailed to you”, counters the uptick in malicious QR use in SMS, PDFs, and posters. This isn’t fear, it’s hygiene, and it reflects the reality that carriers and messaging layers have been abused to reroute OTPs and deliver look-alike prompts. Your design should shift users to phishing-resistant flows and remove dependence on SMS entirely.

Buyer’s Checklist

For product leaders drafting RFPs or evaluating SDKs, insist on a phishing-resistant option, ideally WebAuthn passkeys and a proven cross-device flow, so your QR login isn’t just convenient but cryptographically anchored. Ask the vendor to demonstrate that each scan produces a one-time, short-lived QR tied to a server-side state and a specific browser session; that the approval is origin-bound; and that their server rejects replays and stale codes by design. Ensure the mobile app requires user presence and user verification via biometrics or a PIN for every approval, and probe how device binding or attestation is used to raise assurance, or when and why it is not, since attestation can have privacy and portability trade-offs. Verify you get complete audit logs with risk signals like IP, device class, geolocation hints, and whether proximity checks succeeded, so your SOC has the telemetry needed for incident investigation and adaptive policy. Finally, map the solution to NIST SP 800-63B authenticator assurance guidance and require SSO protocol support, OIDC and SAML, so you can integrate QR and passkeys across your application estate. The federal Phishing-Resistant Authenticator Playbook and the NIST 800-63B text are excellent baselines for this conversation because they describe exactly why verifier-impersonation resistance, RP scoping, and cryptographic proof of possession matter at AAL2 and require phishing resistance at AAL3. Vendors that speak this language fluently will be easier to land with your auditors.

If you want concrete artifacts to attach to your diligence notes, capture the vendor’s answers to seven questions: what phishing-resistant mechanisms are available; how the system guarantees per-scan one-time use; which fields tie the approval to origin and browser context; what exact user-verification signal the app requires; how devices are bound, paired, or attested and what the lifecycle looks like; what audit fields ship to your SIEM; and where the standards mapping and SSO integration documentation live. For WWPass specifically, you can review public materials describing passwordless MFA, the WWPass Key App user journey, and developer quick starts, which makes it straightforward to evaluate passkey and QR support together.

Case Snapshots

Consider an anonymized Cross-Device Passkeys rollout for a SaaS workforce application. Prior to the change, the company used passwords with SMS OTPs for step-up events; help-desk volume for resets and number changes was a recurring pain, and fraud teams flagged OTP fatigue attacks. The product team replaced typed credentials with a desktop QR that bootstraps a passkey ceremony on the phone using hybrid transport. On day one of the pilot, conversion improved because scanning felt instantaneous, and phishing simulations tanked because assertions were RP-scoped. Over the first quarter, the company observed a measurable cut in authentication-related tickets, and finance noted a corresponding drop in SMS spend because the primary and step-up events moved to biometric + passkey approvals inside the app. Technically, the shift amounted to verifying the standard WebAuthn properties, origin, challenge, user presence/verification flags, and instrumenting risk signals to flag anomalies like remote scans without Bluetooth proximity, while operations hardened recovery with roaming keys for break-glass. This is precisely what the WWPass Alliance, Yubico, and platform vendors describe as the right way to mix usability and assurance in hybrid flows.

For a consumer pattern, look at the WhatsApp Web model that millions already know. The desktop shows a dynamic QR, the phone scans it from inside WhatsApp, you confirm with a biometric or PIN, and the desktop becomes a linked device until you revoke it or go inactive. The QR is simply a rendezvous for pairing; the moment of trust lives in the phone, and the desktop receives access only after the owner approves. This is the archetype of app-mediated QR login: short-lived codes, explicit user presence, and clear device lifecycle controls. If you adopt a similar design in your product, borrow their habit of stating the steps plainly and letting users see and manage linked devices, because lifecycle UI is integral to security.

FAQs

Is QR code authentication secure? Properly implemented, yes. The QR itself is not the credential; it is a pointer to a signed, one-time challenge that your mobile authenticator answers only after verifying the relying party and collecting user presence and verification. That is why passkey-backed QR flows are considered phishing-resistant: the authenticator will only sign for the correct origin, and a stolen code has no value once it expires or without a valid approval. The caveat is that naive implementations can be phished via QRLJacking, where an attacker convinces a user to scan a malicious code that authorizes the attacker’s session. You neutralize that risk with origin-binding prompts, short TTLs, and never approving scans outside your site.

QR codes vs. SMS codes? They solve different problems, but for authentication, QR plus passkeys is materially safer. SMS traverses carrier infrastructure and can be silently redirected or hijacked; extensive reporting has shown that text-message management and forwarding services can be misused to intercept OTPs. QR-mediated flows, by contrast, do not depend on telephony; they rely on public-key cryptography and explicit user approval in your app or platform authenticator. The industry shift away from SMS is not theoretical, it is a pragmatic response to real routing and phishing abuse.

What standards should we follow? Anchor your implementation to WebAuthn and WWPass passkeys, and align your assurance posture to NIST SP 800-63B. WebAuthn gives you RP scoping, signed challenges, and user-presence/verification semantics; WWPass’s cross-device patterns describe how to pair phones and desktops without sacrificing phishing resistance; and NIST explains what constitutes AAL2 and AAL3, with AAL3 explicitly requiring phishing-resistant authenticators with non-exportable keys. If you can meet AAL2 with phishing resistance today, you will satisfy most enterprise risk appetites and be well positioned to scale to AAL3 where warranted.

Does this work offline? No. Authentication and verification require the mobile app and the website to talk to your backend so the signed challenge can be validated and the desktop session upgraded. You can cache UI and gracefully degrade, but the assertion exchange itself needs a network path.

Can we use it for step-up MFA? Yes. Because the mobile app or platform authenticator already enforces user presence and verification, you can trigger a QR approval mid-session to re-verify the user for a high-risk action. In a passkey world, that step-up remains passwordless: the user simply scans and approves, and your backend verifies another signed challenge for the same RP ID. This is a clean way to replace fragile OTPs with cryptographic, phishing-resistant checks while keeping friction near zero.