Passkeys are built on WebAuthn and the FIDO2 CTAP protocols. The headline story is simple: instead of a password, your device holds a private key and proves possession of it by signing a challenge. The website stores only the matching public key, so there is no shared secret to phish or leak in a breach.
But registration carries an extra, optional payload that the day-to-day login flow never uses: an attestation statement. It answers a question the public key alone cannot — not "can this device sign?" but "what kind of device is this, and can the maker vouch for it?" Understanding attestation is the difference between treating passkeys as a convenience feature and deploying them as a hardware-rooted security control.
What Attestation Actually Proves
During registration, the authenticator generates a fresh credential key pair scoped to the website (the "relying party"). Alongside the new public key, it can produce a signature made with a separate attestation key baked into the device at manufacture. That signature covers the new credential and a set of authenticator properties, and it chains up to a certificate issued by the manufacturer.
The relying party verifies that chain against a trusted root — in practice, the metadata published in the FIDO Metadata Service (MDS), a signed catalog of certified authenticators identified by an AAGUID (a 128-bit model identifier). If the chain validates, the server has cryptographic grounds to believe the credential lives inside a specific, certified model of hardware, with known properties: whether the key is hardware-backed, whether user verification is supported, what certification level it holds.
The credential key is unique to you and to one website. The attestation key is shared across an entire production batch of devices — deliberately. If each device had a unique attestation identity, that identity would become a global serial number tracking you across every site. Batching is a privacy defense, not a manufacturing shortcut.
The Attestation Formats
WebAuthn defines several attestation statement formats. The ones you encounter in practice:
- packed — the modern, compact default for FIDO2 security keys. A signature plus an optional certificate chain.
- tpm — used by platform authenticators backed by a Trusted Platform Module, common on Windows devices. See our piece on TPM 2.0 for what that hardware actually guarantees.
- android-key and android-safetynet — Android hardware-backed keystore attestation and the older Play-services-based variant.
- apple — Apple's anonymous attestation for Touch ID / Face ID credentials, which deliberately omits a device-identifying certificate.
- none — no attestation statement at all. The browser strips it, or the authenticator never sent one.
The relying party signals what it wants through the attestation parameter when it calls navigator.credentials.create(): none, indirect (the client may anonymize it, e.g. via a privacy CA), or direct (pass the authenticator's statement through unmodified). Critically, requesting attestation is not the same as receiving it — the browser and the user can refuse.
The Privacy Problem
Here is the tension. Attestation tells a website what hardware you used. The AAGUID reveals your authenticator's exact model. On its own that is coarse — millions of people own the same model — but it is still an entropy contribution to a fingerprint, and it leaks information a password never would. "This account was created with a corporate-issued YubiKey 5 Nano" is a meaningful signal.
Worse failure modes have shipped historically. Early authenticators that used a per-device attestation certificate, or that returned the same AAGUID-plus-certificate in a way that narrowed the population too far, created a genuine linkability risk. The batching rule — the FIDO requirement that an attestation certificate be shared by at least 100,000 devices — exists precisely to keep attestation from becoming a tracking identifier.
Attestation answers a question most consumer websites have no business asking. If your threat model is "stop password reuse and phishing," you do not need to know whether the user's passkey lives in a Pixel, a MacBook, or a hardware key.
This is why the platform vendors made a deliberate choice. Apple's passkeys and Google's synced passkeys generally return no attestation by default for consumer flows. The synced credential is designed to be a privacy-preserving password replacement, and a device-identifying attestation would work against that goal.
When Attestation Is the Right Call
Attestation earns its complexity in enterprise and regulated environments, where the relying party is the same organization that issued the hardware:
| Scenario | Why attestation helps |
|---|---|
| Hardware allow-listing | An enterprise can require that only specific certified authenticator models register — rejecting unknown or software authenticators outright. |
| Assurance-level enforcement | Verify that the key is hardware-backed and non-exportable, not a synced credential that could exist on multiple devices. |
| Compliance evidence | Some regimes require proof that authentication factors meet a certified bar (e.g. FIPS-validated hardware). Attestation provides auditable proof. |
| Supply-chain trust | Confirms the device is a genuine product from the expected vendor, not a counterfeit returning a forged AAGUID. |
The defining feature of every good use case: the organization verifying attestation already has a relationship with the user and a legitimate reason to know what hardware protects the account. That is the opposite of an anonymous consumer signup.
A Practical Default for Relying Parties
If you are building authentication and weighing whether to request attestation, the conservative answer for almost every public-facing service is request none. You get all the anti-phishing, anti-reuse benefits of WebAuthn without collecting hardware identifiers you cannot justify holding. Reserve direct attestation for the cases above, where you are issuing or governing the hardware and can defend the data collection.
Also remember that attestation verification adds real operational burden: you must consume and refresh the FIDO MDS, handle certificate revocation, and decide what to do when a perfectly legitimate authenticator returns an AAGUID you have not seen yet. Many breaches of usability — locking out users with valid keys — come from over-strict attestation policies, not from attackers.
Consumer login: attestation none, keep the privacy win. Enterprise-issued hardware: attestation direct + MDS verification, keep the assurance win. There is rarely a good reason to sit between these two.
How This Connects to the Bigger Picture
Attestation is one corner of a larger move away from shared secrets toward possession-based, hardware-rooted authentication. It sits alongside passkey portability, hardware keys versus authenticator apps, and the broader question of how much an identity provider should know about the device on the other end of the connection.
The recurring theme: stronger authentication and more device telemetry are not the same thing, and conflating them is how privacy erodes under the banner of security. A passkey can be both unphishable and anonymous. Attestation is the dial that decides which of those two properties you keep — so set it deliberately.
Where Haven Fits
Haven's account model is built around keys that never leave your device and a passphrase that is never transmitted, even as a hash of itself. We treat authentication telemetry the way we treat all metadata: collect the minimum required to keep the account secure, and nothing that would let us — or anyone compelling us — build a richer profile of the hardware in your pocket. Attestation is a good feature used in the wrong place, and we'd rather not be in the business of knowing what made your keys.