What a registry of trusted authenticators actually tells you.

When a user signs in with a passkey, two cryptographic checks happen at the server. The first is the obvious one: did the device sign the challenge correctly? That confirms the user has the right private key, which is the credential. There’s a second check — less common, more consequential — that separates a credible identity platform from an also-ran. It asks: what hardware actually signed this, and is it hardware we trust?

That question is what the FIDO Alliance calls attestation, and the answer comes from a global registry maintained by the same body that defines the WebAuthn standard. This brief is a working tour of that registry, the four flavors of attestation that exist in the wild, where each one helps or doesn’t, where Enterprise Attestation fits for government and high-assurance deployments, and what changes the moment you pipe registry findings into a policy engine.

A note on terminology before we go further: we use passkey to mean the key that authenticates the user, and attestation key for the distinct key the hardware uses to vouch for itself. The two are deliberately separate; conflating them is the source of much confusion in the field.

The second cryptographic check

Every passkey is generated inside an authenticator — a hardware or platform module that holds the private key. That might be a USB security key, a TPM inside a laptop, a phone’s secure enclave, or a platform authenticator like Windows Hello. Each authenticator model — not each device, but the model, the line, the firmware build — carries a 16-byte identifier called the AAGUID (Authenticator Attestation Globally Unique Identifier).

When a passkey is created, the authenticator can optionally include an attestation — a signed statement bundling the AAGUID with the new public passkey, signed by a key that belongs to the authenticator (or to a trusted attestation service), not to the user. Crucially, that attestation signature is verifiable against a root of trust controlled by the authenticator’s manufacturer, and that root of trust is published in a global, signed registry called the FIDO Alliance Metadata Service (MDS).

The chain reads, end to end: the user just signed in → with this private key → bound to this authenticator model → which attests to its own integrity using this manufacturer-issued key → whose certificate sits in the public, signed MDS → which our identity platform checked against your policy before granting access.

Most identity providers verify the first link in that chain and stop. Trustaige walks the full chain at every sign-in.

Authentication keys vs. attestation keys

This is the single distinction that makes attestation legible. The authenticator carries two kinds of cryptographic material:

• A passkey is created at registration, unique per relying party (per website, per app), and is the credential the user proves possession of at every subsequent sign-in. Each new account you create gets its own passkey.
• An attestation key is created at manufacture (or, for platform authenticators, provisioned by the platform’s attestation service), is the same for every authenticator of the same make/model/batch, and signs statements about the authenticator. It’s not unique to a user. It’s barely unique to a device — FIDO Alliance requires attestation batches of at least 100,000 units sharing the same key, precisely to prevent the attestation key from doubling as a tracker.

When attestation happens, the authenticator uses the attestation key to sign a small object containing the new passkey’s public key plus the AAGUID plus a few authenticator flags. The relying party verifies that signature against the trust chain published in the MDS. Once the signature checks out, the relying party knows: “the passkey I just received was generated inside a real instance of this specific authenticator model, not a software emulation pretending to be one.”

That’s the whole point. The signature doesn’t tell you which physical device this is. It tells you what kind of hardware you’re trusting, and lets your policy engine decide whether that’s enough for the resource being accessed.

The four flavors of attestation

FIDO authenticators can produce attestations in one of four formats. They differ in who signs the attestation statement and how much information that signature actually carries.

1. Self-attestation. The authenticator signs its own attestation statement with the passkey itself. There’s no separate attestation key; there’s no manufacturer in the chain; there’s no MDS lookup because there’s no AAGUID-bound attestation key to look up. It gives you cryptographic integrity (“this attestation statement hasn’t been tampered with”) but no provenance (“I have no idea what hardware produced this”). Useful only when the relying party has some prior trust anchor for the user’s device — otherwise it’s information without conviction.

2. Basic attestation. The attestation is signed by a key generated at manufacture and shared across at least 100,000 units of the same authenticator model. The certificate chain links back to the manufacturer’s root, which the relying party verifies via the MDS. This is the common case for hardware security keys. You learn the make and model. You don’t learn the specific physical unit.

3. Attestation CA / Anonymization CA (AttCA / AnonCA). Used primarily with TPM-based platform authenticators (the chip inside a modern laptop). The TPM has its own deeply-held endorsement key, but that key isn’t used directly for attestation — using it would make every laptop globally trackable. Instead, an attestation authority issues per-device attestation certificates that hide the endorsement key’s identity. You learn that this is a real TPM in a real laptop family. You don’t learn which TPM, which laptop.

4. Enterprise attestation. The deliberate exception. We’ll return to this one in detail in the next section.

There’s one more wrinkle worth knowing: synced passkeys do not currently provide attestation. A passkey that lives in iCloud Keychain, Google Password Manager, 1Password, or any other cross-device sync vault, by design, does not carry hardware attestation — the credential is portable across the user’s ecosystem, and a hardware attestation tied to a single device of origin would not survive the sync. This is fine for low-assurance consumer login. It’s not fine for the resources your auditor cares most about, which is one of the reasons Trustaige’s policy engine distinguishes synced from hardware-bound credentials at decision time, not just at registration.

Enterprise Attestation: the high-assurance lane

For most attestation flavors, the FIDO Alliance is allergic to unique device identifiers. That’s the right default for a global consumer-grade standard — you don’t want consumer banks tracking which physical YubiKey their customer holds, and you don’t want governments using FIDO infrastructure to enumerate dissidents by hardware serial.

But there’s a specific situation where uniqueness is exactly the property you want: the workforce of an organization that issues authenticators to its own staff, manages the supply chain, and needs to prove that a particular credential came from a particular inventoried device. Health systems issuing tap-to-sign-in tokens to clinicians. Defense ministries provisioning sealed authenticators to cleared personnel. Banks distributing branded hardware to back-office staff. In each case, the organization is both the buyer of the authenticator and the relying party for it — and the unique identifier is the audit trail.

The FIDO specification accommodates this with Enterprise Attestation. It works by a deliberate, hard-edged constraint: authenticators capable of Enterprise Attestation are not sold on the open market. They are shipped directly from the manufacturer to the procuring organization, and at manufacture time, a list of permitted relying-party identifiers (RPIDs) is permanently burned into the authenticator. When such an authenticator registers with an RPID on that list, it includes a per-unit serial number in the attestation object. When it registers with any other RPID, it falls back to basic attestation and the serial number stays hidden.

This gives the procuring enterprise three things at once:

• A cryptographically attested supply chain — the authenticator came from the manufacturer they ordered it from.
• Per-device traceability inside their own walls — this credential, on this audit log line, came from authenticator serial #18293.
• Privacy preservation outside their walls — that same authenticator, if a staff member uses it on their personal banking website, won’t leak the serial to anyone else.

For Trustaige’s public-sector and regulated-workforce deployments, Enterprise Attestation is one of the operational levers that maps real-world inventory to digital sign-ins. Trustaige’s policy engine supports validating Enterprise Attestation, exposing the per-device identifier to the audit log, and gating access to specified resources on Enterprise-Attestation-bearing devices only.

What lives in the registry

The FIDO Metadata Service is a continuously-updated, signed JSON document that, for every certified authenticator AAGUID, publishes:

• The legal name and identifier of the manufacturer.
• The certification level the authenticator has achieved (L1, L2, L3, or L3+ in FIDO Alliance terms). L3 is hardware tamper resistance plus restricted operating environment; L3+ adds independent side-channel attack assessment by a certified lab.
• The NIST SP 800-63B authenticator assurance level the device qualifies for (AAL1, AAL2, AAL3).
• Whether the authenticator supports biometric user verification, and if so, the biometric accuracy class it’s certified to.
• Whether the authenticator supports PIN-based user verification and the PIN complexity it enforces.
• The set of cryptographic algorithms and transports (USB, NFC, BLE, internal) the authenticator supports.
• Status reports: revocations, security advisories, certification changes. If a researcher publishes a paper compromising an authenticator model, the MDS entry for that AAGUID can be flipped to FIDO_CERTIFIED_REVOKED within days — and any relying party reading the MDS will see the change at the next refresh.

This last property is the underrated one. The MDS isn’t a static allowlist published once and forgotten. It’s a living document. A relying party that embeds the MDS, refreshes it continuously, and acts on status changes can revoke an entire class of compromised authenticators across its workforce in the time it takes to push a config change. A relying party that doesn’t is, by default, still trusting authenticators their own community has already flagged.

What this changes in your policy

Once attestation findings and MDS metadata are reachable from your policy engine, the kinds of decisions you can make on every sign-in expand substantially.

1. Require a specific FIDO certification level for sign-in to sensitive applications. Trustaige’s policy engine exposes minimumFIDOCertLevel (none / L1 / L2 / L3) and minimumAAL (aal1 / aal2 / aal3). Set these per application or per role. An administrator with a valid passkey on an L1 software credential cannot open a resource pinned to L3 + AAL3 — the server refuses the sign-in before the resource is touched.

2. Require biometric user verification with a minimum accuracy class, for roles where shoulder-surfing or shared-PIN risk is real. The MDS publishes per-authenticator biometric accuracy; the policy refuses sign-ins that don’t meet the threshold.

3. Refuse access from authenticator models with active status reports — revoked certifications, published advisories, compromised firmware ranges. The MDS update propagates to your tenant on the next refresh; affected users are stepped up to a new credential without manual intervention.

4. Attribute the sign-in to a specific authenticator model in the audit log — useful when the regulator or the SOC asks how a particular session was allowed. “An L3-certified authenticator from manufacturer X, biometric verification confirmed, AAGUID logged, status nominal at sign-in time” is a stronger answer than “the signature checked out.”

5. For Enterprise Attestation deployments, attribute the sign-in to a specific authenticator serial number — the inventory row that says “asset #18293, assigned to clinician X on date Y, currently active.” Forensic investigations and non-repudiation become tractable.

The privacy tradeoff, honestly

Attestation is information sharing. The relying party learns something about the user’s hardware that the user themselves may not have intentionally disclosed. The FIDO Alliance’s design choices on this front are deliberate and worth naming:

• The 100,000-unit minimum batch size for basic attestation keys means knowing the AAGUID tells you the model, not the unit. You can’t fingerprint a specific person’s device from a basic attestation alone.
• AttCA / AnonCA exists specifically because TPM endorsement keys would be globally unique, and that’s exactly what you don’t want for citizen-grade authentication.
• Non-enterprise attestations prevent two different relying parties from correlating that the same physical authenticator is being used with both, even if they collaborate. Each relying party sees its own scoped attestation, no cross-RP linkage.
• Enterprise Attestation is the explicit opt-in to uniqueness, and only the relying parties whose RPIDs were burned into the authenticator at manufacture see the unique identifier. A user’s personal sign-ins on the same hardware remain unlinkable.

A privacy-aware deployment uses non-enterprise attestation by default and reserves Enterprise Attestation for the workforce-managed inventory where unique-device traceability is the explicit goal. Both positions are legitimate. The mistake is using either without understanding what it implies.

What Trustaige actually does

Three things, end-to-end:

1. We embed the full FIDO MDS in the platform and refresh it on a schedule that survives air-gapped on-prem deployments. The trust anchor for the MDS signature is pinned at provisioning time. No phone-home dependency at sign-in.

2. We expose every meaningful registry field to the policy engine — AAGUID, certification level, AAL qualification, biometric accuracy class, hardware-bound vs synced, manufacturer, status. Policies are configurable per application, per role, per resource, in the same syntax the rest of your access controls use.

3. We support Enterprise Attestation validation end-to-end — verifying the attestation chain, surfacing the per-device identifier to your audit log, and gating access where your policy requires it. This is the operational backbone of our public-sector deployments and the answer to the question “how do we prove the credential came from the specific inventoried device we issued?”

Why most providers skip this layer

The registry check is harder to ship than signature verification. It requires an embedded copy of the MDS, a continuous update mechanism, a trust anchor for the registry’s signing key, a policy engine that can act on the registry’s findings, and — for Enterprise Attestation — the full per-device validation pipeline. None of that is conceptually difficult. It’s just operationally tedious to maintain. So most identity platforms ship without it and accept the gap.

Trustaige doesn’t, because the people who built it had personally seen the consequences of identity platforms that didn’t — breaches where the post-mortem read “the signature checked out, but the device was a software emulation,” or “the authenticator had a revoked certification at the time of sign-in but our IdP never checked.” For the kind of organization that has to defend a sign-in to a regulator, a board, or a parliamentary inquiry, that gap is the entire job.

Further reading

• FIDO Alliance: FIDO Attestation: Enhancing Trust, Privacy, and Interoperability in Passwordless Authentication (May 2024). The canonical primer on attestation from the body that defines the standard. Editors: Khaled Zaky (AWS), Monty Wiseman (Beyond Identity), Sean Miller (RSA Security), Eric Le Saint (Visa). https://fidoalliance.org/wp-content/uploads/2024/06/EDWG_Attestation-White-Paper_2024-1.pdf
• W3C: Web Authentication: An API for accessing Public Key Credentials, Level 3 — specifically the attestation section. The normative specification for how attestation objects are structured and transmitted at the browser layer. https://www.w3.org/TR/webauthn-3/#sctn-attestation
• FIDO Alliance: Metadata Service (MDS) v3. The registry itself, with its JSON schema, the trust-anchor signing key, and the published metadata for every certified authenticator AAGUID. https://fidoalliance.org/metadata/
• NIST: Special Publication 800-63B: Authentication and Lifecycle Management. The U.S. National Institute of Standards and Technology’s reference framework for authenticator assurance levels (AAL1, AAL2, AAL3), used as the policy anchor in many global regulatory regimes including procurement frameworks far outside the U.S.