Enterprise Attestation Conveyance Explained
Enterprise attestation is the one WebAuthn mode that can uniquely identify the specific physical authenticator — for example by a device serial number — rather than just its model. That capability is exactly why it is tightly gated: it is only released when an authenticator or platform is configured to permit it for a named RP ID, almost always on managed corporate devices. This page explains what it exposes, how to request and verify it, and the privacy obligations it brings. It sits under the attestation conveyance policy selection guide.
Capability Reference
| Aspect | direct |
enterprise |
|---|---|---|
| Identifies | Model (AAGUID + batch cert) | Individual device (may include serial) |
| Availability | Broadly, when requested | Only on permitted/managed authenticators |
| Typical use | Model allowlisting via MDS3 | Asset-to-user binding in regulated fleets |
| Privacy weight | Low–medium | High — uniquely identifying |
| Downgrade on consumer device | May stay direct |
Silently drops to direct/none |
Enterprise attestation comes in two flavours defined by the platform: a vendor-facilitated list of permitted RP IDs baked into the authenticator, or a platform-managed policy (MDM) that authorises release. Either way, the RP cannot force it on an unmanaged device.
Root Cause Analysis (of enterprise-attestation surprises)
1. Expecting a serial on consumer devices. Requesting enterprise on an unmanaged phone yields direct or none; code that assumes a serial is present breaks.
2. Storing identifying data without a basis. A serial number is personal data in many jurisdictions; collecting it without a documented purpose and retention policy is a GDPR problem.
3. Treating enterprise attestation as a trust upgrade for everyone. It only raises assurance where the device management chain is trusted; on its own it is not a phishing-resistance improvement over direct.
Step-by-Step Resolution
Step 1 — Request enterprise attestation for managed fleets only
const options = await generateRegistrationOptions({
rpID: 'corp.example.com',
userID: employee.userHandle,
userName: employee.email,
attestationType: 'enterprise', // honoured only where policy permits release
});
Step 2 — Verify the statement and extract the identifier
Validate the attestation format and certificate path as usual, then read any individually-identifying field only if your policy requires it.
const { verified, registrationInfo } = await verifyRegistrationResponse({ /* … */ });
if (!verified) throw Object.assign(new Error('attestation invalid'), { status: 400 });
const aaguid = registrationInfo?.aaguid;
// Serial/identifying data, if present, lives in the attestation certificate extensions —
// extract ONLY the fields your asset-binding policy needs.
Step 3 — Bind the authenticator to the employee asset record
Record the model (AAGUID) and, where mandated, the device identifier against the corporate asset inventory — the auditable link enterprise deployments need.
Step 4 — Minimise and set retention
Store only what the policy requires, document the lawful basis, and set a retention window; do not keep serials indefinitely.
Verification and Testing
Enterprise attestation is hard to emulate without managed hardware, so test the policy branches:
// On a device that does not release enterprise attestation, we must not assume a serial
expect(registrationInfo.aaguid).toBeDefined();
expect(() => requireSerial(registrationInfo)).not.toThrow(); // graceful when absent
Confirm your code accepts a direct/none downgrade without error when enterprise is not released. On real managed hardware, verify the serial is extracted and bound to the asset record, and that a privacy review has approved the field set and retention.
Pitfalls
1. Assuming a serial is always present. Handle the downgrade path; consumer devices ignore the request.
2. Over-collecting identifying data. Extract only required fields; document basis and retention (GDPR).
3. Believing enterprise attestation adds phishing resistance. It adds device identity, not origin binding — see attestation vs assertion.
Related
- Attestation Conveyance Policy Selection Guide — the parent guide to
none/indirect/direct/enterprise - Validating Attestation Statements on the Server — the format and certificate-path verification enterprise attestation still requires
- WebAuthn Security Boundaries for Enterprise Apps — AAGUID policy and the managed-device trust model