Learn about different considerations when deploying enterprise attestation
Below are a list of considerations that you should keep in mind when attempting to deploy enterprise attestation (EA) in your environment.
Not all security keys/authenticators will allow for EA. If your authenticator was not created with the ability to support EA, then it will not be able to send EA, even if allowed by a platform managed policy. Ensure that you work with your security key vendor to verify if their keys support EA, and your relying party vendor/development team to verify they support EA.
The FIDO standard recommends that an RP ID list must only be modifiable by the vendor, and must not be allowed to be modified by the customer. Ensure that if you are going the route of a vendor facilitated that you have a firm understanding of the domains that you want to allow to request EA.
Just because an application supports attestation, does not mean that it will support EA. Changes to a relying party will need to be made to ensure the attestation conveyance is set to request enterprise attestation (rather than another option like direct). Also ensure that your local attestation metadata repository includes an entry to verify the attestation certificate, and ability to parse the data sent as part of the EA (like device serial number).
Until EA is widely adopted, there may be cases where your chosen operating system, or browser may not allow for the ability for an application to request EA. Some ecosystems, like Google Chrome, require that the feature be enabled but also provides the ability to set a list of domains that are allowed to request EA.
As it currently stands, there are no known plans for passkeys created through multi-device credentials to include the ability to support enterprise attestation. The feature is supported by passkeys created on YubiKeys in the future firmware version.
Click the link below to continue to our next section where we will outline what is needed to get started deploying enterprise attestation.