Skip to main content
Identity Authority
Category: FIDO & Passkeys

Attestation Object

Also known as: attestationObject
Simply put

An attestation object is a signed data structure created by an authenticator (such as a security key or a device's built-in authenticator) when a new credential is registered. It contains information about the newly created public key credential and about the authenticator itself, allowing the receiving party to verify that the credential was genuinely produced by an authentic device. It is generated during the registration (attestation) step rather than during later sign-ins.

Formal definition

In the WebAuthn/FIDO2 model, the attestation object is a specific type of signed data object returned during credential creation (registration) that contains statements about a newly generated public key credential and about the authenticator that created it. Per the evidence, it includes authenticator data and cryptographic attestation that the key pair was created by that authenticator, enabling a relying party to validate the authenticator's authenticity, typically through trust chains, as part of verifying attestation. It is distinct from the assertion produced during subsequent authentication ceremonies; attestation concerns the creation and provenance of credentials, whereas assertion concerns proving possession of an existing credential. Note that the object being signed establishes integrity and origin of the statements but is not equivalent to encryption. Specific attestation formats, statement contents, and trust-chain validation behavior depend on the authenticator and deployment configuration, and are otherwise out of scope for this definition.

Why it matters

The attestation object is what lets a relying party answer a critical trust question at the moment a credential is registered: was this public key credential actually produced by a genuine, trustworthy authenticator, or by something masquerading as one? In WebAuthn/FIDO2 registration, the private key never leaves the authenticator, so the relying party has no direct way to inspect the device that generated the key pair. The attestation object closes that gap by carrying signed statements about the newly created credential and the authenticator itself, which the relying party can validate, typically through trust chains, before deciding to accept the credential.

This matters most in higher-assurance deployments where an organization needs to constrain registration to specific, approved authenticator models or vendors. For example, an enterprise or government relying party may require that only certified hardware security keys be enrolled, and attestation is the mechanism that makes such a policy enforceable at registration time. Because the object is signed, its statements have integrity and verifiable origin; however, signed is not the same as encrypted, so attestation establishes provenance rather than confidentiality of the contained data.

It is important to keep attestation scoped to the registration (credential creation) step. The attestation object is not involved in later sign-ins, where an assertion is produced instead to prove possession of an existing credential. Conflating the two leads to design and audit errors, such as expecting device provenance checks to occur on every authentication, so understanding where the attestation object appears in the ceremony is essential to reasoning about what trust the relying party actually gains and when.

Who it's relevant to

IAM and authentication engineers
Engineers implementing WebAuthn/FIDO2 registration need to parse and validate the attestation object to confirm that a credential was genuinely produced by an authentic authenticator before storing the associated public key. This includes handling authenticator data and validating cryptographic attestation, typically via trust chains, with the understanding that exact formats and validation behavior vary by authenticator and configuration.
Security architects
Architects designing high-assurance authentication can use attestation to enforce policies that restrict registration to approved authenticator models or vendors. They should scope this control correctly: attestation applies at credential creation, not at each sign-in, and it establishes authenticator provenance rather than protecting data confidentiality, since a signed object is not an encrypted one.
Compliance and audit leads
For those verifying that only trusted devices are enrolled, the attestation object is the evidence artifact that supports device provenance claims at registration. Understanding that attestation is distinct from the assertion used during authentication helps auditors correctly assess when and how device trust is established versus how ongoing possession of a credential is proven.

Inside Attestation Object

Authenticator Data
A binary structure that includes the RP ID hash, flags (such as user presence and user verification bits), a signature counter, and, during registration, the attested credential data. It conveys the state and characteristics of the authenticator at the time of the WebAuthn ceremony.
Attested Credential Data
Present in the authenticator data during a registration (create) ceremony. It typically contains the AAGUID identifying the authenticator model, the credential ID, and the newly generated public key (in COSE_Key format) that the relying party will use to verify future assertions.
Attestation Statement Format (fmt)
A string identifying the format of the attestation statement, such as packed, tpm, android-key, android-safetynet, fido-u2f, apple, or none. The format determines how the accompanying statement should be parsed and validated.
Attestation Statement (attStmt)
A format-specific structure that typically carries a signature and, depending on the format, certificate chains or other material used by the relying party to verify the provenance and integrity of the newly created credential.
Public Key (COSE_Key)
The credential public key encoded in COSE_Key format, embedded within the attested credential data. The relying party stores this key to later verify assertion signatures during authentication ceremonies.
CBOR Encoding
The attestation object is typically serialized as a CBOR map containing the fmt, attStmt, and authData fields. Relying parties decode this CBOR structure during registration to extract and validate its components.

Common questions

Answers to the questions practitioners most commonly ask about Attestation Object.

Is the attestation object the same thing as an assertion or authentication response?
No. In the WebAuthn context, the attestation object is produced by an authenticator during credential registration (the create() ceremony) and conveys information about the newly created public key credential and, optionally, the authenticator's provenance. It is distinct from an authentication assertion, which is returned during the get() ceremony to prove possession of a previously registered credential. Conflating the two blurs the registration step from the subsequent authentication step; they occur at different points in the credential lifecycle and carry different data structures.
Does the attestation object prove the user's identity to the relying party?
Not on its own. The attestation object primarily provides assurance about the authenticator and the public key being registered, it supports the binding of a credential to an authenticator, and depending on the attestation type may convey information about the authenticator model. Establishing who the user is (identification) and how strongly they were verified typically depends on other factors, such as the relying party's account-binding process and any user verification the authenticator performed. Attestation speaks to the authenticator's characteristics, not directly to the human's identity.
What are the main components inside an attestation object?
An attestation object is typically CBOR-encoded and, in most WebAuthn deployments, contains three elements: the authenticator data (which includes flags, a signature counter, and the attested credential data such as the credential ID and public key), the attestation statement format identifier (fmt), and the attestation statement itself (attStmt), whose structure depends on the format in use. The exact contents and encoding are defined by the WebAuthn specification and the relevant attestation statement format; verify against the specific version and format your deployment targets.
How should a relying party choose an attestation conveyance preference during registration?
The choice depends on your assurance and privacy requirements. Requesting no attestation (the 'none' conveyance) reduces privacy exposure and is often sufficient when you only need a working credential. Requesting attestation is generally reserved for deployments that must verify authenticator provenance, for example, restricting registration to approved authenticator models. Requesting attestation typically adds verification complexity and may raise privacy considerations, so in most deployments it is enabled only where policy genuinely requires authenticator vetting.
What does verifying the attestation statement involve on the server side?
Verification depends on the attestation statement format indicated by the fmt field, and each format defines its own procedure. Broadly, in most implementations the relying party parses the CBOR attestation object, validates the authenticator data (including checking relevant flags and the relying party ID hash), and then applies the format-specific steps to validate the attestation statement, which may include verifying a signature and validating a certificate chain up to a trusted root, depending on the format and configuration. Consult the WebAuthn specification and any authenticator metadata source you rely on rather than assuming a single universal procedure.
How can a relying party validate the authenticator model referenced by an attestation?
Where attestation includes an authenticator identifier (such as an AAGUID in the authenticator data), a relying party can, in many deployments, cross-reference it against an authenticator metadata source to check the model against policy. The availability and trustworthiness of such metadata varies by deployment and by the metadata service used, so the specific matching and trust decisions depend on configuration. This is out of scope for the attestation object structure itself, which carries the identifier but does not define the metadata lookup process.

Common misconceptions

The attestation object authenticates the user, confirming who they are.
The attestation object is produced during the WebAuthn registration (credential creation) ceremony and conveys information about the authenticator and the newly created credential. It is distinct from an assertion, which is used during authentication ceremonies. Verifying the attestation object establishes provenance of the credential, not the identity of the user; user verification, where required, is signaled separately via flags in the authenticator data.
An attestation statement being signed means the attestation object is encrypted and confidential.
A signature over the attestation statement provides integrity and, depending on the format, provenance assurance, but it does not provide confidentiality. Signing is not the same as encryption. The attestation object fields such as the AAGUID and public key are not concealed by the presence of a signature.
Every registration must include a meaningful attestation statement that proves the authenticator's make and model.
The attestation conveyance preference is configurable by the relying party, and the 'none' format produces an attestation object without authenticator provenance material. In many deployments attestation is not requested or not verified, so the presence and usefulness of the attestation statement depends on configuration and policy.

Best practices

Decode the CBOR attestation object and validate the fmt, attStmt, and authData fields against the WebAuthn registration ceremony steps rather than trusting the client-supplied data unconditionally.
Decide deliberately whether your relying party requires attestation; only request and verify attestation statements when your risk model and policy actually need authenticator provenance, since many deployments accept the 'none' format.
When verifying attestation, validate the statement according to its declared format and check certificate chains or metadata (for example against authenticator metadata such as the FIDO Metadata Service) as appropriate to your configuration.
Extract and durably store the credential public key (COSE_Key) and credential ID from the attested credential data so future assertion signatures can be verified during authentication ceremonies.
Treat the AAGUID and other attestation fields as non-confidential; do not rely on the signature over the attestation statement to provide any privacy or encryption guarantees.
Check the user presence and user verification flags in the authenticator data to confirm the ceremony met your policy requirements, keeping these signals separate from the credential provenance conveyed by the attestation statement.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide