Hey crew,

This issue is about something most people now use without ever seeing: the little cryptographic ceremony behind a passkey login.

The project is ESP32-Key, an experimental Arduino CLI firmware project that turns Waveshare ESP32-S3 display boards into USB FIDO/WebAuthn lab authenticators. In plain English: it is a tiny board that can act like a security key in disposable WebAuthn tests, show what the browser is asking it to do, and make the hidden parts of passkey authentication easier to reason about.

That last sentence needs a big boundary around it. This is not a certified security key. It is not production hardened. It is not for your email, bank, code hosting, cloud admin, password manager, crypto wallet, work systems, or anything you would panic about losing.

It is a bench key. That is exactly why I like it.

Passkeys are becoming normal. The FIDO Alliance's 2026 report says passkeys are now in active use at global scale, with broad consumer awareness and growing workforce deployment. That is great for sign-in security. It also means more builders are going to touch WebAuthn from the outside without understanding the moving parts inside.

ESP32-Key gives you a way to slow the whole thing down.

Instead of treating a security key as a sealed object, the project turns the login chain into something you can inspect:

That chain is the lesson. A passkey is not just a nicer password field. It is a ceremony between a relying party, a browser, an authenticator, a user gesture, and cryptographic proof.

Good questions for the bench:

That is the sweet spot: learn the protocol, respect the boundary, and do not confuse interoperability with hardening.

ESP32-Key turns small ESP32-S3 display boards into USB FIDO/WebAuthn lab authenticators.

The useful bits:

The 1.8-inch AMOLED board gives you a bigger visual consent surface. The 1.47-inch LCD board is the tiny version: compact, cheaper-feeling, and more demanding about screen layout. Both are interesting because they make a hidden security flow visible on hardware you can hold.

The design goal is not to beat a commercial authenticator. The design goal is to learn what a real authenticator has to do before you trust one.

For a first pass, focus on these paths:

Before plugging anything in, decide what accounts are allowed.

Use only:

Do not use the device for important accounts. The project stores or derives credential secrets from ESP32-S3 flash/NVS state. Physical access to the board may be enough for the wrong person with the right tooling to extract or clone useful material.

That is the whole operating boundary.

The two main build paths are:

The debug profiles exist for bring-up work, but the realistic browser/WebAuthn path should not depend on serial debug output. A security-key-shaped demo should expose the FIDO interface it is trying to prove, not a pile of extra host interfaces.

ESP32-Key is useful because it names the proof levels.

That ladder is worth borrowing for almost every hardware project. A compile is not a flash. A flash is not a working device. A probe is not a browser. A browser demo is not a security certification.

The repo documents Chrome/WebAuthn.io registration and sign-in success for disposable lab flows, including non-discoverable and discoverable/resident credentials. That proves a useful lab path. It does not prove production security.

Passkeys are no longer a niche feature. FIDO's 2026 consumer and workforce report says passkeys have reached global scale, with 5 billion passkeys in active use, 90% consumer familiarity, 75% consumer enablement on at least some accounts, and 68% of surveyed organizations deploying, piloting, or rolling them out for employee authentication. That makes protocol literacy more valuable, not less.

WebAuthn Level 3 is still moving through the standards track. The W3C Web Authentication Level 3 document is a Candidate Recommendation Snapshot intended to gather implementation experience. That is a reminder that passkeys are mainstream in use, but the platform details still evolve.

The Waveshare boards are real embedded UI hardware, not just USB dongles.

Waveshare's 1.47-inch Touch LCD board uses an ESP32-S3R8, USB-C, BLE/Wi-Fi, PSRAM, 16MB flash, a 172 x 320 touch display, and a TF card slot.

The 1.8-inch AMOLED board adds a 368 x 448 AMOLED display, BOOT/PWR buttons, IMU, RTC, TF slot, microphone, speaker, and power-management hardware. Those extra surfaces matter because a lab authenticator should make consent and state visible.

Comparable commercial keys solve a different problem. A certified authenticator is for protecting real accounts. ESP32-Key is for understanding what the protocol asks a tiny device to do. Those are different jobs. The moment the project sounds like a replacement for a YubiKey, SoloKey, Titan key, platform authenticator, smart card, or passkey manager, the framing has gone wrong.

ESP32-Key is a small way to understand a big chain:

That is the lesson.

The project is interesting because it does not hide the rough edges. It tells you which board profile to use, which commands matter, which probes prove what, and why a functional WebAuthn demo still belongs on the bench instead of your real account list.

Build one if you want to learn how passkeys work under the hood.