When to Require Direct Attestation

Requesting direct attestation is a commitment to certificate-chain validation, a metadata dependency and a documented policy for unattested registrations. This page covers the test for whether that commitment is justified, what requiring it actually excludes, and the tiered alternative that suits most products better than a hard requirement. It sits under the Attestation Conveyance Policy Selection Guide.

Decision Reference

Setting Ask yourself Typical fit
none does any decision read the model? most consumer products
direct, accept unattested do you want the model where available? products with a mixed population
direct, require attested is there a written hardware requirement? regulated or managed environments
enterprise do you need a device serial and can you obtain it? managed fleets only

The second row is the one most teams should be in and the one least often chosen, because the decision is usually framed as request-or-not rather than as what-to-do-with-the-answer.

The test for whether you need it Four questions; a no to all four means direct attestation is cost without benefit. Answer these before changing the option is there a written requirement naming certified hardware? must you distinguish company-issued authenticators from personal ones? will you act on a disclosed vulnerability in a specific model? does any decision in the system read the authenticator model? If the honest answer to all four is no, the requirement is aspirational and "none" is the correct setting.

Root Cause Analysis

1. Requesting direct with no consumer. The most common state after a security review that asked for “attestation” without asking what would be done with it. It adds a validation dependency, a privacy exposure and a failure mode, and changes no decision.

2. Requiring attestation on a consumer product. Refuses most synced platform passkeys, which is to say most modern enrolments. The symptom is a registration failure rate that rises steadily as the ecosystem moves, with no code change to explain it.

3. Blocking sign-in rather than enrolment. Attestation is a registration-time input; a policy that reaches into authentication has confused a device claim with a possession proof.

4. No policy for the unknown. Certification lags hardware, so unknown models arrive constantly. Without a documented answer the behaviour is whatever the code happens to do, which is usually a hard failure nobody intended.

What requiring it actually excludes A policy that refuses unattested registrations refuses most consumer passkeys. The excluded column is the majority in a consumer product still able to enrol certified hardware security keys some managed platform authenticators models present in your metadata cache excluded most synced platform passkeys uncertified but legitimate hardware models certified since your last sync anything behind a policy that strips attestation Which is why "require attestation" is an enterprise posture rather than a general one.

Step-by-Step Resolution

Step 1 — find the consumer of the answer

Name the decision that reads the authenticator model. If you cannot, set none and stop.

Step 2 — if a consumer exists, request direct and accept unattested

Collect the model where it is available, record it, and let registrations without it succeed.

Step 3 — express the policy as a tier

Credentials with a verified model claim satisfy the higher-assurance requirement; credentials without one still sign the user in.

Step 4 — document the three outcomes

Attested and recognised, attested and unknown, not attested. Each needs an explicit answer in one place.

Step 5 — reserve require for written requirements

And when you do require it, give users an interface naming the kind of authenticator they need rather than reporting a verification failure.

The tier that usually fits Accept the registration, record what was proved, and let that gate the sensitive surfaces rather than enrolment. Three outcomes, not two registration accepted either way record attested or not sign-in unaffected sensitive action requires an attested credential This keeps enrolment open to everyone while giving the policy a real place to apply.

Verification and Testing

Register with a virtual authenticator that produces no attestation and assert the ceremony succeeds with the credential recorded as carrying no model claim. This is the case a requirement-shaped policy breaks, and it is the majority case in production.

Register with a fixture carrying valid attestation from a model absent from your metadata and assert that the unknown-model branch runs rather than an exception.

Assert the tiering: a credential without a model claim signs in successfully and is refused at whichever action carries the higher requirement, with a response the front end can act on.

Pitfalls

1. “Direct, but we never look at it”. The worst of the three options and the most commonly shipped.

2. Refusing the unknown by default. Refuses new hardware, including devices your own organisation bought.

3. Treating attestation as an authentication control. It is an enrolment policy input and nothing else.

Frequently Asked Questions

Does requiring attestation make phishing resistance stronger?

No. Phishing resistance comes from origin binding, which applies identically whether or not attestation was collected. Attestation tells you what kind of device holds the key; it has no bearing on whether a phishing site can obtain an assertion, which it cannot in either case.

What is the privacy cost of requesting direct attestation?

Modest but real. Attestation certificates are batched across a model, so the statement identifies a product rather than a person — but it does tell you what hardware someone uses, which is information you did not previously hold and now have to govern. That is the trade to weigh against whatever decision consumes it.

Can I change the setting later?

Yes, and it only affects new registrations. Existing credentials keep whatever was recorded at enrolment, which is another reason to store the resolved outcome rather than the raw statement: a policy change should not require re-deriving history.

What if a security questionnaire asks whether we use attestation?

Answer with what you do and why rather than with yes or no. “We request attestation and record the authenticator model where one is supplied; we do not require it, because the majority of legitimate registrations carry none” is complete, defensible, and more useful to the reader than a checkbox.

Should enterprise attestation ever be requested by a consumer product?

No. It is gated behind managed-device policy and will simply degrade to direct, and the identifier it would return is a durable hardware identifier a consumer product has no business holding.

How does this interact with a bring-your-own-device policy?

Awkwardly, which is worth surfacing early. Requiring attested company hardware and permitting personal devices are contradictory positions, and the tiered approach is usually how the contradiction is resolved: personal devices enrol and work, company hardware unlocks the systems that require it.

Who should own this decision?

Whoever owns the requirement it serves — a compliance or security function in a regulated environment, and nobody at all in a product that has no such requirement. The failure mode worth avoiding is an engineering team inheriting the setting from a template and then defending it in a review without knowing why it is there.

Reviewing an Existing Policy

Most teams inherit this setting rather than choosing it, so the useful exercise is an audit rather than a design.

Start by finding every place the attestation result is read. In a healthy deployment there is exactly one — a policy function that maps a verified model claim to an assurance tier. If the search returns nothing, the setting is decorative and can be relaxed to none immediately, removing a trust store, a metadata dependency and a class of failure from your registration path.

If the search returns something, check what it does with the three outcomes. A branch that handles “recognised model” and falls through to an exception for everything else is the shape that produces slow-burning registration failures: it worked when it was written, because the population was small and homogeneous, and it degrades as the ecosystem diversifies. Making the unknown and unattested cases explicit is usually a ten-line change.

Then check the operational side. When was the trust store last updated, when did the metadata cache last verify successfully, and does anything alert if either goes stale? An attestation policy is the only part of a WebAuthn deployment with a live external dependency, and it is the part most likely to fail silently.

Finally, re-ask the four questions at the top of this page against today’s requirements rather than the ones that were current when the code was written. Requirements are withdrawn as often as they are added, and a policy that no longer serves anything is pure operational cost.

Related