Summary
Of the 17 mitigations in §6.1, Veriqa covers 7, partly covers 2 and does not cover 6; another 2 are addressed to parties other than the authorization server. The table below describes each mitigation and the risks it addresses, including how to provide the mitigations the Veriqa core does not have. To see whether Veriqa covers a lot or a little, we set out to compare how fully other common sign-in methods cover these mitigations. But RFC 10027 came out in August 2026, and ratings of other methods against it barely exist yet, so we rated them ourselves against the same table. An SMS code covers 2 mitigations and partly covers 2; another 7 are set by the server that sends the code rather than by the method itself. Google’s sign-in with a code on another device (RFC 8628), going by Google’s documentation, covers 3 and partly covers 2; Google has not published an assessment of its own against BCP 247. An independent review of Amazon Cognito found settings for 3 of the 17 mitigations and none for 5; it does not address the other 9.Threat model
In RFC terms, Veriqa is the Authorization Server. The browser where the sign-in starts is the Consumption Device, and the phone with the messaging app is the Authorization Device. The QR code or the link travels from one device to the other over an unauthenticated channel, and only the user can verify that channel: “The only mitigation against this unauthenticated channel is the user’s judgment” (§1.1). This is what Cross-Device Consent Phishing (CDCP) exploits. The attacker starts a sign-in to the application themselves and, under some pretext, passes their QR code to the victim or shows it on a fake page. The victim confirms the sign-in in their messaging app, and the session opens for the attacker. The attacker does not get the messaging account — they get signed in to the application. Veriqa’s flows are cross-device authorization flows (§3.1), so the RFC’s second family of threats, Cross-Device Session Phishing (CDSP, §3.2), does not apply to them. Veriqa’s flows match the patterns in §3.1 as follows (the mapping is derived from the RFC’s definitions; the RFC itself does not mention Veriqa):
The initiator context in the question, short lifetimes and one-time codes lower the risk, but they do
not protect against a forwarded sign-in. Only a mandatory passkey
protects against it. The place factor, when the surface is
picked based on the session, only stops browsers outside the office, and only if your application
grants access after the presence check.
Sign-in from trusted networks likewise only stops browsers outside
those networks.
§6.1 mitigations in Veriqa
Statuses: covered — a Veriqa mechanism does what the mitigation describes; partly — part of the mitigation is covered, or only one of the flows; not covered — Veriqa does not have it; outside the product — the mitigation is addressed to someone other than the authorization server. The table primarily assesses the sign-in; a confirmation your server creates is counted where it complements the sign-in. Mitigation names are as in the RFC.Limitations and future directions
Future directions have no dates; each one gives its current status, and a planned one links to the release plan.Device proximity and the place factor
What is not covered. Veriqa has none of the proximity methods in §6.1.1: a messaging app gives the server neither radio nor a shared network with the sign-in browser. What you can do today. Build the place factor from the Place and identity scenario: after signing in, the person scans a QR code on a printer, a meeting-room screen or an IP phone and confirms in the messaging app. This is a compensating control for the risk assessment, not a method in §6.1.1: it checks that the phone is near the place surface, not near the sign-in device. A CDCP attack relies on distance and scale: the RFC describes it as sending codes “to large numbers of users that are geographically distributed” (§6.1.1). A QR code on a sheet from the office printer or on a meeting-room panel cannot be delivered remotely or sent to a thousand recipients. Where perimeter policy forbids radio, FIDO proximity over Bluetooth does not work at all (both devices need BLE, §6.2.3.3), while a paper or on-screen QR code needs no radio. The place confirms the person, not the session. If your service picks the surface based on the network or workstation where the session is open, a session outside the office gets no surface and does not pass the presence check, provided your application grants access only after that check. If the surface is picked based on who signed in, the scenario only narrows the victims down to those who are on site: with a forwarded sign-in, the person confirms the place in their own office, and the session stays with the attacker. Direction. The core itself would print the place QR code through a device adapter, and the browser would not show it. The place QR code would then never appear on a screen, and neither a remote desktop nor screen sharing would see it. Status: under discussion.Passkeys alongside Veriqa
What is not covered. The confirmation in the messaging app is not tied to the browser where the session opens, so a Veriqa sign-in is not phishing-resistant. What you can do today. The Passkeys alongside Veriqa scenario: the user creates a passkey from a button that arrives in the messaging app after the sign-in, and the application requires the key before it opens the session. A passkey does not sign a request for another origin. Signing in with a key from another device requires Bluetooth near the sign-in browser (§6.2.3.3). That is a proximity method in §6.1.1 and the phishing-resistant sign-in §6.1.15 describes. The RFC recommends FIDO2/WebAuthn wherever the devices support it (§6.2.3.5, SHOULD). Only the mandatory mode protects, and only the users who have it on: as long as sign-in without the key remains available, the attacker will use it. Do not let a session opened through Veriqa create a key: that session may belong to the attacker. Add further keys only after a signature with an existing one. Creating the first key remains the weak spot: the link in the button is a bearer link. Direction. A passkey as a step of the binding levels.Binding levels
What is not covered. The confirmation is not cryptographically tied to the browser that started the sign-in (§6.1.1, §6.1.16). What you can do today. Passkeys alongside Veriqa. Direction. The binding-levels specification describes a scale of trust between the browser that started the sign-in and whoever confirms it. Its target is a level at which a confirmation is accepted only from the same device, or from a device cryptographically bound to it in advance. The candidate mechanisms are a passkey as an additional step, a channel key, and an email link accepted only by the browser that started the sign-in. The last one would remove the cross-device step from the email sign-in altogether (§2, item 2). In a non-normative note, the specification also mentions number matching — §6.1.16 in substance, with the same limitation the RFC names: an attacker who guides the victim interactively will ask for the number too. The specification does not promise a particular mechanism. Status: planned for the release after the next one — see the release plan.Anomaly detection
What is not covered. There is no chain of “attack detected → tokens issued for this code revoked → resource servers notified”, no “this wasn’t me” button and no CAEP (§6.1.6). TheAnomalyDetection:Enabled switch exists, but the core does not yet keep a history of confirmed
sign-ins to compare with, so flagging stays inactive even when the switch is on.
What you can do today. Watch the transaction audit trail
and revoke the tokens of a sign-in the person did not start
(EnableRevocation).
Direction. Veriqa would remember derived, non-personal signals of confirmed sign-ins — the
country and the device type — and flag a sign-in that does not match them. IP, User-Agent and city
would not be stored, and the feature would be opt-in. This would partly cover the detection part of
§6.1.6; revoking tokens and notifying resource servers would stay with your service. Status: planned
for the next release — see the release plan.
Browser mark
What is not covered. Any browser can start a sign-in, and Veriqa does not recognize a browser the person has signed in with before (§6.1.7). What you can do today. Your application knows its own devices: it can refuse to open a session in an unfamiliar browser without an extra check, such as a passkey. Direction. A browser mark — a cookie for the Veriqa domain under Data Protection (encrypted and signed),HttpOnly, Secure. An unfamiliar browser would not receive the authorization code, and
the session would open in a familiar one: the sign-in would start again there, initiated by a third
party (OpenID Connect Core, §4). A web push would make that one tap. The attacker’s browser does not
carry this person’s mark, and a fake page cannot see the cookies of the Veriqa domain.
This would partly cover §6.1.7. Trust goes to a browser the person has signed in with before, not to
a device the server has registered. A cookie is not attestation, and the RFC points this out among
the limitations of the mitigation. It does not help on a new computer or at the first sign-in. The mark is
exactly as reliable as the protection of the Data Protection key ring: whoever can read the ring can
forge the mark. Encrypt the ring with a certificate —
Veriqa:DataProtection:CertificateBase64 or :CertificatePath.
Status: under discussion.
Trusted network
What is not covered. Veriqa has no list of networks a sign-in may start from (§6.1.8). What you can do today. Follow the Sign-in from trusted networks scenario: on the reverse proxy, restrict/connect/authorize, the route that starts a sign-in, to
your networks, and keep the routes the phone and the channel webhooks reach open.
Direction. The client entry would hold a list of networks a sign-in may start from. The RFC
advises combining such a control with others (§6.1.8, SHOULD). Status: under discussion.
Service address
What is not covered. There is no check for an unfamiliar browser at the first sign-in. Direction. The messaging app would ask the person to type a Veriqa service address by hand, and Veriqa would match the browser against the one that started the sign-in. The check would work at the first sign-in too, but it would rest on the person: a fake page can lead them to its own service page. It does not literally cover any §6.1 mitigation — it is a hardening step. Status: under discussion.A chain of several channels
The channel-chain specification describes a sign-in confirmed in several channels in a row. It protects against the takeover of one channel account: one stolen messaging session is not enough for the attacker. It does not protect against a forwarded sign-in — every link of the chain can be forwarded the same way — and changes no row of the table. You can build it today from the Stronger sign-in with a chain of channels scenario. Status of built-in support: frozen.Protocol selection (§6.2)
§6.2 compares three protocols: RFC 8628, CIBA and FIDO2/WebAuthn. A Veriqa sign-in uses none of them: the application gets its tokens through the authorization code flow with PKCE (OpenID Connect), and the cross-device step runs between the Veriqa page and the messaging app. RFC 8628 and CIBA describe how a device gets a token; Veriqa answers a different question — how the person proves it is them. The RFC recommends FIDO2/WebAuthn wherever the devices support it (§6.2.3.5, SHOULD) and allows it together with the authorization code flow and PKCE (MAY) — that is how the Passkeys alongside Veriqa scenario works. Where Bluetooth is forbidden or missing, signing in to a computer with a key on a phone does not work (§6.2.3.3), while a sign-in through a messaging app does.Next steps
Preparing for production
Limits, audit, certificates and token rotation before going live.
Initiator context
What the person sees in the sign-in question.