October 2025

Authors:

Jacob Harlin, Microsoft
Josh Cigna, Yubico
Martin Gallo, HYPR
Sumana Malkapuram, Netflix
Apoorva Deshpande, Okta

Abstract

In today’s fragmented enterprise security landscape identity and access management (IAM) systems often operate in silos. The need for cohesive, real-time coordination across platforms is more critical than ever. This paper introduces a strategic approach that combines FIDO-based strong authentication with the OpenID Foundation’s Shared Signals Framework (SSF) to orchestrate agile and secure IAM workflows, enable stronger continuous authentication, and promote collaborative defense against identity threats.

FIDO protocols offer a robust foundation for user authentication as they leverage public-key cryptography to eliminate password-based vulnerabilities. However, authentication alone is insufficient for sustaining zero-trust principles. Once an authenticated session is established, its trustworthiness must be continuously evaluated. This broader need for continuous evaluation is where SSF comes in – enabling the secure exchange of identity and security events, such as risk signals and session revocations, across disparate systems and vendors.

This document explores how integrating SSF into IAM architectures enhances visibility and responsiveness throughout the user journey, including joiner-mover-leaver (JML) and account recovery scenarios. It also highlights how Continuous Access Evaluation Protocol (CAEP) and Risk Incident Sharing and Coordination (RISC) protocols, when layered atop FIDO2, empower organizations to make real-time, risk-informed decisions that reduce fraud and accelerate incident response.

This synthesis of FIDO and SSF represents a paradigm shift toward continuous, adaptive trust that enables organizations to move beyond static controls and toward dynamic, signal-driven security ecosystems.

Audience

This white paper is for enterprise security practitioners and identity and access management leaders whose responsibility is to protect the security and life cycle of online and identity access management. Specifically, the target audience should include those whose purviews cover activity monitoring for threat detection and response as well as IAM staff who support those goals. Additionally, IAM leadership and architects should review this document to understand opportunities the described technologies offer and the implications of implementing them.

1. Introduction

The FIDO Authentication protocol has a proven track record of securing initial session authentication by leveraging strong public key infrastructure (PKI) based cryptography. Adoption of this technology has been a leap forward as a unified approach for secure and usable session establishment, however the ability to maintain, monitor, and manage ongoing sessions has historically remained fractured. This challenge is exacerbated by the reality of today’s enterprise security landscape, where numerous security vendors and solutions often operate in silos with limited communication. These barriers hinder comprehensive security outcomes during adverse events, leading to localized mitigations rather than unified responses. 

Shared signals offer a crucial pathway to facilitate a more holistic and effective response by providing a way to exchange security events across vendor boundaries. Ongoing management and monitoring are required to adopt the full zero-trust model.  The OpenID Foundation’s Shared Signals Framework (SSF) aims to address these challenges. If you root an IAM program with a strong footing, such as FIDO based authentication, and combine it with strong ongoing activity monitoring enabled by an SSF, you can achieve substantial changes that reduce (and enable you to react to) fraud and maligned activities.

2. What is the Shared Signals Framework?

The Shared Signals Framework (SSF) standard simplifies the sharing of security events across related and disparate systems. The framework allows organizations to share actionable security events and enables a coordinated response to potential threats and security incidents. SSF is defined by the OpenID Foundation’s Shared Signals Working Group (SSWG). The SSF standards are still evolving, but evaluation of the specifications provides a clear picture of what the SSWG hopes to achieve and can inform practitioners around what can be done with these tools today. The goal of this framework is to define a common language and mechanism for communicating actionable security events in near real-time, that allows systems to respond more effectively and in a coordinated way to potential threats.

SSF helps bridge gaps between identity providers, relying parties, and other services by creating a unified way for entities to notify each other of relevant changes, such as risk signals or session status updates. 

For example, Mobile Device Management (MDM) tools can transmit a device compliance change event to indicate a user’s laptop is no longer compliant with corporate policies. When this event is received by a downstream system, that service may determine that the user’s authenticated session should be terminated until such a time as the device moves back into a healthy state. 

Note: It is important to remember that SSF security events standardize and facilitate the sharing of information. They are not directives. Recipients need to determine the actions to take in case of a security event.

The SSF standard describes how to create and manage streams, which are used to deliver notification of events to the receiver using push (RFC 9835) and poll (RFC 8936) mechanisms. From a technical perspective, SSF describes using secure, privacy protected generic webhook transit with events delivered via HTTP in streams. 

Software vendors can act as transmitters and receivers; however, they must establish independent unidirectional streams. Events are formatted as Security Event Tokens (SETs) (RFC 8417) and the entities involved are identified by Subject Identifiers for Security Event Tokens (RFC 9493). Additional Subject Members are also defined in the OpenID Shared Signals Framework Specification 1.0. 

Since SETs do not describe the content or semantics of events, the SSWG is developing two standard profiles under SSF: 
Continuous Access Evaluation Profile (CAEP): For sharing access relevant state changes like token revocation or device posture.
Risk Incident Sharing and Coordination (RISC): For sharing signals about “risky” behaviors, such as account compromise.

2.1 Continuous Access Evaluation Profile (CAEP)
To further simplify interoperability between various vendors, the SSWG has also defined the CAEP Interoperability Profile. This specification “defines the minimum required features from SSF and CAEP that an implementation MUST offer in order to be considered as an interoperable implementation”. (CAEP Interoperability Profile).

Federated systems commonly assert the login only during initial authentication, which can create security risks if user properties (such as location, token claims, device status, or org membership) change during an active session. CAEP aims to enhance the “verify, then trust” mantra by defining a common event profile to communicate such changes as they happen. For example, early proposed examples suggest CAEP events can be used to:

• Tie risk signals to known identities (users and non-human identities (NHIs)
• Track sessions and behavioral changes over time
• Dynamically adjust access without requiring the user to re-authenticate

This list is non-exhaustive, and capabilities are expected to grow and evolve as CAEP is more widely adopted. Because CAEP is built upon SSF principles, interoperable push and poll of SETs can be sent in real-time between trusted entities. These entities can include identity providers, relying parties (RP), monitoring systems like Security Information and Event Management (SIEM) systems, MDM systems, or any security-focused software vendor. 

When an entity receives a SET, they can then evaluate the event and decide whether to revoke tokens or transmit an updated security status to other services. Monitoring systems such as MDM, endpoint detection and response (EDR)/extended detection and response (XDR), SIEMs, or any security-focused software vendor can emit/consume CAEP events. As enterprise architectures evolve, CAEP can serve as a foundational tool for zero-trust strategies, enabling continuous and adaptive access evaluation that is informed by real-time context.

2.2 Key components of the Security Token Event (SET)

At the core of SSF is the Security Event Token (SET), a JWT based envelope defined by RFC 8417, that provides the foundational format for encoding and transporting these events.

“The intent of this specification is to define a syntax for statements of fact that SET recipients may interpret for their own purposes.” (RFC 8417)

Based on this principle, SETs provide a structured, interoperable format to convey claims (statements of fact) such as account changes, credential updates, or suspicious activity, without prescribing any particular enforcement action. This allows recipient systems to evaluate and respond to events in accordance with their own policies. Each profile (CAEP, RISC, SCIM) imposes specific constraints on the base SET and its associated subject identifiers (per RFC 9493), thereby defining clear semantics and expected behaviors for particular use cases. 

The SET itself is composed of several key claims, which together define the issuer, audience, subject, and event full context. A full description is available within the official documentation from the OpenID foundation, RFC 8417, and RFC 9493. The following is a brief outline of these claims. 

• iss (issuer) – Represents the entity that issued the token, such as https://idp.example.com/ (as per SET examples). This is used by the receiving service to verify that the event originates from a trusted provider.
• aud (audience) – Specifies the intended recipient of the token. Depending on the deployment, the recipient may be the relying party application, an identity provider, or another trusted service. This helps ensure that only the designated service processes the security event.
• jti (JWT ID – unique event identifier) – A unique identifier for this specific event within the security stream. Helps with tracking and deduplicating events to avoid processing the same event multiple times.
• iat (Issued At Timestamp) – Indicates the exact Unix timestamp when the event was generated. Helps determine the event’s freshness and prevent replay attacks.
• sub_id (subject identifier) – Structured information that describes the subject of the security event. 
• events (Security Events Information) – The core claim that contains details about the specific security event. This is a mapping from an event type identifier (for example, https://schemas.openid.net/secevent/risc/event-type/account-disabled) to an event-specific JSON object that typically includes attributes such as subject, contextual metadata (for example, reason, timestamp, and risk level), and any profile-defined parameters required to interpret and act on the event.
• event_timestamp – Represents the date and time of an event. Uses NumericDate 
• txn (Transaction Identifier) – OPTIONAL – Represents a unique transaction value. Used to correlate SETs to singular events.

2.3 Risk Incident Sharing and Coordination (RISC)

While CAEP defines a standardized messaging transport for communicating session-related state changes between trusted parties during active sessions, additional security events that might compromise an identity outside of a single session must also be addressed. This is where Risk Incident Sharing and Coordination (RISC) comes into play. 

RISC is designed to share security events that are related to potential threats, credential compromises, and account integrity across federated systems. RISC hopes to define profiles that enable each recipient system to assess and act upon security events based on their unique risk policies, rather than mandating specific enforcement actions. 

RISC SETs might also empower standards compliant systems (via the System for Cross-Domain Identity Management (SCIM) standard for example) to communicate “statement of fact” assertions, with the goal to enable simpler automation and coordination across an asynchronous federated environment.

It is important to remember that RISC, like CAEP, suggests a framework of profiles and roles for platforms to leverage.

• SETs only state provable assertions. They do not issue specific directives.
• Receivers may need to leverage profiles that are not yet established, to always take prescribed actions based on SETs received from transmitters. However, those profiles need to be understood by the transmitter/receiver pair.
• The ultimate goal is to enable more automation and faster reactivity across sessions through the sharing of SETs.

3. SSF and user journeys 

When you plan for implementation of IAM tools and capabilities, it is a common practice to consider the user journeys that need to be supported. These user journeys include day-to-day authentication and authorization processes, as well as more impactful (but less common) JML and recovery processes. Both CAEP and RISC methodologies can be used to enhance these workflows, building off strong authentication backed with FIDO2. With FIDO2 you are able to make decisions about users with certainty and with SSF you can track actions and react more quickly and accurately based on identity signals and user behaviors.

While the adoption of SSF is expected to grow, it will be up to the individual practitioner or organization to best determine how to leverage these capabilities. At the time of writing, the proposed workflows (as well as many of the transmitter and receiver interfaces) all need to be manually created and configured. Instead, it is recommended that you evaluate how these suggestions can enrich existing workflows and request delivery of these capabilities from your vendors and implementers.

3.1 Onboarding (joiners) and upgrading (movers) access

One journey that affects every end user is the joiner, or onboarding, process which generally establishes accounts for a user before they start at an organization. Accounts are created and entitlements are granted, with the expectation that they will not be used immediately. This timeframe is normally documented as “Day Zero -1.” This timeframe varies depending on organizational practices, but in order to ensure a speedy onboarding process most mid to large sized organizations follow this trend. 

The risk here is that it is easy to perform OpenSource Intelligence Gathering (OSINT) and enumerate accounts that fall into the “pending start day” category. The current set of IAM tools may lack the intelligence or agility to dynamically enable and disable accounts based on a strong identity proofing workflow and business demands of “hitting the ground running” often mean that these accounts are active and unmonitored before a user starts.

Profiles built on Shared Signal Frameworks (specifically RISC) can be leveraged to enhance this process. You can develop workflows that use the successful establishment of FIDO credentials via strong ID Proofing workflows, or initial detection of the use of pre-registered FIDO credentials, to trigger account enablement via IAM systems. With this workflow, accounts can sit inactive during the Day Zero – time frame and will only be dynamically activated once a successful strong authentication has been detected.

Role or access changes (known as mover workflows) can follow a pattern similar to that of the onboarding enhancement. New accounts can be created in a disabled state, awaiting specific triggers (such as date and time) in conjunction with authentication. RISC also opens the door to more dynamic access elevation, where the signaling framework can be used to trigger approval workflows in IAM ticketing and provision systems to temporarily grant higher privileges or roles.

Creative use of the shared signals frameworks, paired with a FIDO backed Root of Trust (RoT), can strengthen and enhance joiner and mover user journeys. These emerging techniques should be evaluated and adopted in a timely manner, to raise the bar for all IAM practitioners.

3.2 Device recovery/replacement

Another common user journey is establishment of a user on a new device. While it is similar to the onboarding journey, pre-existing permissions, accounts, and roles add complexity to this journey. This is also a common area of attack as attackers can abuse this workflow to enroll their own devices or otherwise compromise the pre-existing identity via unsecured channels. 
A best practice for device loss workflows is to lock down access as soon as a lost device is reported. You can leverage RISC signals to inform RISC consumer systems of the new device registration activity as part of an automated workflow that helps disable access as needed. Once a new device is issued, an identity can be re-established on the new device with a FIDO2 authentication workflow. The workflow can then leverage RISC signals to have IAM provisioning systems re-enable access.

Similar workflows can be leveraged if the FIDO2 authenticator needs to be replaced. This includes the loss of a device that contains a synced credential or a hardware token that contains a device-bound credential. Identity proofing workflows need to be leveraged to securely re-establish identity before a new credential can be bound to a user’s account. After this workflow is complete, RISC signals can be leveraged to re-enable sensitive access that was disabled when the credential was reported missing.

3.3 Offboarding (Leaver events in JML)

Offboarding workflows fall into two categories: planned and unplanned. Planned offboarding remains fairly unimpacted by SSF. It is possible to leverage CAEP signals to trigger termination of any active sessions after the user signs off for the last time. However, the SSF is more useful for unplanned offboarding events. A workflow can evaluate CAEP signals, and any open sessions can be identified and ended. As part of this workflow FIDO credentials should be de-associated from the user’s accounts, ensuring that the user can no longer log in. Both of these controls can ensure that unplanned offboarding events are well controlled and executed across the board.

3.4 Session tracking

Within the scope of modern identity security, session tracking plays a pivotal role in maintaining the integrity and security of user sessions. While authentication methods like FIDO effectively protect the initial login, they are significantly enhanced when complemented by session tracking. This involves the continuous monitoring of a session’s behavior and context throughout its entire lifecycle, from creation to termination. Such ongoing evaluation is crucial for identifying risk signals that may indicate potential security threats, such as session hijacking or unauthorized access attempts.

Platforms within a networked environment use CAEP events to send a range of signals to an authentication system responsible for managing sessions. You can utilize session tracking data so that as events are received, the authentication system can implement appropriate security measures, such as enforcing step-up authentication or terminating sessions. These events originate from multiple, diverse platforms, which each act as both transmitters and receivers within the SSF. This interconnected network offers valuable insights into potential security threats, enabling each platform to contribute to and enhance session tracking across the entire network.

To illustrate the impact of session tracking, we will explore use cases that compare an environment that uses only WebAuthn authentication with an environment that uses an enhanced approach that incorporates continuous authentication and shared signals. This comparison highlights how continuous session tracking can significantly bolster security and mitigate risks. 

The following table describes some possible ways to design these workflows. The table outlines the traditionally observed behaviors of systems and how security policies can be enhanced with the inclusion of SSF capabilities. When compared side by side, you can see the advantages provided by the adoption of SSF signaling. 

User Journey – Adding continuous access and session evaluation to a high assurance authentication.

4. Filling gaps – compliments to FIDO and conclusion

As demonstrated, by the use cases outlined above, both CAEP and RISC pair well with FIDO authentication standards to improve overall security postures and practices for enterprises and organizations. These cases only cover the largest areas where these frameworks should be adopted and integrated into current tools and workflows. In addition to our recommendation of implementing these standards, a robust and well planned SSF/FIDO program can provide buffers/flagging against potential false positive signaling and help make the tasks of attributing improper activities and detection of rogue actors easier for Network Operations Centers (NOCs). 

SIEM systems rely on credible data from endpoints. SSF helps to normalize the structure of many tasks that historically have required bespoke connectors. Shared signals (such as CAEP session state changes or RISC credential-compromise events) can add clarity and deeper insight into principal (the user or entity associated with the event) and system behavior. Additionally, SSF-enabled SIEM or IAM tools can be leveraged to strengthen current step-up authentication practices, providing native ways to track high privilege interactions without the need for full reliance on single point of failure third party systems. 

In the past, passive signals were used for dark web monitoring. With shared signals coordination we now have the capabilities to send notifications and cycle credentials automatically for systems that do not support strong authentication. Accounts with leaked credentials can either be auto-disabled and shunted to a reset workflow that is backed by a strong authentication with FIDO or automatically rotated with credentials that are vaulted and retrievable with IDV or FIDO authentication. Stolen credentials may not be limited to usernames and passwords and can also include stolen synced passkeys and or certificates. CAEP can be leveraged to communicate out of context credentials, and the shared signals should be leveraged as part of a risk-based authentication workflow.

CAEP, RISC, and FIDO provide a risk-averse way to enable federated login. Implementation of both enhanced session tracking and strong authentication creates a workflow in which external users can leverage federated login processes and security teams can more closely monitor and attribute activity and behavior. In the Customer Identity space, these enhanced signals can provide more secure ways to allow end users to authenticate using their existing trusted identity provider accounts (for example Google, Apple or enterprise Identity Providers) instead of creating new local credentials, through enhanced session tracking and strong, phishing resistant authentication.

When practitioners and vendors embrace RISC and CAEP frameworks for signaling, they strengthen not only their own environments but also the broader information security ecosystem. A common, interoperable signaling language increases the ability of systems across organizational boundaries to track and correlate user and process activity, detect inappropriate behavior, and respond consistently. In this way, the adoption of SSF moves security practice toward a more collaborative, standards-based model that prioritizes shared defense and ecosystem resilience. When SSF is put into practice, it enables external entities to be better informed in real time, improving collective security and ensuring that end users are more effectively protected.

5. SET examples

This section contains several mockup examples of the makeup of SETs. These are provided to add clarity to the contents and capabilities of each component of the SSF. They describe the information systems can expect to receive and what data points can be included in a token.

5.1 CAEP example tokens

CAEP provides a standardized way to communicate access property changes in real time. It defines Security Event Tokens (SETs), which are sent by transmitters using the SSF framework. Upon receiving a CAEP event, the receiver can dynamically adjust access permissions, which reinforces zero-trust security principles and ensures security decisions remain context aware and adaptive. 

The following are examples of key CAEP Security Event Tokens (SETs).

5.1.1 Session revoked

Session revoked: Indicates an active session has been terminated

Event transmission example.

5.1.2 Credential changes

Token claims change: Signals changes in token claims such as roles, entitlements, and group memberships that affect access control.

Credential change: Signals that a user’s credentials have been changed (for example, deleted, updated, created, or revoked). Examples of credentials include passwords, fido2-platform, and fido2-roaming. 

Event transmission example

5.1.3 Assurance level or compliance change

Assurance level change: Indicates that the assurance level of user’s authentication has changed, impacting session security.

Device compliance change: Signals a change in the security posture of a user’s device. For example, a previously compliant device is now non-compliant.

Transmission event for device compliance example.

5.2 RISC example tokens 

The following examples show the key RISC SETs.

5.2.1 Account credential change required

Indicates an event requiring a credential update for the subject, typically due to detected compromise or reuse. For example, this helps prevent credential stuffing attacks across federated accounts. 

5.2.2 Account enabled

Notifies that a previously disabled account has been re-enabled. This allows relying parties to reinstate access where appropriate (for example, after resolving a false positive).

5.2.3 Account purged

Notifies that the subject’s account has been permanently deleted and should no longer be recognized by relying parties.

5.2.4 Account disabled

Notifies that the subject’s account has been disabled and is no longer accessible. This helps prevent unauthorized access (for example, after fraud detection or HR termination).

Transmission event for account disabled for fraud detection.

5.2.5 Identifier changed/recycled

Notifies when a user’s identifier (for example, email or username) has changed or is reassigned. Helps prevent unauthorized access using outdated identifiers.

6. Document history

7. References

Internet Engineering Task Force (IETF). (2020, November 30). Poll-Based Security Event Token (SET) Delivery Using HTTP. IETF Datatracker. https://datatracker.ietf.org/doc/rfc8936/

Internet Engineering Task Force (IETF). (2020, November). Push-Based Security Event Token (SET) Delivery Using HTTP. IETF Datatracker. https://datatracker.ietf.org/doc/html/rfc8935

Internet Engineering Task Force (IETF). (2018, July). Security Event Token (SET). IETF Datatracker. RFC 8417https://datatracker.ietf.org/doc/html/rfc8417

Internet Engineering Task Force (IETF). (2023, December). Subject Identifiers for Security Event Tokens. IETF Datatracker. https://datatracker.ietf.org/doc/rfc9493/

OpenID. (2025, August 29). OpenID Continuous Access Evaluation Profile 1.0. OpenID. 
https://openid.net/specs/openid-caep-1_0-final.html 

OpenID. (2024, June 25). CAEP Interoperability Profile 1.0 – draft 00. OpenID. https://openid.net/specs/openid-caep-interoperability-profile-1_0-ID1.html

OpenID. (2025, August 29). OpenID RISC Profile Specification 1.0. OpenID. 
https://openid.github.io/sharedsignals/openid-risc-1_0.html

OpenID. (2025, August 29). OpenID Shared Signals Framework Specification 1.0. OpenID. https://openid.net/specs/openid-caep-1_0-final.html

Christine Owen, 1Kosmos
Teresa Wu, IDEMIA Public Security

Abstract

Around the world, government entities are currently working to create and implement their digital identity strategies, which includes issuing verifiable digital credentials (VDCs) to their citizens. As a result of these initiatives, organizations are also beginning to discuss using VDCs as a primary form of authentication. VDCs are an important part of verifying a user’s identity that can be used alongside FIDO’s passkeys, which provide a primary authentication mechanism that is fast, safe, and reliable. Passkeys should be issued after a citizen’s VDC is presented for identity verification. This paper will discuss how VDCs and passkeys should coexist when implementing authentication for citizens.

We anticipate a growing confusion in recognizing the differences between the use of digital ID to ascertain identity attributes and allowing users to authenticate themselves online as solutions that follow digital ID standards for online use cases (such as ISO/IEC 18013-7, W3C, IETF, or SD-JWT) are deployed.

This paper aims to clarify misperceptions and avoid confusion by discussing the coexistence of passkeys and digital ID/VDCs, including best practices for using these technologies.

Audience

Government entities, policy makers, relying parties

1. Verifiable digital credentials (VDCs) and passkeys

As new technologies continue to emerge, experts are finding new ways to use these solutions together. This paper discusses how verifiable digital credentials (VDCs) and passkeys should coexist when implementing authentication for citizens. VDCs and passkeys were both developed to secure identities in the digital world. However, they have different yet intersecting roles for end users. The following sections introduce VDCs and passkeys.

1.1 VDCs

A VDC can contain an electronic version of identity attributes or can be a digital representation of physical credentials (for example, driver licenses, passports, other identifiable information) that can be cryptographically verified. Typically, a VDC follows the W3C Verifiable Credentials Data Model, Internet Engineering Task Force (IETF) Selective Disclosure for JWTs (SD-JWT), or ISO/IEC 18013-5/7 (mobile driver’s license) standards, which require cryptographic signatures to prove authenticity. Because these standard models use digital wallets, a secure, portable, and instant verification mechanism is created that can preserve privacy by requiring user approval prior to disclosure of sensitive information.

Deployment of VDCs is currently prolific in multiple regions around the world. For example, Asia-Pacific countries are embracing the idea of a VDC. Countries such as Japan, South Korea, and Australia are working together to ensure interoperability amongst their VDCs. Australia’s 2024 Digital ID Act created accreditation requirements for digital IDs and enhanced the trust framework between different providers. In the United States, the mobile driver’s license (mDL) movement is gaining momentum, and several states have already implemented or are piloting mDL programs. For a more detailed look at how government agencies are deploying VDCs, refer to the Appendix.

VDCs can be either a Person ID (PID) that represents a physical person or Attested Attributes which are documents that present properties of a person such as a driver license, age in a certain range, or educational degrees. The validity of VDCs can be expressed by Identity Assurance Levels (IAL) or Levels of Assurance (LOA) (depending on a country’s digital identity standards). In cases where a PID is used, a government entity may determine the types of verified information that are necessary to establish the identity of a person. In most cases, information about a person’s name, address, date of birth, place of birth, official government document number, phone number, and other attributes such as name of parents, gives a strong base for properly identifying a person through the controls available to government or private entities that perform verification on behalf of organizations. Modern technology may add records of biometrics such as fingerprints or face capture to further strengthen identity assurance. The European Digital Identity Wallet (EUDI Wallet) requires that PID be a high level of assurance (LoA), in accordance with the principles used by member states for their civil registration process. Refer to section 5.3 EU VDC Efforts for more information on EUDI Wallets. Similarly, the United States Digital Identity Guidelines^[1] require remote identity vetting to be performed at an IAL2 for government use.

VDCs hold a digital representation of a document by defining the syntax of the issuer’s URL, the category of the document, and other standardized syntax such as a trust list (where government entities issue a certificate that guarantees that the URL is what it claims to be), then creating a cryptographic seal that guarantees the authenticity of the document when presented to a relying party (also known as a verifier). Under this W3C Verified Credentials Data Model, the URL serves as a trust model.

Because government entities are also building digital identity wallet schemes based on clear identity standards and mutual recognition mechanisms across different jurisdictions, the adoption of digital identity wallets internationally will facilitate the acceptance of VDCs by traffic police to validate a driver’s license from another country or for a bank to provide the proper checks and balances (for example, know your customer) during transactions.

^[1]https://www.nist.gov/identity-access-management/projects/nist-special-publication-800-63-digital-identity-guidelines

1.2 Passkeys

Passkeys, a passwordless and phishing-resistant authentication mechanism, represent a significant advancement in privacy-preserving authentication and are designed to replace traditional passwords with a more secure and user-friendly alternative.

There are two types of passkeys: synced passkeys and device-bound passkeys. Synced passkeys are stored in the cloud and can be accessed across multiple devices, offering convenience and easy recovery. Device-bound passkeys, on the other hand, are stored locally on a specific device or security key, which provides enhanced security. For a more in-depth look at passkeys and how to implement them, refer to Passkey Central.

Passkeys exhibit a robust resistance to phishing attacks due to their foundational design principles. Each passkey is intrinsically tied to the specific origin of the service, identified by the Relying Party ID, thereby ensuring that authentication can only occur with the legitimate and intended service provider. This origin-specific challenge-response mechanism is inherently resistant to replication by phishing sites, rendering such attacks ineffective.

Equally significant is the privacy-preserving architecture of passkeys, which is designed to uphold user confidentiality and prevent tracking. During authentication, no personal or biometric data is transmitted or shared externally. Biometric verification processes, such as fingerprint or facial recognition checks, are conducted locally on the user’s device, ensuring that sensitive data remains under the user’s control.

Because passkeys generate unique cryptographic keys for each service and cannot be reused across platforms, cross-platform tracking is precluded and the privacy concerns associated with social logins that enable providers to monitor user activity across multiple services are avoided. Unlike traditional authentication methods (such as passwords or two-factor authentication), the use of unique cryptographic keys effectively mitigates the risk of cascading breaches that can result from a single compromised account. By replacing shared secrets with device-bound cryptographic keys, passkeys fundamentally neutralize phishing as a viable attack vector. When passkeys are synchronized across devices via cloud-based mechanisms, they are protected through end-to-end encryption.

This privacy-centric design fosters a sense of security and trust among users and reassures them that their personal information is not being tracked or misused by government entities or service providers. By combining phishing-resistant authentication with privacy-preserving principles, passkeys represent a significant advancement to secure and user-centric digital identity management.

1.3 The intersection of VDCs and passkeys

Both VDCs and passkeys enhance security and reduce friction during digital interactions. VDCs focus on securely representing qualifications and attributes (association with the real user), while passkeys specifically target phishing-resistant authentication (what a user has). When used together, these two technologies complement each other to enhance security within the digital world.

2. Core concepts of digital identities

This section covers the differences between digital identities, authentication, and authorization. It also examines how to enhance the use of verifiable digital credentials.

2.1 Verified identities vs authentication vs authorization

Digital identities play a crucial role in facilitating online transactions. Commonly, VDCs contain identity attributes that can be presented as evidence to verify the identity of the VDC holder. For example, an individual might use their VDC to assert attributes such as name, date of birth, and address in order to verify their identity and open a financial account with a bank. The bank can use these attributes to comply with regulations such as Know Your Customer (KYC) or Anti-Money Laundering (AML).

Identity verification is the process of confirming that a person is who they claim to be, often during onboarding, using trusted documents for proof of identity. Once a verified identity is established, authentication helps verify individuals on return visits. While passwords or two-factor authentication have traditionally been used for authentication, passkeys are not only more secure than traditional authentication methods but also provide users the convenience of quickly using a biometric to unlock a cryptographic key which is then used for authentication. Passkeys, unlike VDCs which may assert information about the user each time they are presented, are privacy preserving and do not provide user attributes during authentication.

VDCs can be used to transmit requested identity attributes to relying parties during authorization requests.^[1] This method can decrease the relying party’s exposure to risk, as it provides a more holistic view of an end user through their verified set of attributes. The relying party can then make an informed decision regarding that user’s access based on their rules for access and the attributes presented.

^[1] Authorization is the process of granting the correct level of access to a user after their identity is authenticated. As a specific function within Identity and Access Management (IAM) systems, authorization helps system managers control who has access to system resources and set client privileges. Access controls are used to assign a set of predetermined access rights to a user identity and use of attribute exchanges to help determine authorization requests is gaining traction in the cybersecurity industry.

Enhancing verifiable digital credentials use

VDCs are designed to enable individuals to make verifiable claims about identity attributes or entitlements without serving as direct authentication mechanisms. Unlike authentication methods that authenticate users to specific services, VDCs focus on sharing attested claims (for example, date of birth, and address) through a decentralized triangle of trust that involves issuers, holders, and verifiers. VDCs are designed with privacy in mind, as standards such as SD-JWT and ISO mdoc require that when users share specific claims from a credential (for example, age from a driver’s license), the integrity of the original document must be proven cryptographically. Users retain ownership of VDCs, enabling them to present credentials across platforms without relying on centralized authorities. This flexibility makes VDCs ideal for scenarios that require proof of identity.

Passkeys provide a phishing-resistant authentication method that binds authenticators to specific domains. Passkeys do not pass Personally Identifiable Information (PII) or similar information at the time of authentication, thus preserving the privacy of the user. However, VDCs can pass along unnecessary PII, when requested by a relying party and agreed upon by the Holder. For instance, a malicious actor could impersonate a bank’s identity verification portal, capture a user’s PII from their VDC, and exploit the user’s PII. While cryptographic signatures ensure credential integrity, they do not address contextual misuse, highlighting a gap in current standards. Therefore, it is better to utilize VDCs for user credentials and attributes.

Despite these risks, VDCs are increasingly adopted for high-assurance processes:

• Universities can use VDCs to streamline enrollment by verifying academic records and extracurricular participation.
• Banks can employ VDCs for eKYC (electronic Know Your Customer), combining document verification (for example, passports), biometric liveness checks, and AML and Politically Exposed Person (PEP) screening to onboard customers remotely.
• VDCs mitigate fraud in transactions requiring stringent identity assurance, such as cross-border financial transfers or healthcare licensing. For example, selfie verification and document-centric checks ensure the physical presence of users during high-value agreements.
• In cross-border education, VDCs enable instant verification of international student credentials, reducing administrative delays and fraud risks.

However, these applications often require supplementary safeguards (for example, multi-factor authentication, liveness detection) to compensate for the PII phishing susceptibility of VDCs.

VDCs offer transformative potential for decentralized identity management, particularly for enrollment and high-assurance transactions. By integrating VDCs with phishing-resistant authentication mechanisms and advancing interoperability standards, government entities and organizations can harness their benefits while mitigating risks. As the ecosystem evolves, collaboration among government entities, standards bodies, and industry stakeholders will be essential to balance innovation with security.

3. Key considerations

VDCs and passkeys are built according to widely accepted standards, which promotes interoperability and offers seamless integration across various platforms and services. This standardization is crucial for widespread adoption and the creation of a truly interconnected digital identity ecosystem.

3.1 Privacy consideration

Privacy preservation is a key feature that must be present for both VDCs and passkeys. Combining VDC’s and passkeys benefit both the end users and relying parties. In this ecosystem, users maintain control over their credentials and can selectively share attributes as needed, for example when enrolling as a user with a relying party. Relying parties can be confident that the person behind the VDC is, more likely than not, who they say they are.

Moving forward however, the identity industry as a whole should address growing concerns about data privacy and control in the digital age. While VDCs are privacy-preserving mechanisms that hold and share verified credentials, relying parties should only request the minimum attributes required from the end user to enroll them in the application. Depending on the application type and legal and regulatory requirements, the attributes could be as little as email address and name or may also include verified home address and national identity number.

3.2 eIDAS 2.0 regulation

The European Digital Identity Regulation 2.0 (eIDAS 2.0) regulation describes where passkeys can be implicitly or explicitly used within the EUDI Wallet. The PID for an EUDI Wallet should be used with a high eIDAS LoA for initial authentication to a relying party. A FIDO passkey can be enrolled to the user’s EUDI Wallet to meet this requirement. The passkey can then be used for repeated authentication with pseudonyms to the relying party. In this way, passkeys can co-exist or complement the VDC in the EUDI Wallet ecosystem.

Section 5f.3^[1] of the eIDAS 2.0 regulation reads that while very large online platforms must accept and facilitate the use of EUDI Wallets for authentication, they must do so “in respect of the minimum data necessary for the specific online service for which authentication is requested”. Therefore, eIDAS 2.0 allows online platforms to support pseudonymous PID authentication, rather than require those platforms to also accept VDCs that are issued by and tied to a government-issued credential.

Consequently, passkey providers will need to issue and restore passkeys. The passkey provider services can be operated by different entities in the EUDI Wallet ecosystem: by the cloud-based EUDI Wallet backend, by the PID provider, or by the Qualified Trust Services Provider (QTSP) that issues the (Qualified) Electronic Attestation of Attributes ((Q)EAAs).

^[1] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401183

Cloud-based EUDI wallets and passkey providers have an interesting synergy. PIDs and (Q)EAAs are hosted at a cloud-based EUDI Wallet backend that is accessed from the user’s devices using FIDO passkeys. If the user’s device is lost or replaced, the user would only need to restore the FIDO passkey, which will then give the user access to the PIDs and (Q)EAAs. This allows for rapid recovery of an EUDI Wallet since the user can first download the FIDO passkey to a device and then use the FIDO passkey to get instant access to the cloud-based EUDI Wallet.

3.3 Use cases for an integrated approach for VDCs and passkeys

Passkeys and digital identity wallets are not competing technologies, but rather complementary solutions that together create a robust, portable identity ecosystem. Passkeys serve as a secure gateway to digital identity wallets, providing strong defense against unauthorized access, and wallets serve to provide valuable data during high-risk transactions. This combination enhances security and streamlines the user experience by unifying verified identity (EUDI Wallet) with easy authentication (passkey).

Perhaps most importantly, this combination allows for the creation of reusable identities. Users can prove their identity once and then reuse the same VDC across multiple services, significantly reducing friction for digital interactions while maintaining high security standards. The potential applications for this integrated approach to digital identity and authentication are vast and span multiple sectors:

• Online verification: In e-commerce, (for example, state-backed liquor stores) age verification for purchasing restricted products can be streamlined using verified credentials stored in a digital wallet and accessed securely with a passkey.
• Government services: Secure access to tax filing systems and other government benefits can be facilitated through this combined approach, enhancing security while improving user experience.
• Healthcare: Verifying prescribing doctor’s credentials across multiple hospitals becomes more efficient and the secure transfer of patient records between healthcare providers can be streamlined.
• Education: Higher education systems can more effectively prevent account takeovers and students can create reusable identities that carry their records throughout their academic careers and beyond.
• Financial services: Know Your Customer (KYC) processes can be significantly streamlined and enhanced security for high-risk transactions can be implemented more effectively.

In most use cases, relying parties should use VDCs to enroll their constituents at the beginning of their interactions and accept passkeys for further interactions with the constituent. If a constituent is conducting a high-risk transaction, then the relying party should ask for additional attributes from the VDC at the time of authentication. Additionally, a VDC should be used for passkey recovery, while a passkey should be used to access the VDC.

4. Recommendation

Government entities and organizations who adopt passkeys as the primary form of authentication for constituents can leverage their enhanced security and ease of use. To ensure trust and usability, passkeys should be backed by verified digital credentials (VDCs), especially in scenarios where a verified identity is required for passkey issuance or account recovery. VDCs provide a robust mechanism to securely recover passkeys while maintaining a high level of assurance.

To implement this effectively, a tiered approach based on Identity Assurance Level (IAL) requirements and the risk tolerance of the data being protected within the service is recommended. For services with moderate IAL requirements, relying parties (RPs) should:

• Read a government-issued ID to verify the user’s identity.
• Create a passkey tied to the verified identity.
• Use the passkey for re-authentication in all subsequent interactions.

Government entities and organizations who adopt passkeys as the primary form of authentication for constituents can leverage their enhanced security and ease of use. To ensure trust and usability, passkeys should be backed by verified digital credentials (VDCs), especially in scenarios where a verified identity is required for passkey issuance or account recovery. VDCs provide a robust mechanism to securely recover passkeys while maintaining a high level of assurance.

To implement this effectively, a tiered approach based on Identity Assurance Level (IAL) requirements and the risk tolerance of the data being protected within the service is recommended. For services with moderate IAL requirements, relying parties (RPs) should:

• Read a government-issued ID to verify the user’s identity.
• Create a passkey tied to the verified identity.
• Use the passkey for re-authentication in all subsequent interactions.

For services with higher IAL requirements, collaboration between government entities and organizations like the FIDO Alliance is essential. Together they can develop solutions to ensure that passkeys meet stringent assurance levels while maintaining user privacy and convenience.

Additionally, there is a pressing need for standards and mutual recognition arrangements for IAL across jurisdictions. Government entities should work to establish clear guidance that states which IAL levels are required for specific services for legal compliance and consumer protection. These standards should aim to be valid across as many countries as possible to facilitate interoperability and trust for cross-border digital interactions.

By adopting passkeys as the foundation of authentication and aligning them with verified credentials and standardized IAL frameworks, government entities can enhance security, improve user experience, and foster global cooperation in digital identity management.

5. Appendix

5.1 Verifiable digital credentials for government deployments

The digital identity landscape is undergoing significant transformations worldwide. This appendix explores how government entities around the world are implementing VDCs.

5.2 APAC VDC efforts

Asia-Pacific countries are embracing the idea of a VDC. Countries such as Japan, South Korea, and Australia are working together to ensure interoperability amongst their VDCs. Australia’s Digital ID Act 2024 created accreditation requirements for digital IDs and enhanced the trust framework between different providers.

In Asia, government-issued digital credentials are advancing rapidly but unevenly; a reflection of diverse economic, technological, and regulatory landscapes. Recent deployments highlight both the progress and the critical role of standards bodies (such as ISO/IEC and W3C) in shaping secure, interoperable systems. In Asia, countries such as India, Singapore, and South Korea are leading with robust digital ID systems, while Australia is harmonizing mDLs with international standards for secure, interoperable credentials.

Singapore’s SingPass is a benchmark for seamless public and private service access. South Korea leverages digital IDs for e-governance, incorporating FIDO and ISO/IEC 29115 standards. Japan’s Digital Agency^[1] drives Individual Number (My Number) card enhancements through initiatives such as the Asia Pacific Digital Identity Consortium^[2] launched in December 2024.

The government of Japan started issuing digital National IDs (individual number card/My Number card on smartphones) in mdoc format (standardized under ISO/IEC 18013-5) for iPhone users on June 24, 2025, and is planning to issue it for Android users in 2026. For the digital National ID, identity information such as name, birthdate, address, gender, and individual number (called My Number in Japan) are included. The aim is for digital National IDs to be used in various identity proofing use cases for both in-person and remote use cases.

In Southeast Asia, Thailand’s 2022-24 Digital ID Framework targets 10 million digital IDs and National Digital ID platforms. When discussing biometrics across Mobile ID, D.DOPA, the creators of this framework referenced NIST 800-63 and ISO/IEC 19794 standards. Malaysia’s MyDigital ID, which adheres to ISO/IEC 27001, and Sarawak’s planned Sarawakpass, aims to emulate SingPass for cashless transactions and service access. The Philippines’ PhilSys has enrolled 68 million, focusing on digital issuance to bypass physical card delays. In March 2025, Taiwan’s Digital Ministry introduced a prototype Taiwan Digital Identity Wallet (TW DIW), a non-mandatory mobile app for storing IDs and licenses, using biometric authentication and selective disclosure. A sandbox trial began in March, with broader testing planned for December, but it is not a full digital ID replacement and excludes medical data sharing.

Australia and New Zealand are harmonizing mobile driver’s licenses with ISO/IEC 18013-5. In Australia and New Zealand, harmonization efforts for mDLs center on adopting ISO/IEC 18013-5, which ensures secure, interoperable digital credentials verifiable domestically and internationally. In Australia, Austroads’ Digital Trust Service (DTS) leads the charge with a pre-production version tested successfully for national scalability. New South Wales, with 4.5 million users since 2019, is transitioning its Service NSW app, which offers app-based mDLs, to full compliance, ensuring legal equivalence to physical cards. South Australia’s mySAGOV app incorporates the standard’s verification features. The DTS, targeting a 2025-26 rollout, enables cross-jurisdictional and global verification, was demonstrated at the 2024 Identity and Verifiable Credentials Summit for uses like U.S. airport access and includes New Zealand in its interoperability framework. New Zealand is aligning its NZTA app-based digital licenses with ISO/IEC 18013-5, building on mutual recognition agreements with Australia.

5.3 EU VDC efforts

In Europe, the European Digital Identity Regulation 2.0 (eIDAS 2.0) regulations, which came into force in May of 2024, mark a pivotal shift in how digital identities are managed across the European Union. This updated framework introduces the European Digital Identity Wallet (EUDI Wallet), which aims to provide EU citizens with a secure, interoperable digital identity solution for accessing public and private services across member states.

The EUDI Wallet is a cornerstone of the eIDAS 2.0 regulation^[3] and will be offered free of charge to all EU citizens. The purpose of the EUDI Wallets is to enable EU citizens to prove their identity when accessing both online and offline resources or to present specific personal attributes without revealing their full identity. The EUDI Wallets will be able to be used for use cases such as the mobile driving license, payments, access to public services, and opening a bank account.

The EUDI Wallet architecture is outlined in the European Digital Identity Wallet Architecture and Reference Framework (the ARF), which specifies the formats and protocols to be used by the EUDI Wallets. Each EUDI Wallet will be bootstrapped with a Personal Identity Document (PID), which will be enrolled at the high eIDAS Level of Assurance (LoA). In addition to the PID, users will have the option to add additional (Q)EAAs, which can prove the user’s identity and claims to relying parties.

The ARF has specified that the following formats are suitable for the PID and (Q)EAAs:

• ISO/IEC 18013-5 mobile driving license (mDL)
• W3C Verifiable Credentials Data Model v1.1
• IETF SD-JWT-based Verifiable Credentials (SD-JWT VC)

Furthermore, International Civil Aviation Organization (ICAO) Digital Travel Credentials (DTC) can also be used as a (Q)EAA with the EUDI Wallet.

5.4 US VDC Efforts

In the United States, the mobile driver’s license (mDL) movement is gaining momentum, and several states have already implemented or are piloting mDL programs. Unlike the centralized approach of eIDAS 2.0, the U.S. initiatives are being developed more organically, driven by individual federal agencies and state efforts, alongside industry collaborations. These developments reflect a growing recognition of the need for robust, user-centric digital identity solutions in an increasingly digital world, although they approach this goal through different regulatory and technological paths.

As US states provide their constituents with ID cards and driver’s licenses, the responsibility of creating mID and mDLs lies with each of the states. As such, the development and implementation of mDLs in the US has been a gradual and varied process across different states.^[4] While only about a third of US states currently offer mDLs, many states are pushing forward, as they recognize the potential benefits of mDLs in improving remote transactions, reducing identity fraud, and enhancing digital identity verification for both government services and private sector services.

The Transportation Security Administration (TSA) is evaluating the potential impact of VDCs (such as mobile driver’s licenses) on aviation security and operations. The TSA has integrated digital identity capabilities, including the acceptance of state-issued mobile driver’s licenses, at TSA checkpoints using the Credential Authentication Technology 2 (CAT-2) system to provide for a secure and seamless method of verifying an individual’s identity. Currently, the TSA is accepting mobile driver’s licenses and mobile IDs from 15 participating states. In October 2024, the TSA published a final rule in the Federal Register that would allow passengers to continue using mobile driver’s licenses (mDL) for identity verification at TSA airport security checkpoints now REAL ID enforcement began on May 7, 2025.

In addition to publishing the Digital Identity Guideline SP 800-63, the NIST National Cybersecurity Center of Excellence (NCCoE) launched an mDL adoption acceleration project to bring together stakeholders from across the mDL ecosystem to work to build out a reference implementation to promote standards and best practices for mDL deployments and to address mDL adoption challenges. The first NCCoE use case will focus on helping consumers create financial accounts and helping financial institutions meet Customer Identification Program/Know Your Customer (CIP/KYC) requirements using mDLs.

For the US Federal government’s digital interactions with users, agencies are embracing the idea of a reusable identity stored in a digital identity wallet. Generally speaking, these VDCs are cloud-based and would be used to verify a user’s identity prior to interacting with a federal agency for actions such as enrolling in public benefits or filing taxes. These VDCs are also tied to an authenticator that the constituent would use to sign in to the agency’s application. Within the federal space, a VDC tied to an authenticator is called a credential service provider (CSP).

5.5 UK VDC Efforts

​The UK Government released the Digital Identity and Attributes Trust Framework (DIATF) gamma version (0.4)^[5], in November 2024, which outlines the standards and roles for digital identity services which relate to digital wallets. The UK plans to introduce digital driving licences in 2025, that will be available through a new GOV.UK digital wallet app on smartphones.

^[1] https://www.digital.go.jp/en

^[2] https://www.apdiconsortium.org/

^[3] The “Regulation (EU) 2024/1183 as regards establishing the European Digital Identity Framework” (eIDAS 2.0) was adopted by the EU parliament in April 2024. The eIDAS 2.0 regulation will be extended with Commission Implementing Regulations (CIRs), also known as “implementing acts”, which will elaborate certain legal aspects of the eIDAS 2.0 regulation. The eIDAS 2.0 CIRs continue to be specified.

^[4] As of March 2025, the states that offer mDLs include Alaska, Arkansas, Arizona, California, Colorado, Delaware, Georgia, Hawaii, Iowa, Louisiana, Maryland, Mississippi, New York, Ohio, Puerto Rico, Virginia, Utah, and West Virginia.

^[5] https://www.gov.uk/government/publications/uk-digital-identity-and-attributes-trust-framework-04

6. Contributors

• Jerome Becquart, Axiad
• John Bradley, Yubico
• Tim Cappalli, Okta
• Sebastian Elfors, IDnow
• Hideaki Furukawa, Nomura Research Institute, Ltd.
• William Fisher, NIST
• Henna Kapur, Visa
• Sue Kooman, American Express
• Matthew Miller, Cisco
• Jeff Nigriny, CertiPath, Inc.
• Joe Scalone, Yubico
• Alastair Treharne, Ingenium Biometric Laboratories

7. Document History

8. References

The Asia-Pacific Digital Identity (APDI) consortium. APDI consortium. https://www.apdiconsortium.org/

Digital Agency. Home. Digital Agency. https://www.digital.go.jp/en

The FIDO Alliance. Home. Passkey Central. https://www.passkeycentral.org/home

NIST. Digital Identities – Mobile Driver’s License (mDL). NIST National Cybersecurity Center of Excellence. https://www.nccoe.nist.gov/projects/digital-identities-mdl

NIST. (2025, July). NIST SP 800-63-4 Digital Identity Guidelines. NIST. https://www.nist.gov/identity-access-management/projects/nist-special-publication-800-63-digital-identity-guidelines

Office for Digital Identities and Attributes and Department for Science, Innovation and Technology. (2025, June 26). UK digital identity and attributes trust framework (0.4).  Gov UK. https://www.gov.uk/government/publications/uk-digital-identity-and-attributes-trust-framework-04

The European Parliament and the Council of The European Union. (2024, April 11). Regulation (Eu) 2024/1183 of the European Parliament and of the Council. EUR-Lex.europa.eu. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401183

Transportation Security Administration. (2024, October 7). TSA announces final rule that enables the continued acceptance of mobile driver’s licenses at airport security checkpoints and federal buildings. TSA. https://www.tsa.gov/news/press/releases/2024/10/24/tsa-announces-final-rule-enables-continued-acceptance-mobile-drivers

As the automotive industry transitions toward software-defined vehicles, autonomous technologies, and connected services, cybersecurity has become a critical concern. This white paper from the FIDO Alliance outlines key challenges and emerging solutions for securing next-generation vehicles. It examines global regulatory frameworks such as UN R155, UN R156, and ISO/SAE 21434 and presents the FIDO Alliance’s standards for passwordless authentication, secure device onboarding, and biometric certification.

Audience

This paper addresses the automotive industry. The audience includes automotive system engineers, automotive IVI product and development managers, automotive networking and in-vehicle cyber security engineers, product managers for in-vehicle services for applications such as purchasing, IT system cyber security managers, engineers seeking to support global regulatory frameworks such as UN R155/R156 and ISO/SAE 21434, manufacturing system engineers, and car-to-cloud connectivity engineers.

1. Introduction

The automotive industry is undergoing transformative changes, including the shift to software-defined and autonomous vehicles, advanced IT-like architectures, over-the-air (OTA) updates, and the rise of in-vehicle commerce. While these changes offer new revenue opportunities, they also bring significant cybersecurity threats.

Global cybersecurity legislation, such as UN Regulation 155, UN Regulation 156, and ISO/SAE 21434, aim to protect vehicles from emerging threats. The FIDO Alliance plays a crucial role by providing standards for secure authentication, device onboarding, and biometrics certification.

Utilizing standards helps automotive companies ensure consistent security, leverage collective expertise, and avoid proprietary solutions that have the potential to stymie new markets and revenue. FIDO standards apply to various automotive applications, including consumer services, in-vehicle solutions, workforce authentication, and manufacturing, ensuring robust cybersecurity across the industry.

This paper provides companies within the automotive ecosystem an insight into the standards and services the FIDO Alliance offers together with a review of current and future use cases.

The FIDO Alliance is seeking feedback and partnership with industry experts to help ensure that FIDO’s programs are fit for purpose and successfully help companies meet cybersecurity needs, improve driver experiences, and tap into new opportunities.

2. Evolution of the automotive industry

The automotive industry has 140 years of history and is currently going through changes that affect all aspects of the industry:

• Electrification and sustainability
• Software-defined vehicles and connectivity
• Autonomous and assisted driving
• Shifting business models: Mobility-as-a-Service (MaaS) and direct sales
• Supply chain disruptions and geopolitical risks
• New revenue streams: data monetization and services
• Rollout of EV charging infrastructure and its energy grid impacts
• Changing consumer expectations and digital experiences

These changes bring potential upside to manufacturers in terms of new revenue opportunities and improved vehicles, but they also introduce considerable cyber threats.

Vehicles have evolved from isolated mechanical systems into interconnected cyber-physical platforms (often created by various entities) that integrate complex software, hardware, and communication networks. Manufacturers implement these systems to provide end users with a better vehicle and an enhanced driving experience, but they also bring an increased risk of cyber threats associated with new “attack surfaces”. These potential threats come in many forms, from malicious hackers to state funded actors. To minimize these threats, it is now a fundamental priority for manufacturers, their suppliers, regulators, and other industry stakeholders to focus on cybersecurity.

3. Meet the challenges and seize the opportunity

Automotive cybersecurity professionals have a massive challenge in front of them. On one side they need to react to the rise in threats and account for the associated legislation that has been developed to protect consumers. On the other side they need to be open to supporting new business models such as in-vehicle commerce, value added vehicle features such as subscription services, as well as additional cybersecurity for factories and offices. While there is no one simple solution to meet all of these needs, utilizing standards and certification programs from organizations such as the FIDO Alliance can help greatly.

4. Automotive cybersecurity and global legislation

National governments and international organizations have enacted regulations that require stringent cybersecurity measures throughout the automotive lifecycle, including design, operation, and even end-of-life. These frameworks aim to shield vehicles from emerging threats and establish a baseline for safety and trust across the automotive ecosystem. Major worldwide examples include:

• United Nations Regulation 155 and United Nations Regulation 156: mandate that vehicles incorporate a Cybersecurity Management System (CSMS) and a Software Update Management System (SUMS)
• ISO/SAE 21434: provides the foundation for global automotive cybersecurity engineering, outlining processes for managing cyber risks throughout the entire vehicle lifecycle
• China’s GB 44495-2024 and GB 44496-2024: regulate the Cyber Security Management System (CSMS) and govern secure software updates in a granular fashion
• India’s AIS 189 and AIS 190: align with UN R155 and R156, to regulate the cybersecurity of connected vehicles
• United States: Publication of cybersecurity best practices by the National Highway Traffic Safety Administration (NHTSA) that emphasize secure vehicle development processes, incident response plans, and continuous risk monitoring

Refer to Appendix A to learn more about these standards.

5. The FIDO Alliance and FIDO standards

The FIDO Alliance is an open industry association with a focused mission: reduce the world’s reliance on passwords. To accomplish this, the FIDO Alliance promotes the development of, use of, and compliance with standards for user authentication and device onboarding.

The FIDO Alliance:

• Develops technical specifications that define an open, scalable, interoperable set of mechanisms to reduce reliance on passwords for authentication of both users and devices.
• Tracks the evolution of global regulations and evolves its own standards to help industries satisfy those regulations in a harmonized way, reducing their compliance burdens.
• Operates industry certification programs to ensure successful global adoption of these specifications.
• Provides education and market adoption programs to promote the global use of FIDO.
• Submits mature technical specifications to recognized standards development organizations for formal standardization.

The FIDO Alliance has over 300 members worldwide, with representation from leaders in IT, silicon, payments, and consumer services and features a Board of Directors that includes representatives from Apple, Visa, Infineon, Microsoft, Dell, Amazon, and Google. The Alliance also has a variety of active working groups where like-minded members can develop and advance technical work areas and coordinate on market-specific requirements.

The FIDO Alliance is planning to launch an automotive working group, where leaders in this sector can identify and collaborate on technical, business, and market requirements. To learn more, use the Contact Us form at https://fidoalliance.org/contact/ or email info@fidoalliance.org.

6. FIDO for automotive cybersecurity compliance

Meeting the demands of the primary automotive cybersecurity standard ISO/SAE 21434 and subsequently the most prominent regulation, UN R155, hinges on strong identity management and secure device onboarding. While these standards don’t prescribe FIDO protocols per se, they outline key principles where FIDO offers tangible benefits.

ISO 21434, particularly Clauses 8 and 9 concerning risk assessment and threat mitigation, calls for strategies to prevent unauthorized access. FIDO’s passwordless authentication directly addresses this by eliminating weak credentials and reducing risks from phishing and credential stuffing, common threats to connected vehicle systems. Additionally, Clause 10’s focus on secure software deployment aligns with FIDO Device Onboard (FDO), ensuring only authenticated devices join the ecosystem, mitigating supply chain attacks and unauthorized software injections. This direct mapping of FIDO’s capabilities to specific clauses demonstrates its value in achieving compliance.

Beyond these founding standards, FIDO’s approach has broad applicability to emerging regulations, providing OEMs with a pathway to meeting global compliance demands and bolstering cybersecurity resilience across their connected car ecosystem. Some examples include China’s GB 44495-2024 and India’s AIS 189, which call for regional automotive cybersecurity standards and reinforce the need for features such as secure authentication in the software-defined vehicle (SDV) era. China’s GB regulation, similar to UN R155, emphasizes authenticity and integrity in remote updates, where FIDO’s passkey-based authentication provides a compliant approach to verifying access. India’s regulations, currently still in draft, align with UN R155, highlighting the importance of securing vehicle-to-cloud communications and identity management.

7. Overview of emerging use cases where FIDO standards may apply

FIDO standards can be applied to a wide range of scenarios. These can be customer-facing, embedded within the vehicle, or as part of the manufacturer’s IT infrastructure.

High level overview of some of some of these scenarios include but not limited to:

• In-vehicle commerce: This includes payments using credentials stored and managed in vehicle to enable convenient fueling, EV charging, parking reservations, car washes or even in-vehicle marketplaces managed by the car manufacturer. Implementation of passkeys to authenticate the associated car user and biometric component certification are most relevant to these use cases.
• Authentication to personalized services: These applications include easy access to customized automotive settings (for example, headrest and seat adjustments) as well as to informational and entertainment content.
• In-vehicle solutions: This segment includes applications such as car-to-cloud connectivity and onboarding of ECUs and zone controllers within the vehicle. Implementation of FIDO Device Onboard (FDO) is most applicable to these applications.
• Workforce authentication: These applications include controlling workforce access to IT systems whether at a development office, manufacturing site, or dealership. Implementation of passkeys and FIDO USB authentication keys are most applicable to these applications.
• Manufacturing: Modern manufacturing facilities are moving towards software defined control, AI, and robotic systems. The secure deployment of these solutions is often time consuming and expensive. Implementation of FIDO Device Onboard (FDO) can accelerate deployments and increase security.

8. FIDO Alliance technology overview

In the same way that Ethernet started as an IT networking solution, FIDO standards were not specifically created for automotive applications. However, they are highly relevant in modern vehicles where robust cybersecurity is a critical, foundational element rather than just a desirable feature. FIDO standards, such as passkeys, are being used as is in the automotive world today.

The FIDO Alliance technology portfolio for automotive applications can be broadly grouped into three main areas:

Passkeys: The FIDO Alliance is transforming authentication through open standards for phishing-resistant sign-ins using passkeys. Passkeys are more secure than passwords and SMS OTPs, easier for consumers and employees to use, and simpler for service providers to deploy and manage. Automotive manufacturers leverage passkeys for a wide variety of use cases.

Device Onboarding: The FIDO Alliance establishes standards for secure device onboarding (FDO) to ensure the safety and efficiency of connected devices in segments such as industrial and enterprise. In the automotive sector, manufacturers can apply this standard to the connections between Electronic Control Units (ECUs) and zone controllers or connections between the vehicle itself and the cloud services that facilitate over-the-air software updates. This standard has been adopted by Microsoft, Dell, ExxonMobil, Red Hat and others.

Biometrics certification: The FIDO Alliance offers a certification program tailored to specific applications that uses independent test labs to measure performance of biometric sensors (such as iris or fingerprint sensors). Biometric sensors are becoming an increasingly important component of vehicles. Typical use cases might be to automatically configure the driver’s seat position or as part of a payment system. In these two examples the definition of “good technical performance” can differ greatly. Samsung, ELAN Microelectronics, Thales, Qualcomm, Mitek, iProov, and others have had biometric components certified by FIDO Alliance.

9. FIDO Alliance technology deep dive

To better understand how automotive manufacturers and the FIDO Alliance can work together, this section discusses current FIDO technologies and how they might integrate with automotive applications.

9.1 Passkeys and user authentication

A passkey is a FIDO authentication credential based on FIDO standards, that allows a user to sign in to apps and websites with the same steps that they use to unlock their device (biometrics, PIN, or pattern). With passkeys, users no longer need to enter usernames and passwords or additional factors.

Passkeys are the signature implementation of FIDO authentication standards, and they offer secure yet simplified sign-in to a wide range of services. Passkeys are supported by all major device operating systems and browsers and have been utilized by many industry leaders including Apple, Google, Microsoft, Samsung, Amazon, Walmart, PayPal, and Visa.

The following diagram illustrates how passkeys can be used for in-car applications, such as when a driver signs in to a cloud service.

Figure 1:Sample passkey usage in automotive

Passkeys rely on a technology known as public key cryptography (PKC), in which a virtual key pair is created, one private and the other public. For each private key (stored on the user’s device) there exists a matching public key (stored on the server) that is used to check signatures created with the private key.

In the diagram, a user (the driver in this case) first registers with a cloud service such as a payment service. During the registration process, a private and public cryptographic key is created by the FIDO Authenticator. The private key is stored securely in the infotainment system of the vehicle and is associated with that driver. The public key is stored on the cloud of the service provider.

When the driver wants to sign in to the service, a request is sent from the vehicle to the cloud service. The service then sends an authentication request to the vehicle. This challenge can only be successfully authorized by the user that holds the matching private key. To make sure that request is genuine, the driver is asked to confirm that they want to sign in. This is typically achieved via a biometric sensor such as fingerprint or face. Once this verification is complete, the user gains access to the service. Several FIDO hardware and software components are used for this process.

9.2 Passkey components

Three FIDO Certified components are used in the example:

FIDO authenticator

A FIDO authenticator is a software component or a piece of hardware that can perform FIDO authentication to verify possession and/or confirm user identity. In the example, the FIDO authenticator likely resides in the car infotainment system.

FIDO server

The server provides an application with a programming interface that can be leveraged with a FIDO Certified client to perform strong authentication. The server sits inside the cloud application.

Biometric components

Biometric components can identify an individual and are often used to compliment a FIDO authenticator. These sensors can take multiple forms including fingerprint, iris and face. The FIDO Alliance certifies the efficacy of biometric subsystems including end-to-end performance, differential assessment of demographic groups, and presentation attack detection (PAD).

Although the example is an in-vehicle use case, the same passkey technology can be applied inside a factory, development center, or dealership to ensure that systems are resilient to phishing attacks or other common password attack vectors.

9.3 In-vehicle biometrics

Installation of biometric components in vehicles is expected to increase rapidly over time. The performance needs of these components will vary by sensor type and target application. Today, the FIDO Alliance offers a comprehensive independent certification program for biometric components such as fingerprint and iris sensors. By specifying in a request for quote (RFQ) that products should be FIDO Certified, automotive manufacturers can simplify selection of sensors. For more information on FIDO Certification, visit https://fidoalliance.org/certification/.

9.4 FIDO Device Onboard (FDO)

When a computer device (such as an ECU) first connects to its management platform (the zone controller), it needs to be onboarded and provisioned. A parallel example might be the connection between a vehicle and its cloud. FIDO Device Onboard (FDO) was developed by FIDO Alliance members to meet the automation and high security requirements of such onboarding experiences.

With FDO, a device is first connected to the (wired or wireless) network and then powered up. The device then automatically and securely onboards to the management platform. FDO is based on a zero-trust architecture and therefore offers a high level of security as both the device and the management platform must cryptographically authenticate themselves to each other. FDO also provides resilience to supply chain attacks.

A number of leading technology providers have demonstrated implementations of FDO solutions including Dell, Microsoft, Red Hat, Intel, and ASRock.

10. FIDO technology use cases deep dive

The FIDO Alliance has identified several use cases where FIDO technology can be applied to support the automotive industry. This section discusses possible use cases with the hopes of fostering further conversations.

10.1 Consumer use cases

Historically, many cybersecurity applications have been “behind the scenes”. In modern vehicles there is an increasing number of new applications that directly impact the driver and passenger in-vehicle experience and open new revenue opportunities for manufacturers. One such area is the emergence of in-vehicle commerce.

Several factors are driving in-vehicle commerce:

• Technological advancements
  • Software Defined Vehicles (SDVs) allow for continuous updates and new functionality without hardware modifications.
  • Autonomous driving introduces a new use case for vehicles as productivity or leisure spaces.
• Changing consumer expectations
  • Consumers demand experiences in their vehicles akin to those offered by their smartphones and other digital devices.
• Revenue opportunities
  • By acting as platforms for digital services, vehicles open new revenue streams for car manufacturers and service providers.

10.2 Identity verification, authentication, and authorization

The growing connectivity and services associated with modern vehicles brings about new requirements for identity verification, authentication, and authorization.

• Identity verification: The process of confirming a person’s identity. It can involve comparing information provided by a person with records in a database or with the person’s physical documents such as a driver’s license.
• Authentication: Confirms that a person is who they say they are when attempting to sign in to systems, services, and resources.
• Authorization: The step after authentication that determines user access in terms of accessing data or performing actions.

Unlike other computing devices, such as smartphones and wearables, vehicles often have multiple users including family members, friends, co-workers, or renters. Each user may need access to services or to perform transactions tied to their unique identities and credentials. Therefore, vehicular computing resources must be cyber secure and capable of managing secure access and authentication for a diverse user base, including third-party service providers.

10.3 In-vehicle commerce and authentication

Commerce services in vehicles are closely tied to payments, making strong and user-friendly authentication essential. Drivers must trust that transactions are secure, manufacturers aim to minimize liability for unauthorized payments, and financial institutions require robust, standards-compliant authentication mechanisms. In addition, regulatory frameworks, such as Europe’s Payment Services Directive 2 (PSD2), mandate strong customer authentication (SCA) for cardholder-initiated transactions.

SCA requires a combination of at least two out of three factors:

• Possession (something the user has, for example, a key, phone, or vehicle)
• Inherence (something the user is, for example, biometrics like fingerprint or facial recognition)
• Knowledge (something the user knows, for example, a PIN or password)

If the passkey authenticator is not natively integrated into the vehicle, authentication must be implemented using alternative multi-factor configurations. This can be achieved through software-based approaches, such as combining a PIN (knowledge) with the vehicle as a possession factor, or through hardware-based methods, such as biometric authentication (inherence) via fingerprint sensors or facial recognition, again anchored by the vehicle as the possession factor.

In-vehicle commerce can be broadly categorized into three main areas:

On-demand features

• With on-demand features, vehicles now allow users to activate specific functionalities based on their needs. This includes advanced driver-assistance systems, comfort features like heated seats, and performance upgrades.
• On-demand features can be offered through flexible subscription models or pay-per-use systems. These features enhance customer satisfaction and create additional revenue streams for manufacturers.

Vehicle-related services

• Vehicle-related services are seamlessly integrated services that include fueling, EV charging, parking reservations and payments, car washes, and toll payments.
• To maximize user convenience, the vehicle acts as a payment hub without reliance on a smartphone.

Convenience features

• With implementation of convenience features such as shopping, entertainment, education, and even remote work functionalities, the vehicle becomes an extension of the user’s digital ecosystem.
• Examples include ordering coffee or groceries on the go, streaming movies, or attending virtual meetings during commutes.
• These categories illustrate that vehicles are no longer just modes of transportation but platforms that enable various service providers to engage with drivers and passengers.

10.4 Driver ID Verification for vehicle access control

Vehicle access requires a high level of authentication and is well suited to biometric sensors.

• Keyless entry and ignition: Biometric systems like fingerprint and facial recognition can replace traditional keys to provide secure, biometric-based authentication for vehicle access and ignition.
• Anti-theft measures: Vehicles can utilize biometric authentication to prevent unauthorized usage or theft, including carjacking.
• Vehicle and OEM services: Vehicles can use biometric authentication as the first step to assessing a driver’s rights and privileges in determining how vehicle services can be accessed.

10.5 Personalization, fleet management and autonomous vehicles

Vehicles are often shared and the ability to automatically adapt to a specific driver is an important capability. The criteria and threshold for identification and authentication varies greatly depending on the specific application. For example, adjusting a driver’s seat adjustment versus passenger authorization for an autonomous vehicle.

10.5.1 Personalization

• Adaptive in-car settings: Biometric recognition can identify drivers or passengers in order to adjust seat positions, climate controls, infotainment preferences, and navigation routes according to stored profiles.
• Adaptive usage-based services: By seamlessly authenticating the driver, the automaker can provide use-based insurance or leasing and financing options for personal and commercial scenarios.
• Fleet management
• Shared vehicles and fleets: Biometric-enabled processes ensure smooth transitions between users in car-sharing or fleet systems, loading personal settings for each verified driver.
• Compliance tracking: Digital wallets can hold compliance documents (for example, licenses and vehicle inspection reports) to reduce paperwork and enhance audit readiness by asserting compliance attributes to authorized users.

10.5.2 Autonomous vehicles

Passenger authentication and ID verification: In self-driving cars, biometric systems authenticate passengers to ensure authorized use and personalized experiences.

Why key possession is not sufficient authentication

There are several reasons why a physical key is not a sufficient form of user authentication.

• A physical key verifies access to the vehicle but does not confirm the identity of the individual using it. In scenarios such as ridesharing, fleet management, or multi-user vehicles, relying solely on key possession fails to distinguish authorized users from unauthorized users.
• As discussed earlier, for payment use-cases there is a need in some markets to be compliant with SCA regulations. A key only satisfies the possession factor and therefore does not meet the SCA requirements for secure payments.
• A vehicle key can be lost, stolen, or duplicated allowing unauthorized individuals to gain access. Without additional layers of authentication, transactions made in the vehicle could be fraudulent.
• Multi-party and platform complexity: In-car commerce involves multiple stakeholders such as Original Equipment Manufacturers (OEMs), service providers, and users. Authentication must ensure that the user is authorized to transact across all platforms and services, necessitating identity verification beyond simple possession.

10.6 Electronic systems and manufacturing use cases

10.6.1 In-vehicle ECU, zone controller, and compute onboarding

As the compute level rises within vehicles, the need for efficient and fast communication becomes increasingly important. In response to this need, cars are increasingly moving to an IT-centric architecture with Ethernet becoming the networking technology of choice to link zone controllers and ECUs inside a vehicle.

In addition to high speed and secure communication, there is a need to ensure that both the device (ECU) and the management platform (Zone controller) are cryptographically authenticated against each other. Although initially developed for IoT and IT systems, the FIDO Alliance team believes that FIDO Device Onboard (FDO) can be a fast and secure way to automate the onboarding process. As FDO is an open standard, automotive manufacturers can benefit from economies of scale savings versus paying for the development and maintenance of proprietary solutions.

In addition to speed and security, FDO also provides resilience to supply chain attacks and grey market counterfeits.

10.6.2 Car to cloud onboarding

As the complexity of car features grows and autonomous driving technology increases, a modern car is essentially a computer on wheels that requires a vast amount of software for all functions to operate.

Most sources agree that a typical modern car is managed by software generated by around 100 million lines of code. The very nature of this complexity confirms that the days when vehicle software can be frozen at vehicle product launch is no longer realistic.

Software updates are now a mandatory feature of modern automobiles and a secure and efficient way of connecting the vehicle to the manufacturer’s cloud is essential.

FDO provides a secure and fast method for vehicles to onboard to their management platforms, making Over the Air (OTA) software updates possible.

Figure 2:FIDO fit for in-vehicle systems

Additionally, new updates to the FDO standard are expected to allow software to securely deploy to bare ECUs or zone controllers, which would greatly simplify dealership repairs and upgrades.

10.7 Workforce authentication (passkeys/FIDO keys)

For many years the IT industry has been using FIDO authenticators to ensure that only authorized staff have access to systems. The risks associated with attacks in this space have been highlighted by the recent challenges faced by some automotive dealers.

Figure 3:FIDO fit for workforce authentication

A cyberattack on a software provider for car dealerships occurred in June of 2024 and disrupted the operations of thousands of dealerships in North America. This attack caused major disruptions, including delays for car buyers and an estimated $1 billion in collective losses for dealerships.

10.8 Manufacturing use cases

Factories are using classic fixed function manufacturing functions such as motion control and PLCs less as they move towards use of far more flexible and intelligent software defined control and AI based vision systems. This transition introduces large numbers of general-purpose computers to the factory floor.

At installation, each server or industrial PC needs to be onboarded to its respective management platform (on-premises or cloud). This onboarding process typically requires that skilled technicians manually configure the credentials or passwords in the devices, a process that is slow, not secure, and expensive.

With FIDO Device Onboard (FDO), a technician can plug in an industrial PC and have it automatically and securely onboard the management server platform.

The following diagram shows how FDO is used to onboard the industrial PCs to the local servers which are in turn onboarded to the manufacturing cloud.

Figure 4:FIDO fit for automotive manufacturing

11. Why using standards helps

Cybersecurity standards, such as those from the FIDO Alliance, offer value in ways that are hard for any single company to achieve. These consensus-based standards represent maturity and provide consistency for the industry, which are crucial for reliable authentication and authorization. FIDO cybersecurity standards are based on diverse expertise, provide clarity in a changing cybersecurity landscape, and offer essential guidance for certification authorities and regulators as they develop new laws.

Although the automotive industry has utilized standards almost since its inception, there are still areas where companies have tried to develop their own proprietary solutions. Such solutions rarely add value for the manufacturers and require engineering talent to develop and time to maintain.

As the automotive computing platform is a system of systems, the automotive industry can benefit from lessons learned by related industries. Open standards supported by certification programs help streamline product and service development.

FIDO’s standards are essentially commoditizing authentication elements that are critical to cybersecurity, but that are not natural areas for competitive differentiation. By leveraging standards, vendors and manufacturers can now focus their resources and development efforts on higher-value services.

11.1 Benefits of partnering with the FIDO Alliance

Diverse expertise: The FIDO Alliance brings together skilled professionals from various companies, including cloud players, credit card companies, and manufacturers.

Ecosystem cohesion: Standards ensure quality, security, and interoperability within ecosystems, which is crucial for applications like payments.

Adapt to emerging threats: The threat landscape is always evolving. As an example, quantum computing represents a significant threat to commonly used encryption techniques. Although quantum computing is in a relatively early stage of maturity, standards groups such as the FIDO Alliance are already defining how to create quantum resilient solutions.

12. FIDO Certification programs for the automotive industry

The FIDO Alliance’s world-class certification programs validate that products conform to FIDO specifications and interoperate effectively and assess security characteristics and biometric performance. With over 1,200 FIDO Certified products from hundreds of vendors around the world, these programs unlock the value of FIDO’s open standards for vendors and buyers. By specifying FIDO Certification in their RFQ’s, manufacturers can be sure that their suppliers will deliver performant, secure, and interoperable products.

Automotive OEMs can seek out and leverage components that are already certified (for example, authenticators or biometric components) and FIDO Alliance’s certification team is also developing an automotive profile with its lab partners that replicates in-car environments for more precise biometric tests. The Alliance seeks automotive sector feedback to help us collectively:

• Address gaps in the current certification specifications
• Update specifications as needed
• Issue sector-specific policies
• Implement new testing procedures

For more information on FIDO Certification, visit https://fidoalliance.org/certification/.

13. Conclusion and next steps

The automotive industry and cybersecurity are evolving quickly; the FIDO Alliance’s proven and established standards and certification programs can help with a wide range of automotive industry applications. Applications include in-vehicle services and payment authentication, onboarding zone-controllers, car-to-cloud connectivity, OTA updates, and leveraging biometrics for a better driver experience.

The FIDO Alliance provides a path for automotive manufacturers and their suppliers to simplify their development processes, raise security levels, improve customer experience, reduce costs and tap into new revenue opportunities.

Feedback is welcome on the topics covered within this white paper and the FIDO Alliance encourages interested parties to engage with the Alliance and its members. FIDO Alliance members can learn more about FIDO standards and have opportunities to influence how these standards evolve. Additionally, members get the benefit of being able to engage with a broad range of thought leaders from leading companies within the broader ecosystem.

To get involved visit https://fidoalliance.org/members/become-a-member/ or use the Contact Us form at https://fidoalliance.org/contact/.

14. Appendix A – Global legislation applicable to automotive cybersecurity

National governments and international organizations have enacted regulations that require stringent cybersecurity measures throughout the automotive lifecycle, from design to operation and even end of life. These frameworks aim to shield vehicles from emerging threats and establish a baseline for safety and trust across the automotive ecosystem.

United Nations Regulations 155 and 156: These are the most prominent and clearly defined automotive cybersecurity regulations. Adopted under the WP.29 framework in 2021, UN R155 and R156 are globally recognized and mandate that vehicles incorporate a Cybersecurity Management System (CSMS) and a Software Update Management System (SUMS). These regulations are prerequisites for type approvals in over 50 countries, including most EU nations, Japan, South Korea, and Australia (UNECE, 2021).

ISO/SAE 21434: This standard provides the foundation for global automotive cybersecurity engineering, outlining processes for managing cyber risks throughout the entire vehicle lifecycle. It complements existing regulations and aids manufacturers in complying with mandatory regulations such as UN R155 (ISO, 2021).

China’s GB 44495-2024 and GB 44496-2024: Introduced in the summer of 2024, these regulations mirror UN R155 and R156 but are more detailed in specificity. GB 44495 outlines cybersecurity requirements for connected vehicles, while GB 44496 governs secure software updates. China’s focus on intelligent connected vehicles highlights its ambition to lead in autonomous and connected technologies (Shadlich, 2024).

India’s AIS 189 and AIS 190: India has introduced AIS 189 and AIS 190, standards aligned with UN R155 and R156, to regulate the cybersecurity of connected vehicles. These frameworks emphasize risk management, monitoring, secure communication protocols, and secure software updates, similar to UN R155/R156 (Vernekar, 2024).

United States: While there are no mandated federal regulations for automotive cybersecurity, the National Highway Traffic Safety Administration (NHTSA) has published cybersecurity best practices. These guidelines emphasize secure vehicle development processes, incident response plans, and continuous risk monitoring. They align with ISO/SAE 21434 and offer a proactive approach to mitigating vulnerabilities in connected vehicles (NHTSA, 2022).

Document history

15. Contributors

Conor White, Daon, Inc
Richard Kerslake, FIDO Alliance
Andrew Shikiar, FIDO Alliance
Nimesh Shrivastava, Qualcomm Inc
Drew Van Duren, Qualcomm Inc
Jens Kohnen, Starfish GmbH & Co. KG
Tin T. Nguyen, VinCSS JSC
Henna Kapur, Visa

16. References

Harley, M. (2024, March 28). EU Cybersecurity Laws Kill Porsche’s 718 Boxster and Cayman Early. Retrieved from https://www.forbes.com/sites/michaelharley/2024/03/28/eu-cybersecurity-laws-kill-porsches-718-boxster-and-cayman-early/

ISO. (2021). ISO/SAE 21434:2021 Road vehicles—Cybersecurity engineering. International Organization for Standardization. Retrieved from https://www.iso.org/standard/70918.html

Miller, C., & Valasek, C. (2015, July 21). Hackers remotely kill a Jeep on the highway—With me in it. Wired. Retrieved from https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway

National Highway Traffic Safety Administration (NHTSA). (2022, September 7). Cybersecurity best practices for new vehicles. NHTSA. Retrieved from https://www.nhtsa.gov/press-releases/nhtsa-updates-cybersecurity-best-practices-new-vehicles

Shadlich, E. (2024, September 2). China’s New Vehicle Cybersecurity Standard: GB 44495-2024. Retrieved from https://dissec.to/general/chinas-new-vehicle-cybersecurity-standard-gb-44495-2024/

UNECE. (2021). UN Regulation No. 155 – Cyber security and cyber security management system. UNECE. Retrieved from https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security

University of Detroit Mercy. (n.d.). Vehicle cybersecurity engineering program. Retrieved from https://eng-sci.udmercy.edu/academics/engineering/vehicle-cyber-eng.php

Vernekar, A. (2024, October 10). Securing The Future Of Indian Automobiles: Understanding AIS-189 And Cybersecurity For Vehicles. Retrieved from https://vayavyalabs.com/blogs/securing-the-future-of-indian-automobiles-understanding-ais-189-and-cybersecurity-for-vehicles/

Walsh College. (n.d.). Bachelor of Science in Automotive Cybersecurity. Retrieved from https://walshcollege.edu/walsh-undergraduate-degree-programs/bachelor-of-science-in-information-technology/bachelor-of-science-in-automotive-cybersecurity/

Shane Weeden, IBM
An Ho, IBM

Abstract

Session hijacking is a growing initial attack vector for online fraud and account takeover. Because FIDO authentication reduces the effectiveness of other simpler forms of compromise, such as credential stuffing and phishing, cybercriminals turn to theft and re-use of bearer tokens. Bearer tokens are a form of credential which include session cookies used by browsers connecting to websites and OAuth access tokens used by other thick client application types such as native mobile applications. When these credentials are long-lived and can be “lifted and shifted” from the machine where they were created to be usable by a bad actor from another machine, their tradable value is significant. Emerging technologies such as Device Bound Session Credentials (DBSC) for browsers and Demonstrating Proof of Possession (DPoP) for OAuth applications seek to reduce the threat of session hijacking. This article describes how these technologies address the problem of session hijacking and how they complement strong phishing resistant authentication in online ecosystems.

Audience

This white paper is for chief information security officers (CISOs) and technical staff whose responsibility it is to protect the security and life cycle of online identity and access management from online fraud. 

1. Introduction

Authentication and authorization are integral parts of an identity lifecycle, especially for online credential ecosystems. The growing threat of online identity fraud with costly security incidents and breaches has enterprises looking for ways to protect and secure their workforces from account takeover through different attack vectors such as phishing, credential stuffing, and session hijacking. For authentication, FIDO authentication with passkeys provides users with “Safer, more secure, and faster online experiences”, and an increase in the adoption of passkeys has contributed to a reduction of the success of attack vectors of credential phishing, credential stuffing, and session hijacking accomplished via man-in-the-middle (MITM) phishing attacks. However, what happens after the authentication ceremony?

After authentication, browsers and application clients are typically issued other credentials. Enterprise applications generally fall into two primary categories: those that are web browser based and use session cookies for state management and those that are thick client applications using OAuth access tokens (this includes some browser-based single page applications and most native mobile applications). Both types of credentials (session cookies and access tokens) are considered, in their basic use, as “bearer” tokens. If you have the token (the session cookie or the access token), then you can continue to transact for the lifetime of that token as the user who authenticated and owned it.This whitepaper explores adjacent technologies that address the “lift and shift” attack vector for bearer tokens and how these technologies complement FIDO-based authentication mechanisms. In particular, this paper focuses on the proposed web standard Device Bound Session Credentials (DBSC) for protecting browser session cookies and OAuth 2.0 Demonstrating Proof of Possession (DPoP) for protecting OAuth grants.

2. Terminology

session hijacking: An exploitation of the web session control mechanism that is normally managed for a session cookie.

credential stuffing: An automated injection of stolen username and password pairs (credentials) into website login forms to fraudulently gain access to user accounts.

<sub>1. Passkeys – https://fidoalliance.org/passkeys/
2. Device Bound Session Credentials – https://github.com/w3c/webappsec-dbsc
3. OAuth 2.0 Demonstrating Proof of Possession (DPoP) – RFC9449: https://datatracker.ietf.org/doc/html/rfc9449
4. Session hijacking attack https://owasp.org/www-community/attacks/Session_hijacking_attack
5. Credential stuffing https://owasp.org/www-community/attacks/Credential_stuffing</sub>

access token: A credential used by a client-side application to invoke API calls on behalf of the user.

session cookie: A credential managed by browsers to maintain session state between a browser and a website.

bearer token: A token (in the context of this whitepaper may refer to either an access token or a session cookie) so called because whoever holds the token can use it to access resources. A bearer token on its own can be “lifted and shifted” for use on another computing device.

sender-constrained token: A token protected by a mechanism designed to minimize the risk that anything other than the client which established the token during an authentication process could use that token in subsequent requests for server-side resources.

Device Bound Session Credential (DBSC): A proposal for a W3C web standard defining a protocol and browser behavior to establish and maintain sender-constrained cookies. The mechanism uses proof of possession of an asymmetric cryptographic key to help mitigate session cookie hijacking.OAuth 2.0 Demonstrating Proof of Procession (DPoP): A mechanism for implementing sender-constrained access tokens that requires clients to demonstrate possession of an asymmetric cryptographic key when using the token.

OAuth 2.0 Demonstrating Proof of Procession (DPoP): A mechanism for implementing sender-constrained access tokens that requires clients to demonstrate possession of an asymmetric cryptographic key when using the token.

3. Adjacent/complementary technologies for a secure ecosystem

While FIDO authentication technology can effectively eliminate phishing and credential stuffing attacks that occur during the login process, the addition of solutions to mitigate threats associated with bearer token theft is equally important. Bad actors whose attacks are thwarted during the login process will go after the next weakest link in the chain and try to steal post-authentication bearer tokens. This section explores two of these technologies for protecting bearer tokens: Device Bound Session Credentials (DBSC) protect browser-based session cookies and Demonstrating Proof of Possession (DPoP) protects OAuth grants. Alternative approaches to protect bearer tokens are also discussed.

Because no single piece of technology can protect against all threats, a combination of multiple techniques is required for adequate protection.

Table 1: Combination of technologies for increased security

Technologies	Authentication threats		Post-authentication threats
	Remote Phishing	Credential Stuffing	Token Theft
Passkeys
DBSC/DPoP
Passkeys + DBSC/DPoP

3.1 Browser session cookie security

Before discussing Device Bound Session Credentials (DBSC), you will need to understand the problem being addressed regarding browser session cookies. Session hijacking via cookie theft allows an attacker, who possesses stolen cookies, to bypass end-user authentication, including any strong or multi-factor authentication (MFA). This is particularly problematic when browsers create long-lived session cookies (which are a type of bearer token), since these cookies can be traded as alternatives to a user’s primary authentication credentials and then used from the attacker’s machine. This can lead to unauthorized access to sensitive data, financial loss, and damage to an organization’s reputation. 

Attackers perform cookie theft through various methods such as man-in-the-middle phishing of a user’s existing MFA login process (when phishing-resistant authentication such as FIDO is not used), client-side malware, and occasionally through vulnerabilities in server-side infrastructure or software. Regardless of how cookie theft is perpetrated, when successful, these attacks are not only dangerous, but also hard to isolate and detect. Complementary technologies, such as Device Bound Session Credentials (DBSC), minimize the risks associated with browser cookie theft by making stolen cookies impractical to use from any machine other than the machine to which they were issued during authentication.

3.2 Device Bound Sessional Credentials – DBSC

DBSC refers to a proposed web standard currently in development within the Web Application Security working group of the W3C[2]. The goal of DBSC is to combat and disrupt the stolen web session cookies market. This is achieved by defining an HTTP messaging protocol and required browser and server behaviors to result in binding the use of application session cookies to the user’s computing device. DBSC uses an asymmetric key pair and in browser implementations the private keys should be unextractable by an attacker – for example stored within a Trusted Platform Module (TPM), secure element, or similar hardware-based cryptographic module.

At a high level, the API in conjunction with the user’s browser and secure key storage capabilities, allows for the following:

• The server communicates to the browser a request to establish a new DBSC session. This includes a server-provided challenge.
• The browser generates an asymmetric key pair, then sends the public key along with the signed challenge to the server. This process is referred to as DBSC registration. Browser implementations of DBSC should use operating system APIs that facilitate secure, hardware-bound storage and use of the private key.
• The server binds the public key to the browser session by issuing a short-lived, refreshable auth_cookie which is then required to be transmitted in subsequent browser requests to the web server.

As the auth_cookie regularly expires, a mechanism is required for the browser to refresh the auth_cookie asynchronously to primary application web traffic. The refresh process requires signing a new server-issued challenge with the same private key created during DBSC registration, thereby re-proving (regularly) that the client browser is still in possession of the same private key.

Limiting the lifetime of the auth_cookie to short periods of time (for example, a few minutes) disrupts the market for trading long-lived session cookies. An attacker can only use stolen session cookies (including the auth_cookie) for a brief period, and cannot perform a refresh operation, since the private key required to perform a refresh operation is not extractable from the client machine.

DBSC may be introduced into existing deployments with minimal changes to the application. This is important as DBSC could easily be incorporated as a web plugin module in existing server-side technology (for example, Apache module, Servlet Filter, or reverse proxy functionality). This permits enterprises to roll out deployment of DBSC in phases without a complete overhaul of all current infrastructure and companies can prioritize certain critical endpoints or resources first.

DBSC server-side implementations can also be written in a manner that permits semantics, for example: “If the browser supports DBSC, use it, otherwise fallback to regular session characteristics.” This allows users to gain the security advantages of DBSC when they use a browser that supports it without having to require all users to upgrade their browsers first.

Refer to the Device Bound Session Credentials explainer for more details on the DBSC protocol and standard, including a proposal for enterprise-specific extensions that adds attestation to DBSC keypairs.

3.2.1 What makes DBSC a technology complementary to FIDO?

The DBSC draft standard permits the login process to be closely integrated with the DBSC API. While FIDO is a mechanism that makes authentication safer and phishing resistant, DBSC is a mechanism that makes the bearer credential (session cookie) safer post-authentication. They complement each other by reducing the risk of account takeover and abuse, making the entire lifecycle of application sessions safer.

3.2.2 Alternative solutions

DBSC is not the first standard to propose binding session cookies to a client device. Token Binding is an alternative that combines IETF RFCs 8471, 8472, and 8473. Token Binding over HTTP is implemented via a Transport Layer Security (TLS) extension and uses cryptographic certificates to bind tokens to a TLS session. Token Binding has had limited browser adoption and is complex to implement as it requires changes at the application layer and in TLS security stacks. The Token Binding over HTTP standard has not been widely adopted and only one major browser currently offers support.

3.2.3 Advice

The DBSC standard relies on local device security and operating system APIs for storage and use of the private key that is bound to the browser’s session. While these private keys cannot be exported to another device, the key is available on the local system and may be exercisable by malware residing on the user’s device. Similarly, in-browser malware still has complete visibility into both regular session cookies and short-lived auth_cookies. DBSC is not a replacement for client-side malware protection, and the threat model for DBSC does not provide protections from persistent client-side malware. Ultimately, the user must trust the browser.

As browsers start to support DBSC over time, it will be important for servers to be able to work with a mix of browsers that do and do not include support for this technology. Some enterprises may dictate that corporate issued machines include browsers known to support DBSC, but many will not. It will be necessary for server-side implementations to take this into consideration, using DBSC when the browser responds to registration requests, and tolerating unbound session cookies when the browser does not. When building or choosing a commercial solution, ensure you consider this scenario, and include the ability to implement access control policies that strictly require DBSC in highly controlled or regulated environments or for specific applications.

At the time of writing, DBSC is in early evolution. It remains to be seen whether or not it will be widely adopted by browser vendors. The hope is that incubating and developing this standard via the W3C will result in wider adoption than previous proposals, similar to the way that the WebAuthn API has been adopted to bring passkey authentication to all major browser implementations.

4. OAuth grants

The previous section introduced DBSC as a means to protect against session cookie theft in web browsers. Thick application clients, including mobile applications and single-page web applications, typically use stateless API calls leveraging OAuth grants instead of session cookies. An OAuth grant may be established in several ways, with the  recommended pattern for thick clients being to initially use the system browser to authenticate a user, and grant access for an application to act on their behalf. Conceptually this is remarkably similar to browser-based sessions, including the ability and recommendation, to use FIDO authentication for end-user authentication when possible. At the conclusion of the browser-based authentication portion of this flow, control is returned to the thick client application or single-page web application where tokens are established for use in programmatic API calls. 

The challenge that occurs from this point forward is almost identical to that described for browsers – the OAuth tokens are bearer tokens that if exposed to a bad actor can be used to call application APIs from a remote machine instead of from the legitimate application.

This section describes the use of DPoP, a technology for protecting the “lift and shift” of credentials used in OAuth-protected API calls which, just like DBSC, makes use of an asymmetric key pair and ongoing proof of possession of the private key.

4.1 Demonstrate Proof of Possession (DPoP)

OAuth 2.0 Demonstrating Proof of Possession (DPoP) is an extension of the existing OAuth 2.0 standard for implementing device bound (or sender-constrained) OAuth access and refresh tokens. It is an application-level mechanism that allows for the tokens associated with an OAuth grant (that is, refresh tokens and access tokens) to bind with the requested client using a public and private key pair. This requires the client to prove ownership of its private key to the authorization server when performing access token refresh operations and to resource servers when using access tokens to call APIs.

_{6. OAuth 2.0 for Native Apps https://datatracker.ietf.org/doc/html/rfc8252}

High assurance OpenID specifications, such as Financial-grade API (FAPI 2.0), mandate the use of sender-constrained tokens and DPoP is the recommended method for implementing this requirement when Mutual TLS (mTLS) is not available.

At a high level, DPoP requires that:

• The client generates a per-grant public/private key pair to be used for constructing DPoP proofs. Best practice implementations should use operating system APIs to ensure the private key is non-extractable.
• On initial grant establishment (for example, exchanging an OAuth authorization code for the grant’s first access token and refresh token), a DPoP proof (a JWT signed by the client’s private key that contains, among other things, a copy of the public key) is used to bind a public key to the grant.
• Requests to a resource server using an access token obtained in this manner must also include a DPoP proof header, continuously proving possession of the private key used during grant establishment. This is done for every API request. Resource servers are required to check if an access token is sender-constrained, confirm the public key, and validate the DPoP proof header on each API call.
• For public clients, subsequent refresh_token flows to the authorization server’s token endpoint must also contain a DPoP proof signed with the same key used during initial grant establishment. This is particularly important as the refresh tokens are often long-lived and are also a type of bearer token (that is, if you have it you can use it). The authorization server must enforce the use of a DPoP proof for these refresh token flows and ensure signature validation occurs via the same public key registered during initial grant establishment.

Unlike a plain bearer access token which can be used by any holder, DPoP based access tokens are bound to the client that initially established the OAuth grant, since only that client can sign DPoP proofs with the private key. This approach minimizes the risks associated with malicious actors trading leaked access tokens.

Refer to DPoP RFC 9449 – OAuth 2.0 Demonstrating Proof of Possession (DPoP) for more information.

4.2 What makes DPoP a complementary technology to FIDO?

FIDO can be leveraged for phishing resistant end-user authentication during establishment of an OAuth grant. Refresh and access tokens obtained by a client following this authentication should be safeguarded against “lift and shift” attacks just like session cookies in browser-based apps. DPoP is a recommended solution for protecting these OAuth tokens from unauthorized post-authentication use. Together, FIDO for end user authentication and DPoP for binding OAuth tokens to a client device complement each other to improve the overall security posture for identities used in thick client applications.

4.2.1 DPoP alternative solutions?

RFC8705 – OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens describes a mechanism that offers a transporter layer solution to bind access tokens to a client certificate. While it has been approved for use in FAPI 2.0 for open banking solutions, it is not particularly suitable for public clients such as native mobile applications.

RFC9421 – HTTP Message Signatures defines an application-level mechanism for signing portions of an HTTP message. Key establishment and sharing between the client and verifier are not defined by this specification, although this could be performed in a trust on first user manner during initial grant establishment in a similar manner to DPoP. There is no known public specification that maps the use of HTTP message signatures to the use case of sender-constrained bearer tokens in an OAuth client application. In the absence of such a public specification, widespread adoption for this use case is unlikely.

4.2.2 Advice

Sender-constrained tokens are a good idea, and, in some deployments, they are a regulatory requirement. For example, use of the FAPI profiles of OAuth is now mandated by many sovereign open banking initiatives. DPoP is a relatively simple way to achieve this requirement and is flexible enough to cover a wide range of application client types. That said, care must still be taken to adhere to the security considerations of DPoP. Pay close attention to section 11 of RFC9449, as well as apply other application security strategies for native or browser based single page applications as your scenario dictates. Remember that DPoP is focused solely on addressing the threats associated with token exfiltration, which include trading and use by malicious actors. It should be considered part of a defense-in-depth strategy for OAuth applications.

5. Conclusion

The intent of this paper is to inspire thinking around how different web security standards fit together and how those standards relate to the use of FIDO authentication for users. There are so many standards and standards bodies that it is often hard to understand which compete in the same space and which augment one another to form part of a comprehensive defense-in-depth strategy for identity fraud protection in online applications.

This paper tackled a specific, prevalent application security problem – the malicious trading and use of stolen cookies and access tokens. This paper also showed how technologies such as DBSC and DPoP mitigate the threats associated with token theft and how these technologies are complementary to FIDO authentication. Paired with FIDO, DBSC and DPoP provide greater overall identity fraud protection for your applications.

• Part 1: Overview – Introduces the concepts of a passkey journey toward phishing prevention.
• Part 2: Partial prevention – Details strategies for enforcing passkeys in specific scenarios.
• Part 3: Full prevention – Explains how to achieve comprehensive phishing resistance.

Making your services phishing-resistant takes more than one day because you are not just adopting a new phishing-resistant authentication method. It is a journey with multiple stages where you improve security by strengthening account login and recovery processes. This paper outlines the passkey journey and defines the authentication and recovery requirements for each stage.

Audience

Relying parties and developers who want to protect their applications from phishing attacks by adopting passkeys.

You can read the white papers on Passkey Central or use the following buttons to download PDF versions.

For any questions or comments, please contact feedback@fidoalliance.org.

Note this white paper has been revised – March 2025.

1. Executive Summary

IoT and edge computing solutions are exploding as manufacturers are looking for new ways to modernize their operations and accelerate production. By 2025, over 75 billion IoT devices will be connected globally. The industrial IoT market, which spans industries like manufacturing, healthcare, and retail is valued at USD 194 billion in 2024 and is projected to reach USD 286 billion by 2029. This surge unlocks immense opportunities and innovation for businesses and manufacturers alike. However, keeping up with the pace of demand for these devices and deploying them sustainably has created unprecedented challenges.

Namely, two key factors have the potential to derail the edge revolution entirely:

• Costly and inefficient installation processes
• Security vulnerabilities

2. What is Onboarding?

When an edge node or IoT device is installed in a facility, the device must be onboarded to its management platform hosted in the building or in the cloud.

The Onboarding Challenge

Device onboarding at scale is expensive and can introduce significant risks if not done properly. Meanwhile, typical manual onboarding processes and default passwords have created severe vulnerabilities, with 57% of IoT devices vulnerable to medium or high-severity attacks.

Nearly half (48%) of critical infrastructure security leaders reported experiencing at least one major security impact due to a compromised device within the last year.

What is FIDO Device Onboarding (FDO)?

FIDO Device Onboard (FDO) is a revolutionary standard designed to simplify, secure, and automate the onboarding process for IoT and edge devices. FDO simplifies device onboarding in edge and  IoT computing environments with a plug and play, zero trust approach embedded in the specification. Developed by industry leaders like Arm, Amazon, Google, Intel, Microsoft and Qualcomm, the specification is one of the first openly available standards designed specifically to solve edge and  IoT onboarding challenges: time-intensive, complex manual processes, high costs, and security vulnerabilities. It is targeted at industrial, medical, automotive, IT and retail use cases and is complemented by an independent certification program. 

3. The Overlooked Opportunity and Risk

With the introduction of AI, a new layer of complexity was added to the edge challenge. Organizations are now hyper-focused on AI adoption and its promise of smarter, faster, and more efficient operations, but without addressing foundational IoT security, these ambitions are at risk of being undermined.

FIDO Alliance Device Onboard (FDO) provides the answer, offering a zero trust, plug and play standard that accelerates deployments while safeguarding infrastructure. In today’s challenging economic climate, automating zero-touch device onboarding enables leaders to deliver ambitious digital transformation projects with limited resources and budgets, saving installation costs, accelerating time-to-value, and improving security. FDO is an open standard that allows users to innovate. FDO’s zero-trust approach is an important piece of the IoT security puzzle and sets the stage for future AI updates inside protected enclaves.

Which industries benefit from FDO?

What Device Types Can Be Enabled with FDO?

Just as passkeys revolutionized user authentication, FDO is transforming device onboarding in edge computing and IoT environments.

Key Features of FDO

The key features of FDO include:

• Late binding: Late binding saves money and time as FDO-enabled devices can be onboarded to any platform without the need for unique customization. This reduces the number of device SKUs needed versus other onboarding solutions. It ensures devices are authenticated and provisioned properly for the device recipient after ownership is verified.
• Plug and Play: Whereas manual onboarding requires expensive, skilled technicians, FDO is highly automated, often allowing semi-skilled staff to carry out the installation. This is important in markets such as retail where FDO will allow the store manager to do the installation rather than needing to bring in an expensive IT expert.
• Ownership voucher: Device ownership is established and transferred securely in the supply chain with the “ownership voucher,” which uses cryptographic authentication protocols in the FDO specification to verify the device recipient’s physical and digital ownership.
• Zero-touch and zero trust: Combined, these attributes establish a zero trust approach that covers end-to-end device onboarding using embedded, cryptographic protocols, and sequential processes to perform initial onboarding actions securely and quickly. The zero trust strategy covers both the device and the management platform during the onboarding process.

FDO for AI and Additional Features

FDO is designed to permit a secure subsystem to onboard independently and securely from the rest of the system. This makes FDO an excellent candidate for updating AI models deployed in edge secure enclaves from a cloud repository.

Additional features include:

• Interoperability with OPC Unified Architecture (OPC UA)
• Wi-Fi ready
• Flexible configurations for cloud, multi-cloud, and closed network environments with multi-tenant and cloud servers
• Multiple open source implementation methods available

3. FDO Certified Products

The FIDO Alliance is an open industry association with a mission to reduce the world’s reliance on passwords. Consisting of the biggest global tech organizations and experts in cybersecurity, identity, and authentication, the alliance has a proven track record in transforming consumer authentication with passkeys. 

In two years since the initial launch, passkeys have been enabled on 20% of the world’s top 100 websites and over 15 billion accounts.

The FIDO Alliance has launched this complementary independent certification program that brings additional value to end users and solution providers alike. It assures that FDO certified solutions meet all the specifications, that devices comply with all security requirements, and have been tested for interoperability with other products. 

FDO Certified products bring considerable additional value to end users by offering:

• Guaranteed interoperability and security assurance
• Faster deployments and time to value 
• Greater efficiencies
• Assures security and interoperability, eliminating the need for time-consuming vendor bake-offs with uncertified or homebrewed onboarding solutions

Now FIDO is applying this expertise to improve device authentication in industrial IoT and edge computing environments. FDO ensures devices and edge nodes can quickly and securely authenticate and connect online during initial deployment.

4. On the Edge: The Urgency to Secure and Simplify Device Security

Operational bottlenecks are a significant challenge in both industrial and commercial sectors. Manual, unsecured device onboarding not only consumes time and resources but also increases the risk of breaches. According to Microsoft’s recent white paper, How to Scale Intelligent Factory Initiatives Through an Adaptive Cloud Approach, today’s manufacturing leaders are burdened with “technical sprawl and inefficiencies that create major obstacles to being able to scale solutions – including AI – to multiple production lines and geographically dispersed factories.”

This technical sprawl has led to data silos and management complexities, hindering global visibility and scalability. Ultimately, this prohibits the promise of connected devices from being realized in any industry. 

The average cost of a data breach in 2023 was $4.88 million (USD).

Edge implementations involve a lot of risk. Often these edge nodes are used in remote, precarious, and high-risk environments. Industries like healthcare, energy, and manufacturing face unique challenges and regulations, such as vulnerable patient monitoring systems, hazardous environments, and risks to complex supply chains. To make matters more complex, new threats are constantly emerging, such as the rise of quantum computing and zero-day exploits.

Some companies may feel that they can develop their own proprietary onboarding solution, but given today’s economic pressures and the growing threat landscape, businesses often simply cannot afford to develop and maintain proprietary solutions or risk a preventable breach.

FDO and AI: A Symbiotic Future

Edge and IoT are also the “eyes and ears” of AI, collecting and transmitting data for analysis. There is a huge risk in overlooking IoT security and threats such as data poisoning, which can cripple AI models reliant on real-time data. Securing the foundation of edge and IoT is essential to unlock the full potential of AI.

AI systems depend on clean, reliable data streams. A compromised IoT device does not just threaten the device itself – it can corrupt AI models, disrupt decision-making, and open doors to adversarial attacks. FDO’s zero trust onboarding ensures these vulnerabilities are eliminated from the start.

5. What Problems Does FDO Solve?

• Human error: 34% of data breaches involve human error – FDO minimizes this with automation and a zero-touch approach. 
• Time-intensive and inefficient deployments: FDO can deploy 10 times faster than manual methods. It dramatically reduces the time and budget needed to hire skilled technicians in high-risk environments, like oil rigs and factories. In some applications, such as retail, existing on-site staff can install FDO as it is plug and play technology.
• Market speed to innovation: Open standards help advance innovation and level the competitive playing field. By standardizing processes, providers can focus on truly adding value to their solutions. For customers, they can benefit from better solutions that are faster to deploy and more secure.

Device Security Risks  – The Supply Chain Lifecycle

Stage 1: Manufacturing
Risk: Supply chain compromises (i.e., tampered devices)
FDO: Establishes cryptographic ownership during manufacturing, ensuring device integrity

Stage 2: Shipment and storage
Risk: Device ownership asset mismanagement
FDO: Tracks and secures ownership transfers, maintaining a secure chain of custody

Stage 3: Onboarding and deployment
Risk: Exposures from default passwords and manual installation errors
FDO: Eliminates passwords and human errors with plug and play device onboarding and zero-touch automation

Stage 4: Operations 
Risk: Insecure data transmission, spoofing and infiltration
FDO: Encrypts data exchanges and ensures ongoing device authentication 

6. Benefits of FDO for Enterprises and Providers

Standards are vital to unlocking the full potential of any major global technology innovation. Global industry standard initiatives help remove huge amounts of waste, advance technology far more quickly, and increase market competitiveness. Standards also provide long-term security. As threats evolve, experts in the field continue to evolve the standards to keep up.

The FDO standards have been developed and backed by the best companies in the industry, including Microsoft, Dell, and Intel. Experts from these organizations proactively work together to develop use cases and best practices for seamless and secure IoT device authentication, provisioning, and also support the adoption and implementation of the FDO standard.

The FDO standard is also continuously improved within the FIDO Alliance. In the last two years, several Application Notes have been released to deal with implementation and other areas related to FDO 1.1. The newest version of the standard, FDO 1.2, is currently in development with new enterprise-ready features and is expected to be released in 2025.

Benefits for enterprises:

• Protect devices and supply chains with zero trust security.
• Integration is flexible with existing systems. 
• Reduce the need to develop and manage your own testing requirements and protocols – buy with confidence with FDO certified products. 
• Reduce time to market/deployment and increase value.

Benefits for providers:

• Leverage FDO certification as a competitive advantage. Ensure compatibility and earn customer trust with external independent validation. This becomes increasingly valuable as market adoption rises and FDO is increasingly referenced in Requests for Proposals (RFPs).

• Realize hardware efficiencies, simplify production, and reduce waste. As with FDO, operating systems can be deployed on-site and do not need to be hard programmed in. This capability is now part of an active workstream within the FDO Working Group called “Bare Metal Onboarding”.
• Fast-track solution development with confidence.
• Free engineer time to focus on higher value projects rather than waste time with manual or proprietary onboarding solutions. Offer a faster, more efficient solution to customers.
  

“Deploying FDO has marked a pivotal shift for ASRock Industrial, establishing a new benchmark in secure, scalable onboarding for industrial edge IoT solutions. FDO’s advanced security framework enables us to deliver unparalleled reliability and adaptability, empowering our clients to scale confidently in increasingly complex environments. This deployment cements ASRock Industrial’s leadership in industrial computing security and sets the stage for us to shape the future of Industry 4.0 with solutions that are both resilient and future-ready” – Kenny Chang, Vice President, ASRock Industries

7. How to Adopt FDO Today

FDO offers a simple, secure, and scalable solution for enterprises and providers to accelerate edge computing and IoT device deployment at scale. With proven benefits like streamlined procurement, reduced costs, and enhanced security, FDO offers a clear path to efficiency and innovation – even in complex, high-risk, distributed environments. 

Now is a perfect time to join industry leaders like Microsoft, Dell, Red Hat, and Intel in backing FDO and paving the way for wider adoption.

There are several ways to get involved with FDO with the FIDO Alliance:

• Explore: Discover FIDO^Ⓡ Certified FDO products for seamless device onboarding.
• Get certified: Learn how to get FDO certified and demonstrate your products meet global security and interoperability standards.
• Join the FIDO Alliance: Become a FIDO Alliance member and help shape the future of the FDO standard.

The technology, resources, and support are in place for FDO to transform the way leaders and teams deploy IoT devices at scale while managing edge security risks in today’s fast-paced economy.

References

• Industrial IoT Market Forecast to 2029 Research and Markets Report. https://www.researchandmarkets.com/report/industrial-iot
• Palo Alto Unit 42 IoT Report. https://start.paloaltonetworks.com/unit-42-iot-threat-report
• Verizon 2024 Mobile Security Index. https://www.verizon.com/business/resources/reports/mobile-security-index/
• Microsoft: How to Scale Intelligent Factory Initiatives Through an Adaptive Cloud Approach. https://clouddamcdnprodep.azureedge.net/gdc/gdcQll0SB/original
• IBM 2024 Cost of a Data Breach Report. https://www.ibm.com/reports/data-breach
• Verizon 2024 Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/

Marc Findon, Nok Nok Labs
Jonathan Grossar, Mastercard
Frank-Michael Kamm, Giesecke+Devrient
Henna Kapur, Visa
Sue Koomen, American Express
Gregoire Leleux, Worldline
Alain Martin, Thales
Stian Svedenborg, BankID BankAxept

1. Introduction

Global e-commerce is booming and is expected to reach more than $6T by the end of 2024¹. Having the ability  to sell products online has provided great opportunities for merchants to sell goods and services beyond their  local market; however, it comes with increased fraud. In fact, it is estimated that in 2023, global ecommerce  fraud was roughly to reach $48B¹, with the US accounting for 42% of that and the EU with about 26%. 

1.1 Current Challenges in Remote Commerce 

There are many types of ecommerce fraud, but the most prevalent type is transaction fraud. Transaction fraud  occurs when a transaction is made on a merchant site with a stolen card and/or stolen credentials. Stolen  credentials are readily available on the dark web to those who know how to access and use them. 

To address those concerns, measures have been introduced to increase the overall security of remote  commerce transactions, including tokenization of payment credentials and cardholder authentication. In some  countries, regulations are mandating the adoption of either or both measures, such as in India or in Europe  (second Payment Services Directive PSD2). These regulations are meant to ensure secure remote transactions;  however, they add complexity to the checkout flow, as they may require a switch between the merchant and  another interface, such as a bank’s interface. 

Unfortunately, additional authentication may add friction which can result in cart abandonment. The main  reasons for cart abandonment include a distrust in the merchant website or a complicated check out flow.  Customers prefer a simple payment process that doesn’t add friction such as that caused by payment failure, the need to respond to a one-time password (OTP) on a separate device, or the need to login into a banking  application. 

1.2 How FIDO can help 

The use of biometric authentication enabled through the Fast Identity Online (FIDO) Alliance standards is an  opportunity to deliver a better user experience during the authentication process and hence reduce the risk of  transaction abandonment. 

FIDO has established standards that enable phishing-resistant authentication mechanisms and can be accessed  from native applications and from the most popular browsers – thereby enabling a secure and consistent  experience across the channels used by consumers. FIDO refers to ‘passkeys’ as the FIDO credentials based on  FIDO standards, used by consumers for passwordless authentication. 

The World Wide Web Consortium (W3C) has developed Secure Payment Confirmation (SPC). SPC is a web API  designed to enhance the consumer experience when authenticating to a payment transaction using FIDO  authentication, and to simplify compliance with local regulations (such as PSD2 and dynamic linking in Europe). 

1.3 Scope 

This whitepaper intends to: 

• Define Secure Payment Confirmation (SPC) and the benefits that it brings when FIDO is used to authenticate payment transactions 

¹ https://www.forbes.com/advisor/business/ecommerce statistics/#:~:text=The%20global%20e%2Dcommerce%20market,show%20companies%20are%20taking%20advantage.

• List the current SPC payment use cases that can deliver those benefits and illustrate consumer  journeys 
• Provide a status on SPC support and the list of enhancements that could be added to the web standard to further improve security and user experience

2. Secure Payment Confirmation (SPC) Benefits

Secure Payment Confirmation (SPC) is an extension to the WebAuthn standard, and aims to deliver the  following benefits: 

• A browser native user experience that is consistent across all merchants and banks
• Cryptographic evidence of authentication (FIDO assertion) including transaction details signed by a  FIDO authenticator 
• Cross origin authentication – For example, even if passkeys are created with the bank as the Relying  Party, merchants can invoke cardholder authentication with passkeys within their environment,  using input parameters received from the bank, so there is no need to redirect the consumer to the  bank to authenticate with passkeys.  

2.1 Browser Native User Experience  

SPC introduces a standardized payment context screen showing details such as a merchant identifier, the card  logo, the last 4 digits of the card number, and the transaction amount. The consumer is invited to explicitly  agree to the transaction information displayed and then authenticate. Therefore, SPC can be experienced as a  mechanism to collect consent from the consumer about the transaction details. 

As in standard WebAuthn, the payment context screen is controlled by the user’s browser which renders  common JavaScript presentation attacks ineffective. The screen provides increased security, as it ensures that  malicious web content cannot alter or obscure the presentation of the transaction details to the user – the  browser display always renders on-top of the web content from the triggering website. Figure 1 depicts an  example of the SPC experience in chrome.

Figure 1 Example of SPC experience in chrome 

2.2 Generation of FIDO Assertion  

With SPC, the transaction-related information displayed to the consumer, such as the merchant identifier and  transaction amount, is sent securely to the FIDO authenticator and is signed by the same authenticator  (transaction data signing). 

The FIDO assertion generated by the authenticator reinforces compliance with some regulations as it does with  the dynamic linking requirement under PSD2 in Europe, because the merchant identifier and transaction  amount will be signed by the authenticator itself. When combined with the browser native user experience  described in section 2.1, the relying party can be confident that the user was shown and agreed to the  transaction details. 

2.3 Cross Origin Authentication  

When using FIDO without SPC, a consumer that creates a passkey with a relying party will always need to be in  the relying party’s domain to authenticate with that passkey. In the remote commerce payment use case, this  means that the consumer typically needs to leave the merchant domain and be redirected to the bank’s domain  for authentication. 

With SPC, any entity authorized by the relying party can initiate user authentication with the passkey that was  created for that relying party. For example, a merchant may be authorized by a bank to authenticate the  cardholder with the bank’s passkey. 

Note that the mechanism for the relying party to authorize an entity to invoke SPC may vary. For example, a  bank may share FIDO credentials with the merchant during an EMV 3DS interaction or through another  integration with a payment scheme. The merchant will then be able to use SPC to initiate the payment  confirmation and authentication process with a passkey, even if that passkey was created with the bank.  Ultimately, the bank maintains the responsibility to validate the authentication. 

2.4 Interoperability With Other Standards 

SPC can be used in combination with other industry standards such as EMV 3-D Secure and Secure Remote  Commerce (SRC), both of which are EMVCo global and interoperable standards.

3. SPC Use Cases

SPC can be used to streamline payments in a variety of remote commerce checkout scenarios such as guest  checkout or a checkout using a payment instrument stored on file with a merchant.  

In each of those payment scenarios, the relying party may be the issuer of the payment instrument (the bank), or a payment network on behalf of the bank. 

The flows provided in this Chapter are for illustrative purposes and may be subject to compliance with  applicable laws and regulations. 

3.1 SPC With Bank as Relying Party 

The creation of a passkey can be initiated outside of or during the checkout process: 

• Within the banking interface: 
  • For example, when the consumer is within the banking application and registers a passkey  with their bank, in which case the passkey will be associated to one or multiple payment  cards and to the consumer device 
• Within the merchant interface: 
  • For example, when the consumer is authenticated by the bank during an EMV 3DS flow and  is prompted to create a passkey with the bank to speed up future checkouts – in which case  the passkey will be associated to the payment card used for the transaction (and to additional  payment cards depending on the bank’s implementation), as well as to the device used by the  consumer 

Figure 2 depicts the sequence (seven steps) of a passkey creation during a merchant checkout, where the  merchant uses EMV 3DS and the consumer is authenticated by their bank:

Figure 2: Passkey creation during checkout

Once the passkey creation is complete, any merchant that has received the passkey information (which includes  FIDO identifiers and Public Key) from the bank, through a mechanism agreed with the bank or the payment  scheme, will be able to use SPC. Such a mechanism may include EMV 3DS or another integration with the  payment scheme. For example, a merchant who implements EMV 3DS (i.e., version 2.3²) will be able to benefit  from SPC through the following steps: 

1. When the merchant initiates EMV 3DS to authenticate the consumer, the bank decides whether an  active authentication of the cardholder is necessary. If the decision is to perform the active  authentication of the cardholder, the bank can first retrieve one or several passkeys associated with the  card used for the transaction, verify that the consumer is on the same registered device, and then  returns the passkey(s) information to the merchant. 

2. The merchant invokes the SPC web API to a SPC-supporting browser, including a few parameters in the  request, such as the passkey information, card / bank / network logos, the merchant identifier and the  transaction amount. 

3. If the browser can find a match for one of those passkeys on the device used by the consumer, the  browser displays the logos, merchant identifier and the transaction amount to the consumer, and  prompts for authentication with the passkey. 

4. The authentication results are returned to the merchant, who in turn will share those results with the  bank for validation through the EMV 3DS protocol. 

Figure 3 depicts an example of an authentication flow using SPC and EMV 3DS, with a previously registered  passkey:

Figure 3: Authentication sequence using SPC and EMV 3DS

3.2 SPC With Payment Scheme as Relying Party 

In some payment scenarios, payment schemes can be a relying party on-behalf of the banks to remove the need  for banks to deploy a FIDO infrastructure, thereby scaling the adoption of passkeys faster. 

The creation of a passkey can be initiated outside of or during the checkout process:

• Outside of the checkout: for example, when the consumer is within the banking application and the  bank invites the consumer to create a passkey for faster and more secure transactions, the passkey  can be created with the payment scheme as the relying party, and will be associated by the payment  scheme to one or multiple payment cards and to the consumer device; or 
• Before, during or after a checkout: for example, the consumer may be prompted to create a passkey  for faster and more secure transactions at merchants supporting the payment scheme’s payment  method. The passkey will be associated by the payment scheme to one or multiple payment cards  and to the consumer device, once the identity of the consumer has been verified by the bank. Figure 4 depicts this sequence. 

Figure 4 Passkey creation during checkout 

Once the passkey creation is complete, any merchant that is using the authentication facilitated by the payment  scheme will be able to benefit from SPC: 

• The merchant checks with the payment scheme that a passkey is available for the card used in the  transaction and retrieves the passkey information from the payment scheme.  
• The merchant invokes the SPC web API with the merchant identifier and transaction amount. 
• If the browser can find a match for one of those passkeys on the device used by the consumer, the  browser displays the merchant identifier and the transaction amount to the consumer, card / bank /  network logos, then prompts for authentication with the passkey. 
• The authentication results are returned to the payment scheme that validates the results. The  payment scheme shares those results with the bank, during an authorization message, for the bank  to review and approve the transaction. Figure 5 shows this sequence.

Figure 5: Authentication sequence using SPC
(left to right)
1. & 2. Checkout at the merchant’s store
3. Passkey is found, transaction details displayed and consent is gathered
4. Device authenticator prompts cardholder for gesture
5. Confirmation of gesture
6. Transaction completed by the merchant

3.3 Summary of SPC Benefits 

The benefits provided by SPC include: 

• Cross-origin authentication – Any merchant authorized by a Relying Party can request the  generation of a FIDO assertion during a transaction even when they are not the relying party. This  provides a better user experience as there is no redirect that is required to the relying party to  perform consumer authentication. 
• Consistent user experience with increased trust – With SPC, the consumer has a consistent user  experience across all merchants and independently of who plays the role of relying party. In each  case, the consumer will see a window displayed by the browser, that includes payment details, the  logos of their card / bank / payment scheme, increasing the trust in using FIDO authentication for  their payments. 
  • Increased security – With SPC, the FIDO assertion will include payment details in the cryptogram  generation such as the merchant identifier and transaction amount, making it difficult to modify any  of those details in the transaction without being detected by the bank or payment scheme. This also  simplifies the compliance with local regulations such as PSD2 regulation related to dynamic linking.

4. Status of SPC Support and Future Enhancement

4.1 Availability 

Secure Payment Confirmation is currently published as a W3C Candidate Recommendation, and there is on going work to include this as an authentication method in EMVCo specifications. 

At the time of writing, the availability of the Secure Payment Confirmation API is limited to:

• Google Chrome and Microsoft Edge browsers 
• MacOS, Windows, and Android operating systems. 

4.2 Future Enhancements 

The W3C Web Payments Working Group continues to work and iterate on Secure Payment Confirmation with  the goal of improving the security and the user experience when consumers authenticate for payments on the  web.  

Features currently under consideration include: 

• Improve user and merchant experiences when there is not a credential available on the current  device (i.e., a fallback user experience) 
• Improve consumer trust with additional logos being displayed to the user, such as bank logo and  card network logo 
• Improve security with support for device binding, with the browser providing access to a  browser/device-bound key 
• Consider additional use cases such as recurring payments or support for roaming and hybrid FIDO  authenticators

An example of enhanced SPC transaction UX that is under review is illustrated in Figure 6. 

Figure 6: SPC transaction UX under review

5. Conclusion

Secure Payment Confirmation (SPC) is a web standard that has been designed to facilitate the use of strong authentication during payment transactions with best-in-class user experience, where the relying party can be a  bank or a payment scheme.  

The main benefits of SPC are to deliver an improved user experience, with the display of transaction details that  the consumer approves with FIDO authentication, and to enable cross-origin authentication when a merchant  authenticates a consumer without the need to redirect to the relying party (the bank or the payment scheme).  

SPC also facilitates the inclusion of the transaction details within the FIDO signature, which can help deliver  higher security and/or simplify the compliance with local regulations.

6. Acknowledgements

The authors acknowledge the following people (in alphabetic order) for their valuable feedback and comments:

• Boban Andjelkovic, BankID BankAxept 
• John Bradley, Yubico 
• Karen Chang, Egis 
• Jeff Lee, Infineon 
• Olivier Maas, Worldline

7. References

^[1] “EMV 3-D Secure,” [Online]. Available: https://www.emvco.com/emv-technologies/3-d-secure/.
^[2] “Secure Payment Confirmation,” [Online]. Available: w3.org/TR/secure-payment-confirmation/. 
^[3] “Secure Remote Commerce,” [Online]. Available: https://www.emvco.com/emv-technologies/secure remote-commerce/.

Husnan Bajwa, Beyond Identity
Josh Cigna, Yubico
Jing Gu, Beyond Identity

Abstract

For enterprises that have implemented a second factor, such as SMS OTP, to mitigate the risk of credential stuffing, this paper will provide guidance on displacing passwords + OTP with passkeys.

Audience

This white paper is intended for ISRM and IT staff tasked with deploying and maintaining multi-factor authentication (MFA) sign-in processes.

1. Introduction

Many enterprises aiming to secure their workforces have deployed SMS and application-based one-time passcodes (OTPs) as an additional factor of authentication to passwords. This whitepaper is aimed at these organizations that are now considering a move to FIDO authentication with passkeys. While this whitepaper focuses on OTPs specifically, the discussion and recommendations can be generalized to any system using phishable second factors including application-based OTP and push notifications.

This whitepaper compares OTPs as an additional authentication factor to passwords and passkeys in terms of security, user experience and ease of deployment. And it provides general guidance about migrating from OTPs to passkeys in order to improve user experience while strengthening the organization’s overall security posture. The guidance within this paper will cover key steps for moving towards passkeys, including planning, use case identification and documentation, pilot considerations, as well as deployment and training guidance. This document targets low-assurance use cases, including internal authentication, external authentication and third party and B2B authentication strategies. Given that organizations typically implement OTPs as the second factor to passwords, for this document all references to OTPs should be assumed as being used as a second factor to passwords.

This document will not cover specific vendor technologies or implementations. For guidance on moderate or high assurance use cases please refer to additional whitepapers published by the FIDO Alliance [1]. As this document is a part of a series of whitepapers, it is recommended that the reader start with the introductory document [2].

2. OTP MFA vs Passkeys: Why Choose Passkeys

Passkeys offer several benefits to security, user experience, and ease of deployment when compared to OTPs.

2.1 Security

OTP-based MFA has been widely adopted to mitigate the risk of credential stuffing and reuse. SMS and authenticator application-based OTP are the most commonly deployed solutions due to their relative low-cost and ease of deployment across a broad set of users and use cases. The relative simplicity of this type of MFA, however, leaves it vulnerable to social engineering and many MFA bypass toolkits, because no bidirectional communication exists between the secrets generator and the validating identity provider (IDP), meaning that an OTP can be intercepted and used by a third party without the knowledge of the end user or IDP.

Additionally, OTP-based MFA requires trust in a device that an organization may not manage nor have visibility into its security posture. This means that organizations are relying on end-users to maintain the security of their own device and their ability to discern phishing attempts. While user training can help to address some of these attacks, historic guidance like checking for secure connections and familiar URLs, still relies on an ever-vigilant user base.

Passkeys provide phishing-resistant, replay-resistant sign-ins that reduce the cognitive load on users and strengthen organizations’ overall security posture. This is achieved because passkeys implement a cryptographic challenge-response protocol scoped to the relying party’s domain. The authenticators then rely on secure behaviors, like biometric proofs or PINS to unlock the credentials on the authenticator while retaining a user-friendly experience. With passkeys, an organization can have a strong first-factor of authentication for passwordless scenarios OR a strong second factor for traditional MFA workflows.

2.2 User Experience

• Passkeys improve the user experience over passwords and OTPs in several ways, including:
• Passkeys work even when there is poor cell coverage whereas SMS OTPs require mobile network connectivity. For example, a user can have wireless access on an airplane but are not permitted to use SMS. In this instance, the SMS OTP cannot be delivered whereas passkeys can be used to authenticate.
• AutoFill UI enables seamless integration within browsers on mobile devices and on desktops.
• Up to four times faster login, no need to wait for code delivery [3]
• Protection against mis-keyed passwords and codes
• Passkeys build on common behaviors for authentication like biometric proofs (face or fingerprint).

2.3 Ease of Deployment

For some micro, small, and medium sized businesses without large, dedicated support staff, end-user deployment of dedicated
authentication hardware tokens can create roadblocks. This includes both OTP hardware tokens or FIDO security Keys. Historically, the ease of deployment of SMS/App based OTPs made them a more favorable option. Procurement, logistics, and configuration are a constant battle fought by operations and IT teams. With updates to the FIDO2 ecosystem to expand the authenticator landscape, this problem is alleviated and allows the use of many different devices as passkey stores.

• All of this comes together to mean that the deployment of passkeys is much easier and less costly compared to SMS OTP for a few reasons:
• There is no SMS integration required. Enterprises will not need to configure or maintain interfaces with mobile carriers or third-party SMS vendors which reduces deployment complexity.
• Enterprises will not have to pay per-transaction fees associated with SMS OTP therefore reducing the total cost of ownership for authentication.
• FIDO authentication uses passkeys. Passkeys are simple to implement across a range of devices and applications.
• SMS OTP rely on carrier-specific APIs or third-party vendor APIs that are not standardized which increases risk of vendor lock-in and lack of interoperability.
• No time-synchronization is needed. Passkeys avoid the time-synchronization requirements of SMS time-bound OTPs (TOTPs). Codes don’t need to be entered within a short time window, and deliverability issues with SMS do not result in login failures.

FIDO authentication with passkeys has been embraced by operating system (OS) and browser providers. This existing OS support from most major vendors means that, in most cases, existing hardware in the enterprise, such as laptops, phones, and tables, can be leveraged to deploy FIDO with passkeys without costly updates and replacements.

In some cases, enterprises use shared, single user devices such as iPads. For these use cases, a passkey stored in the integrated platform authenticator may not be appropriate, since any user of the device has access to the credential. In these cases, organizations should use roaming authenticators (hardware security keys) to generate and store passkeys for use on the shared device. This offers the same ease of use and convenience. Keep in mind, there may be an additional cost to purchase and manage these hardware keys for users. In many cases using hardware keys there may be a need to issue users a second hardware key as a backup to reduce the risk of the user being locked out of their account(s).

3. Deployment Strategy for Migration from OTP to Passkeys

3.1 Identifying the Deployment Model

Planning for a successful passkey deployment requires organizations to consider the needs of the user and the computing devices they use in their role to maximize the utility of passkeys for staff. At a minimum, organizations should consider the following questions when planning a passkey deployment in order to make passkeys accessible to the broadest audience possible:

• What kind of computing devices are used?
• Are your users working on laptops or desktop computers? Mobile devices? Tablets?
• Are the devices single user devices or multi-user (e.g., shared) devices?
• Are the devices provisioned by the company or are users using their own personal devices at work?
• Are there limitations on using USB ports, Bluetooth, or NFC?
• Are there limitations on access to the internet?
• Are your users commonly wearing gloves or masks which limit the use of on-device biometrics?

Based on the answers to the previous questions, organizations can choose one of a few types of authenticators to store user’s passkeys. The flexibility of passkeys means that organizations can mix and match as their security posture and UX needs dictate. Other documents in this series go into more detail on each type of authenticator.

3.2 Deployment Testing

After determining the deployment model and deploying a FIDO server with applications integrated, it is recommended that organizations use pilot groups to test registration, authentication, and recovery processes (see below) with users. Then use the feedback from the pilot to improve processes and address issues raised by the pilot population before embarking on a broad rollout of passkeys.

3.3 User Experience

3.3.1 Registration

Enterprises should implement a reliable registration process to ensure that users are correctly and securely associated with their passkeys, as stated in earlier FIDO whitepapers. The registration experience is critical to consider because it is a user’s first interaction with passkeys. Here are a few elements to consider when it comes to designing the registration experience:

• Identity Proofing – Physically or remotely having the user prove their identity at the start of the registration process is recommended to ensure a strong, abuse resistant process. This may involve SMS OTP for the final time.
• Self-service registration – Users use their existing credentials to bootstrap a new passkey.
• Supervised registration – work with IT/helpdesk for registration. This reduces the risk associated with self-service models that are vulnerable to phishing the original creds.
• Pre-provisioned credentials – high effort, high assurance, but a mechanism is needed to get the credential into the user’s hands.
• Remote users – self-service or pre-provisioned, but a mechanism is needed to provide the PIN to the user to unlock the device the first time.

3.3.2 Sign-In

The first step in designing a FIDO deployment with passkeys is to understand the user base, common work paradigms, and available devices – phones, tablets, laptops, desktops. This step is critical because enabling user-friendly workflows that work with the user’s existing devices is core to developing a successful rollout.

Common users’ environments and equivalent suggestions include:

• Environments with users who primarily operate on mobile devices or tablets – Look into built-in unlock capabilities.
• Mixed device environments or environments that rely on a variety of SaaS tools – Leverage SSO provided by IDP or build flexible login workflows.
• Shared accounts – FIDO RPs can be configured to allow for more than one credential to be associated with a login. Investigate
  cross device hybrid authentication or roaming authenticators.

3.3.3 Recovery

Any authentication process is only as strong as its weakest point, which is why recovery processes have often been abused by attackers to compromise systems. Synced passkeys are durable credentials that can survive device loss and unintentional wiping by restoring from a passkey provider and reduce the need to perform account recovery to establish new credentials for the user. With passkeys, users are expected to lose their credentials less frequently. However, there may be cases where passkeys, or access to the passkeys, is lost, thus requiring account recovery.

For passkey implementations utilizing device-bound passkeys that cannot be backed up or recovered, account recovery should be performed using the backup authentication method, such as using a backup authenticator, to bootstrap enrollment of a new authenticator. In the event that a backup authentication mechanism is not available, organizations must provide alternative pathways to recovery. Organizations should take a risk-based approach to designing and implementing account recovery systems. The specific implementation details will vary widely depending upon organizational requirements. In general, recovery mechanisms should never depend on weaker factors than the credential that the user is trying to recover. In the case where passkeys need to be re-registered, organizations should design mechanisms, either automated or manual, to prevent the use of passkeys no longer registered to that user.

For passkey implementations where synchronized passkeys are used, be sure to document the bootstrapping/enrolment process for new devices as well as building a risk averse process (including identity proofing) for full provider account recovery or replacement. While these catastrophic events should be low, it may still be necessary to have users go through this process. Knowing the proper process ahead of time will insulate organizations against manipulations and stop work events.

For additional considerations around account recovery, please see the FIDO Alliance’s Recommended Account Recovery Practices for FIDO Relying Parties. [5]

3.4 Admin Considerations:

Monitoring of implementation and adoption metrics are critical to ensuring the success of the deployment and ensuring that the security benefits of FIDO authentication with passkeys is realized. Below are recommendations for metrics and processes that are indicative of the success of enterprise passkey migrations.

3.4.1 Monitoring and Visibility into Utilization

Admins are strongly encouraged to use groups or other segmentation structures to allow graceful transition of subsets of users and applications to passkeys. Pilot populations should be carefully constructed and should be composed of a variety of end user types and levels in the organization. Monitoring the usage of items below, both before and after the migration, will provide critical insights into the effectiveness of the program and guide important adjustments.

• Device enrollment:
  • How long did it take the user to enroll their first device?
• Security events:
  • Where was the device at time of onboarding?
  • What, if any, identity proofing approaches were used to ensure that the correct user was onboarded?
  • If manager, IT support, or peer approval workflows were used, who provided attestation?
  • Are there any time of day or device location anomalies that did not previously exist?
• User authentication:
  • Was the user able to successfully authenticate?
  • Are there any observable changes in their daily authentication patterns that would suggest problems or added friction?
  • Does analysis of day-of-week and time-of-day suggest any issues?
• Key management:
  • Are keys being used as expected and only from known devices? Some authenticators support device attestation which provides key provenance and assurance of the identity of the authenticator. If the source of the passkey is an important security control for your implementation, be sure to verify if your chosen authenticator solution supports this kind of attestation.
  • How many keys are associated with an individual’s account? Normal guidance would be to expect the number of passkeys associated with a user’s account to be close to the number of devices that a user leverages. For example, if your users use Android phones & Windows laptops then you should expect to see two to three passkeys associated with a users’ account, one stored on each platform authenticator, and possibly one backup from a security key. In this scenario if an account had five to six passkeys registered, then it would be time to investigate and potentially remove excessive keys. Every organization’s definition of excessive may vary, and should be defined based on observations from their environment. Additionally, depending on your deployment, consider the number of applications that you have enabled for passkey authentication. If you deployed passkeys as credentials for an SSO integration, your users may only have one passkey per device. If you deployed passkeys on an application-specific basis, there may be one passkey per device per application. Organizations are recommended to monitor the number of keys associated with each user and use this data as context for informing passkey management.
• Whose keys are associated with administrative/service/break-glass accounts? In the same way that it is best practice to segregate administrative access from normal user access, generating a separate set of passkeys for administrative accounts is also recommended. If they are shared, be sure to include rotation, monitoring, and good cleanup practices.
• How will passkeys be removed?If an employee leaves the company or moves into a different role, their accounts should be disabled, deleted, or access should be evaluated and vetted. In situations where this is not reasonable due to legal requirements, passkeys should be promptly removed to prevent unauthorized account access as part of the disablement process. Similarly, if a user reports a device missing or stolen, any passkeys associated with those devices should also be removed.
• Compatibility assurance:
  • Do any combinations of applications and endpoint platforms show unusual changes or decline in authentication events?
  • Are all invocation methods for passkey authentication continuously functioning, including after upgrades?

Next Steps: Get Started Today

• Enterprise organizations should consider migrating to FIDO authentication where possible.
• Use FIDO standards.
• Think about what your relying parties are supporting as well as your own enterprise security requirements.
• Passkeys are far more secure than traditional OTP mechanisms.
• Passkeys are far more secure than passwords. Look for the passkey icon on websites and applications that support passkeys.

For more information about passkeys, check out the FIDO Alliance passkeys resource page [6]

5. Acknowledgments

The authors acknowledge the following people (in alphabetic order) for their valuable feedback and comments:

• Dean H. Saxe, Amazon Web Services, Co-Chair FIDO Enterprise Deployment Working Group
• John Fontana, Yubico, Co-Chair FIDO Enterprise Deployment Working Group
• FIDO Enterprise Deployment Working Group Members
• Dirk Balfanz, Google
• Jerome Becquart, Axiad
• Vittorio Bertocci, Okta
• Greg Brown, Axiad
• Tim Cappalli, Microsoft
• Matthew Estes, Amazon Web Services
• Rew Islam, Dashlane
• Jeff Kraemer, Axiad
• Karen Larson, Axiad
• Sean Miller, RSA
• Tom Sheffield, Target Corporation
• Johannes Stockmann, Okta
• Shane Weeden, IBM
• Monty Wiseman, Beyond Identity
• Khaled Zaky, Amazon Web Services

6. Glossary of Terms

Please consult the FIDO Technical Glossary for definitions of these terms.

7. References

[1] FIDO Alliance Enterprise Deployment Whitepapers – https://fidoalliance.org/implement-passkeys-overview/
[2] FIDO Alliance Enterprise Deployment Introduction Whitepaper –
https://media.fidoalliance.org/wp-content/uploads/2023/06/June-26-FIDO-EDWG-Spring-2023_Paper-1_Introduction-FINAL.docx.pdf
[3] Forrester Report of Total Economic Impact of YubiKeys –
https://resources.yubico.com/53ZDUYE6/at/6r45gck4rfvbrspjxwrmcsr/Forrester_Report_Total_Economic_Impact_of_Yubico_YubiKeys.pdf?format=pdf
[4] High Assurance Enterprise FIDO Authentication –
https://media.fidoalliance.org/wp-content/uploads/2023/06/FIDO-EDWG-Spring-2023_Paper-5_High-Assurance-Enterprise-FINAL5.docx-1.pdf
[5] Recommended Account Recovery Practices for FIDO Relying Parties –
https://media.fidoalliance.org/wp-content/uploads/2019/02/FIDO_Account_Recovery_Best_Practices-1.pdf
[6] Passkeys (Passkey Authentication) – https://fidoalliance.org/passkeys/

Sean Miller, RSA

Abstract

Enterprises should consider using passkeys, especially if they are currently relying on passwords. By replacing these credentials with passkeys, enterprises will immediately reduce the risk of phishing and eliminate credential reuse, improving authentication service security. Different types of FIDO authenticators may be used to meet users’ needs with a balance between convenience and security. For enterprises that require high levels of identity assurance, internal security policies, or regulatory requirements, additional scrutiny is needed to determine the appropriate type of passkey. It is important to look at both the enterprise as a whole, as well as parts of the organization because high assurance requirements may not apply to the entire enterprise.

For many high assurance scenarios, attested device-bound passkeys may be more desirable. Relying parties with high assurance requirements will need to decide whether to accept all types of authenticators and adapt their authentication flow based on the attestation characteristics or reject registrations from unattested or unacceptable authenticators at the risk of a poor user experience.

Audience

This white paper is intended for IT administrators and enterprise security architects who are considering deploying FIDO authentication across their enterprises and defining life cycle management policies. This paper provides an overview of the different use cases for multi-factor authentication MFA and the FIDO Authenticator choices available to administrators. The intent is to help guide administrators in choosing the right authenticator types for their specific environment. Companies requiring higher levels of security, such as those involved in healthcare, government organizations, or financial institutions that have a hard requirement around the control of the credential, in particular should read this white paper.

It is assumed that the reader has an understanding of FIDO architecture, relying parties, protocols, and has read “FIDO EDWG 2023 Papers – Introduction” that introduces key concepts used in this white paper.

1. Introduction

This document focuses on deploying passkeys for enterprise users in high assurance environments.
Readers can find an introduction to the series of papers here. The introductory whitepaper provides additional descriptions and links to all papers in the series, which cover an array of use cases from low to high assurance. Most enterprises will likely have use cases that span more than one of these papers, and readers are encouraged to review the white papers relevant to their deployment environment.

This white paper examines what it means to be in a high assurance environment and how that may influence how FIDO is used. More specifically, the document addresses the challenges with password-only authentication and proposes passkeys as a stronger, phishing-resistant alternative to using passwords to authenticate users. Additionally, the document provides some adoption considerations for IT and security professionals to consider to ensure compliance with regulatory and security requirements for high assurance authentication scenarios. This white paper examines the use cases of registering a device, using a registered device, and dealing with recovering a lost device.

A key part in deciding if a passkey should be allowed in an environment is based on attestations. Attestations can be provided for credentials as part of the registration process, which relying parties can trust as provenance of the authenticator being used. For high assurance enterprise scenarios, attestations should always be requested. What can be discovered from the attestation associated with the credential, or the absence of any attestation, can help drive policy decisions about whether to accept the registration. Without any attestation, it may be difficult for the relying party to decide if the credential should be allowed. They may reject the registration outright, making for a poor user experience, or the enterprise may choose to employ additional, conditional multi-factor authentication (MFA) along with FIDO authentication to meet the high assurance requirements. With an attestation, the enterprise has assurances about the provenance, manufacture type, certifications, and features of the authenticator and often can rely on these assurances as MFA devices, providing multiple factors like credentials and a PIN to unlock the authenticator.

Synced passkeys work well in many use cases and can still work for some high assurance scenarios, depending on the security or regulatory requirements of the enterprise. Synced passkeys are attractive because of their recoverability and ease of use; however, they also change where credentials reside and who controls them. Given this external control of the credentials, some additional MFA may be desired for synced passkeys where the enterprise has control of the lifecycle management of the MFA method.

The remainder of this white paper will examine enterprises or organizations that have high assurance requirements based on Authenticator Assurance Levels [7] and FIDO Certified Authenticator Levels [8] to operate.

2. Passkey Use Cases

This section will focus on use cases around passkeys in an enterprise or an organization. There are many use cases for enterprises where synced passkeys work very well for ease and convenience in registering devices, using devices, and recovering lost devices since the credentials are available on other devices. It is highly recommended that organizations look at all the benefits of synced passkeys to determine if they are appropriate for the organization. However, the use of synced passkeys, while convenient, may not meet all the security requirements for an enterprise or organization needing high assurance (e.g., AAL3 requirements). AAL3 level has several requirements with the most significant being the use of a hardware-based authenticator. Please refer to NIST for more detail on the different levels of Authenticator Assurance Levels (AAL) [7]. Quite often, AAL3 applies to companies and organizations requiring higher levels of security, such as those involved in healthcare, government, or finance, which have a hard requirement around the control of the credential, specifically, that it is device-bound and never copied.

2.1. Registration
The enterprise or organization should first consider what device(s) they will support in their environment and how they will manage the provisioning of devices. For example, an organization may support an environment where users can bring their own device (e.g., mobile phone), or an organization may have very strict requirements around issued devices that meet specific security requirements such as PIN length, particular user presence features, or even specific hardware models. Finally, organizations need to consider whether they will allow passkeys to reside on multiple devices or just a single device. This has both security and recovery implications that need to be considered.

Organizations may have use cases that require credentials to be device-bound and not copyable at all, in which case synced passkeys are not recommended. Organizations may choose to allow synced passkeys alongside traditional MFA mechanisms, replacing the password with a passkey. However, if the organization has strict requirements for where the credentials can reside, they should look closely at restricting use to device-bound passkeys. These factors will decide how organizations manage registration. All these cases put some added burden on the relying party if types of passkeys need to be restricted.

The relying party may need to check if some requirements are met during the registration process, such as requiring an authenticator that meets or exceeds the FIDO L1+ certification [8]. To assess the authenticator’s compliance with these requirements, the authenticator must provide an attestation that can be validated and examined. If an authenticator does not meet the requirements of L1+ then, the relying party may be forced to reject the registration since nothing can be proven about the provenance of the credential, or the party may consider an implementation with additional MFA to meet the requirements of high assurance.

If an attestation is provided, the relying party can check what type of device it is and if it meets the requirements of the enterprise or organization. The relying party may also want to restrict based on the unique identifier for the authenticator, provided an attestation is available. The unique identifier, known as an Authenticator Attestation Globally Unique Identifier (AAGUID), can be used to look up the details against the FIDO Alliance Metadata Service [2] to understand what type of device is being registered, the certification level, and what features it provides.

Enterprise Attestation is another form of attestation that can be leveraged during registration. This is implemented by some authenticator vendors to add additional information that is unique to the organization. Including this additional information as part of the attestation and narrowing allowed authenticators can be used to further enhance the registration experience.

Similarly, there may be flags about whether the credential is eligible for backup and/or if it has been backed up. These flags cannot be trusted, however, without some attestation that the device is certified. A relying party might decide to allow or deny the registration based on this information as well as other information provided at runtime.

Unfortunately, if the relying party fails the registration of a credential, it forces the user to repeat the registration process again with a different authenticator at step one. Although WebAuthn [5] does not support a preflight mechanism to identify suitable authenticators, relying parties may provide feedback to the user before registration to identify acceptable authenticators. Additional guidance can be provided after failed registration to guide the user’s choice of authenticator. This guidance should be explicit and identify why the authenticator was rejected during registration, which authenticators meet the RP’s requirements, and guidance on managing browser-mandated optionality on communicating attestations.

Relying parties should be able to be more prescriptive in describing requirements of authenticators, allowing for a much better user experience where the end user can only select authenticators that meet the requirements and remove this burden from relying parties. These changes have been proposed to WebAuthn, but they have not yet gathered the support of platform vendors.

Another approach for enterprises might be not to offer any registration use case exposed to the end user. Instead, the enterprise would manage the lifecycle of registering the devices before they are provisioned to users. Similarly, the enterprise might provide some form of supervised registration experience to ensure only authorized authenticators are provisioned and registered. This avoids a number of pitfalls with the user experience mentioned above but puts more lifecycle management burden on the enterprise.

2.2. Sign In
Once a credential has been registered, FIDO credentials can be accessed when needed at authentication. The application(s) will leverage the WebAuthn browser API or platform passkey APIs to perform a FIDO authentication using a registered device. Depending on the type of registered device, there will be multiple factors involved in the authentication, like the entering of a PIN or a user presence challenge. The requirement for these interactions is there is a high level of assurance that the user is who they say they are, and they are not impersonating any user. These requirements need to be enforced during the registration process to ensure devices are allowed to meet the requirements of the enterprise or organization.

The only difference in this use case between synced passkeys and device-bound passkeys is what needs to be authenticated. For device-bound passkeys, the original hardware device used during the registration process is needed. Synced passkeys may be accessed from multiple devices that have access to an account hosted by a passkey provider. Furthermore, some synced passkeys may be shared after registration. Relying parties do not have a mechanism for identifying shared credentials in the current specifications, making it harder to understand and manage the lifecycle of synced passkeys.

There are several enterprise use cases covered in the white paper on “Choosing FIDO Authenticators for Enterprise Use Cases” [4]. Organizations should review these to evaluate how FIDO is leveraged. In particular, an organization planning to rely on FIDO as a first factor (passwordless) or a second factor is a key decision, and the white paper may help organizations understand what truly requires high assurance. For example, there may be a specific project, or a use case may apply to an entire industry driven by government or regulatory requirements. Employees might be allowed to use a synced passkey to access a laptop for example, but then need to use a device-bound passkey to sign in to a specific application restricted to certain employees with a particular clearance level.

2.3. Recovery/Lost Device
Recovery is where a synced passkey shines. If one loses a FIDO device that holds a credential, they can just access the credential from a different device that shares the same platform account. This is convenient, but also means that a passkey is only as secure as the platform account with which it is associated. Enterprises should examine the vendor solutions to understand how secure it is before relying on a service external to the organization. For example, does it provide end-to-end encryption with keys that are not known to the vendor? What additional measures like MFA are used to secure the user’s account? What process is used for account recovery? End users may not be concerned about such matters, but these details may represent a security concern for the organization’s security administrators. The organization’s security requirements need to be examined to see if an external party can store and manage credentials. Furthermore, without requiring attestations, the relying party has no idea who or what is the issuer of a credential—whether it be the platform, a roaming authenticator, a browser plug-in, or something else. As a result, the relying party cannot provide any guidance as to how to recover access to the credentials while providing high assurance. An alternative form of account recovery external to recovering the FIDO credential would be needed to verify the identity of the user and issue a new device and credentials. Finally, the recovery of a passkey from a provider when using synced is not known to the relying party. This represents a potential attack that the enterprise is unaware of.

For device-bound passkeys, the recovery process is more involved and will likely require the involvement of a help desk [6] to issue a new device and possibly revoke access for the old device. This is a security-first approach over convenience that allows an enterprise or organization to control who has devices. It does mean there are additional steps needed for the end user before they can regain access. However, this gives enterprises more control over the lifecycle of the credentials, allowing enterprises to revoke or expire authenticators at any point and be able to guarantee that credentials are not copied or do not exist outside enterprise controls. Some enterprises have solved this by provisioning multiple devices so users can self-recover. Ultimately, there is a business decision to be made regarding recovery models. In some cases, it may be appropriate to block access until the user can receive a new device, taking loss of productivity over a lower security model. The extra burden highlighted in the registration step if an enterprise chooses to manage the registration experience has a direct impact on the recovery/replacement experience.

2.4. Unregistering
At some point an employee will either leave a project or the enterprise overall. The enterprise will want to be sure they have control over credentials and unregister their use so access is no longer possible. This is a bigger consideration when it comes to synced passkeys where the enterprise does not have full control of the lifecycle and management of the credentials. If synced passkeys require additional MFA, the enterprise can control the MFA aspect, expiring the factors involved so authentications no longer are allowed. Device-bound passkey environments have much more control over unregistering devices, either by physically handing in a device and knowing no copies were made, or invalidating/expiring the device so subsequent authentication attempts fail.

The credential lifecycle requires the ability to disable or remove a credential, whether due to a change in status of an employee, such as a leave of absence or separation from the organization, or due to the potential loss or compromise of a credential. Passkeys differ from passwords in these instances since the user may have multiple passkeys registered with the relying party, as opposed to passwords, where the user is expected to only have one password per relying party. In the case of a permanent separation between the user and enterprise, disabling the user account and/or rotating the credential in the service is standard practice to ensure the user is no longer able to authenticate. If the separation is temporary, such as for leave of absence, enterprises may choose to rotate all the user’s credentials or disable the user account until the user returns.

In the case of credential loss, the next steps are dependent upon the deployment scenario. Users with device-bound passkeys who lose their security key should have the credential revoked by the service. Synced passkeys create additional challenges. If the device has been compromised, all credentials resident on the device, including those resident in different passkey providers, should be treated as compromised and revoked by the RP. If the user’s passkey provider account has been compromised, the impacted credential(s) stored with the provider must be revoked. To facilitate revocation in these scenarios, RPs should allow credentials to be named or otherwise identified by the user during registration to facilitate the revocation of specific credentials where possible. Administrative controls must narrow their focus on eliminating credentials from the RP rather than removing the credential private key material from either hardware security keys or a passkey provider’s sync fabric, which may not be possible.

3. Deployment Strategy

In a high assurance environment, the enterprise is likely going to want to manage the distribution and retirement of all authenticators. Device-bound passkeys would be managed by IT and provisioned to individuals. Relying parties would need to check for attestations and only allow the registration of authenticators that are managed by the enterprise or organization. If attestations are absent or do not meet the security requirements, the registration should fail. Processes should be established to manage the pool of authenticators to ensure they are retired when individuals leave or no longer require high-level access. Lastly, the organization or enterprise should define what the process looks like for recovering lost/stolen devices. Depending on how critical the access is to the continuity of the business, multiple hardware devices might be issued for a given individual to ensure they always have access.

4. Conclusion

There is no argument that passkeys are a strong phishing-resistant alternative option to traditional passwords. In an enterprise environment, it is important to look at security and regulatory requirements to determine if synced passkeys work, or if there are stricter constraints such as internal security policies, regulatory, or compliance requirements that require the use of device-bound passkeys. With either approach, enterprises should spend the time to understand how registration, management, and recovery of FIDO credentials will be managed. This includes important use cases like storage of credentials (external), recovery of lost credentials, and unregistering devices when employees leave. Based on the requirements of the enterprise, passkeys may work without any customizations, or enterprises may need to invest to ensure their authentication experience is more managed and filtered to specific devices.

5. Next Steps: Get Started Today

• Use FIDO standards.
• Think about what your relying parties are supporting and consider your enterprise security requirements.
• Passkeys are far more secure than passwords. Look for the passkey icon on websites and applications that support it.

For more information about passkeys, visit the FIDO Alliance site [3].

6. References

[1] FIDO Deploying Passkeys in the Enterprise – Introduction
[2] FIDO Alliance Metadata Service – https://fidoalliance.org/metadata/
[3] Passkeys (Passkey Authentication) –
https://fidoalliance.org/passkeys/#:~:text=Can%20FIDO%20Security%20Keys%20support,discoverable%20credentials%20with%20user%20verification.
[4] FIDO Alliance White Paper: Choosing FIDO Authenticators for Enterprise Use Cases –
https://fidoalliance.org/white-paper-choosing-fido-authenticators-for-enterprise-use-cases/
[5] WebAuthn – https://fidoalliance.org/passkeys/
[6] FIDO account recovery best practices –
https://media.fidoalliance.org/wp-content/uploads/2019/02/FIDO_Account_Recovery_Best_Practices-1.pdf
[7] NIST Authenticator Assurance Levels – https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/
[8] FIDO Certified Authenticator Levels – https://fidoalliance.org/certification/authenticator-certification-levels/

7. Acknowledgements

We would like to thank all FIDO Alliance members who participated in the group discussions or took the time to review this paper and provide input, specifically:

• Matthew Estes, Amazon Web Services
• John Fontana, Yubico
• Rew Islam, Dashlane
• Dean H. Saxe, Amazon Web Services, Co-Chair FIDO Enterprise Deployment Working Group
• Johannes Stockmann, Okta
• Shane Weeden, IBM
• Khaled Zaky, Amazon Web Services
• FIDO Enterprise Deployment Group members

Jerome Becquart, Axiad
Greg Brown, Axiad
Matt Estes, Amazon Web Services

Abstract

The intent of this whitepaper is to provide guidance for organizations as they analyze the abilities and features of both device-bound passkeys and synced passkeys to determine how both credential types can be utilized in a moderate assurance environment. In this paper, the term “moderate assurance” refers to an environment or organization where the legal, regulatory, and security requirements are flexible enough to allow for the use of both types of credentials, using synced passkeys to replace passwords and multi-factor Authentication (MFA) for standard user accounts and device-bound passkeys for user accounts that require the highest level of protection and assurance. The paper is designed to provide a comparison of features and requirements that are supported by device-bound passkeys and synced passkeys, providing a vision of how both types of credentials can be utilized together in an organization that has moderate assurance needs.

Audience

This white paper is one in a series of white papers intended for anyone who is considering deploying FIDO Authentication across their organization, including IT administrators, enterprise security architects, and executives.

Readers can find an introduction to the series of papers here. The introductory white paper provides additional descriptions and links to all papers in the series, covering an array of use cases from low to high assurance. We expect that most enterprises will have use cases that span more than one of these papers and encourage readers to review the white papers that are relevant to their deployment requirements.

The white paper assumes that the reader has a foundational understanding of FIDO2 credentials and the role they play in the
authentication process.

1. Introduction

The initial implementations of FIDO2 credentials were created as device-bound passkeys on either a roaming authenticator or platform authenticator, where the private key of the credential is stored on the device’s authenticator and not allowed to be exported, copied, backed up, or synchronized from the authenticator. This configuration presents a very secure and phishing-resistant solution for authentication that gives relying parties (e.g., web sites or service providers), a very high level of confidence that the user and the device are legitimate users of the system. With this high level of assurance, however, comes some challenges – primarily regarding usability and account recovery. For example, because there is no way to get the private key off the authenticator, if the device the private key is stored on becomes lost or damaged, then access to the resources that key authenticated would be lost. With device-bound passkeys, the solution is to register a second device-bound passkey with every relying party. This creates a more difficult user experience as the user would be required to register both authenticators. This is somewhat reduced for organizations that have consolidated their authentication flow by using an identity provider (IdP) to federate access to their applications, as the relying party is then the IdP itself.

To solve these challenges, in May 2022 Apple, Google, and Microsoft announced their intent to support synced passkeys in their operating systems. Synced passkeys have many of the same characteristics of device-bound passkeys, including the continued use of private and public key pairs. One significant difference, however, is that synced passkeys allow for the private key of the credential to be synchronized to other devices the user owns that exist in the same vendor’s synchronization fabric ecosystem (e.g., iCloud in the Apple ecosystem). Synced passkeys also allow for the creation of a more streamlined and user-friendly experience. All passkeys share several common security properties, are highly phishing resistant, and use unique key pairs to enable strong authentication. However, it is also important to note the difference between synced and device-bound passkeys. For example, synced passkeys introduce new security considerations when analyzed against a device-bound passkey. Conversely, synced passkeys can more easily address account recovery challenges.

As organizations work to evaluate how and where both credential types can be utilized in their environment, they will need to review and understand their organization’s legal, regulatory, and security requirements. When organizations evaluate these requirements, they will many times refer to the combination of these requirements as an authentication assurance level (AAL) and will reference documentation from the National Institute of Standards and Technology (NIST), which provides guidance and recommendation for different assurance levels. While there is currently work underway by NIST to update these assurance levels to better incorporate synced passkeys, the current standards can be helpful when evaluating the implementation of device-bound passkeys and synced passkeys into an organization. More information regarding NIST and AALs can be found here: Authenticator Assurance Levels (nist.gov).

In terms of this white paper, a moderate assurance environment is an organization that has several different authentication use case scenarios that can be met by a combination of AAL1 and/or AAL2 as well as AAL3 levels of assurance. This white paper will dive deeper into the advantages and disadvantages of both device-bound passkeys and synced passkeys to provide a comparison between the two that an organization can use along with their own legal, regulatory, and security requirements to determine how and where they can implement both device-bound passkeys and synced passkeys into their moderate assurance environment so that they can take advantage of the secure, phishing-resistant, and user friendly authentication process that FIDO2 credentials provide in all parts of their organization.

2. FIDO Credential Adoption Considerations

When organizations are evaluating the use of both device-bound passkeys and synced passkeys to support the AAL1, AAL2, and AAL3 requirements of their organization, there are several factors that they should consider. These factors are described below and are intended to provide the organization with the information they need to help analyze both types of credentials and determine where they can be used in their enterprise.

2.1. User Experience
In terms of user experience, the goal of using FIDO credentials to authenticate to a system has always been to provide an easy-to-use and effortless process for the user. The original FIDO implementations provided a streamlined sign-in experience, but still presented some user experience challenges.

Passkeys introduce several enhancements to help provide improve user experience including a new feature called “passkeys Autofill UI” that provides users easier access to the creation of the passkeys and provides an autofill-like experience where users simply pick the credential they want to use when authenticating and no longer type in their username or password. This experience becomes quite easy to use and is very similar to the experience that most users already like and are comfortable with when using solutions such as password managers. Creating a passkey user experience that users like more than their current password experience removes the hurdle to adoption that has been seen with previous passkey implementations.

2.1.1 Backup, Lost Devices, and Recovery
With device-bound passkeys, the private key is stored on and not allowed to leave the authenticator. This creates a very secure solution but does create challenges for users and enterprises regarding backup of the key data, loss of the authenticator, and addition of new authenticators for the user. While there are recommended recovery practices for device-bound passkeys (FIDO_Account_Recovery_Best_Practices-1.pdf (fidoalliance.org)), synced passkeys work to resolve these challenges in a more user friendly manner. With the implementation of a synced passkey solution, the user no longer must register multiple authenticators with a relying party to ensure continued access in the event of a lost authenticator. If an authenticator is lost, a user can recover their passkey by using the recovery process provided by the passkey provider. Additionally, synced passkeys make for a better user experience as a user does not have to register unique credentials per device or maintain multiple device-bound passkeys to minimize the risk of credential loss. Once configured, synced passkeys are available across all devices synced with the passkey provider.

Synced passkeys do, however, create a dependency on the passkey provider and their synchronization fabric. Each provider implements their own synchronization fabric, which includes their own security controls and mechanisms to protect credentials from being misused. Organizations with specific security or compliance requirements should assess which provider(s) or hardware security keys meet their requirements.

Synced passkeys have a lower security posture as they allow the private key on the authenticator to be synchronized to authenticators of other devices the user has in the same vendor’s ecosystem. Organizations should also be aware that there currently are no standards or systems that allow them to keep track of what devices these credentials have been created and stored on, nor mechanisms to identify when the credential has been shared with another person. For use cases in an organization that require a high level of assurance, the fact that this information cannot be determined or obtained means that synced passkeys would not be a good solution for those specific organizational use cases, and they should look to device-bound passkeys to support those use cases.

2.3 Attestation and Enforcement of Credential Type
Attestation is a feature that is designed to enhance the security of the registration process. Attestation mechanisms are defined by the specifications as an optional feature, though most hardware security keys implement it. Attestation is the ability of the authenticator to provide metadata about itself back to the relying party so that the relying party can make an informed decision on whether to allow the authenticator to interact with it. This metadata includes items such as an Authenticator Attestation Globally Unique Identifier (AAGUID), which is a unique ID that represents the vendor and model of the authenticator, the type of encryption that the authenticator uses, and the PIN and biometric capabilities of the authenticator. Some authenticator vendors also support a feature called Enterprise Attestation that allows an organization to add additional uniquely identifying information in an attestation that is included with an authenticator registration request, with the intent to use this additional information to support a controlled deployment within the enterprise where the organization wants to allow the registration of only a specific set of authenticators. Additional information about Enterprise Attestation can be found in this white paper: FIDO-White-Paper-Choosing-FIDO-Authenticators-for-Enterprise-Use-Cases-RD10-2022.03.01.pdf (fidoalliance.org).

At the time of publication, synced passkeys do not implement attestation, which means they are not an appropriate solution for scenarios with highly privileged users that require higher levels of assurance or for organizations that want to implement Enterprise Attestation. To support these highly privileged users, relying parties and organizations have historically looked to, and will need to continue to look to, device-bound passkeys and authenticators from vendors that support and include attestation in their solutions. For organizations that have regulatory, legal, or security requirements that require all users to be treated as high privilege users or have a need to implement Enterprise Attestation, it is recommended that only device-bound passkeys be implemented in their environment. A companion white paper, “High Assurance Enterprise Authentication,” provides details on this scenario and can be found here: https://media.fidoalliance.org/wp-content/uploads/2023/06/FIDO-EDWG-Spring-2023_Paper-5_High-Assurance-EnterpriseFINAL5.docx-1.pdf. Moderate assurance organizations can support all their users by implementing synced passkeys for their standard users to replace passwords and MFA with a more secure solution and then use device-bound passkeys for highly privileged users and their access to resources that require the highest level of assurance.

Implementing both types of passkeys in the same authentication domain does however create an additional challenge that will require organizations to take additional steps to ensure that the correct type of passkey is used when accessing resources: for example, ensuring that a highly privileged user is using a device-bound passkey and not a synced passkey when accessing a resource that requires a high level of assurance. Organizations can leverage the user risk evaluation and policy engine framework of their Identity Provider to solve this challenge. Watermarking the user’s session with an identifier representing the AAL (or other properties of their choosing) to be used in downstream authorization decisions can also be used to solve this challenge. In federated authentication environments, this may be communicated using standards such as the Authentication Method Reference (amr, RFC8176) standardized by OpenID Connect.

3. Conclusion

In moderate assurance environments, both device-bound passkeys and synced passkeys may be implemented together to provide a more secure authentication solution for all use cases of the organization. The more user-friendly synced passkeys can be implemented to replace passwords and MFA for users with standard assurance level requirements, giving them a more secure authentication method that is also easier to use. For highly privileged users in the organization that require the highest level of security, device-bound passkeys can be issued that provide an even higher level of security and an additional level of trust in the authentication process. The white paper provides information comparing synced passkeys, with their better user experience, against device-bound passkeys, with their enhanced security features. Using this information, organizations can evaluate device-bound passkeys and synced passkeys to determine how both can be leveraged in their organization to provide easy-to-use and secure authentication methods that meet and exceed the requirements of their moderate assurance environment.

4. Next Steps

The next step for organizations is to start the evaluation of FIDO2 credentials so that organizations can move away from passwords, which are susceptible to phishing and are well documented to be a significant weakness in their overall security posture. Organizations that have a moderate assurance need and will implement both device-bound passkeys and synced passkeys should determine which credential type will provide the best return on investment, work towards implementing that credential type first, and then follow up by completing the deployment of the other credential type when possible. Implementing either type of FIDO2 credential is a large step forward in moving to a passwordless environment and significantly increasing the overall security posture of the organization.

5. Acknowledgements

We would like to thank all FIDO Alliance members who participated in the group discussions or took the time to review this paper and provide input, specifically:

• Karen Larson, Axiad
• Jeff Kraemer, Axiad
• Dean H. Saxe, Amazon Web Services, Co-Chair FIDO Alliance Enterprise Deployment Working Group
• Tom Sheffield, Target Corporation
• FIDO Enterprise Deployment Working Group Members

Khaled Zaky, Amazon Web Services

Abstract

This white paper describes the need for a more secure and convenient solution for authentication. Passwords have long been the standard for authentication, but the risks inherent to passwords reduce their efficacy as an authentication mechanism. Multi-factor authentication (MFA) solutions have been on market for some time, but their widespread adoption has been slow due to various barriers. Passkeys are an authentication solution that reduces the adoption barriers of traditional MFA mechanisms, while offering improved security, ease of use, and scalability over passwords and classic MFA solutions. Passkeys utilize on-device biometrics or PINs for authentication and provide a seamless user experience. This white paper outlines the benefits of passkeys, the user experience, and adoption considerations for enterprises.

1. Introduction

Passwords have long been the standard for authentication, but their inherent security flaws make them exploitable. Many passwords can be easily guessed or obtained through data breaches, and the reuse of passwords across multiple accounts only exacerbates the problem. This vulnerability makes them susceptible to credential stuffing attacks, which use leaked or commonly used passwords to gain unauthorized access to user accounts. In fact, passwords are the root cause of over 80% of data breaches, with up to 51% of passwords being reused. Despite these security concerns, many consumers and organizations continue to rely solely on passwords for authentication. According to a recent research by the FIDO Alliance, 59% of consumers use only a password for their work computer or account.

Traditional multi-factor (MFA) mechanisms, such as one time passwords (OTPs) delivered via SMS, email, or an authenticator app, are used by organizations to reduce the risk associated with a single-factor, password-based authentication system. Organizations using single-factor authentication with passwords, or those that have deployed OTPs to reduce phishing and credential stuffing, can implement passkeys as a password replacement to provide an improved user experience, less authentication friction, and improved security properties using devices that users already use—laptops, desktops, and mobile devices. For an introduction to passkeys and the terminology, please see the FIDO Alliance’s passkeys resource page. In the following pages, we will focus on migrating existing password-only use cases to passkeys. For additional use cases, please see here.

2. Why Are Passkeys Better than Passwords?

Passkeys are a superior alternative to passwords for authentication purposes and offer improved usability over traditional MFA methods. They offer several benefits such as better user experience, reduced cost of lost credentials, phishing resistance, and protection against credential compromise.

Synced passkeys offer a consistent authentication experience for users across multiple devices. This is made possible by leveraging the operating system platform (or a third party synchronization fabric such as that from password managers) to synchronize cryptographic keys for FIDO credentials. This allows for quick and easy sign-in using biometrics or a device PIN. Synced passkeys also improve scalability and credential recovery. With synced passkeys users do not have to enroll a new FIDO credential on every device they own, ensuring that they always have access to their passkeys, regardless of whether they replace their device.

On the other hand, device-bound passkeys such as security keys can be used on multiple devices allowing for cross-device portability. Unlike synced passkeys that are accessible on any synchronized device, device-bound passkeys are tied to the specific physical security key.

In terms of security, passkeys are built on the FIDO authentication standards, providing strong resistance against the threats of phishing and credential stuffing. Additionally, passkeys rely on existing on-device security capabilities, making it easier for small and medium enterprises to adopt stronger authentication methods.

Finally, passkeys offer a comprehensive solution for secure and efficient authentication that is better than passwords and traditional MFA authentication methods. With a seamless user experience, improved scalability, and enhanced security, passkeys are a valuable solution for organizations of all sizes.

3. Passkeys User Experience

3.1 Create a passkey visual UX/UI

Note: This section will provide an overview of the passkey registration and sign-in process using examples. Note The FIDO Alliance User Experience Working Group has developed UX guidelines for passkeys that are available here.

1. In the passkey registration flow, users are first prompted to provide an email or username along with their password to authenticate.

2. Then, users simply follow the prompts to provide their on-device biometric or PIN authentication.

3.2 Sign in with a passkey visual UX/UI

1. To sign in with a passkey, a user just selects the email or username.
2. Available passkeys will be shown in the passkey autofill user interface.

4. Adoption Considerations for Enterprises

Within businesses large and small, there are systems and services dependent upon single factor authentication using passwords. We collectively refer to these use cases as “low assurance use cases.” For low assurance use cases, technology leaders can displace password-only authentication mechanisms with passkeys, dramatically reducing the risk of phishing, and eliminating password reuse and credential stuffing. However, even for low assurance use cases, businesses must consider factors that will influence their choice of technology and implementation, which we outline below.

As a prerequisite to deploying passkeys in the enterprise, leaders must clearly define the set of use cases, users, and the suitability of passkeys for this set.

4.1 Does the relying party (RP) support passkeys?
At the time of writing (Q2 2023), passkeys are a relatively new technology, and as such broad-based support is not guaranteed. As organizations review their systems to identify candidates for migration to passkeys, leaders must start by identifying where passkeys are supported within their ecosystem.

First, for in-house developed/managed applications, how can passkey support be added to the application(s)?If a single-sign on (SSO) mechanism is used to federate multiple applications and services, adding passkey support to the Identity Provider (IdP) can propagate support for passkeys to numerous federated applications, creating a rich ecosystem of services supporting passkeys with engineering efforts focused on the SSO IdP. Conversely, if the environment uses multiple independent applications, each of which uses password-based authentication, organizations will have to prioritize FIDO implementation across their suite of applications to leverage passkeys, or consider migrating to a federated authentication model where the IdP supports passkeys.

Second, third-party developed or hosted applications may or may not support passkeys. If an organization’s service provider does not support passkeys today, inquire when support is expected. Alternatively, if the organization is pursuing a federated identity model, does the service provider support inbound federation?If so, end users can authenticate to the IdP with a passkey before federating to the service providers’ systems.

4.2 Which devices are used to create, manage, and authenticate with passkeys?
After identifying a set of targeted applications or IdPs, identify the users of the applications and the devices they use to access the same. Generally speaking, users on modern operating systems, browsers, and hardware will have broad support for passkeys registered on a platform device, using a credential manager, or with a hardware security key. There are tradeoffs with each mechanism.

Today, passkey providers allow users to register passkeys that are synchronized to all of the devices the user registered with the sync fabric. Passkeys providers may be part of the operating system, browser, or a credential manager which stores and manages passkeys on behalf of the user. If the user loses or replaces their device, the passkeys can be synchronized to a new device, minimizing the impact on users. Typically, this is a good solution for users who use a small number of devices on a regular basis.

Conversely, hardware security keys create device-bound passkeys; they never leave the device. If a user loses their hardware key, they must have a backup or perform account recovery for all credentials stored on the device. Passkeys may be shared with other users if they are not hardware bound.

Hardware security keys require connectivity to the user’s computing device through USB, Bluetooth, or NFC whereas providers are always available on the user’s devices once bootstrapped. Platform credentials may be used to authenticate on nearby devices using the FIDO Cross-Device Authentication. Enterprises should consider whether users who move between a number of shared devices should synchronize passkeys across all the shared devices, use hardware keys, or use the hybrid flow to best support their work style.

When users operate on shared devices using a single account (or profile), passkeys registered to the platform or credential managers are not a good fit. Device bound passkeys on a hardware key are recommended for this scenario. If the user carries a mobile device, consider registering a passkey on the device and using the cross device authentication flow to authenticate users.

Unlike passwords, all of the passkey solutions reviewed above provide strong phishing resistance and eliminate credential theft from the RP and reuse.

4.3 Registration & Recovery
If there are no restrictions on which device(s) or platform(s) the user can register their passkeys, users may self-provision passkeys by bootstrapping a new credential from their existing password using the device(s) of the user’s choice. If using hardware security keys, organizations should provide two per user to allow for a backup credential.

As long as a password remains active on the user account, the user can recover from credential loss following the self-provisioning described above. This step is only required if the user is unable to restore their credentials from their passkey provider.

5. Conclusion

Passkeys offer a significant improvement in security compared to traditional passwords, but it is important to carefully evaluate and understand the adoption considerations before proceeding with an implementation. Organizations should ensure its technical requirements, security, and management preferences align with the passkey solution. Not all use cases are suitable for a passkey-only implementation. For additional deployment patterns, see the other white papers in this series here.

6. Next Steps: Get Started Today

Organizations should upgrade their authentication method and take advantage of the stronger security that passkeys provide. Based on the FIDO authentication standards, passkeys offer a robust solution to the growing threat of phishing attacks. Look for the passkey icon on websites and applications that support it, and take the first step towards a more secure future. Don’t wait. Make the switch to passkeys today!

For more information about passkeys, visit the FIDO Alliance site.

7. Acknowledgements

We would like to thank all FIDO Alliance members who participated in the group discussions or took the time to review this paper and provide input, specifically (in alphabetic order):

• Jerome Becquart, Axiad
• Vittorio Bertocci, Okta
• Greg Brown, Axiad
• Tim Cappalli, Microsoft
• Matthew Estes, Amazon Web Services
• John Fontana, Yubico, Co-Chair FIDO Enterprise Deployment Working Group
• Rew Islam, Dashlane
• Jeff Kraemer, Axiad
• Karen Larson, Axiad
• Sean Miller, RSA
• Dean H. Saxe, Amazon Web Services, Co-Chair FIDO Enterprise Deployment Working Group
• Tom Sheffield, Target Corporation
• Johannes Stockmann, Okta
• Shane Weeden, IBM
• Monty Wiseman, Beyond Identity
• FIDO Enterprise Deployment Working Group Members

Dean H. Saxe, Amazon Web Services, Co-Chair FIDO Enterprise Deployment Working Group

1. Introduction

Last year FIDO Alliance, Apple, Google, and Microsoft announced their intentions to support passkeys— FIDO credentials that may be backed up and made available across devices that are registered to the same passkey provider. Since then, we have seen the support for passkeys and beta implementations by multiple platforms and password managers. Enterprises have expressed interest in passkeys but do not know where to start, what type of passkeys work in their environment, or how passkeys fit in their authentication strategy.

It is important to note that FIDO Alliance has embraced the term “passkey” to describe any passwordless FIDO credential. This includes synced passkeys(consistent with the original announcement and intent) as well as device-bound passkeys – which are FIDO authentication credentials that cannot leave the issued device (e.g., on a FIDO Security Key).

In the following series of papers, the FIDO Enterprise Deployment Working Group (EDWG) will provide guidance to leaders and practitioners on deploying FIDO solutions scaling from SMBs to large enterprises. With recognition that there are a variety of different use cases for FIDO credentials, from synced passkeys to device-bound passkeys, this series will identify key decision points for identifying which solution(s) are a good fit across different enterprise use cases. Enterprises are likely to find there are multiple FIDO-based solutions required to meet their different use cases.

As organizations evaluate how to use passkeys in their environment, they will need to determine the legal, regulatory, and security requirements of their organization and evaluate how both synced passkeys and device-bound passkeys can meet these requirements.

We assume that the reader has a high level understanding of the FIDO protocols, if not, please consult https://passkeys.dev/.

2. Why Choose Passkeys?

Passwords are the root cause of over 80% of data breaches, and up to 51% of passwords are reused, making them subject to credential stuffing attacks. FIDO credentials are inherently more secure than passwords due to their design. These credentials are unique cryptographic key pairs scoped to a specific origin (e.g., https://fidoalliance.org/) to prevent discovery by unrelated services. Unlike passwords, FIDO credentials are highly phishing resistant, and the credential—a private key—cannot be stolen from the relying party (RP) servers.

FIDO credentials can be utilized across a variety of use cases—from low to high assurance, balancing user experience, convenience, and security. Authenticators—ranging from hardware security keys to biometric hardware in phones, tablets, and laptops to password managers—enable enterprises to choose the right tools for their unique environments.

While all FIDO credentials are based on cryptographic key pairs, they do not exhibit the same security characteristics, nor are they all suitable for all use cases. For example, hardware security keys may be FIPS certified devices with device-bound passkeys. RPs can identify these credentials based upon the attestation statements provided at registration. On the other hand, synced passkey implementations synchronize key material through a cloud-based service. The export and management of credentials in a third-party service introduces additional considerations and may not meet every organization’s security requirements. The table on page 4 summarizes the use cases and properties of device-bound and synced passkeys.

As you read the series you may encounter terminology that is unique to the FIDO ecosystem. Please consult the FIDO Technical Glossary for definitions of these terms.

We expect that most enterprises will have use cases that span more than one of these papers. Wherever organizations find themselves on this journey, they can start using FIDO credentials today to reduce credential reuse, phishing, and credential stuffing.

In the first paper, we examine how organizations can deploy passkeys to their users who are using passwords as their only authentication factor. By deploying passkeys, companies can immediately reduce the risk of phishing or credential stuffing for their staff while using corporate or personal devices for authentication.

There are many organizations that have deployed classic second factor authentication solutions such as SMS OTP, TOTP, and HOTP. In many cases, these deployments were tactical responses to reduce the success of phishing attacks. However, none of these mechanisms are immune to phishing. In the second paper of the series, we examine how passkeys can displace less phishing resistant mechanisms while improving the authentication user experience. 

Enterprises in regulated industries may be obligated to utilize higher assurance authentication for some, or all, of their staff. These companies (or other companies with stringent security requirements) may be able to deploy synced passkeys, device-bound passkeys, or both to meet their authentication requirements. The third paper in the series provides guidance on deciding which FIDO-based solution(s) can meet these requirements. 

The final paper describes using device-bound passkeys where functional or regulatory requirements require high assurance
authentication. These scenarios use attestation data to securely validate the hardware devices used to generate and manage passkeys.

This attestation data can be used to ensure compliance with regulatory and security requirements for regulated enterprises and use cases. 

3. Acknowledgements

• Vittorio Bertocci, Okta
• Greg Brown, Axiad
• Jerome Becquart, Axiad
• Tim Cappalli, Microsoft
• Matthew Estes, Amazon Web Services
• John Fontana, Yubico, Co-Chair FIDO Enterprise Deployment Working Group
• Rew Islam, Dashlane
• Sue Koomen, American Express
• Jeff Kraemer, Axiad
• Karen Larson, Axiad
• Sean Miller, RSA
• Tom Sheffield, Target Corporation
• Johannes Stockmann, Okta
• Shane Weeden, IBM
• Monty Wiseman, Beyond Identity
• Khaled Zaky, Amazon Web Services
• FIDO Enterprise Deployment Working Group Members

Editors

Khaled Zaky, Amazon Web Services
Monty Wiseman, Beyond Identity
Sean Miller, RSA Security 
Eric Le Saint, Visa

Abstract

This document intends to provide a comprehensive understanding of attestation’s role in enhancing and advancing the digital security landscape, specifically with respect to authentication. It focuses on the core function of attestation: verifying the origin and integrity of user devices and their authentication materials. FIDO credentials are discussed with a focus on how they offer more secure alternatives than traditional password-based systems and how FIDO attestation enhances authentication security for both Relying Parties (RPs) and end-users. In this document, RPs are those entities that provide websites, applications and online services that require the need for secure user access by confirming the identity of users or other entities. FIDO Alliance’s historical journey is presented with practical analogies for understanding FIDO attestation, its enterprise-specific technical solutions, and privacy aspects involved in the attestation process.

Audience

Targeted for CISOs, security engineers, architects, and identity engineers, this white paper serves as a guide for professionals considering the adoption of FIDO within their enterprise ecosystem. Readers should possess a baseline understanding of FIDO technologies, the meaning of attestation, and have a desire to understand why and how to implement attestation.

1. Introduction

2. Practical Implications and Use-Cases of FIDO Attestation

3. FIDO Attestation Explained

4. Technical Solutions 

This section describes the sequence of events and involved components that make up FIDO attestation.

4.1 Authentication vs. Attestation Keys 

The use of keys and methods for user authentication from FIDO have been introduced in previous documents, but the use of  keys and methods used for attestation may not be familiar.  

• User Authentication: This is the process where the user demonstrates possession of the correct system credentials, utilizing a passkey instead of the traditional password, which is a common application of FIDO technology.
• Attestation: This is the process of the authenticator using a key that is not assigned to a user, but instead  assigned to the authenticator,  to digitally sign a message providing proof of the message’s authenticity. The message involved is called the “attestation statement” and contains information about the authenticator. When the attestation statement is digitally signed by the authenticator’s attestation key, the RP can verify the validity of the attestation statement.

In summary:

• A passkey authenticates the user to an RP
• An attestation key signs an attestation statement to authenticate its origin

As stated in section 3.3 an RP may obtain the authenticator’s make and model by simply checking the authenticator’s AAGUID against the Metadata Service to get this information. Without being digitally signed by a key trusted by the RP, the RP has no proof this information is authentic or associated with the authenticator being queried. 

Note: As discussed in section 3.2, there are several attestation types. One of these, “self-attestation”, uses the User Authentication key to sign the attestation statement. This is not technically a contradiction, but a simplification provided to allow integrity protection, not authenticity, of the attestation statement.

4.2 Trust in the Attestation Key – Trust Chain

Fundamental to attestation is the RP’s trust in the Attestation Key. The Attestation Key must be generated by a trusted source and protected by the authenticator. The trusted source is typically the authenticator’s manufacturer however, in the case of “Attestation CA (AttCA) or Anonymization CA (AnonCA)”, a trusted agent or Certification Authority (CA) is asserting the authenticity of the authenticator. The public part of the Attestation Key is obtained by the RP using a trusted channel, typically the FIDO MDS [1], mentioned previously.

4.3 FIDO Attestation Sequence

Attestation uses a key pair associated with an authenticator, not a user. It is important that all authenticators of the same make and model return the same attestation statement. The format of the attestation is examined later in this section, but it is important to understand that, at a high level, the attestation provides information about the type of authenticator, and it is not specific to a single device.

The following steps (1.a or 1.b then 2.) summarize a FIDO authenticator’s attestation lifecycle:   

1. Authenticator Manufacturing: There are two models for provisioning the Attestation Key: case “a” for roaming authenticators, such as smartphones or USB security keys used across multiple platforms, and case “b” for platform authenticators, which are built-in authentication mechanisms within devices like laptops or smartphones.

Note: This two-model distinction is not architecturally required by the FIDO Specification, but it is the practical implementation known today and provides a simplified explanation for the purpose of this paper. Also, the descriptions are generalizations and manufacturers may deploy different methods than described here – this is only a generalization.

• Roaming Authenticator: The authenticator manufacturer generates an Attestation Keypair (AK) for a specific authenticator model. The manufacturer creates a certificate with the AK’s public key. The AK Certificate is commonly put into the MDS. This allows a RP to retrieve the AK Certificate from a trusted source, MDS, when an AAGUID is provided. The AK Certificate itself is usually signed with the authenticator’s manufacturer’s issuer key. This creates a verifiable cryptographic chain from the authenticator back to its manufacturer.
• Platform Authenticator: The authenticator is not shipped from its manufacturer with an attestation key that can be used for FIDO attestation. Instead, it relies on persistent keys within the platform authenticator. These keys are crucial cryptographic elements that the attestation service uses to generate a FIDO Attestation Key. The attestation service is trusted by the Relying Party to provide assurance in the platform authenticator’s integrity and compliance. The attestation service creates an attestation key that is used to sign an attestation object which asserts the properties of the authenticator. The RP must trust the attestation service in the same way it trusts the roaming authenticator’s manufacturer.

2. User Provisioning with Attestation: During registration (setting up the new account), a new User Credential (a passkey) is created with a unique cryptographic key pair, and the public key is sent to the RP. The RP may optionally require an attestation. Note that the User or the authenticator may ignore the requirement for attestation. If the authenticator possesses an attestation key and it is allowed by the User, the user’s public passkey (along with the attestation statement) will be sent to the RP signed with the attestation private key. This allows the RP to verify the attestation statement which includes the User’s Public passkey for the newly created User. Therefore, providing confidence/proof that the User’s private passkey originated from a specific authenticator with known properties.

4.4 A General Description of the Attestation Lifecycle

The attestation key generally has an associated attestation certificate, which links to a trusted root certificate of the Manufacturer. Once the RP has determined the authenticity of the signed attestation statement, the RP can use the attestation statement along with the MDS to learn more about the authenticator. For example, the RP may want to understand what level of encryption is used and what type of activation secrets is leveraged (e.g., biometrics) with a certain level of accuracy, etc. In order to get details about the authenticator an AAGUID value identifying the authenticator model is sent to the RP along with the newly created public passkey. Since the  AAGUID represents a specific group of authenticator instances such as specific product release with a specific characteristic, specific form factor, or enterprise branding, an RP can use this AAGUID to lookup more information about the authenticator from the MDS.

As shown in the diagram, the attestation object, if provided, will indicate the format of the attestation statement, and then include some data the RP can examine. The attestation object includes a statement that typically contains a signature as well as a certificate or similar data providing provenance information for the attestation public key.  Detail of the attestation object is provided in section 9.1 of the Appendix.

RPs should first verify the signature of the attestation statement and once verified, then examine the attestation statement.  Once the RP has identified the attestation statement’s format and type, the RP then reviews the contents and compares the contents against its policy.

An example attestation response resulting from a  direct request to the authenticator by an RP is provided in 9.2 of the Appendix. The AAGUID provided in the attestation response can be used to obtain additional  details about the authenticator from the FIDO Metadata Service.

4.5 Enterprise Attestation

By default, FIDO allows an authenticator to provide only product information using the AAGUID and high-level information about its type and capabilities, explicitly prohibiting an authenticator from providing uniquely identifying information.  However, Enterprise attestation removes that limitation, as it binds a unique authenticator key pair to a serial number or equivalent unique identifier.

4.5.1 Use Cases

Enterprises actively manage authenticators for various purposes and are essential for securing high-value assets. While employees may select their own authenticators, enterprises may limit authenticators per employee and revoke them upon a departure or loss, as they oversee the entire process from purchase to collection. Additionally, enterprises may prioritize manageability and traceability to safeguard resources. Upon a threat incident, forensic investigations may need to trace activities related to a particular authenticator and correlate the authenticator’s usage activity patterns in order to discover anomalies or the source of threat. Tight management enhances their ability to ensure non-repudiation for transactions. High-risk users may be assigned dedicated authenticators from the enterprise for access to restricted sensitive information or services. These authenticators are assigned specific PINs and are acquired through trusted supply chains. 

Certain enterprise deployments require the use of FIDO authenticators with enterprise attestation in order to identify specific device identities (e.g. device serial numbers). Enterprise Attestation validation must also be supported by the organization’s specific Relying Parties. These practices actively address enterprise-specific needs for improved control over device provisioning and lifecycle management.

4.5.2 Process

4.5.2.1 Provisioning 

Provisioning for enterprise attestation, is modified from the process described in section 4.3 to include both authenticator unique information in the attestation statement and to add any specific RPs permitted to receive this unique information from any set of RPs permanently “burned” into the authenticator by the authenticator’s manufacturer. The authenticator performs enterprise attestation only to those RPs provisioned to the authenticator. Other RPs may still perform any other type of attestation that excludes the unique identifier.

Authenticators that have the enterprise attestation burned into them must not be sold on the open market and may only be supplied directly from the authenticator’s manufacturer to the RP.  An RP wanting an enterprise attestation enabled authenticator will order them directly from the authenticator’s manufacturer by providing a list of RP IDs (RPIDs). These specific RPIDs are the ones permanently burned/written to the authenticator.

4.5.2.2 User Registration with Enterprise Attestation

During a FIDO user registration described in section 4.3, the RP may indicate the need for enterprise attestation. This will uniquely associate the user with the specific authenticator by providing proof of the authenticator’s unique identifier. During user registration the authenticator verifies that the requesting RP (using its RPID) is among those listed in the permanently provisioned list of RPID permitted to perform enterprise attestation. If approved, this unique identifier is added to the attestation object and signed by the Attestation Key. The RP should validate the attestation object and, optionally, the certificate link/chain used to sign the attestation object. The RP can then verify, at user registration time, that the unique identifier was indeed purchased by the enterprise and may include that verification in its records.

The implementation used by an RP to authenticate the uniquely identifying information varies by authenticator. Some authenticators may use vendor facilitated methods where the enterprise provides a list of the RP IDs to the manufacturer and those are imprinted into the authenticators. Another is where some enterprise managed platforms maintain a policy, such as an enterprise managed browser. Rather than imprinting the list of allowed RPs into the authenticator, an enterprise managed platform will make the determination if the enterprise attestation is provided to the RP based on the policy.

5. Privacy Implications and Considerations

6. Adoption and Deployment Considerations

7. Conclusion

8. Acknowledgments

9. Appendix

9.1 Attestation Object

Appendix Figure 1 – Attestation object*
*layout illustrating the included authenticator data (containing attested credential data) and the attestation statement.

9.2 Example Attestation Object

attestationObject: {
  "fmt": "packed",
  "attStmt": {
    "alg": -7,
    "sig": "3045022100da2710ff0b5f5e5d72cda8c1e650f0b696e304942e55138672aa87a5e370a92d02205fd1a48bbda4757aac21252c7064f21130aba083151ab8ae75a26a356b675495",
    "x5c": [
      "3082026f30820213a003020102020404ae6da1300c06082a8648ce3d04030205003077310b3009060355040613025553310b3009060355040813024d413110300e06035504071307426564666f726431193017060355040a1310525341205365637572697479204c4c4331133011060355040b130a4f7065726174696f6e733119301706035504031310525341204649444f20434120526f6f743020170d3232303632333034323132315a180f32303532303632323034323132315a30818c310b3009060355040613025553310b3009060355040813024d413110300e06035504071307426564666f726431193017060355040a1310525341205365637572697479204c4c4331223020060355040b131941757468656e74696361746f72204174746573746174696f6e311f301d06035504031316525341204453313030204649444f20426174636820343059301306072a8648ce3d020106082a8648ce3d0301070342000465f2b3189a6dd2f7df9de784c1c8fd00ae804ac8de7bea042d00563dcd5d7a40948ae59d9dcf8722d8b6025ba98fbb80e6698bbe5003e4db4d80c4a50a3348e4a37330713021060b2b0601040182e51c010104041204107e3f3d3035574442bdae139312178b39301f0603551d23041830168014b851a38b84da69c9fd5b467c1f8e374ac0433419300c0603551d130101ff04023000301d0603551d0e041604142806df6c60b1656a78f97a28e168e5ec8d2937b4300c06082a8648ce3d0403020500034800304502210088122ea59cca8480ed57a0a60a2e203302b4d93713f837be7acc3a2c895c6251022010f67d709ea2dc04ca63aec8d341dc9e562909dcea3f2a4abee2bdfd21dd162d"
    ]
  },

  "authData": {
    "rpIdHash": "f95bc73828ee210f9fd3bbe72d97908013b0a3759e9aea3d0ae318766cd2e1ad",
    "flags": {
      "userPresent": true,
      "reserved1": false,
      "userVerified": true,
      "backupEligibility": false,
      "backupState": false,
      "reserved2": false,
      "attestedCredentialData": true,
      "extensionDataIncluded": false
    },

    "signCount": 4,
    "attestedCredentialData": {
      "aaguid": "7e3f3d30-3557-4442-bdae-139312178b39",
      "credentialId": "c0a3eb62197b77edd0cd1c73bffeb068dcc2595cfdf2e4dc01478bddc9cefcf52282f95bc73828ee210f9fd3bbe72d97908013b0a3759e9aea3d0ae318766cd2e1ad04000000",
      "credentialPublicKey": {
        "kty": "EC",
        "alg": "ECDSA_w_SHA256",
        "crv": "P-256",
        "x": "D3Ki/INLfrmlNogo8d1lK7kBT4Fh3wPyVt/kusDAMKY=",
        "y": "M11KJSPXRiBn1ZtAo1eynxvaUXqipZJYV0AT0gC2czo="
      }
    }
  }
},

Appendix Figure 2 – Example Attestation object

10. References

This paper is written with independence for each section, allowing readers to read specific topics of interest without the need to read the entire paper from the beginning.

This white paper is intended for various stakeholders of relying parties, including non-developers, such as information security executives, product owners, identity and access management practitioners, UI/UX designers, and accessibility practitioners.

This paper is directed to those who have or are considering FIDO-enabled products and solutions but have concerns about the impact of Quantum Computing on their business. This paper will focus, from a high-level approach, on the FIDO Alliance’s acknowledgment of issues related to Quantum Computing and explain how the FIDO Alliance is taking appropriate steps to provide a seamless transition from the current cryptographic algorithms and protocols to new PQC (or quantum-safe) algorithms in a timely manner.

For any questions or comments, please contact feedback@fidoalliance.org.

This white paper is aimed at governmental agencies that are interested in using FIDO for the EUDI Wallet according to the eIDAS2 regulation. The intended readers are project managers, technical experts, and developers.

Enterprises and governments around the globe are turning to modern online authentication solutions featuring FIDO specifications based on public key cryptography. Governments and industries have embraced FIDO as the preferred way to deliver high-assurance MFA to consumers. Notably, the Cybersecurity & Infrastructure Security Agency (CISA), a component of the U.S. Department of Homeland Security (DHS), refers to FIDO security keys as the gold standard of MFA¹. 

Several governments globally have deployed and/or supported FIDO authentication for citizens to securely conduct government transactions, including making tax payments and applying for and accessing government benefits. Governments leveraging FIDO authentication solutions have realized reduced operational costs and increased consumer satisfaction.

This white paper provides guidance for policymakers and department/agency heads seeking to learn about FIDO authentication to support or deploy FIDO for e-government services.

This white paper is intended for information security executives, product owners, identity and access management, attorneys, accessibility practitioners, and others who are considering deploying FIDO Authenticators across their enterprises. This white paper may also help hardware manufacturers identify opportunities to deliver more accessible external authenticators. 

In this paper, we explain how FIDO and WebAuthn standards previously enabled low-cost deployments of authentication mechanisms with very high assurance levels. While this has proved an attractive alternative to traditional smart card authentication, and even opened the door to high-assurance authentication in the consumer space, we haven’t attained large-scale adoption of FIDO-based authentication in the consumer space. We explain how the introduction of multi-device FIDO credentials will enable FIDO technology to supplant passwords for many consumer use cases as they make the FIDO credentials available to users whenever they need them—even if they replace their device.

Secure access to online applications and services has evolved into a framework reliant on devices, public-key cryptography, and biometrics to replace the shared secrets of aging passwords. Since 2013, the FIDO Alliance has developed open and scalable advancements to eliminate phishing and other security attacks. To introduce these improvements and to educate employees throughout corporate management and IT security, the FIDO Alliance has established a series of best practices and how-to white papers that align the Alliance’s goals with the responsibilities and titles of technology professionals. This work is dedicated to eliminating passwords and securing the simple act of logging on within the enterprise. 

This white paper is intended for IT administrators and Enterprise Security Architects who are considering deploying FIDO Authenticators across their enterprise and defining life cycle management policies. In this paper, we provide an overview of the different use cases for multi-factor authentication and the FIDO Authenticator choices administrators have. The intent is to help and guide administrators in choosing the right authenticator types for their specific environment.

This white paper is intended for IT administrators and enterprise security architects who are considering deploying FIDO Authenticators across their enterprises and defining life cycle management policies. In this paper, we provide an overview of the different use cases for multi-factor authentication and the FIDO Authenticator choices administrators have. The intent is to help and guide administrators in choosing the right authenticator types for their specific environment.

This white paper targets IT administrators and Enterprise Security Architects considering deploying FIDO Authenticators across their enterprises and defining lifecycle management policies.

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. Although multiple companies have worked to automate the onboarding process, there wasn’t a widely accepted industry standard. Also, many proprietary solutions that do exist require that the end customer be known at the time of the device manufacture so that the device can be pre-configured. This creates friction and cost in the supply chain. 

The FIDO Alliance stepped up in the summer of 2019 to address this industry challenge. With its broad membership of leading cloud service providers, semiconductor companies and security companies, the Alliance is well positioned to bring together those that create and supply the technologies in the IoT ecosystem. The FIDO Alliance formed its IoT Technical Working Group (IoT TWG) with these stakeholders to define a new standard for automated, secure IoT onboarding. Less than 2 years after the working group formed, the FIDO Alliance is now releasing to the industry the FIDO Device Onboarding (FDO) specification.

Read the paper for a full introduction to FDO.

The authentication of consumers during remote transactions has undeniable benefits in terms of security and approval rates but raises concerns of transactions being abandoned by consumers, as those consumers are not always able to authenticate properly to their banks.

Merchants and wallet providers have an existing relationship with consumers, and there is an opportunity to leverage authentication mechanisms established during that relationship to authenticate to remote transactions as a delegation of the bank’s authentication.

This white paper reviews the different authentication mechanisms that can be used by merchants or wallet providers in the context of Strong Customer Authentication (SCA) Delegation and explains why FIDO is best positioned to meet the requirements from regulatory authorities, banks, merchants, or wallet providers.

Today, secure access to online applications and services has evolved into a model based on devices, public key cryptography and biometrics to replace the anachronistic use of passwords as shared secrets. Since 2013, the FIDO Alliance has developed open and scalable advancements to eliminate phishing and other security attacks. To introduce these improvements and to educate employees throughout corporate management and IT security, FIDO Alliance has developed a series of best practices and how-to white papers that match the Alliance’s goals with the responsibilities and titles of technology professionals. This work is dedicated to eliminating passwords and securing the simple act of logging on within all companies. 

A FIDO server is a necessary component in a FIDO implementation. The FIDO server stores the user’s public key credential and account information. During a FIDO Authentication or registration flow, the server generates a cryptographic challenge in response to a request from the application. The server then verifies the signature provided by the client using the server’s corresponding public key, and logs the user in. 

This white paper is intended for IT professionals and identity architects to guide them in choosing the right FIDO server implementation and deployment architecture when integrating and enabling FIDO-based authentication in enterprise applications. Enterprises must consider several factors in their planning to select and deploy a FIDO server, including build vs. buy assessment (and the risks and benefits associated with each), the desired deployment model, the required server capabilities, and the security and privacy requirements. 

Today, secure access to online applications and services has evolved into a framework reliant on devices, public key cryptography and biometrics to replace the shared secrets of aging passwords. Since 2013, the FIDO Alliance has developed and advanced open and scalable standards to eliminate phishing and other security attacks. To introduce these improvements and to educate employees throughout corporate management and IT security, FIDO Alliance has developed a series of best practices and how-to white papers that match the Alliance’s goals with the responsibilities and titles of technology professionals. This work is dedicated to eliminating passwords and securing the simple act of logging on within all companies. 

Enterprises that accept FIDO credentials are participating in a digital credential exchange. This white paper is intended for CISOs and IT professionals who are considering deploying FIDO across their enterprise. In this paper, we provide a high-level overview of the most common digital exchange – the authentication exchange. We will examine the participants, protocols, and decisions that enterprises must make regarding the creation, management, and usage of FIDO credentials. 

This document focuses on the role of the merchant as the FIDO or WebAuthn relying party and defines the methods for the merchant to leverage EMV 3DS as the conduit to report FIDO Authentication Data to the issuing bank. This data, along with the other transaction details sent using EMV 3DS messaging via the 3DS Authentication Request message, can help ensure minimized friction through risk-based authentication at the time of online payment. Although the resultant assurance level is reduced using this method, as opposed to an issuer-managed credential, and it will need to be viewed within the context of the entire EMV 3DS message, it can provide an approach that can be more easily deployed at scale than issuer-managed FIDO Authentication methods. 

Besides generic session authentication, there is an increasing need to gather explicit user consent for a specific action, i.e. “Transaction Confirmation”. Transaction Confirmation allows a relying party to not only determine if a user is involved in a transaction, but also confirm that the transaction is what the user actually intended – for example, whether they intended to pay $1000 to company X for purchasing product Y, or whether they consent to have specific data shared with another party, such as test results with a doctor.

This paper provides an overview on Transaction Confirmation and the drivers for its support including: regulatory requirements (PSD2, eIDAS); addressing friendly and mobile fraud; and to enable online binding agreements. It explains current approaches for Transaction Confirmation, including through FIDO protocols for native applications, and the value of adding support for it directly in web browsers. It concludes with a call for feedback from relying parties on whether they would like to see Transaction Confirmation should be supported directly in web browsers.

Today, secure access to online applications and services has evolved into a framework reliant on devices, public key cryptography and biometrics to replace the shared secrets of aging passwords. Since 2013, the FIDO Alliance has developed open and scalable advancements to eliminate phishing and other security attacks. To introduce these improvements and to educate employees throughout corporate management and IT security, FIDO Alliance has developed a series of best practices and how-to white papers that match the Alliance’s goals with the responsibilities and titles of technology professionals. This work is dedicated to eliminating passwords and securing the simple act of logging on within all companies. 

This white paper answers the most common questions from CXOs about the value proposition of FIDO Authentication and how the FIDO2 passwordless framework addresses the authentication needs and challenges of companies for the modern workforce. The goal of this document is to guide executive leaders within an organization as to why they should invest in FIDO2 deployment for their employees. 

When a service deploys FIDO Authentication, it must have a secure account recovery process to address lost, damaged or stolen FIDO authenticators. A previous FIDO Alliance white paper, Recommended Account Recovery Practices for FIDO Relying Parties, recommends two strategies:

1. Require the user to register multiple authenticators, to reduce the need for account recovery; 

if #1 is not feasible:

2. Re-run the initial identity proofing or user onboarding process to recover the account.

The first strategy, to require multiple authenticators, plays a very important role for FIDO-enabled consumer-facing accounts where the number of account recovery options can be limited. This includes scenarios where the password has been disabled after FIDO credentials are registered, or where passwords and FIDO credentials are registered for two-step authentication. 

This paper focuses on the first strategy and provides guidance on how to deploy FIDO Authentication with multiple authenticators. It discusses how to register new authenticators bound to an already-registered authenticator, security considerations, coverage/authenticator options, usability, and policy, based on FIDO-enabled browsers and platforms. It provides recommendations for registration methods and policy examples for deploying the solution.

Banks in Europe have deployed customer authentication solutions for several years. These solutions have served their purpose well and enabled customers to safely log in to their bank accounts. In the world of e-commerce, these solutions, when used, have been successful in combatting online payment fraud. 

The Second Payment Services Directive (PSD2) and its associated Regulatory Technical Standards (RTS) dramatically change the payment landscape, considering:

• The mandate for strong, multi-factor authentication, 
• The emergence of Third Party Providers (TPP) accessing accounts via open APIs

The success of PSD2 will ultimately be determined by how well banks can balance user convenience with security obligations, while maximizing reach. As such, they may want to evaluate how well their legacy authentication solutions meet this new need. 

FIDO authentication standards have been proposed as a way for banks to meet all requirements in a PSD2 world — but is the change from a legacy method to FIDO worthwhile? This paper proposes guidance to banks to help them decide. 

The paper describes FIDO Authentication standards and compares it with legacy authentication methods used to access an account or secure an online payment. The methods compared are SMS OTPs, hardware OTP generators, CAP readers, and proprietary smartphone and biometrics-based solutions in terms of PSD2 compliance, security, usability and scalability. Ultimately, the paper answers the question: Why change to FIDO?

eIDAS stands for “electronic identification, authentication and trust services” It builds the legal basis for cross-border interoperability of electronic identification, authentication, and electronic signatures amongst EU Member States.

This introductory white paper describes the relationship between FIDO2 standards and eIDAS compliant schemes that can accommodate modern authentication protocols. The paper includes:

• An introduction to eIDAS
• An overview on how to use FIDO as part of an eID scheme
• An overview on using FIDO2 for authentication to Qualified Trust Service Providers (QTSPs)

This paper is intended for governmental agencies that are interested in using FIDO2 as part of an eIDAS notified eID scheme, and QTSPs who are interested in deploying eIDAS remote signing services that leverage the FIDO2 standard.

For details, including architectural concepts for integration of FIDO2 into the eIDAS interoperability framework, please read the complementary white paper, “Using FIDO with eIDAS Services.”

eIDAS stands for “electronic identification, authentication and trust services” It builds the legal basis for cross-border interoperability of electronic identification, authentication, and electronic signatures amongst EU Member States.

This white paper describes how to use FIDO2 standards with eIDAS compliant schemes and Qualified Trust Service Providers (QTSPs), including architectural concepts for integration of FIDO2 into the eIDAS interoperability framework. The paper includes: 

• An introduction to eIDAS
• Detailed information on how FIDO as part of an eID scheme
• Detailed information on how to use FIDO2 for secured access to QTSPs

This paper is intended for governmental agencies that are interested in using FIDO2 as part of an eIDAS notified eID scheme, and QTSPs who are interested in deploying eIDAS remote signing services that leverage the FIDO2 standard.

For introductory level information on the relationship between FIDO and eIDAS, please read the complementary white paper, “Introduction to FIDO and eIDAS.”

This white paper is aimed at enterprises and government agencies looking to expand their authentication capabilities to include FIDO technology, and have FIDO work in conjunction with other authentication systems such as a Public Key Infrastructure (PKI), Kerberos, and Lightweight Directory Access Protocol (LDAP) that may be in place at the organization.  This document specifically focuses on the use and coexistence of FIDO with a PKI, and answers the following questions:

• How can FIDO protocols deliver new and/or enhanced business benefits to the enterprise?
• Which enterprise applications (and application layer protocols) can use PKI?
• Can FIDO be used to provide similar services as PKI for applications that use or can use public key cryptography?
• Which enterprise security needs and security threats are best addressed using FIDO?
• How can an expanded public-key cryptographic system incorporating PKI and FIDO benefit an enterprise?
• What are the business implications for adding FIDO technology within an enterprise that already operates other authentication systems?

This document covers enterprise and government use cases. Consumer use cases are not in the scope of the whitepaper.

The document analyses articles in the following relevant sections of the RTS:

• [RTS Chapter I] General provisions
• [RTS Chapter II] Security measures for the application of Strong Customer Authentication
• [RTS Chapter IV] Confidentiality and integrity of the Payment Service User’s security credentials

This white paper is aimed at enterprises deploying FIDO for strong authentication. It is intended to provide guidance to architects and developers on how to integrate FIDO authentication and existing federation protocols, namely SAML and OpenID Connect.

It is assumed that the reader has an understanding of FIDO architecture and protocols.

When PSD2 is deployed in Europe, users will be able to take advantage of services offered by Third Party Providers (TPPs) to trigger payments or to view account information. These users will typically start interacting on the TPP’s user interface. However, at the point when a TPP will request from an Account Servicing Payment Service Provider (ASPSP) access to a user’s account(s), the PSD2 Regulatory Technical Standards (RTS) for Strong Customer Authentication (SCA) require that the user be strongly authenticated by the ASPSP and demonstrate that he/she has provided consent for the operation that the TPP is requesting to execute.

The Strong Customer Authentication requirement introduces challenges in the customer experience as there are no longer just two parties involved, the user and its bank, but three: The end user journey starts and ends on the TPP’s user interface.

TPPs will interface with the ASPSPs via open APIs. A number of standardization bodies have released drafts of such Open APIs, for example, the Open Banking Implementation Entity (OBIE) in the UK, STET in France and the Berlin Group for various European countries.

These specifications describe how Strong Customer Authentication should be implemented and several models have been defined, if not (yet) fully specified: the redirection, decoupled and embedded models. At the time of this paper’s release, a potential delegated model is also being discussed. These models vary in the way the user interacts with the TPP and the ASPSP and have a deep impact on both the user experience and the security of the user’s financial accounts.

This paper examines the advantages and drawbacks of the different SCA compliant authentication models and outlines how FIDO compliant solutions deliver the best user experience in any of these models, in a way that meets the needs of TPPs and ASPSPs.

This paper introduces the details of a hardware-backed Keystore authenticators (HKA) implementation approach, based on the first commercial deployment. It takes advantage of secure Android Keystore with key attestation and fingerprint sensors in hardware on standard off-the-shelf Android 8.0 or later mobile devices. Since it is enabled only by Android applications, any RPs and application developers can develop their own secure FIDO UAF 1.1 authenticators.