.. sp-bestpractices-mds.rst .. |MDS| replace:: :term:`MDS` .. |AAGUID| replace:: :term:`AAGUID` =============================================================== Authenticator Enforcement Best Practices for Identity Providers =============================================================== Intended audience ----------------- This documentation is intended for identity providers and organizations who would like to limit authenticator selection for self-service FIDO authenticator enrollment within a bring-your-own authenticator model. Service providers likely won't have any control over which authenticator a user prefers, but identity providers that facilitate access to a specific organization will likely need to accommodate organization preferences or hard requirements for specific authenticator models. This document will outline the steps that identity providers can take to allow customers to limit end user authenticator choice while still providing the flexibility required to support custom authenticators, preview devices, technology pilots, and vulnerability remediation. Overview -------- Organizations may wish to limit FIDO authenticator use to specific makes and models to meet their security and compliance requirements. The FIDO specification supports this through a mechanism called attestation, which uses manufacturer-supplied data, aggregated in the FIDO Alliance's Metadata Service (MDS) [#fidomds]_ , to verify cryptographic signatures during authenticator registration. Identity Providers use an authenticator's |AAGUID| to identify which public keys from the MDS can validate attestation signatures. IdPs may also use the MDS to retrieve additional information, such as supported features, FIDO Alliance [#fidocert]_ or third-party certifications. For a conceptual overview of how attestation and the FIDO Metadata Service work together, see :doc:`concept-attestation` MDS Management -------------- The |MDS| is a large document [#fidomds]_, making it unsuitable for real-time validation during every new user registration. Instead, the FIDO Alliance recommends that IdPs download and ingest updated MDS blobs at least once per month [#mdsfaq]_. This ensures access to the latest device information, certifications, and security features. However, the MDS is not comprehensive. Even certified authenticators are not required to be listed. This omission may reflect privacy preferences of manufacturers or customers, particularly when devices are customized. Customer-centric enforcement ---------------------------- Do not override customer authenticator selection ================================================ While it is appropriate to offer default minimum requirements for authenticator selection, customers must always have the final say in which authenticators are approved for use in their environment. IdPs should avoid rigidly enforcing any default minimum requirements they impose. Rigidly enforcing default minimum authenticator requirements may: * Prevent customers from testing emerging features or newly developed devices. * Delay deployment of devices needed to address vulnerabilities. Instead, IdPs should warn customers when their selected authenticators do not meet default criteria, but still allow their use. This provides flexibility for organizations to align device selection with their threat models and risk tolerances. Allow custom metadata ===================== Because the MDS does not include every authenticator model, IdPs must support customers' ability to add manufacturer-provided metadata to allow enforcement for such devices. At a minimum, this includes: * The device's AAGUID * A list of valid trust anchors for attestation .. note:: An authenticator's absence from the MDS does not imply insecurity. Privacy is often the primary reason for non-listing. Examples of custom metadata needs include: * Custom AAGUIDs: Large organizations may request custom identifiers from manufacturers without disclosing this publicly. * Co-development projects: Devices under joint development may be used internally before public release or certification. Because custom metadata is sensitive, IdPs must maintain robust audit logs for its addition or removal and notify customers of any conflicts between custom and official MDS entries. .. _Use cases: Use cases ------------------------------- New AAGUIDs are issued when an authenticator's functionality or metadata changes [#aaguidkb]_ . These identifiers enable fine-grained control during enforcement, even for devices that are uncertified. Organizations may encounter legitimate use cases more frequently now that FIDO adoption has accelerated than they ever have before. This section groups related use cases into two broad classes: devices which are not certified but are listed in the MDS and devices which are not listed in the MDS but may or may not be certified. Non-certified devices with MDS metadata ======================================= These are authenticators for which manufacturers have published metadata in the MDS but have not yet completed certification. Examples include: * Preview units sent for evaluation * Production devices released before certification Preview devices may never be certified due to cost or timing constraints. While production models are usually certified eventually, this is not guaranteed. Organizations may also supply their own metadata to support these devices, but they should weigh the added risk from using non-FIDO-managed data. Authenticator verification and testing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Customers may wish to evaluate uncertified authenticators for: * Compatibility testing * Assessment of emerging technologies * Feature development with vendors Allowing AAGUIDs to be added for testing purposes reduces operational friction. It enables testing without requiring the deactivation of attestation enforcement, thus maintaining security boundaries. Vulnerability remediation ^^^^^^^^^^^^^^^^^^^^^^^^^ Vendors may assign new AAGUIDs to firmware versions that fix vulnerabilities. These updates may precede certification. If the threat from the vulnerability is greater than the risk of uncertified usage, temporarily allowing non-certified AAGUIDs can mitigate risk. Once certified, no configuration changes are needed. Customer-provided metadata ========================== Custom authenticators ^^^^^^^^^^^^^^^^^^^^^ Some organizations use devices that are not listed in the MDS. This may be due to privacy concerns or specialized requirements. Customers should have the ability to: * Add specific AAGUIDs * Provide custom metadata While these devices carry added risk, customers are responsible for evaluating and accepting that risk. Certified devices not listed in MDS ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some certified devices are intentionally excluded from the MDS. IdPs should support enforcement for such devices by allowing customers to manage metadata manually. Considerations for authenticator selection --------------------------------------------------- Security vetting and assessment =============================== **Non-certified authenticators** Organizations should evaluate uncertified devices using internal testing, documentation reviews, and compensating controls. Review the FIDO Alliance's Level 1 certification requirements to establish baseline expectations. **Custom metadata** Custom metadata introduces potential security gaps. Most metadata elements (such as supported algorithms) can be validated using the FIDO GetInfo command via tools like libfido2 [#libfido2]_ . However, attestation root certificates must be independently validated. Errors can result in failed authentications or vulnerability to spoofed devices. Allowing customers to validate that the selected attestation root certificate(s) are valid for the AAGUID in the custom metadata can be achieved by evaluating an attestation statement. **Non-attestable AAGUIDs** AAGUIDs that lack associated root certificates cannot be attested. In such cases, malicious actors could potentially spoof device identities. Mitigate this risk with compensating controls. **Implementing compensating controls** When using uncertified or non-attestable authenticators, apply additional safeguards such as: * Behavioral analytics * Risk-based authentication * IdP-specific usage policies Additional considerations ========================= * Establish a robust firmware vulnerability disclosure process * Regularly review custom metadata for continued relevance * Deprecate or remove custom AAGUIDs once they appear in the MDS with appropriate certifications * Validate AAGUID entries periodically * Prepare migration plans for deprecating unauthorized devices * Monitor for shifting security standards or new threats IdP implementation recommendations ---------------------------------- Lifecycle and MDS updates ========================= To ensure continued enforcement and alignment with FIDO guidance, IdPs should: * Download and cache the FIDO MDS blob at least monthly, as per FIDO Alliance recommendations [#fidomds]_ * Consider downloading and processing the FIDO MDS blob more frequently, to support the rapidly evolving FIDO authenticator ecosystem. * Display the current MDS version in use and the time/date of the last update * Define clear rules for metadata precedence (MDS vs. custom) * Alert customers to conflicts between metadata provided by the MDS and by custom entries * Indicate the metadata source (MDS or custom) in user interface when displaying metadata. * Support root certificate uploads for custom AAGUIDs * Warn administrators of the risks associated with using AAGUIDs missing attestation root certificate information * Detect and warn administrators of custom AAGUIDs with malformed or un-parsable attestation root certificate information Logging and API access ====================== Managing AAGUIDs and certificates is prone to human error. IdPs should support secure workflows by implementing: #. Read-only API * Provide authenticated access to AAGUID and metadata listings * Support certificate validation through the API #. Writable API * Enable automated metadata updates via secure, authenticated endpoints * Accommodate regulatory and procurement workflows #. Change logging * Record all metadata changes in detail * Use SIEM-compatible formats for logs Known incompatible devices ========================== Some IdPs, such as Entra, require device support for specific features like hmac-secret. Metadata overrides might allow unsupported devices unless properly restricted. IdPs should: * Display UI indicators for known incompatible devices * Prevent customers from uploading unsupported device metadata ------------------------ .. [#fidomds] FIDO Metadata Overview https://fidoalliance.org/metadata/ .. [#fidocert] FIDO Certification Levels https://fidoalliance.org/certification/authenticator-certification-levels/ .. [#mdsfaq] "How often should I be fetching MDS3 blob?" at https://fidoalliance.org/metadata/ .. [#libfido2] Yubico libfido2 on Github https://github.com/Yubico/libfido2/ .. [#aaguidkb] Yubico Support "Best practices for managing AAGUID changes" https://support.yubico.com/hc/en-us/articles/17779217014812-Best-practices-for-managing-AAGUID-changes