DEV Community: Gernard Cerma

QRVA: A protocol for cryptographic verification of physical QR codes — design decisions and open questions

Gernard Cerma — Mon, 13 Apr 2026 20:48:28 +0000

Physical QR codes have no trust layer.

When your phone decodes a QR sticker on a parking meter, it reads a URL and opens it. That's the entire security model. The camera has no way to verify that the code was placed by the claimed authority — or that it wasn't placed by someone with a label printer and a freshly registered lookalike domain.

This has been underexploited until recently. It is no longer underexploited.

NYC's Department of Transportation issued an official consumer alert in June 2025 after fraudulent QR stickers appeared on ParkNYC meters city-wide. Austin PD confirmed 29 compromised pay stations. In Southend-on-Sea, councils manually removed approximately 100 fake stickers from parking signage. In every case the same thing happened: existing mitigations failed silently. Safe Browsing had nothing to flag. HTTPS verified the attacker's server correctly. The codes looked legitimate because nothing in a QR code identifies who placed it.

QRVA is a protocol we've been building to fix this at the infrastructure layer. This post covers the threat model, every design decision (including the ones we argued about), and — critically — the six areas we believe are still broken. We're publishing before a formal security audit because the protocol needs scrutiny at the design stage, not after it hardens.

The reference implementation is open: github.com/qrauth-io/qrauth

TL;DR

QR code fraud is a physical-world attack that bypasses every existing digital trust signal
QRVA proposes: ECDSA-P256 signing per issuer, geospatial binding, ephemeral server-generated visual proof, heuristic anti-proxy detection, and WebAuthn passkeys for returning users
We chose P256 over Ed25519 because of WebAuthn authenticator compatibility and FIPS requirements — not because it's the better curve in isolation
Geospatial binding catches displaced clones but GPS accuracy limits make it useless below ~15m radius in urban environments
WebAuthn is the only tier that is cryptographically unphishable — but only for returning users who've enrolled a passkey
Six open problems we haven't solved: adaptive anti-proxy detection, Merkle-backed transparency log, tenant identity bootstrapping, sub-second revocation, geolocation API trust boundary, and radius selection tooling

If you find a flaw in the signing model or the anti-proxy heuristics, we want to know. Open an issue or drop a comment here.

1. Threat model

Six attack classes, ordered by sophistication. The first two are the dominant real-world attacks. The remainder are currently theoretical but become relevant once the lower tiers are defended.

T1 — Physical sticker overlay

The attacker prints a QR code sticker pointing to a lookalike domain (parkng-thessaloniki.gr, paybyphone-nyc.com) and places it over or adjacent to the legitimate code. No technical capability required beyond a label printer and physical access.

Why existing mitigations fail: Safe Browsing blocklists require days to propagate; freshly registered phishing domains have no reputation yet. HTTPS is irrelevant — the attacker's server has a valid certificate for their domain. Visual inspection cannot distinguish a printed QR from a genuine one.

T2 — Legitimate domain, fraudulent QR registration

The attacker generates their own signing keys, creates a QR pointing to a convincing endpoint, and places it physically. Without a registry of legitimate issuers and their authorized locations, nothing distinguishes this from a genuine code.

Why existing mitigations fail: Nothing in a standard QR payload identifies the issuer or the authorized deployment location. Any entity can generate a QR pointing to any URL.

T3 — Static page cloning

The attacker scrapes the legitimate verification page and hosts an identical copy on their domain. The victim scans a fraudulent code, lands on the clone, sees convincing trust indicators.

Why existing mitigations fail: Client-side rendered pages are trivially cloneable. Visual trust indicators generated client-side can be reproduced.

T4 — Real-time MitM proxy

Rather than cloning the page, the attacker proxies all requests to the legitimate verification endpoint. Responses are genuinely fresh — defeating static clone detection — but the proxy introduces detectable artifacts: an additional TLS hop, measurable latency overhead, and a fingerprint mismatch.

T5 — Geospatial spoofing

Against a protocol that performs geospatial binding, an attacker who knows the registered coordinates can instruct the victim's browser to report those exact coordinates. The browser Geolocation API is user-controllable and does not authenticate GPS data.

T6 — Tenant key compromise

If an attacker compromises a tenant's ECDSA signing key, they can issue arbitrarily many QR codes that verify as legitimate. This is the highest-severity attack class — analogous to a compromised TLS certificate — and the one with the slowest response path.

2. Protocol response

QRVA addresses the attack classes through four successive tiers. Each tier builds on the previous. All tiers are active simultaneously.

Tier	Mechanism	Defeats	Automated
1	ECDSA-P256 signing + issuer registry	T1, T2	Yes
2	Server-generated ephemeral visual proof	T3	Yes
3	Anti-proxy heuristics	T4 (partially)	Yes
4	WebAuthn passkey (origin-bound)	T4, all known phishing	After opt-in

T5 (geospatial spoofing) is addressed partially by cross-referencing browser Geolocation against IP geolocation. A meaningful discrepancy contributes negatively to the trust score. This is heuristic, not cryptographic.

T6 (key compromise) is addressed by KMS-backed key isolation, a transparency log, and a revocation endpoint. The propagation window is currently 5 minutes. This is not good enough for high-value deployments and is discussed in section 6.

3. Why ECDSA-P256 and not the alternatives

This was the most contested internal decision. The two serious candidates were ECDSA-P256 and Ed25519.

The case for Ed25519 is strong. It is faster, has a simpler implementation surface, eliminates the nonce dependency that makes naive ECDSA implementations dangerous, and has no known patent issues. In a fresh system with no compatibility constraints, Ed25519 would be the default choice.

QRVA has compatibility constraints.

WebAuthn authenticator key material. QRVA's Tier 4 uses WebAuthn passkeys. The FIDO2 specification mandates P256 (COSE algorithm -7) as the required algorithm for Level 1 authenticators. Ed25519 (COSE algorithm -8) is optional and unsupported in several hardware authenticators — particularly older Android FIDO2 implementations and some YubiKey models. Using P256 throughout the stack means a single key type to audit, a single curve implementation to trust, and no algorithm negotiation surface.

KMS availability. Tenant keys are managed in AWS KMS or HashiCorp Vault. P256 has near-universal KMS support. AWS KMS added Ed25519 in late 2023 but it remains unavailable in some regions and absent from several enterprise KMS providers.

FIPS compliance. P256 is specified in FIPS 186-4. Ed25519 is not FIPS-approved. For US government and regulated-industry tenants this is a procurement requirement, not a preference.

The nonce problem. We implement deterministic ECDSA per RFC 6979, which derives the nonce from the private key and message hash. This eliminates the nonce management risk — the catastrophic failure mode of standard ECDSA — while retaining P256.

Why not P384? Security level of P256 is 128 bits against classical computers — sufficient against all known classical attacks. P384 provides 192 bits and produces 96-byte compact signatures versus 64 bytes for P256. QR codes have finite payload capacity. Higher density QRs are harder to scan in degraded conditions: dirt, damage, low light, camera angle. The 32-byte difference is meaningful at scale.

4. Why geospatial binding — and what it doesn't solve

Geospatial binding addresses T2: it is not enough to verify that a QR was signed by a legitimate tenant. The code must have been registered at the location where it's being scanned.

The registration model: when a tenant generates a QR, they supply GPS coordinates and an accuracy radius in meters. This tuple is bound into the signed payload. At scan time, the verifier requests the scanner's location via the browser Geolocation API and computes the Haversine distance against the registered centroid. Distance greater than the registered radius fails verification or degrades the trust score.

// Haversine distance computation (simplified)
function haversineDistanceMeters(
  lat1: number, lng1: number,
  lat2: number, lng2: number
): number {
  const R = 6371000; // Earth radius in meters
  const φ1 = lat1 * Math.PI / 180;
  const φ2 = lat2 * Math.PI / 180;
  const Δφ = (lat2 - lat1) * Math.PI / 180;
  const Δλ = (lng2 - lng1) * Math.PI / 180;
  const a = Math.sin(Δφ/2) ** 2 +
            Math.cos(φ1) * Math.cos(φ2) * Math.sin(Δλ/2) ** 2;
  return R * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1-a));
}

What it solves: a cloned QR code displaced five blocks from its registered location fails verification at the new location. Simple code copying is caught.

What it doesn't solve:

GPS accuracy constraints. Consumer GPS in open sky provides ±3–10m accuracy. In urban canyons — exactly where parking meter fraud concentrates — multipath reflections degrade accuracy to ±20–50m. Indoors, GPS is unavailable entirely; the API falls back to WiFi triangulation (±15–40m) or cell towers (±100–300m). The practical minimum radius that avoids false negatives in urban environments is approximately 15m. This means the geospatial check cannot distinguish codes on opposite sides of the same city block.

The Geolocation API is not authenticated. navigator.geolocation reports coordinates but does not attest their authenticity. A user with device control can override reported coordinates. QRVA treats geolocation as a probabilistic signal, not a cryptographic guarantee.

Radius selection is unspecified. A restaurant QR on a table has a different appropriate radius than a billboard visible from 50m. Incorrect radius selection — too small causes false negatives that erode user trust; too large degrades the security property — is a systematic misconfiguration risk invisible to end users. We have not defined guidance or tooling for this yet.

5. Where WebAuthn fits — and what it doesn't solve

WebAuthn passkeys are origin-bound at the hardware level. A passkey created for https://qrauth.io authenticates only on https://qrauth.io. This is enforced by the authenticator — Secure Enclave on iOS, Titan chip on Pixel, TPM on Windows — not by JavaScript. A phishing page at any other origin physically cannot activate the passkey prompt.

This makes WebAuthn the only component of QRVA that is cryptographically unphishable. Tier 1 can be defeated if the key is compromised. Tiers 2 and 3 are heuristic. WebAuthn's origin binding is unconditional.

The enrollment flow:

// Triggered after a successful Tier 1–3 verification
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,           // Fresh from server, single-use
    rp: { name: 'QRAuth', id: 'qrauth.io' },
    user: { id: userId, name: userEmail, displayName: userEmail },
    pubKeyCredParams: [
      { type: 'public-key', alg: -7 },   // ECDSA-P256 (required)
      { type: 'public-key', alg: -8 },   // Ed25519 (optional, where supported)
    ],
    authenticatorSelection: {
      residentKey: 'required',            // Discoverable credential
      userVerification: 'required',       // Biometric or PIN
    },
  },
});
// Public key stored on server, scoped to this tenant's user pool

What WebAuthn solves: for returning users with an enrolled passkey, it provides hardware-attested confirmation of the genuine qrauth.io origin. Combined with Tier 1 signature verification, this creates a two-factor trust chain: the QR was signed by the legitimate issuer (cryptographic), and the user is on the genuine verification endpoint (hardware-attested).

What WebAuthn doesn't solve:

The first scan. A first-time user falls through to Tier 1–3. Tier 4 is only available after opt-in enrollment. In practice, most users will never enroll a passkey for a parking meter interaction. The lower tiers carry the majority of real-world traffic.

The passkey proves endpoint integrity, not code legitimacy. A passkey enrolled on qrauth.io confirms the user is on the genuine verification page. It does not confirm the QR code being verified was placed by its claimed issuer. These are different trust claims.

Cross-device enrollment. A passkey enrolled on an iPhone syncs to other Apple devices via iCloud Keychain but does not transfer to Android. Platform switching requires re-enrollment. Predictably, most users won't.

6. Open questions — what we want scrutinized

These are the areas with the most residual risk. We are naming them explicitly because we want critique at the design stage.

6.1 Anti-proxy detection against an adaptive adversary

The current model uses four heuristic signals: TLS fingerprint (JA3/JA4), round-trip latency, canvas fingerprint, and HTTP header analysis.

JA3/JA4 durability. Tools like curl-impersonate clone the TLS ClientHello of a target browser exactly. A proxy running on a common cloud provider, impersonating a Chrome fingerprint, will produce a JA3 hash indistinguishable from a legitimate Chrome client. We do not have a reliable application-layer answer for TLS fingerprint spoofing.

Canvas fingerprint erosion. Firefox's Resist Fingerprinting mode and Brave's farbling mechanism randomize canvas output per-origin. As privacy browsers gain market share, canvas fingerprint consistency as a signal degrades. An adversary operating their proxy from a privacy browser already evades this signal today.

Latency threshold collapse. The latency heuristic assumes a minimum RTT overhead from the proxy hop. This breaks when both victim and attacker have edge-cached access to QRVA's infrastructure — for example, both terminating through Cloudflare Workers. In this configuration, proxy-added latency can fall below our detection threshold of ~50ms.

We believe robust anti-proxy detection requires CDN-layer cooperation — specifically, mutual TLS authentication that a browser can initiate but a proxy cannot relay without detection. We have not designed this.

6.2 Transparency log integrity

The current transparency log is append-only by operational convention, not by cryptographic guarantee. It works against an honest-but-curious operator; it fails against a compromised one.

Certificate Transparency (RFC 6962) solves this with a Merkle tree structure and inclusion proofs that clients can independently verify. A CT log that omits an entry cannot produce a valid inclusion proof for that entry. We referenced RFC 6962 in the QRVA spec but have not implemented Merkle inclusion proofs. The current log cannot prove to an independent verifier that a given entry has not been silently omitted.

This is a known gap. The implementation is straightforward; the deployment model for distributing Signed Tree Heads to verifiers is not yet designed.

6.3 Tenant identity bootstrapping

QRVA's security model assumes the mapping between a tenant identifier and a real-world organization is trustworthy. The spec describes a KYC verification flow but does not define its rigor.

This is analogous to the DV/EV distinction in TLS: domain validation certificates verify domain control but not organizational identity. QRVA currently only has a DV equivalent. For high-stakes deployments — government payments, healthcare navigation, regulated financial terminals — this is insufficient. The tenant identity verification process needs to be specified with the same rigor as the cryptographic components.

6.4 Key compromise response window

If a tenant's signing key is compromised, every QR code issued under that key appears legitimate until revocation propagates. Revocation propagates to the Cloudflare Workers edge through a cache TTL currently set at 5 minutes.

For payment terminals and government identity applications, 5 minutes of fraudulent verification capability after a known compromise is not acceptable. Certificate Transparency makes rogue certificate issuance publicly auditable in near-real-time — detectable within seconds. QRVA's transparency log propagation is currently batch-based, not real-time. Sub-second revocation propagation is a hard unsolved problem in the current architecture.

6.5 Geolocation API trust boundary

The browser Geolocation API is not authenticated. We cross-reference it against IP geolocation, but both signals are ultimately attacker-controllable.

Modern iOS and Android expose secure enclave attestation primitives. We want to know: can a QRVA-integrated mobile app request a location claim from the device's secure enclave that is attested by the device manufacturer and not spoofable by user-space software?

We believe this is architecturally possible on modern Apple and Google hardware but have not found a documented, stable API surface for it. If you know of one, we genuinely want to hear from you.

6.6 Radius selection tooling

This is more of a UX problem than a cryptographic one, but it has security consequences. The protocol does not prescribe a radius — tenants set it. Systematic underconfiguration (radius too large) degrades the geospatial security property silently. There is no feedback loop from scan events to radius recommendation.

We have not designed tooling or guidance for this. Contributions welcome.

Conclusion

The trust layer that physical QR codes are missing is not technically novel — it's the same primitives that solved analogous problems for TLS (certificate signing), email (DKIM/SPF), and web authentication (WebAuthn). The application to physical-world QR codes just hasn't been done yet.

QRVA is our proposal. The reference implementation is live at github.com/qrauth-io/qrauth. The full protocol specification is at docs.qrauth.io/protocol.

If you find a flaw — in the signing model, the geospatial scheme, the anti-proxy heuristics, or anything else — open an issue or leave a comment below. We are specifically interested in:

Whether the JA3/JA4 fingerprinting model holds against an adaptive adversary with curl-impersonate-equivalent capabilities
Whether authenticated location claims from device secure enclaves are accessible at the app layer
Whether there is a Merkle-backed transparency log deployment model that doesn't require a dedicated CT monitor infrastructure

We want this broken before it is deployed at scale. That's the point of publishing it now.

Animated Cryptographic QR Codes: Killing Screenshot Attacks at the Display Layer

Gernard Cerma — Thu, 09 Apr 2026 13:21:11 +0000

What if the QR code on your screen was alive?

Not alive in the "it links to a website" sense. Alive in the sense that it changes every 500 milliseconds, each frame is cryptographically signed, and a screenshot of it is worthless before you can even share it.

We are building this at QRAuth, and it solves a problem that no amount of short TTLs or rate limiting can fix.

The Problem: Screenshots Kill QR Authentication

QR-based authentication has a vulnerability that gets hand-waved away: the screenshot attack.

A user opens a login page. A QR code appears. The user screenshots it and sends it to someone else — or worse, an attacker captures it via screen share, a compromised display, or a shoulder-surfing camera. The recipient scans the screenshot and authenticates as the original user.

Short time-to-live values help but do not eliminate the window. A QR code valid for 30 seconds is still valid for 30 seconds. That is plenty of time for an automated relay attack.

Static QR codes displayed on physical surfaces (parking meters, restaurant tables, event posters) have an even worse version of this problem: someone sticks a fraudulent QR code over the legitimate one, and every person who scans it gets redirected to a phishing page. This is called quishing, and it is growing fast — cities like Montreal and Ottawa have already issued public warnings about fake QR codes on parking meters.

The Solution: Animated Cryptographic QR Codes

Instead of displaying a static QR code that refreshes every N seconds, we render a continuous animation where each frame is a new, independently signed QR code.

The protocol:

frame_payload = {
  challenge: base_challenge,
  frame_index: counter,
  timestamp: Date.now(),
  hmac: HMAC-SHA256(server_secret, challenge + timestamp + frame_index)
}

Every 500ms, the display generates a new frame with an incremented counter and fresh timestamp. The HMAC binds the frame to the server secret, the original challenge, and the exact moment it was generated.

When a phone scans the code, the server validates:

Recompute the HMAC with the server secret
Check the timestamp is within the 500ms window
Verify the frame_index is not stale (replay detection)
Confirm the base challenge matches an active session

A screenshot captures exactly one frame. By the time it reaches anyone else, the timestamp window has closed. A video recording captures multiple frames, but without the server secret, the attacker cannot generate the next valid frame in the sequence.

Rendering with Skia

The animation cannot be a flickering mess of black and white squares. It needs to look intentional, designed, and unmistakably alive.

We use Skia for rendering — the same 2D graphics engine behind Chrome, Android, and Flutter. On the web, CanvasKit (Skia compiled to WebAssembly) provides hardware-accelerated canvas rendering. On mobile, @shopify/react-native-skia gives us a declarative rendering pipeline in React Native.

The key insight: QR data modules must stay binary for scanner compatibility, but everything around them is a design surface. Skia lets us:

Ripple modules outward from the center like a pulse
Make finder patterns glow and breathe with subtle animation
Shift a color wash across the quiet zone over time
Add a gradient border that cycles in sync with frame rotation

None of this affects decodability. QR scanners read luminance thresholds at each module position, not color. The styling is cosmetic, but the effect is powerful — it is visually obvious that this QR code is alive and cannot be a printout or a sticker.

Performance target: under 8ms per frame generation (ECDSA signing + QR matrix computation + Skia draw call), leaving 492ms of headroom on the 500ms rotation cycle.

Beyond the QR: The Trust Reveal

The animation on the display is half the story. The other half is what happens when you scan.

Most verification flows end with a web page showing a green checkmark. That is forgettable. We are building a Trust Reveal — a designed, 2-3 second verification moment:

Full-screen takeover on the scanning device
A server-generated visual fingerprint unique to that exact scan — a crystalline pattern derived from the SHA-256 of the timestamp, device ID, location, and token
A color sweep from deep red to verified green
The issuer identity materializes on screen

This is the frame that gets screenshotted and shared. It is also cryptographically meaningful — the visual is server-generated and provably live.

For failed verification (scanning a fraudulent QR code), the experience is equally designed: full-screen red, alarm animation, "UNVERIFIED — This QR code is not cryptographically signed. Do not proceed."

Trust-Reactive Animation

Here is where it gets genuinely novel.

The QR code's animation state reflects its security status in real time. The server pushes animation parameters via WebSocket to the display client:

Server State	Visual Behavior
Clean	Calm, slow pulse
Elevated scan velocity	Animation accelerates, subtle hue shift
Fraud flagged	Visual distortion, finder patterns degrade
Revoked	Code dissolves on screen

The QR code is not just displaying a challenge. It is visually communicating the security state of that challenge to anyone looking at the screen. A calm, slowly pulsing QR code means everything is normal. A distorted, rapidly flickering one means something is wrong — and you do not need to understand cryptography to read that signal.

This sits on top of the existing QRAuth architecture. The event bus already handles scan events. The fraud detection pipeline already tracks scan velocity. The animation layer is a client-side visualization of server-side state, pushed over the same WebSocket connection that handles session authentication.

The Fraud Demo

Two QR codes on a screen, side by side. They look identical to the naked eye — because every QR code looks like a random grid of black and white squares to a human.

Scan QR Code A: the phone shows the Trust Reveal. Green sweep, verified, issuer identity confirmed.

Scan QR Code B: the phone flashes red. "FRAUDULENT CODE DETECTED — DO NOT PROCEED."

The difference was invisible. Until you scanned.

That is the entire value proposition of QR verification in 15 seconds.

What This Means for Quishing

The sticker-over-QR attack works because there is no verification layer between the QR code and the user's browser. You scan, you follow the link, you are on whatever page the attacker set up.

Animated cryptographic QR codes break this at two levels:

A physical sticker cannot animate. If the legitimate QR is pulsing and the sticker is static, the difference is immediately visible.
Even if an attacker manages to display their own animated QR, the cryptographic signature will fail verification because they do not have the signing key.

This is the same trust model as SSL/HTTPS. A padlock icon in your browser means the site's certificate was issued by a trusted authority. A verified QR code means it was signed by a registered issuer. Unsigned codes are flagged — not blocked, but flagged, the same way browsers warn about HTTP sites.

Try It

QRAuth is open source. The animated QR work is on our roadmap for Q3 2026, building on the existing ECDSA-P256 challenge-response protocol.

Demo: qrauth.io
GitHub: github.com/QRAuth-io/qrauth
Medium article on the broader architecture: Passwordless Login Needs Less Than Passkeys

If you are working on anything related to QR security, authentication, or anti-fraud — we would love to hear from you. The protocol (QRVA) is open and licensed under CC BY 4.0.

Passwordless Login Needs Less Than Passkeys

Gernard Cerma — Tue, 07 Apr 2026 14:51:27 +0000

Passwords are broken. This is not a hot take. Every security professional, every developer who has implemented auth, and every user who has clicked "Forgot Password" for the tenth time this month knows it.

The industry response has been a wave of alternatives: magic links, SMS codes, TOTP authenticators, and most recently, passkeys. Each one solves part of the problem while introducing new friction. Magic links depend on email delivery speed. SMS codes are vulnerable to SIM-swap attacks. TOTP apps require users to manually type rotating six-digit codes. Passkeys tie authentication to platform keystores that don't sync well across ecosystems.

The pattern is clear: every method works well in some contexts and fails in others. The answer is not to find the one perfect method. It is to build a platform that unifies multiple methods under one identity.

That is what we set out to build with QRAuth. It started as QR-based authentication. It is becoming an identity verification platform where QR is the primary -- but not the only -- transport.

How It Works

The flow is simple, and deliberately so.

A user opens a login page. The page displays a unique QR code. The user scans it with their phone camera -- no app install, no proprietary reader. The phone asks for confirmation -- biometric, PIN, or passkey, depending on how the developer configured it. Once confirmed, the browser session is authenticated instantly via SSE. Done.

If this sounds familiar, it should. WhatsApp Web, Telegram Desktop, and Signal Desktop all use a variation of this pattern. Billions of people already trust QR-based session authentication daily without thinking about it.

The difference is that QRAuth makes this available as a general-purpose authentication layer, not locked inside a single app.

The Security Model

Every QR code generated by QRAuth is cryptographically signed, single-use, and time-limited -- measured in seconds, not minutes. Each code is bound to a specific session. If nobody scans it before it expires, it is destroyed and replaced.

This means there is nothing persistent to leak. Unlike a password, API key, or even a session token, the QR code is ephemeral by design. A screenshot of a QR code is useless by the time someone tries to use it.

When a user scans the code, their phone does not simply confirm a session. It presents context: the requesting domain, timestamp, device information, and location. The user sees exactly what they are authorizing before they confirm. This makes QR authentication phishing-resistant in a way that most alternatives are not -- you cannot trick someone into confirming a session for evil-site.com when their phone clearly shows the requesting domain.

The phone itself acts as the authentication device. Think of it as a hardware security key that everyone already carries.

But a valid cryptographic challenge is only half the picture. The other half is knowing which device made the request and whether that device should be trusted. That is where the device registry comes in.

Device Trust: From "Valid Request" to "Known Device"

There is a critical difference between verifying that a request is cryptographically valid and verifying that it comes from a device you trust. Most authentication systems stop at the first. QRAuth is building toward the second.

The architecture already captures device data on every authentication event. The next layer -- currently in development -- exposes this as a user-facing device registry. Each user gets a list of their trusted devices: "iPhone Aris," "MacBook Office," "Pixel Personal." Devices can be named, reviewed, and revoked.

This changes the security model fundamentally. Instead of asking "is this challenge valid?" the system asks "is this challenge valid AND does it come from a device this user has previously registered and not revoked?"

The practical implications are significant. A stolen phone can be revoked from any other trusted device. A new device triggers a step-up verification before it is added to the trust list. An enterprise admin can enforce policies: only company-provisioned devices, only devices with biometric capability, only devices in specific geolocations.

This is the layer that turns authentication into identity management.

The Question Everyone Asks: Why Not Passkeys?

This is the first question every developer raises, and rightfully so. Passkeys are a strong technology with serious backing from Apple, Google, and Microsoft.

Here is an honest comparison.

Passkeys store credentials in platform keystores -- iCloud Keychain, Google Password Manager, Windows Hello. The protocol is open, and anyone can run their own WebAuthn server. But the keys live on the client side, inside platform ecosystems. This creates three practical problems.

First, cross-ecosystem portability is still fragmented. A passkey created on an iPhone and stored in iCloud Keychain is not seamlessly available on a Windows workstation. The sync story is improving, but it is not solved.

Second, shared and public devices are a problem. Walk into an office with shared PCs, a library with public terminals, or a hotel business center. Passkeys do not work well on devices that belong to someone else or to no one. There is no keystore to pull from.

Third -- and this is the part that does not get discussed enough -- when passkeys do handle cross-device authentication, the mechanism they use is a QR code. The FIDO Alliance's own cross-device authentication flow involves scanning a QR code with your phone to bootstrap the connection. QR-based authentication is not a competitor to passkeys. It is a layer that passkeys themselves rely on.

QRAuth is complementary, not competitive. The architecture includes a WebAuthn bridge that unifies QR and passkey authentication under the same identity. A developer does not choose between QR and passkeys. They offer both. The user chooses based on context. On their own laptop with a synced keystore, passkeys are the right choice. On a shared PC, a kiosk, a smart TV, or a colleague's machine, QR is faster and simpler. Either way, the identity is the same, the device trust model is the same, and the session management is the same.

This is the core architectural decision: QR is a transport, not the product. The product is a unified identity verification layer that happens to start with QR because it solves the widest range of contexts today.

Where QR Authentication Shines

The use case that generates the most immediate interest is shared device authentication.

Picture an office with ten shared workstations. Currently, each employee either has a local account with a password (credential sprawl), uses a shared account (security nightmare), or goes through an SSO flow that still requires typing credentials on a machine they do not own.

With QR authentication, the employee walks up to a workstation, scans the QR code on the login screen with their phone camera, confirms with a biometric tap, and the workstation loads their session with their permissions. No password typed on a shared keyboard. No credentials stored on the device. When they leave, the session ends.

This pattern extends naturally to kiosks, point-of-sale systems, smart TVs, digital signage, conference room displays, and any environment where typing credentials is either impractical or insecure.

Beyond digital authentication, QRAuth also handles physical QR verification. Any printed or displayed QR code can be cryptographically signed to prevent tampering, spoofing, or replacement. This addresses a growing problem in restaurants, parking systems, event ticketing, and product authentication where fraudulent QR codes redirect users to malicious destinations.

The Developer Experience

None of the above matters if integration is painful.

QRAuth ships stable SDKs for Node.js and Python today, with Go, PHP, Swift, and Kotlin on the roadmap. The target is under ten minutes from npm install to a working QR login. A generous free tier removes evaluation friction.

The architecture is straightforward. The developer creates a session, receives a QR payload, renders it, and listens for a webhook or WebSocket event when the user confirms. No redirect flows, no callback URLs, no OAuth dance. The simplicity is intentional -- authentication should be infrastructure, not a project.

The entire platform is open source. The SDKs, the protocol, and a reference implementation are available on GitHub. We are not asking anyone to trust a black box.

What We Are Building

QRAuth is early, and we are transparent about where we are in the journey.

What exists today: QR-based authentication with cryptographic verification, session management, SDKs for six languages, and a working developer experience. The core protocol is sound and battle-tested.

What is in active development: the device registry with user-facing management and revocation, the WebAuthn bridge for passkey unification, and the admin control plane with session visibility and audit trails.

What is on the roadmap: enterprise features (SSO, SCIM, policy engine), compliance certifications (SOC2, ISO 27001, GDPR documentation), and anomaly detection for risk-based authentication.

The direction is clear. We are not building a QR login widget. We are building an identity verification platform where QR is one method -- the one that happens to work everywhere today -- with passkeys, device trust, and policy controls converging under the same architecture.

The roadmap is shaped by what real developers tell us they need. We launched publicly this month and every conversation -- whether on GitHub, in developer communities, or in direct feedback -- makes the product sharper.

Try the demo at qrauth.io. Read the docs. Break it if you can. Tell us what is missing.