FAQ’s

The FIDO Alliance started from a conversation in late 2009, introduced by Ramesh Kesanupalli who was then the CTO at Validity Sensors (a fingerprint sensor manufacturer, since acquired by Synaptics). Kesanupalli asked Michael Barrett, PayPal CISO at the time, if he was interested in fingerprint-enabling paypal.com. Barrett replied that he was, but only if it could be achieved via open standards. As there were no relevant standards that could be used, Kesanupalli then involved Taher Elgamal (the inventor of SSL), and discussions moved from there. The full history of FIDO Alliance is available here.

The FIDO Alliance publicly launched early in 2013 with six member companies. Since then the Alliance has grown to include over 250 members worldwide — please see the member list here.

The FIDO (Fast IDentity Online) Alliance is a 501(c)6 non-profit organization incorporated in mid-2012 to develop standards that address the lack of interoperability among strong authentication devices as well as the problems users face with creating and remembering multiple usernames and passwords. To learn more about the FIDO Alliance governance and structure please refer to the About FIDO page and the Membership Details page.

The FIDO Alliance website provides comprehensive information about the Alliance, its specifications, FIDO Certified products, a knowledge base of resources and best practices and general progress. You can also sign up to receive updates and invitations to future events, many of which are open to the public. You can also follow @FIDOalliance on Twitter and/or on LinkedIn.

The Alliance provides support for deployers of the technology by operating the new fido-dev@fidoalliance.org public discussion list that anyone can subscribe to. For organizations interested in detailed progress and influencing outcomes, the best way to get involved is to join the Alliance.

The FIDO Alliance has published three sets of specifications for simpler, stronger authentication: FIDO Universal Second Factor (FIDO U2F), FIDO Universal Authentication Framework (FIDO UAF) and the Client to Authenticator Protocols (CTAP). CTAP is complementary to the W3C’s Web Authentication (WebAuthn) specification; together, they are known as FIDO2.

For more information, read the Specifications Overview and/or the technical specifications on the specifications download page.

From its inception, the FIDO Alliance stated intentions to change the nature of authentication by developing specifications that define an open, scalable, interoperable set of mechanisms that supplant reliance on passwords to securely authenticate users of online services. Two years after its inception, the Alliance delivered the final 1.0 specifications on December 2014 to enable that vision. This was an important milestone on the industry’s road to ubiquitous simpler, stronger authentication, and many deployments brought FIDO Authentication to users around the globe. To further add support for FIDO Authentication across devices and platforms, FIDO Alliance published its second set of specifications, FIDO2, in March 2019. See “Why did the FIDO Alliance see the need for FIDO2?” for more information.

The FIDO Alliance has published three sets of specifications for simpler, stronger authentication – FIDO U2F, FIDO UAF and FIDO2 – in order to provide for the widest range of use cases and deployment scenarios:

FIDO U2F supports a second factor experience, while FIDO UAF supports a passwordless experience. The newest set of specifications, FIDO2, supports passwordless, second-factor and multi-factor user experiences. For more details on the specifications, see our Specifications Overview.

All FIDO standards are based on public key cryptography, are strongly resistant to phishing and protect user privacy (for more information, see How FIDO Works).

Many leading organizations around the world have deployed FIDO Authentication to their employees and users, reducing their security risks and improving user experience. Check out our homepage under “who’s using FIDO” for a sample.

The FIDO Alliance developed its FIDO2 specifications with the W3C to enable FIDO Authentication capabilities to be built into a wider array of devices, platforms and web browsers. FIDO is currently supported in Google Chrome, Mozilla Firefox, Microsoft Edge and Apple Safari (MacOS), iOS web browsers, as well as Windows 10 and Android platforms.

FIDO takes a “lightweight” approach to asymmetric public-key cryptography, which offers service providers a way to extend the security benefits of public-key cryptography to a wider array of applications, domains and devices – especially where traditional PKI has proven difficult or impossible. FIDO is not a replacement for PKI but rather complements it, enabling a greater number of users and applications to be protected using asymmetric encryption. This is especially important in situations where the alternative has been username and password.

Please see the required steps on the FIDO Alliance membership web page.

There are significant benefits to taking part in FIDO Alliance as a member, whether your company is a vendor looking to bring FIDO-based solutions to market, or if your organization is a service provider seeking to understand the most effective ways to deploy FIDO Authentication to your customers and/or employees. You can learn more here.

Open industry standards assure that existing and future products and offerings are compatible and that anyone can evaluate the technology. Users can depend on their FIDO devices working wherever FIDO authentication is supported. Service providers and enterprises can accommodate various devices and services without having to make new investments or reverting to proprietary configurations.

Similar to the development of WiFi, Bluetooth, NFC, and other standards, FIDO is developing a new set of industry protocols. Any device manufacturer, software developer and/or online service provider can build support for FIDO protocols into their existing products and services to make online authentication simpler and stronger for their users. With the goal of standardization, the FIDO ecosystem can grow and scale by means of the “net effect”, where any new implementation of the standards will be able to immediately interoperate with any other implementation without the need for any pre-established arrangement between device developer and service provider.

The FIDO Alliance Certification Working Group is responsible for testing products for conformance to FIDO specifications and interoperability between those implementations. You can learn more about the FIDO® Certified program here.

FIDO Alliance members have all committed to the promise contained within our Membership Agreement to not assert their patents against any other member implementation of FIDO 1.0 final specifications (referred to as “Proposed Standard” in our Membership Agreement). Anyone interested in deploying a FIDO compliant solution can do so without joining the Alliance, and they are strongly encouraged to use FIDO Certified products to enable that deployment.

FIDO specifications are device-agnostic and support a full range of authentication technologies, including FIDO Security Keys and biometrics such as fingerprint and iris scanners, voice and facial recognition, as well as PIN or pattern-protected microSD cards. FIDO specifications will also enable existing solutions and communications standards, such as Trusted Platform Module (TPM), USB Security Tokens, embedded Secure Elements (eSE), Smart Cards, Bluetooth Low Energy (BLE), and Near Field Communication (NFC). Because FIDO specifications are open, they are designed to be extensible and to accommodate future innovation, as well as protect existing investments.

FIDO specifications allow users a broad range of choice in devices that meet their needs or preferences, as well as those of service providers, online merchants, or enterprises where users must authenticate.

FIDO’s specifications are public and available for anyone to read and analyze. But only FIDO Alliance Members benefit from “the promise” to not assert patent rights against other members’ implementations (see the FIDO Alliance Membership Agreement for details). Anyone may join the FIDO Alliance; we encourage even very small companies with a very low cost to join at the entry level. Members at all levels not only benefit from the mutual non-assert protection, but also participate with FIDO Alliance members, activities and developments; Associates have more limited participation benefits(https://fidoalliance.org/members/membership-benefits/). All are invited to join the FIDO Alliance and participate.

No. FIDO Alliance only specifies standards for strong authentication and tests implementations for compliance to those standards; the Alliance does not provide services or equip devices or sites. Device manufacturers, online service providers, enterprises and developers use the FIDO specifications to build products, provide services, and enable sites and browsers with FIDO authentication. Under FIDO specifications, the user’s credentials must remain on the user’s device, and they are never shared with a provider or service.

No, this type of information exchange is prevented with FIDO Authentication. Each device/website pairing requires separate registration and a separate cryptographic key pair. Once registered, a user can easily authenticate to multiple sites from the same device, yet each site has no knowledge of the user interactions with other sites. FIDO does not introduce any new tracking mechanism that could be used to correlate user activity online.

The FIDO Alliance recently launched the Authenticator Certification Program. This program introduces Authenticator Security Requirements to the FIDO Certification Program specifically for authenticators. Each authenticator that is certified under the FIDO Certification program is validated to meet specific security assurance levels depending on the level of security the vendor is seeking. The higher the level, the greater the security assurance. More information about this program can be found here: https://fidoalliance.org/certification/authenticator-certification-levels/.

Unlike current password-based authentication models that have proven vulnerable to mass-scale attacks and fraud, FIDO authentication credentials are never shared or stored in centralized databases. FIDO credentials are known and maintained only by the user’s own device. All that is ever stored by the service provider are the public keys paired to the user’s device where the private keys are stored. For additional security and privacy, biometrics used in FIDO Authentication never leave the device. This security model eliminates the risks of phishing, all forms of password theft and replay attacks. A would-be attacker would need the user’s physical device to even attempt a hack (see below, “can’t someone break into an account if they steal a device?” for more information). The password ecosystem has afforded attackers with great return on investment with relatively limited risk; the FIDO ecosystem is far more difficult, expensive and risky for attackers to profit from.

When used in FIDO Authentication, user biometric data never leaves the device and is never stored on a central server where it could be stolen in a breach. FIDO’s on-device model for authentication eliminates the risk of a remote attack. If a would-be attacker had access to the user’s actual device, a successful spoof would be quite difficult. First, the attacker must obtain a perfectly formed, complete latent print that is also enrolled on the target user’s device. Then, the attacker must gain access to the user’s device in order to control only that one device. The single spoof, even if accomplished, doesn’t approach the potential harm done by today’s typical mass-scale attack, which can result in harvesting millions and hundreds of millions of users’ credentials.

No. In order to break into an account, the criminal would need not only the user’s device that was registered as a FIDO Authenticator to the account but also the ability to defeat the user identification challenge used by the Authenticator to protect the private keys – such as a username and PIN or a biometric. This makes it extremely difficult to break into a FIDO-enabled account.

The purpose of the FIDO model is to provide a secure and simple authentication experience for online services. The authentication involves a user with a device connecting to a service over a network.

Yes, you can use multiple websites from one FIDO device. Each device/website pairing requires a separate registration and a separate cryptographic key pair. Once registered, a user can easily authenticate to multiple sites from the same device, yet each site has no knowledge of the user interactions with other sites.

If a user acquires a new device or wants to use multiple FIDO devices, the user needs only register each of the devices at the sites where he wants to use them. Once a device is registered at a site, it will be recognized whenever the user needs to authenticate at that site. When a user visits a site with a new device that hasn’t been registered, and thus isn’t automatically recognized, the user will be prompted to register the new FIDO device to enable FIDO authentication with the new device at that site.

Yes, FIDO authentication can be deployed in an enterprise environment. It provides enterprises with significant benefits such as reduced cost of strong authentication deployment and support. There is an active Enterprise Deployment Working Group within the Alliance that produces white papers on best practices. This guidance can be located within the FIDO Knowledge Base. In the Knowledge Base, you can also learn how Google deployed FIDO across their 85,000 employees resulting in no known successful phishing attacks.

FIDO2 is the overarching term for FIDO Alliance’s newest set of strong authentication standards. FIDO2 includes two specifications: W3C’s Web Authentication (WebAuthn) and FIDO Alliance’s Client to Authenticator Protocol (CTAP).

FIDO2 standards enable users to leverage common devices to easily authenticate to online services in both mobile and desktop environments, and with much higher security over passwords and SMS OTPs.

FIDO2 includes two specifications:

• W3C WebAuthn. The Web Authentication specification defines one standard web API to enable browser users to sign in with a cryptographic key pair that is stronger than a password. The specification supports passwordless and second factor logins. The specification allows strong FIDO Authentication across all web browsers and related web platform infrastructure. (see question “What is the relationship between FIDO2 and W3C WebAuthn?” for more information.)
• FIDO CTAP. CTAP enables browsers and operating systems to talk to external authenticators, like USB-based devices, NFC- and Bluetooth-enabled devices, and removes the requirement for users to re-register on every device they use. With this specification, a user could log in to their computer, tablet, IoT device, etc. via the browser or platform using, for example, a connected device or their mobile phone – with the latter being an entirely new use case introduced with CTAP.

FIDO2 is the official name for the complete set of FIDO’s latest standards.

The FIDO Alliance goal has always been ubiquitous strong authentication across the web. That means building support for FIDO Authentication into every device that people use every day. The Alliance made notable progress with its initial FIDO U2F and FIDO UAF specifications, especially on mobile platforms. FIDO2 expands the reach of FIDO Authentication by making it a built-in feature across browsers and web platforms, which is a significant step toward the Alliance’s overall goal.

A good rule of thumb is to remember this simple equation:

FIDO2 = W3C WebAuthn + CTAP

This is the full story of FIDO2’s development:

After the release of the FIDO UAF and FIDO U2F specifications, FIDO Alliance focused on making FIDO Authentication more accessible to users worldwide. The Alliance developed three technical specifications that defined one web-based API, enabling FIDO Authentication to be built directly into browsers and platforms. These specifications were submitted to the W3C, the international standards organization for the World Wide Web, in November of 2015. FIDO Alliance member companies worked within the W3C’s Web Authentication Working Group to finalize the API, which became known as WebAuthn. WebAuthn was officially recognized as a W3C web standard in March 2019.

In the same time period, the FIDO Alliance created and finalized a complementary specification to WebAuthn: the Client to Authenticator Protocol (CTAP). CTAP makes WebAuthn even more accessible to users by allowing them to use the devices they already own, such as their mobile phone, security key or Windows 10 PC to authenticate to WebAuthn-enabled browsers and platforms.

Together, WebAuthn and CTAP are called FIDO2. The FIDO Alliance manages and maintains the certification program to ensure interoperability of all the FIDO2 implementations in the market – clients, servers and authentication devices.

FIDO Alliance partnered with W3C to standardize FIDO Authentication for the entire web platform so the FIDO ecosystem could grow by an entire community of web browsers and web application servers supporting the standard. W3C is where the web community produces their standards, so it was more practical to work in that forum.

FIDO2 standards are published and available for implementation today. WebAuthn reached W3C’s final Recommendation status in March 2019 and is an official web standard. CTAP is a final FIDO Alliance specification.

Current adoption status is available here.

The specifications under FIDO2 support existing passwordless FIDO UAF and FIDO U2F use cases and specifications and expand the availability of FIDO Authentication. Users that already have external FIDO-compliant devices, such as FIDO U2F security keys, will be able to continue to use these devices with web applications that support WebAuthn. Existing FIDO UAF devices can still be used with pre-existing services as well as new service offerings based on the FIDO UAF protocols.

Not at all. FIDO U2F capabilities have merged into FIDO2’s CTAP2 protocol, and FIDO U2F security keys will continue to work with services that support U2F authentication as well as those that have support FIDO2 authentication.

FIDO Alliance provides interoperability testing and certification for servers, clients, and authenticators adhering to FIDO2 specifications. Additionally, the Alliance has introduced a new Universal Server certification for servers that interoperate with all FIDO Authenticator types (UAF, U2F, CTAP). As a best practice, the FIDO Alliance recommends online services and enterprises deploy a Universal Server to ensure support for all FIDO Certified Authenticators.

FIDO Alliance’s work is just beginning. The specifications and certification programs are continuing to evolve, and our deployment work is taking on even greater importance. Additionally, the Alliance has just launched new work areas in IoT and identity verification, which leverage the Alliance’s broad coalition of leading organizations from around the world to help standardize technologies adjacent to user authentication. For more information on these work areas, read https://fidoalliance.org/fido-alliance-announces-id-and-iot-initiatives/.

The Alliance announced new work areas to develop standards and certification programs in identity verification and the Internet of Things (IoT).

Ultimately, the Alliance is striving to increase the efficacy and market adoption of FIDO Authentication by addressing adjacent technology areas that leave security vulnerabilities on the web. There is a gap between the high assurance provided by FIDO Authentication standards and the lower assurance methods used in identity verification for account recovery and IoT authentication. The Alliance aims to strengthen identity verification assurance to support better account recovery and automate secure device onboarding to remove password use from IoT.

Identity verification and IoT security are both adjacent to the FIDO Alliance core focus on user authentication. For accounts protected by FIDO Authentication, identity verification for the account recovery process when a FIDO device is lost or stolen becomes critical to maintaining the integrity of the user’s account. With IoT devices, typical industry practices is to ship them with default password credentials and manual onboarding, which leaves them open to attack. The security gaps in both of these areas can most effectively addressed through industry collaboration and standardization rather than siloed, proprietary approaches.

The Alliance has formed two new working groups: the Identity Verification and Binding Working Group (IDWG) and the IoT Technical Working Group (IoT TWG) to establish guidelines and certification criteria in these areas. The FIDO Alliance will continue to focus on development and adoption of its user authentication standards and related programs and use them as a foundation for this expanded work, with contributions from current members and new industry participants.

The FIDO Alliance has identified newer remote, possession-based techniques including biometric “selfie” matching and government-issued identity document authentication as having the potential to greatly improve the quality of identity assurance for new account onboarding and account recovery. The IDWG will define criteria for this type of remote identity verification, as well as others, and develop a certification program and educational materials to support the adoption of that criteria.

The IoT TWG will provide a comprehensive authentication framework for IoT devices in keeping with the fundamental mission of the Alliance – passwordless authentication. The IoT TWG will develop use cases, target architectures and specifications covering: IoT device attestation/authentication profiles to enable interoperability between service providers and IoT devices; automated onboarding, and binding of applications and/or users to IoT devices; and IoT device authentication and provisioning via smart routers and IoT hubs.

The IDWG and IoT TWG are now open to industry participants. Participation in FIDO Alliance working groups is open to all board and sponsor level members of the FIDO Alliance. For more information on joining the Alliance, visit https://fidoalliance.org/members/membership-benefits/.

By taking part in FIDO Alliance’s technical working groups, members have the ability to shape and have early visibility into FIDO’s technical output – which can help accelerate product and service development. Participating in the working groups will also enable your team to get peer-based feedback to aid with your own implementations, while also creating an opportunity to have your company’s vision reflected in deployment guidelines and recommendations.

Vendor companies looking to bring FIDO-based solutions to market and/or organization service providers seeking to understand the most effective ways to deploy FIDO Authentication will benefit the most from participating in FIDO Alliance working groups.

The FIDO Alliance Metadata Service (MDS) is a web-based tool where FIDO authenticator vendors can publish metadata statements for FIDO servers to download. This provides organizations deploying FIDO servers with a centralized and trusted source of information about FIDO authenticators.

More extensive FAQs related to the FIDO Alliance Metadata Service are available here.

Start by making sure your implementation passes the conformance tests (registration required). After you’ve validated your implementation, register for an Interoperability event and you’re on your way to certifying your product.

Yes. There is a recognizable FIDO Certified logo for vendors to include with their web sites, product materials, packaging, etc.

Use of the FIDO Certified logo will require signing a TMLA. There is a streamlined process for Relying Parties that wish to use the certification logo on their websites, which includes a “clickless” license agreement.

A product is certified indefinitely as long as the code base of its FIDO implementation doesn’t change in any substantial way. Certification can only be terminated in rare instances, such as determining that an implementation improperly passed test tools or interoperability events. Certification only applies to a specific specification and implementation class (i.e. “UAF Authenticator”). If new major version of specifications are released (as determined by the FIDO Certification Working Group) and an implementation would like to claim conformance with that specification, new certification will be required.

The UAF authenticator specification defines an AAID field that is half Vendor ID and half Device ID used to uniquely identify each authenticator. The Vendor ID is a unique identifier assigned by FIDO to each company implementing a UAF authenticator. The other half of the AAID field, the Device ID, is assigned to the authenticator by the implementing company. Only UAF Authenticators require a Vendor ID.

Yes. Non-members are welcome to certify their implementations.

FIDO members can certify an implementation of UAF server, client or authenticator; or U2F server or authenticator for $5,000 per certification. Derivatives (implementations that are the same code embedded into a different product) can be registered for $500 each. Non-member rates are $6,500 for certifications and $750 for derivatives. These fees cover the trademark licensing, interoperability event, test tool usage and support, and documentation processing.

Interoperability events occur at least every 90 days, but may occur more frequently based on implementer demand.

Derivative certification was created to streamline the certification process for implementers that have a large volume of certifications that are essentially all based on the same implementation. In this case, implementers may certify one implementation and the rest may be registered as “derivatives” of that base certification. Derivatives don’t require attending interoperability events to achieve certification, but they do require that the derivative implementation run and pass conformance testing. The implementation cannot change in any substantial way from the original certification earned via our test tools and interoperability testing. If there are changes to the implementation, then it will need to go through the FIDO Impact Analysis to determine if the implementation requires a Delta Certification or Recertification.

No. But a product must be certified to claim to be FIDO Certified and use the FIDO Certified logo.

The FIDO Alliance staff will audit on a monthly basis the usage of FIDO Certified logos and published claims of certification. Auditing of actual implementations will be driven by market feedback. Should any concerns arise, feedback can be submitted through the Certified Logo Violation form.

The FIDO Alliance issued Certificates have the following numerical format:

SSSXYZAYYYYMMDD####

SSS – Specification number (UAF or U2F)

X – Specification number

Y – Specification minor number

Z – Specification revision number

A – Specification errata number

YYYY – Year issued

MM – Month issued

DD – Day issued

#### – The number of the certificate issued today

No. Only products that have passed through FIDO Certification program and have been granted a certification number can claim to be FIDO Certified.

Yes. Implementations must request certification (and pay the certification fees) for each implementation class they are seeking to certify. For example, if an implementation certifies for both a FIDO UAF Server and a FIDO2 Server, that implementation must follow the certification process for both (and pay the certification fees for both). The implementation would ultimately receive two certifications. The primary difference between testing for different specifications is they have different test tools and the different interoperability events.

For those interested in the FIDO UAF program, an additional Vendor ID fee of $3,000 is required for FIDO UAF authenticators only and will be credited towards the certification fee upon completing the certification process and applying for FIDO Certification.

Certification starts with self-assessment of specification conformance through the use of FIDO Alliance provided test tools, followed by interoperability testing with at least three test partners at FIDO Alliance-proctored test events. At this time, there is no lab aspect to the certification program, but the Certification Working Group is currently reviewing requirements to develop and implement a Functional Lab Accreditation program. See the Getting Started web page to learn more.

There are four major testing steps:

1. Conformance self-validation; which uses test tools to ensure that an
   implementation is conformant to the specification.
2. Interoperability testing; where implementers gather to test their implementations together.
3. Certification registration; where the implementation is submitted to FIDO for certification.
4. Optional trademark agreement; enabling the FIDO certification mark to be used with a product or service.

Yes, all authenticators must meet additional security requirements and select at least Level 1 (L1) Authenticator Certification. There are five major testing steps for authenticators and it depends on the level of security selected:

Level 1:

1. Conformance self-validation; which uses test tools to ensure that an
   implementation is conformant to the specification.
2. Interoperability testing; where implementers gather to test their implementations together.
   1. Authenticators are required to show additional interoperability based on the FIDO Authenticator Security Requirements during interoperability.
3. Authenticator Certification processes;
   1. Complete the Vendor Questionnaire for all L1 requirements according to the implementations specification (i.e. UAF, U2F, or FIDO2).
   2. Submit the completed Vendor Questionnaire to FIDO for review by the FIDO Security Secretariat.
4. Certification registration; where the implementation is submitted to FIDO for certification. All certification processes will be verified complete prior to certificate issuance.
5. Optional trademark agreement; enabling the FIDO certification mark to be used with a product or service.

Level 2 and higher:

1. Conformance self-validation; which uses test tools to ensure that an
   implementation is conformant to the specification.
2. Interoperability testing; where implementers gather to test their implementations together
3. Authenticator vendor selects from a list of accredited security labs and negotiates the evaluation process:
   1. Vendor completes the Vendor Questionnaire based on level selected and specification and submits completed questionnaire to the contract lab for evaluation
   2. Lab will complete the evaluation in conjunction with the vendor.
   3. Lab will submit a completed FIDO Evaluation Report to the FIDO Security Secretariat for final result validation.
4. Certification registration; where the implementation is submitted to FIDO for certification. All certification processes will be verified complete prior to certificate issuance.
5. Optional trademark agreement; enabling the FIDO certification mark to be used with a product or service.

The implementation must satisfy two main criteria: that it is conformant to the FIDO specification (to the best of our ability to determine that) and that it is known to interoperate with other implementations. This should provide both businesses and consumers with confidence that a FIDO Certified implementation delivers the FIDO values of stronger, simpler, authentication.

Most likely that an implementation has some bugs to work through before being considered an exemplar of FIDO.

No. However, the manufacturer must be a company who has registered with the FIDO Alliance and obtained a valid FIDO Alliance vendor ID. There is a field in the metadata that indicates whether or not the product is FIDO Certified because some relying parties may prefer products that are FIDO Certified.

Biometric Component Certification Program – the first such program for the industry at large. The program utilizes accredited independent labs to certify that biometric subcomponents meet globally recognized performance standards for biometric recognition performance and Presentation Attack Detection (PAD) and are fit for commercial use.

The FIDO Alliance aims to deliver several benefits to providers and users of biometric recognition systems through the new Biometric Component Certification Program. Until now, due diligence was performed by enterprise customers who had the capacity to conduct such reviews. This required biometric vendors to repeatedly prove performance for each customer.

The FIDO Alliance program allows vendors to test and certify only once to validate their system’s performance and re-use that third-party validation across their potential and existing customer base, resulting in substantial time and cost savings. For customers, such as regulated online service providers, OEMs and enterprises, it provides a standardized way to trust that the biometric systems they are relying upon for fingerprint, iris, face and/or voice recognition can reliably identify users and detect presentation attacks.

No, the Biometric Component Certification program is separate from the FIDO Certified program. A vendor would need to go through the FIDO Authenticator Certification Program to become FIDO Certified. The FIDO Authenticator Certification Program validates that the biometric authenticator conforms to cryptographic FIDO specifications, interoperates with other products in the market and meets certain security requirements in addition to biometric performance.

For authenticators that incorporate biometric sensors, the biometric subcomponent certificate is required in order to achieve the highest levels of FIDO Authenticator security certification but remains optional for the lower levels of assurance. Only those that successfully complete the FIDO Authenticator Certification Program can use the FIDO or FIDO Certified trademarks.

The requirements for the Biometric Component Certification program were developed in accordance with ISO standards: ISO/IEC 19795 and SO/IEC 30107.

No, the testing is completed by an accredited third-party lab. You can view the list of accredited labs here: https://fidoalliance.org/certification/biometric-component-certification/fido-accredited-biometric-laboratories/

The list of the accredited laboratories and further information about the accreditation process can be found at https://fidoalliance.org/certification/biometric-component-certification/fido-accredited-biometric-laboratories/

Visit https://fidoalliance.org/certification/biometric-component-certification/ for an overview of the testing process for the Biometric Component Certification program.

The https://fidoalliance.org/certification/biometric-component-certification/ is open to all biometric authenticator subcomponents.

Those vendors who achieve certification receive a Biometric Subcomponent Certificate to show they have passed the well-defined testing administered by the FIDO Alliance and accredited labs.

Biometric technology suppliers interested in participating in the program can visit https://fidoalliance.org/biometric-component-certification-program to get started.

With more than 600 FIDO Certified products in the market, FIDO Authentication represents the best way for organizations to implement simpler, stronger authentication that meets GDPR’s rigorous requirements – by at the same time enhancing the user experience. Read “FIDO Authentication and the General Data Protection Regulation” (GDPR) to learn more.

Yes! FIDO standards give organizations an easy-to-deploy way to meet PSD2 SCA requirements while meeting organizational and user demand for transaction convenience. We detail exactly why and how in the paper “FIDO & PSD2: Meeting the Needs for Strong Consumer Authentication.”

IoT device onboarding involves the installation of the physical device and the setup of credentials so that it can securely communicate with its target cloud or platform. Today this onboarding process is usually done manually by a technician – a process that is slow, expensive, and insecure. Industry sources have said that it is not uncommon for the cost of installation and setup to exceed the cost of the device itself.

As a result, businesses are crying out for a “USB of the internet” – a way to connect devices to their networks as simply, securely and effectively as plugging a keyboard into a PC. FDO solves the security and onboarding problem holding IoT back by giving businesses a fully automated, standards-based and secure set-up process.

With FDO, organizations no longer have to pay more for the lengthy and highly technical installation process than they do for the devices themselves. Instead, they can decide which networks and cloud platforms they want to onboard devices to at the point of installation (as opposed to manufacture). This is significant in several ways. For manufacturers, they no longer need to create a separate SKU for each customer. For installers, they no longer need high cost technicians to onboard devices, and no sensitive or business-critical information is needed to add a device to a network. The result is a more scalable, cost-effective and secure method for onboarding IoT devices.

FDO offers these features and benefits:

Simplicity – Businesses no longer have to pay more for the lengthy and highly technical installation process than they do for the devices themselves. The highly automated FDO process can be carried out by people of any level of experience quickly and efficiently.

Flexibility – Businesses can decide which cloud platforms they want to onboard devices to at the point of installation (as opposed to manufacture). A single device SKU can be onboarded to any platform, thereby greatly simplifying the device supply chain.

Security – FDO leverages an “untrusted installer” approach, which means the installer no longer needs – nor do they have access to – any sensitive infrastructure/access control

Read the paper here to get the full explanation of how onboarding works with FDO.

At the time of installation, an installer performs the physical installation of the IoT device. FDO protocols are invoked when the device is first powered on. By protocol cooperation between the device, the Rendezvous server, and the new owner, the device and new owner are able to prove themselves to each other, sufficient to allow the new owner to establish new cryptographic control of the device. When this process is finished, the device is equipped with credentials supplied by the new owner. Read the paper here to get the full explanation of how onboarding works with FDO.

As it stands, the term “end-user” really refers to an organization rather than an individual. Stakeholders have an interoperable way of onboarding devices from any manufacturer in a secure interoperable way across the supply chain.

There isn’t necessarily a distinction between end-users and service providers/cloud providers because apps can be utilized locally and/or cloud services in the background.

The interoperability of FDO makes it very attractive to manufacturers. Late-binding and interoperability mean a manufacturer can produce one SKU and know it can be deployed securely in any FDO-compatible environment. In the past, manufacturers needed to create a separate SKU for each different deployment environment.

FDO leverages an “untrusted installer” approach, which means a specialized installer is no longer needed and the installer no longer needs – nor do they have access to – any sensitive infrastructure/access control. This makes installation of devices quicker, more cost efficient and secure.

Currently a certification program is being developed, and we are determining the testing criteria as well as looking at existing FIDO certification.

Adoption is already taking place with companies such as Molex, IBM, BT and Intel. See the paper here for some comments from early adopters.

FIDO Device Onboard was developed through the work of the Alliance’s IoT Technical Working Group, led by co-chairs Richard Kerslake, Intel, Giridhar Mandyam, Qualcomm, and vice-chair Geof Cooper, Intel. Additional companies with specification editors including Amazon Web Services (AWS), Google, Microsoft, and ARM.

A FIDO Authentication credential that provides passwordless sign-ins to online services.

A passkey may be synced across a secure cloud so that it’s readily available on all of a user’s devices, or it can be bound to a dedicated device such as a FIDO Security Key.

The exact user experience may vary from platform to platform, but usually, the user will authorize the use of the credential with a device biometric (TouchID, FaceID, Windows Hello, etc.), or by typing a device secret (screen unlock PIN, device login PIN, etc.)

Apple, Google and Microsoft have announced plans to implement passkeys in their respective platforms.

An update to the Client to Authenticator Protocol (CTAP) will add a hybrid transport method to enable cross-device, cross-ecosystem credential usage. For example, a single- or multi-device credential could be presented from a phone in ecosystem A to a laptop in ecosystem B.

Today, Security Keys hold single-device credentials, as they are bound to the authenticator. Security Key vendors may decide to offer passkey authenticators in the future.

We expect all platforms implementing passkeys to adhere to FIDO’s Privacy Principles, including usage of personal data for the sole purpose of FIDO operations.

Yes, there are no changes to user verification methods or their security properties as part of the effort – and user biometrics will never leave the device.

FIDO Alliance’s mission is to help reduce the world’s over-reliance on passwords. It is true that some relying parties (and their users) get value out of hardware-bound credentials, and the FIDO standards still support this type of deployment. 

But for many relying parties, the fact that FIDO’s approach required users to enroll each new device presents some customer usability challenges, and also limits their ability to replace passwords (as passwords frequently serve as a means to verify new authenticator enrollment).

As such, replacing the password with a challenge-response protocol based on asymmetric cryptography is a huge step forward in security, even if those cryptographic keys aren’t bound to hardware – as this helps RPs thwart the constant threats of phishing, credential stuffing and other remote attacks.

Each authenticator / platform may offer different experiences and controls. But a user can always register a second credential with a site and remove the first, effectively “moving” from one to the other.

Passwords and second-factors such as OTPs and Phone Approvals are inconvenient and insecure. They can be phished, and they are being phished at scale today. Passkeys are designed to solve this problem. They have three fundamental advantages over using passwords (even when used with traditional second-factors):

• Sign-in is easier for the user: It’s the same biometric or PIN users use to unlock their device. The user doesn’t need to deal with typing passwords or OTPs.

• Sign-in is fundamentally safer (phishing-resistant): Phishing-resistance of sign-in is a core design goal of FIDO and is built into every sign-in event that leverages FIDO. Furthermore, breaches of password databases (which can be an attractive target for hackers) no longer pose a threat.

Sign-in is more robust: Users often forget passwords and don’t set up backup emails and phone numbers. With multi-device FIDO credentials, the credentials are backed up and are therefore protected from loss. If the user gets a new phone the credentials can easily be restored to the new phone. When signing in from a new device, the existence of a multi-device credential is a powerful trust signal that websites can leverage to make recovering access to the account radically safer and simpler, since it means that the platform vendor has already verified the user.

Passkeys will have built-in support in the main mobile and desktop operating systems and browsers, similar to the support which already exists for  single-device FIDO credentials. Services would use the built-in WebAuthn and FIDO APIs to exercise FIDO credentials in the service’s websites and apps.

Device OS platforms are working on a feature by which the FIDO credentials on the device (for example, a mobile phone or laptop computer) are synced to the device’s cloud backup tied to the user’s platform account (eg, Apple ID for iOS/macOS, Google account for Android & ChromeOS, Microsoft account for Windows).

When a user creates a passkey on any of their devices, it gets synced to all the user’s other devices running the same OS platform which are also signed into the same user’s platform account. Thus credentials created on one device become available on all devices.

Notably, if the user gets a new device with the same Platform OS and sets it up with their platform account, the FIDO credentials are synced to the new device and are available for sign-in to services on the new device.

This is best understood with an example: say the user has an Android phone where they already have a credential for the RP. Now they want to sign-in to the RP’s website on a Windows computer where they have never signed into the website before.  

For existing devices, the user will point their browser to the RP’s website on the Windows computer. They see a ‘sign-in’ button on the login web page and hit that button.The user sees the option to add a new phone or use a previously paired one.  If the user selects the paired phone and the phone is physically close (in BLE range) to the Windows computer the user sees a pop-up from the Android OS asking in essence “I see you are trying to sign-in on this nearby computer, here are the accounts I have.” The user chooses an account at which point the Android OS asks “Please perform your unlock to approve sign-in to the computer with this account”. The user performs the unlock and they are signed-in to the website

Alternatively, the user can use a security key that has been enrolled with the RP.  In this instance, the user will point their browser to the RP website on the Windows computer. They see a ‘sign-in’ button on the RP’s login web page and hit that button. When the RP asks for FIDO authentication, the user is able to insert or tap their Security Key to unlock and they are signed-in to the website.

The flow described in this example would work regardless of the OS the user’s mobile phone is running and the OS and browser available on the target device for login (eg, computer, tablet, TV etc). The target user experience is very similar to that of a Phone Approval prompt commonly used today as a second-factor today. The crucial difference is that the approval is now phishing-resistant — this is because, when you approve a login on another device on a conventional phone approval, you don’t really know whether your other device is pointed to the correct website or a look-alike phishing site relaying information in real-time. In addition, the mobile phone approval also replaces the password (as opposed to being used as a second factor adjunct).

If the user still has their old device, they can use it to sign into their new device (using the above-mentioned update to CTAP for cross-device authentication across platforms). If they don’t, then the RP can treat sign-in from the new device (which might be from a different vendor) as a normal account recovery situation and take appropriate steps to sign in the user. The RP would then usually create a new multi-device credential on the new device (which runs a different platform OS than the user’s previous device). If the user no longer plans to use their old device, they can let the RP know, and the RP can then delete the credential of the old device from their server records — thus, the credential on the old device will no longer be accepted for sign-in.

If the user is still in possession of their old device, the RP can also use the credential on that old device (say, an Android device) to sign the user into the new device (say, an iOS device) without going through an account recovery step. See previous question for more detail the old mobile can be used to sign-in to the new mobile in a simple phishing resistant way.

Additionally, a user can use a security key to securely authenticate to a new device.

The cross-device authentication flow uses Bluetooth to verify physical proximity and does not depend on Bluetooth security properties for the actual security of the sign-in. Instead, it uses standard cryptographic primitives at the application layer to protect data.

Passkeys are present on a user’s devices (something the user “has”) and – if the RP requests this – can only be exercised by the user with a biometric or PIN (something the user “is” or ”knows”). Thus, authentication with passkeys embodies the core principle of multi-factor security.

FIDO’s phishing-resistant sign-in capabilities are both built right into devices (platform authenticators) and are available in external authenticators (Security Keys). Platform authenticators which support Passkeys will be built into the phones and laptops. Platform Authenticators when used cross device are considered external authenticators to the platform the web browser is on. These authenticators will enable widespread adoption and will simplify the developer experience since the APIs are built into the platform.

Security Keys (external authenticators) are special-purpose authentication devices designed to cover a wide range of authentication use cases. The Security Key is also supported on these platforms and is designed to enable additional use cases for the RP. FIDO Alliance encourages RPs to enable both platform and external authenticators and to tailor the set of use cases specifically for the RP’s user population and design requirements.

Please send inquiries to info@fidoalliance.org, or to the public FIDO developer community at fido-dev@fidoalliance.org.