What is the FIDO:/ QR code my laptop is showing?

It's a cross-device passkey sign-in QR defined by FIDO CTAP 2.2 'hybrid' transport. Your laptop shows it during a passkey login flow when you don't have a passkey stored on the laptop itself — your phone holds the passkey and your phone scans the QR to complete the login.

What happens when I scan a FIDO QR with my phone?

Your phone reads the QR, opens a Bluetooth proximity check with whichever device generated the QR (to make sure the two devices are physically near each other), then runs the passkey signing operation. The result tells the laptop's browser that the passkey holder confirmed the login.

Can someone trick me into scanning their QR?

Yes — this is the central threat. An attacker tries to log into YOUR account on their own laptop. Their laptop shows a FIDO QR. They share that QR with you (a screenshot, a fake helpdesk page, a tech-support scam). If you scan it on your phone expecting to log into your own account, the result signs the attacker into your account on their laptop.

What's the Bluetooth proximity check protecting?

The proximity check requires your phone and the QR-displaying device to be within roughly 10 meters of each other (the BLE advertisement range). This prevents an attacker on a remote network from completing the sign-in — they would need to be physically near you. But proximity alone doesn't prevent the trick where the attacker is sitting next to you with their own laptop.

How is this different from WhatsApp Web's login QR?

Identical threat shape, different protocol. WhatsApp Web, Telegram Web, Signal Desktop, Steam Guard, Microsoft 365 sign-in, GitHub device flow, and several other services use service-specific URL-based QRs that route through their own servers. FIDO CTAP hybrid is the open-standard generalization — it works for ANY service that adopts passkeys, with the wallet on your phone holding the credential.

Standards · FIDO CTAP 2.2 hybrid (passkey QR)

Should I scan this passkey sign-in QR?

Only if YOU just started a passkey sign-in on the device showing the QR. If anyone else generated the QR — a stranger, a "helpdesk" agent, a tech-support call — scanning it on your phone signs them into your account, not you. The protocol's open standard (FIDO CTAP 2.2 hybrid) is solid; the threat is social engineering around who pressed the "Sign in with a passkey" button first.

Check a passkey QR → All standards →

How cross-device passkey sign-in works

A passkey is a credential — a public/private key pair — bound to one of your devices. If you registered a passkey for example.com on your phone, only your phone can sign the login challenge for example.com.

That works fine when you're signing in ON your phone. But what happens when you're signing in on a laptop that doesn't have a passkey for that site? You can:

Type your password — defeats the whole point of passkeys.
Enroll a new passkey on the laptop — fine, but only if you trust this laptop long-term.
Use the phone passkey via cross-device transport — the laptop shows a QR, your phone scans it, the phone signs the challenge, the laptop's browser receives the result and you're signed in.

Option 3 is what FIDO CTAP 2.2 "hybrid" defines. The QR is the bootstrap — it carries enough information for your phone to discover the laptop over Bluetooth Low Energy, establish a one-time secure tunnel, and proxy the WebAuthn ceremony.

What's inside the QR

The URI looks like:

FIDO:/0123456789012345678901234567890123456789...

The decimal digits are a base10 encoding of a CBOR map. After base10 decode + CBOR parse, the map has integer keys:

Key 0 — peer public key

Uncompressed X9.62 public-key bytes (33 bytes for P-256). The phone uses this to establish the encrypted tunnel.

Key 1 — QR secret / tunnel nonce

10 bytes of random data. Identifies this specific QR; the BLE advertisement broadcasts a hash of it so the phone can find the right laptop.

Key 2 — operation hint

0 = make-credential (registering a new passkey), 1 = get-assertion (signing in), 2 = discoverable-credential.

Key 3 — tunnel-server domain

The HTTPS host that proxies the tunnel between the two devices when direct BLE isn't reachable (e.g., across NAT). Usually a vendor-operated server like cable.ua5v.com (Google) or cable.auth.com (Apple/MS).

Key 4 — timestamp

Seconds-since-epoch when the QR was generated. Used for replay protection — the phone refuses to honor a QR older than a few minutes.

Key 5 — state-assisted flag

Boolean. Indicates whether the laptop wants the phone to participate in passive state-keeping (mostly relevant for credential-enumeration flows).

The threat model: who pressed "Sign in with a passkey" first?

The protocol is cryptographically sound. The Bluetooth proximity check is real and limits the attack to whoever is physically near you. So how does this go wrong?

Through social engineering on the initiation. The attacker starts a passkey sign-in to YOUR account on THEIR laptop. Their laptop shows a FIDO QR. They get that QR in front of you somehow:

"Tech support" calls you and asks you to scan a QR to "verify your account."
A "shared screen" Zoom call where the attacker's screen is showing the QR and asks you to scan it on your phone.
An in-person social-engineering attack — the attacker sits next to you at a coffee shop, shows a QR, asks for help "logging in."
A phishing email asking you to scan a QR to "confirm your identity for the new login." (Real FIDO QRs are short-lived; an email arrives well after the QR has expired, but the user may not know that.)

If you scan, your phone proxies your passkey signature back to the attacker's laptop's browser. The site you have a passkey for thinks you signed in. The attacker is now logged into your account.

Note the proximity check doesn't help — the attacker is physically present. The QR contents don't help — they're cryptographically valid. The login destination doesn't help — it's the correct site you have a passkey for. The only thing that helps is recognizing the situation: you should never be scanning a FIDO QR that you didn't generate yourself by clicking "Sign in" on your own device.

What our scanner surfaces

When you drop a FIDO QR into our scanner, the verdict shows:

The operation hint — is this a sign-in, a passkey enrollment, or a discoverable-credential operation?
The tunnel-server domain — does it match a vendor you recognize (Google's cable.ua5v.com, Apple's tunnel server, etc.)?
The QR's timestamp — is this freshly generated, or stale and likely replayed?
The peer-public-key length and QR-secret length — sanity checks that the QR is structurally valid.

The threat class is always suspicious — not because the protocol is broken but because the safety call is contextual and the scanner can't know who pressed "Sign in." The verdict's disclosure tells you exactly that: "scanning completes a sign-in someone STARTED ON ANOTHER DEVICE. If you did not just initiate a login yourself, refuse."

When it's safe (and when it isn't)

Safe: you sat down at your laptop, opened your bank or email site, clicked "Sign in with a passkey", and your laptop showed the QR. You pick up your phone, scan the QR, approve the proximity prompt. Done.

Not safe: anyone other than you initiated the sign-in. This includes anyone over the phone, anyone on a remote-support call, anyone who emailed you a QR, anyone who showed you a "QR to verify your identity," and any QR in a place that isn't your own freshly-displayed device.

If you're not sure whether a QR is from a sign-in YOU started, cancel the sign-in on the original device (close the browser tab), then restart from scratch on the device you intended to use. Real FIDO QRs are valid for only ~10 minutes — restarting flushes any in-flight session and makes the threat impossible.

Inspect a FIDO QR

Drop the image or paste the FIDO: URI. Verdict shows operation, tunnel server, timestamp, and a hard warning to refuse unless you started the sign-in yourself.

Open scanner →