FIDO2 Enterprise Attestation

Recently, YubiOn FIDO Logon implemented a management feature for enterprise authenticators. To briefly explain this feature, it allows you to manage authenticators using the serial number of the security key. This functionality is made possible by utilizing a specification called FIDO2 "Enterprise Attestation". However, although this specification is defined within the FIDO standard, it is not widely adopted, and in my experience, there are few in-depth explanations available in blogs or other resources. Therefore, I would like to summarize the information I have gathered, even if briefly.

Please note that this article is primarily intended for technical professionals. If you are looking for details about the features of FIDO Logon, I recommend reading the previous blog post. This article focuses on explaining the Enterprise Attestation specification itself, which is largely independent of FIDO Logon. I have tried to make it understandable even for those unfamiliar with FIDO authentication technology, but readers with knowledge of FIDO authentication or digital signature technology will gain a deeper understanding.

■Background of Enterprise Attestation Specification

Under the basic FIDO authentication specification, it is not possible to determine whether authenticators used for multiple credentials belong to the same physical device. For example, if the same security key is used on Site A and Site B, or if it is used for Account X and Account Y within Site A, there is no mechanism to identify whether these credentials come from the same authenticator—even if you compare all credential data. (*1) This design primarily aims to prevent “tracking” from a privacy perspective. If such identity could be easily determined, information disclosed only on Site A could potentially be misused on Site B operated by the same company, creating privacy concerns.

As a result of these privacy considerations, the individual identification information of the device used for FIDO authentication is not visible even to the service performing the authentication (the Relying Party, RP). This mechanism is excellent for protecting privacy in personal use cases.

However, when companies want to manage authentication, this can be inconvenient. In the following scenarios, traditional FIDO authentication could not provide a solution:

• Employee X has lost an authenticator, and the company wants to disable the authenticator that was issued to them. Therefore, they need to identify the credentials associated with the authenticator loaned to Employee X.

• An internal report suggests that Employee X, who should only have access to System A, is secretly using System B. The company wants to identify which credentials in System B belong to the authenticator issued to Employee X.

• Employee X appears to have used a personal authenticator instead of the company-issued one. Employee X recently left the company and returned the issued authenticator, but they can still access internal systems using their personal authenticator. The company wants to prevent access with personal authenticators (i.e., allow only company-issued authenticators).

Of course, one might argue, “Just properly manage and disable Employee X’s account.” Ideally, accounts should indeed be managed on a per-person basis. However, in reality, there are cases where shared accounts use authenticators, or authenticators are registered to another employee’s account for operational reasons—situations that often cause headaches for internal IT teams. (*2) From the perspective of verifying whether such poor practices exist, being able to identify which physical device corresponds to a credential can be a significant advantage in enterprise environments.

(*1) Whether the authenticators are of the same type (for example, which vendor and product) can be determined depending on the options used when creating the credential.

(*2) In reality, it is more common for multiple people to know the ID and password of a shared account than to use FIDO authentication for shared accounts...

■Overview of Enterprise Attestation

There are conflicting requirements: on one hand, the need to prevent device identification, and on the other, the need to enable device identification. FIDO’s solution to this conflict is Enterprise Attestation, a specification that allows device identification within a limited scope based on authenticator settings.

I will try to explain Enterprise Attestation as simply as possible. However, explaining only that part in isolation can be confusing, so I will start by describing the overall flow of FIDO authentication. Please note that I will omit parts not necessary for explaining Enterprise Attestation, so this is not a complete introduction to FIDO authentication.

・FIDO Authentication

In simple terms, FIDO authentication consists of two main processes:

• makeCredential: the “registration” (credential creation) process

• getAssertion: the “authentication” process

These processes are based on digital signature technology using public-key cryptography, which involves two types of keys: a private key and a public key. The authenticator stores the private key internally and uses it to create a signature. The server performing authentication verifies the signature using the corresponding public key stored on its side.

Enterprise Attestation is implemented in the makeCredential process, so we will focus on that here. In makeCredential, the authenticator generates a pair of private and public keys and sends the public key to the server. At the same time, it signs a string called a challenge (*3) provided by the server using the private key and returns the signature result to the server. The server verifies that the challenge was issued by the server immediately before and that the signature is valid (*4). If everything checks out, the server stores the public key for future authentication.

This is the basic concept of FIDO authentication. In the case of getAssertion, the overall flow is similar, except that the step of generating a new key pair is skipped. Instead, the authenticator uses the previously created private key to sign the challenge (*3), and the server verifies the signature(*4).

(*3) Strictly speaking, the signature is applied to a JSON object (clientData) that contains the challenge and other information.

(*4) This explanation is simplified for conceptual understanding. In reality, additional checks are required, such as verifying that the operation was performed for the intended RP and that user verification (PIN, fingerprint, etc.) was completed.

・AttestationStatement

So far, we’ve only covered the basic concept of FIDO authentication and haven’t yet touched on the part that relates to Enterprise Attestation. To understand Enterprise Attestation, we first need to explain the Attestation Statement.

The Attestation Statement is a mechanism that guarantees the reliability of the authenticator. Using this mechanism, it is possible to ensure that the registered authenticator is a legitimate device certified by the FIDO Alliance. This helps prevent the use of malicious authenticators (e.g., those designed to leak private keys) or even non-malicious authenticators with vulnerabilities.

From here, it will be easier to understand by looking at the data structure, so let’s start by showing the structure of the data obtained during the makeCredential process.

Within this structure, the attStmt section is called the Attestation Statement, which contains the signature (sig) and the certificate (x5c). The signature here is applied to the fields called authenticatorData and clientDataHash. In simple terms, the signature and certificate confirm that the authenticator itself generated the authenticatorData and clientDataHash (which includes the challenge).

Up to this point, what is guaranteed is only that “authenticatorData and clientDataHash were generated by this authenticator.” It does not guarantee that “this authenticator is a FIDO Alliance-certified authenticator.” To provide that guarantee, the FIDO Alliance offers a service called MDS (Metadata Service). From MDS, you can obtain various information about authenticators provided by each security key vendor (such as model names). Among this information is an item called attestationRootCertificates. This is the root certificate, and by verifying that the certificate obtained from attStmt forms a certificate chain with attestationRootCertificates, you can confirm that the authenticator’s certificate was generated by the vendor—meaning the authenticator was provided by that vendor.

The attestation certificate obtained from attStmt is not unique to each authenticator; rather, it is shared among multiple authenticators. The exact scope of sharing depends on the security key vendor’s implementation—it could be at the product model level or the firmware version level. For example, in my own case, the YubiKey Bio I personally own and the YubiKey Bio issued by my company during the same period had identical attestation certificates.

・EnterpriseAttestation

Enterprise Attestation introduces a slight modification to the attestation certificate mechanism described above. Previously, the attestation certificate was the same across multiple authenticators. In contrast, with Enterprise Attestation, this certificate becomes unique to each authenticator, enabling identification of the specific device used for registration.

In the official WebAuthn specification, the behavior when requesting Enterprise Attestation is described as follows:

This value indicates that the Relying Party wants to receive an attestation statement that may include uniquely identifying information.

Since the specification only states “uniquely identifying information,” it seems that any implementation that provides unique identification would be acceptable. In practice, it is often possible to obtain a serial number or similar identifier. For example, in the Enterprise Attestation-enabled YubiKey provided by Yubico for our development, the serial number was stored in the subject field of the X.509 certificate in the form of a Distinguished Name (DN).

How the serial number or similar identifiers are set within the certificate likely varies by vendor. Currently, FIDO Logon has only been tested with Yubico authenticators. In this implementation, the subject field of the certificate is parsed as a Distinguished Name (DN), and the CN (commonName) field is extracted using a regular expression to obtain the authenticator ID. For other vendors, different parsing methods may need to be implemented.

・Implementing Enterprise Attestation on the Web

When using Enterprise Attestation on the web, specify "enterprise" for the attestation parameter in the navigator.credentials.create method of WebAuthn. If the request is processed correctly, as mentioned earlier, the returned attestationObject will include the Enterprise Attestation certificate in the attStmt section. (*5)

(*5) Technically, the method returns a PublicKeyCredential object, whose response member is an AuthenticatorAttestationResponse containing the attestationObject.

■Additional Notes

Here are some important considerations when using Enterprise Attestation.

・Obtaining Enterprise Attestation-Compatible Security Keys

For the development of FIDO Logon’s enterprise authenticator management feature, we worked with Yubico to obtain development YubiKeys. In actual enterprise deployments, collaboration with vendors (not limited to Yubico) will be necessary. The CTAP2 specification states:

An enterprise attestation is an attestation that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators.

The expectation is that enterprises will work directly with their authenticator vendor(s) in order to source their enterprise attestation capable authenticators.

The FIDO Alliance’s intent seems to be that Enterprise Attestation-enabled authenticators should be managed by the deploying enterprise and obtained through vendor collaboration. These authenticators are not intended for general distribution. Beyond the technical aspects explained here, enterprises will likely need to discuss operational processes with vendors—such as procurement procedures and protocols for lost authenticators. As noted earlier, FIDO’s core principle is that authenticators should not be trackable, so vendors will likely handle this cautiously.

・Scope of RPs That Can Use Enterprise Attestation

Even if you obtain an Enterprise Attestation-compatible authenticator, it will not provide unique identifying information to all RPs without restriction. You must define which RPs are allowed to receive this information. There are two methods:

• Vendor-facilitated enterprise attestation

  The authenticator vendor writes the allowed RP IDs into the authenticator before shipping. This requires sharing RP information with the vendor during provisioning.

• Platform-managed enterprise attestation

  Instead of writing RP IDs into the authenticator, they are specified in the platform (e.g., browser) settings. As of February 13, 2025, Google Chrome is the only browser confirmed to support this method. (*6)

Vendor-facilitated means RP IDs are set on the authenticator, while platform-managed means RP IDs are configured in the browser.

For YubiOn FIDO Logon, which implements CTAP internally, RP ID is currently fixed to fl.yubion.com, so we use the platform-managed approach. Depending on future customer requirements, we may also support vendor-facilitated mode (e.g., registration allowed only if the authenticator has fl.yubion.com RP ID set).

(*6) Chrome’s Enterprise Attestation setting can be found at chrome://flags/#web-authentication-permit-enterprise-attestation. RP IDs are entered in a text box, separated by commas for multiple entries.

・Browser and OS Support (Primarily Windows)

Information on environments supporting Enterprise Attestation is scarce online. Here’s what we know (focused on Windows):

• OS Restrictions:

  • Windows 10 is not supported; only Windows 11 works (*7).

    This is because Windows 10’s WebAuthn API (*8) version does not support Enterprise Attestation. All browsers on Windows rely on the OS WebAuthn API, so this limitation applies universally. For Windows Server, versions before 2025 are based on Windows 10, while Windows Server 2025 aligns with Windows 11.

    For Remote Desktop using WebAuthn redirection, both source and destination must be Windows 11.

• Browser Restrictions:

  • Google Chrome:

    No inherent browser limitation, but you must enable Enterprise Attestation in settings (chrome://flags/#web-authentication-permit-enterprise-attestation) and configure RP IDs for platform-managed mode.

  • Microsoft Edge:

    Unlike Chrome, Edge does not expose Enterprise Attestation settings in the UI. However, when specifying "enterprise" for attestation in WebAuthn API calls, the Windows WebAuthn API dialog clearly includes the serial number, suggesting support for vendor-facilitated mode. (We have not confirmed this fully as our authenticators lack RP ID configuration.)

    

  • FireFox:

    As of February 2025, Enterprise Attestation is not available in Firefox.

• Others:

  On Mac, Chrome can be used in the same way as on Windows by applying the appropriate settings. For Safari, version 17 did not interpret 'attestation=enterprise' (it behaved the same as 'attestation=none'). However, in version 18.3, when using an Enterprise Attestation–compatible key without RP ID configuration, it behaved similarly to the 'attestation=direct' setting. This suggests that it may support Vendor-facilitated enterprise attestation, although there is no mention of this in the release notes, so the exact details remain unclear.

(*7) When registering authenticators from the YubiOn FIDO Logon application (settings tool or logon screen), Enterprise Attestation is available even on Windows 10 systems because CTAP communication is implemented independently. However, when registering authenticators via Remote Desktop Connection, the Windows WebAuthn API is used, so both the source and destination systems must be Windows 11.

(*8) The name is confusing, but this refers to the Win32API on Windows, not the WebAuthenticationAPI on the web.

■ Summary

To summarize the technical implementation points:

• Specify "enterprise" for the 'attestation' parameter when calling the 'navigator.credentials.create' method.

• If the authenticator supports this, the resulting Attestation Statement certificate will be device-specific.

  • The certificate chain mechanism is the same as a normal Attestation Statement.

  • Depending on the vendor implementation, the certificate may include a serial number (for Yubico, it is stored in the subject field).

However, operational considerations seem to be more significant than technical implementation.

• Operational Policy and Structure:

  • How to execute the steps leading up to deployment?

  • How to manage workflows after deployment?

• Selection of Services and Systems Using Authenticators:

  • Enterprise Attestation support is likely limited among general services, so consider which services will use authenticators.

  • For in-house developed systems, additional implementation will be required:

    • Simply storing Enterprise Attestation is easy, but adding features such as credential management based on serial numbers will require further planning.

  • Decide whether to use Vendor-facilitated, Platform-managed, or a combination of both.

• Confirm Supported Environments (OS and Browser):

  • Chrome requires bulk browser setting changes.

  • Consider how to handle unsupported environments.

As the name suggests, this is an enterprise-oriented feature. It assumes managed deployment within an organization, so it’s not just a matter of “install and done.” However, for companies that can build and continuously improve operational and management structures, this feature can be a valuable aid.

In FIDO Logon, we have implemented functionality using Enterprise Attestation–compatible authenticators. Of course, even with security keys or smartphones that do not support this feature, device security can still be improved. A free version offering the same functionality as the paid version is available for a 3-month trial, so please give it a try.

If you are considering introducing Enterprise Attestation–compatible authenticators, please feel free to contact us.

■ Related Links

[YubiOn FIDO Logon]

https://fl.yubion.com

[YubiOn FIDO Logon Overview Page]

https://www.yubion.com/fidologon