| Hardware authentication | EdSSA NanoESP32-C6-WROOM-1 | FIDO2 / WebAuthn keyYubiKey, Solo, OpenSK | Secure-element mTLSATECC608, Trust&GO | Azure SphereMT3620, Pluton | Rolling-codeUltimate KeeLoq | OPAQUE / aPAKE-IoTRFC 9807, research |
|---|---|---|---|---|---|---|
| CapabilityWhat the protocol-on-silicon can do | ||||||
| Runs on commodity MCU, no secure element required | ● | ○ | ○ | ○ | ||
| BOM under $5 per device | ● | ○ | ○ | ● | ||
| Sustained ≥1 Hz per-request unique credentials | ○ | ● | ○ | |||
| No centralised credential vault on verifier side | ● | ○ | ○ | ○ | ○ | |
| No per-device public-key registry on the verifier | ● | ○ | ○ | ○ | ○ | ○ |
| Cryptographic quality at intended ~1/256 per-byte forgery probability | ● | ● | ● | ● | ○ | ● |
| Operates without human-in-the-loop ceremony | ● | ○ | ● | ● | ● | ● |
| Survives multi-day disconnect from any central service | ● | ○ | ○ | ● | ||
| Post-quantum credential security path | ● | ○ | ○ | ○ | ○ | |
| MaturityShipping reality today — where EdSSA correctly answers “not yet” | ||||||
| Available off-the-shelf today | ○ | ● | ● | ● | ● | ○ |
| Shipping in production at million-unit volume | ○ | ● | ● | ● | ○ | |
| Independent published security review | ○ | ● | ● | ● | ● | |
| Standardised in an RFC or comparable open spec | ○ | ● | ● | |||
Notes
- BOM under $5 per device: ESP32-C6-WROOM-1-N4 (the part on our bench) is $4.95 single-quantity on DigiKey, dropping into the $3–4 range at modest volume; Wi-Fi 6, BLE 5, and 802.15.4 are all on-die, not optional. YubiKey 5 NFC $50; ATECC608 adds $0.50–1.20 on top of an MCU; Azure Sphere MT3620 ~$8.95.
- Sustained ≥1 Hz per-request unique credentials: EdSSA proven at 2 Hz over the public internet on demo box. FIDO2 ceremony cost makes ~0.1 Hz the practical ceiling. ATECC608 can sign fast but the deployed mTLS session model reuses session keys.
- No centralised credential vault on verifier side: FIDO2 relying parties store one public key per device; ATECC608 deployments register certs in cloud IoT registries; KeeLoq receivers hold the shared symmetric key + counter. OPAQUE removes the password vault but keeps a per-user record.
- Cryptographic quality at intended ~1/256 per-byte forgery probability: Classic KeeLoq is broken (2007 cryptanalysis, 2008 power-analysis); Ultimate KeeLoq lifts to AES-128 but is not universally deployed. Honda Rolling-PWN (2022) showed the family is still attacked in the wild.
- Operates without human-in-the-loop ceremony: FIDO2 user-presence test (button press) is part of the standard. This is correct for human auth, wrong for machine-to-machine.
- Survives multi-day disconnect from any central service: Azure Sphere requires periodic check-in with Azure Sphere Security Service. mTLS certs expire and need rotation.
- Post-quantum credential security path: EdSSA Phase 6 brings ML-KEM-768 + SPAKE2. FIDO2 PQ extensions are draft. ATECC608 is ECC-only.
- Shipping in production at million-unit volume: YubiKey, Trust&GO, and automotive KeeLoq variants all ship in millions. EdSSA is one fleet on a demo box.
- Independent published security review: EdSSA has 13 internal phases with retros and ADRs but no external academic review yet.
- Standardised in an RFC or comparable open spec: OPAQUE is RFC 9807 (July 2025). FIDO2/WebAuthn is W3C + FIDO Alliance.
Two things this table is not. It is not a claim that EdSSA replaces FIDO2 — FIDO2 solves human-in-the-loop authentication and EdSSA does not. It is not a claim that EdSSA is shipping at the scale any product in the right-hand columns ships at — those products ship in millions, EdSSA runs one fleet on a Hetzner box at demo.edssa.io. The capability block above describes what the protocol-on-silicon does today; the maturity block describes what hasn’t happened yet. Both are true.
What we have not found in the public landscape — and the reason this page exists — is the combination: commodity MCU with no secure element, sustained per-request unique credentials at machine frequency, cryptographic quality at the intended forgery probability, and no centralised vault on the verifier side. Individually each row is solved by something in the table; the conjunction is what the EdSSA demo proves out.
This information is to our best knowledge as of May 2026. The hardware-auth landscape moves fast and product configurations vary — please verify against the vendor’s current docs for your deployment, and report errors to contact@edssa.io. We’ll correct them.