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.

Fees are per implementation certified and must be paid before a Certificate will be issued.

For an overview of the FIDO Certification Fees per program, please go to the Certification Fees page.

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.

Any passwordless FIDO credential is a passkey.

Passkeys are a password replacement that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys are resistant to phishing, are always strong, and are designed so that there are no shared secrets.

They simplify account registration for apps and websites, are easy to use, work across all of a user’s devices, and even other devices within physical proximity.

From a technical standpoint, passkeys are FIDO credentials that are discoverable by browsers or housed within native applications or security keys for passwordless authentication. Passkeys replace passwords with cryptographic key pairs for phishing-resistant sign-in security and an improved user experience. The cryptographic keys are used from end-user devices (computers, phones, or security keys) for user authentication.

Passkeys that are managed by phone or computer operating systems are automatically synced between the user’s devices via a cloud service. The cloud service also stores an encrypted copy of the FIDO credential. Passkeys can also by design be available only from a single device from which they cannot be copied. Such passkeys are sometimes referred to as “single-device passkeys”. For example, a physical security key could contain multiple single-device passkeys.

The word “passkey” is a common noun; think of it the way you would refer to “password”. It should be written in lowercase except when beginning a sentence. The term “passkey” (and plural form “passkeys”) is a cross-platform general-use term, not a feature tied to any specific platform.

When delineation is required, passkeys that are synced between user’s devices via a cloud service are generally referred to as “synced passkeys”, and those that never leave a single device (including those on UAF apps) are referred to as “device-bound passkeys”.

The primary use-case for passkeys is replacing the password as the first/primary factor for account authentication.

For example, a user could sign in to web services using a passkey — instead of a password — on their mobile phone. Since phone based passkeys sync across all of a user’s devices, the process of upgrading to a new mobile phone is a seamless transition.

When a user is asked to sign in to an app or website, the user approves the sign-in with the same biometric or PIN or on-device password that the user has to unlock their device (phone, computer, or security key). The app or website can use this mechanism instead of the traditional username and password.

Yes. There is no change to the local biometric processing that the user devices (mobile phones, computers, security keys) do today. Biometric information and processing continues to stay on the device and is never sent to any remote server — the server only sees an assurance that the biometric check was successful.

For years, passwords have been subject to phishing attacks and credential stuffing attacks, due to the prevalence of password reuse and database breaches.

Because the primary factor — the password — is fundamentally broken in multiple ways, the industry has seen widespread adoption of layering on an additional second factor. But unfortunately the most popular forms of second factors — such as one time passwords (OTPs) and phone approvals — are both inconvenient and insecure. They can be phished, and they are being phished at scale today.

Since passkeys are FIDO credentials, we now have a primary factor that — standing alone — is more secure than the combination of either “password + OTP” or “password + phone approval”.

Passkey syncing is end-to-end encrypted and sync providers have strong account security protections.

Furthermore, syncing is critically important for FIDO to achieve its mission, which is to make sign-in easier and fundamentally safer by replacing passwords in as many places as possible.

This is because replacing passwords means “competing” with passwords across three dimensions:

• Speed: should be faster than creating or using a password.

• Convenience: should be at least equally as convenient — if not more convenient — than using a password.

• Security: should be phishing-resistant, and should be guaranteed to be unique per app/website/service.

Speed

Creation of passkeys eliminates the need for users to comply with password complexity requirements. Registration is as simple as a biometric auth or entering a PIN code, and subsequent sign-in attempts with a passkey again only require a biometric authentication or PIN code — both faster than typing in a password.

Convenience

The usability of a password replacement must compete with the convenience of passwords, and one of the primary usability benefits of passwords is that they can be used from any device.

Syncing means that passkeys are available from all of a user’s devices using the same sync provider. And just like passwords, visiting a website from another device does not require going through a credential registration/creation flow — cross-device sign-in is supported via an enhancement to the FIDO Alliance Client to Authenticator Protocol (CTAP) that uses Bluetooth Low Energy (BLE) to verify physical proximity.

If the cryptographic key is bound to the user’s computer or mobile device, then every time the user gets a new device, the RP would have to fall back to other methods of authentication (typically a knowledge-based credential such as a password). In practice, this often means that the first sign-in on a new device will be both inconvenient and phishable.

Passkeys solve this issue because they are available on the user’s device if and when the user needs them — starting from the very first sign-in to a website from that device.

Last but not least, users often forget passwords and don’t set up backup emails and phone numbers. With passkeys, as long as the user has their device, they can sign in; there is nothing to forget. Because passkeys can be backed up, they can be better protected from loss.

Security

Passkeys, which are FIDO credentials, allow relying parties (which face a constant threat of phishing, credential stuffing, password database breaches, etc.) to replace passwords with FIDO credentials. FIDO offers relying parties a challenge-response authentication protocol based on asymmetric cryptography. This means phishing-resistance, and the elimination of sensitive secrets on the server, resulting in a huge step forward in security.

Phishing-resistance is a core design goal of FIDO Authentication. This goal is achieved at sign-in whether or not the cryptographic keys are bound to hardware. Furthermore, breaches of password databases (which can be an attractive target for hackers) no longer pose a threat as there are no passwords to steal.

RPs will use the built-in WebAuthn (for websites) and platform FIDO APIs (for apps) to exercise passkeys for sign-in. Passkeys will have built-in support in the main mobile and desktop operating systems and browsers. 

Availability of built-in passkeys that automatically synchronize to all of a user’s devices is arriving now and in the near future:

• Apple has announced support in iOS 16 in Sep 2022, and iPadOS 16 and macOS Ventura in Oct 2022.
• Google has announced support in Android starting October 2022 and plans passkey support in ChromeOS by 2023.
• Microsoft has announced passkeys support within Windows Insiders Builds and is expected to deliver broader passkey support later in 2023 and throughout 2024.

Most platforms already support sign-in with a passkey from a nearby device such as a mobile phone or security key.  These include:

• Microsoft Edge and Google Chrome on Windows
• Edge, Safari and Google Chrome on macOS
• ChromeOS   

Please also see the next two questions for more information. Passkeys are accessed using the same WebAuthn API which has been available across all the platforms and browsers since 2018. The cross-device sync of passkeys is managed transparently by the OS.

Device OS platforms are implementing a feature by which the passkeys on the device (for example, a mobile phone or laptop computer) are synced to the device cloud tied to the user’s platform account (eg, Apple ID for iOS/macOS, Google account for Android & ChromeOS, Microsoft account for Windows). Syncing of passkeys is end-to-end encrypted.

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 passkeys 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 user’s passkeys are synced and available for sign-in on the new device.

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

The user visits the RP website on the Windows computer. They then see a ‘sign-in’ button on the RP’s login web page and push that button. The user now sees the option to use another device to sign-in to the RP. 

When the other device (say, their phone) is physically close (in BLE range) to the Windows computer, the user sees a pop-up from the Android OS. The pop-up asks (in essence) “I see you are trying to sign-in to the RP 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 device that has been enrolled with the RP with a very similar flow. In this instance, the user will visit the RP website on the Windows computer. They see a ‘sign-in’ button on the RP’s login web page and push that button. When the RP asks for authentication, the user is able to insert their security key device and unlock the security key with biometric or PIN and they are signed-in to the website.

The flows described in this example above would work regardless of the OS that the user’s mobile phone is running and the OS and browser available on the target device for login (e.g. computer, tablet, TV, etc.) or what model of FIDO-compliant security key the user has.

The flows described are available now for Google Chrome and Microsoft Edge on Chrome OS, Windows, Mac and Linux.

The FIDO Cross-Device Authentication flow, which leverages CTAP 2.2, uses Bluetooth Low Energy (BLE) to verify physical proximity, but does not depend on Bluetooth security properties for the actual security of the sign-in. The CTAP transport, named ‘hybrid’, uses an additional layer of standard cryptographic techniques — on top of standard Bluetooth security properties — to protect data.

Passkeys are kept on a user’s devices (something the user “has”) and — if the RP requests User Verification — 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.

RPs may be concerned that a passkey could be made available to an attacker through a single factor (say, a password) from the platform vendor account. In practice, however, this is not usually the case: platform vendors consider multiple signals beyond the user’s password — some visible to the user, some not — when authenticating users and restoring passkeys to their devices.

Note that some regulatory regimes still have to evolve to recognize passkeys as one of the officially listed forms of multi-factor. This is an area of active engagement for the FIDO Alliance.

If the user is still in possession of their old device, the user can use the passkey on the old device (say, an Android device) to sign the user into their account on the new device (say, an iOS device). Once signed in, the user can create a passkey in the new platform account.

If the user has a FIDO Security Key, they can use it to securely authenticate on the new device.

If the user does not have their old device or a security key, 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 get the user signed in.

Yes, FIDO Security Keys today support single-device passkeys and have done so since 2019, when FIDO2 added support for passwordless sign-ins via discoverable credentials with user verification. All the client platforms and browsers have native support to exercise security keys already. Security key vendors may choose to support passkey synchronization in the future.

Web services can leverage passkeys to support a range of use cases. For example, if the user gets a new computer, they can present their security key in proximity (e.g. by plugging into USB or tapping for NFC) to the computer and sign-in to their online account.

Since all passkeys are FIDO credentials, a web service implementing support for FIDO will be able to support all passkey implementations.

Specific environments with particular compliance needs may be required to guarantee there is only one copy of the cryptographic key available. Passkeys on FIDO Security Keys are a great solution for such use cases.

Also, in scenarios where a user has lost access to all of their other mobile and other devices where their passkeys have been synced, such FIDO Security Keys can act as a recovery credential.