--- url: 'https://www.corbado.com/blog/nist-passkeys' title: 'NIST Passkeys: Synced Passkeys Recognized as AAL2-Compliant' description: 'Learn why synced passkeys are AAL2- & device-bound passkeys are AAL3-compliant after NIST''s SP 800-63B supplement & what ENISA, NCSC & BSI say about passkeys.' lang: 'en' author: 'Vincent Delitz' date: '2024-04-24T12:43:33.133Z' lastModified: '2026-03-27T07:00:42.006Z' keywords: 'NIST, aal2, aal3' category: 'Passkeys Strategy' --- # NIST Passkeys: Synced Passkeys Recognized as AAL2-Compliant ## Key Facts - Synced passkeys meet **AAL2** under NIST SP 800-63B's supplement, provided the sync infrastructure enforces strong encryption and MFA-protected access to private keys. - **Device-bound passkeys** qualify for AAL3, the highest assurance level, because AAL3 mandates hardware-based authenticators and very high confidence in authenticator binding. - **SP 800-63B's** original 2017 guidelines predated FIDO2 and WebAuthn, implicitly blocking synced passkeys. Revision 4 now permanently incorporates both passkey types into core guidance. - **Federal enterprise deployments** require FISMA Moderate-certified devices, mobile device management software and agency-managed cloud accounts to achieve AAL2-compliant synced passkeys. - **Germany's BSI** pushed passkeys as the new authentication standard in March 2024. ENISA recognized FIDO for eIDAS2 but neither body has issued passkey assurance ratings. ## 1. Introduction As technology moves forward, policies often struggle to keep pace. In authentication, guidance has typically been password-centric, originating in a less complex digital era in the early days of the world wide web in the 1990s. That's why it's great to see **NIST (National Institute of Standards and Technology)**, one of the most influential organizations in standards and technology, **respond to the rising adoption of** (recently [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), [Finom](https://www.corbado.com/blog/finom-passkeys) or [Revolut](https://www.corbado.com/blog/revolut-passkeys)) **and push passkeys them** with a clear statement. The release of **NIST Special Publication (SP) 800-63B's (**[**Digital Identity Guidelines: Authentication and Lifecycle Management**](https://pages.nist.gov/800-63-3/sp800-63b.html)**) supplement** officially confirms synced passkeys as meeting **Authentication Assurance Level 2 (AAL2)** standards. These developments have now been fully incorporated into the recently published Revision 4 of SP 800-63B. Unlike earlier versions that discouraged cloning or exporting authentication keys, Rev 4 explicitly recognizes both device-bound and [syncable passkeys](https://www.corbado.com/blog/device-bound-synced-passkeys), giving them a permanent place within NIST’s core guidance. This new **supplement** is released before the Revision 4, because the great adoption of passkeys outpaces the current documentation cycle. **Synced passkeys** (the most user-friendly way form of passkeys) are transforming how private keys are managed. They carry the promise of stronger security through [phishing](https://www.corbado.com/glossary/phishing)-resistant authentication, simplified recovery processes, and better convenience. However, with this evolution, new challenges emerge, necessitating a thorough understanding of threats and a proper implementation strategy. This blog post will help to understand the meaning of this supplement and helps developers and product managers to leverage passkeys for better user authentication. ## 2. What is the NIST (National Institute of Standards and Technology)? ![NIST Logo Passkeys](https://www.corbado.com/website-assets/nist_logo_66af6ae935.png) **NIST, the National Institute of Standards and Technology**, is a federal agency within the U.S. Department of Commerce. Tasked with promoting innovation and industrial competitiveness, NIST advances measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. At the heart of NIST's mandate is the development of technology, metrics, and standards to drive innovation and economic growth. When it comes to **digital identity and cybersecurity, NIST's guidelines are the gold standard**. They lay down the foundational principles for securing digital identities and provide comprehensive frameworks for authentication and lifecycle management, influencing both public and private sectors. NIST does not create laws, but some of its standards are binding for federal agencies in the USA. That is why their significance is so considerable. By aligning with NIST guidelines, developers and product managers can ensure that their products meet high security and interoperability standards, which are critical for [user trust](https://www.corbado.com/faq/fallback-management-user-trust-passkey-retention) and [regulatory compliance](https://www.corbado.com/blog/cybersecurity-frameworks). ## 3. What has NIST Decided in Regards to Synced and Device-Bound Passkeys? NIST has provided a clear stance on the roles of passkeys in the context of modern authentication requirements. The new supplement shines a spotlight on passkeys, particularly **synced passkeys**, positioning them as meeting **Authentication Assurance Levels AAL2** requirements, and in the case of **device-bound passkeys, AAL3** (more on that below). Synced passkeys are now recognized for their [phishing](https://www.corbado.com/glossary/phishing)-resistant attributes when deployed according to NIST guidelines, marking a significant endorsement of their security capabilities. Read this article to better understand the distinction between synced and [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific). Revision 4 further codifies this distinction. [Device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) are mapped to AAL3, delivering the highest assurance level, while [syncable passkeys](https://www.corbado.com/blog/device-bound-synced-passkeys) are confirmed as suitable for AAL2 provided that the synchronization infrastructure enforces strong access controls and MFA. This shift removes any ambiguity around their compliance status. ## 4. Why is this decision by NIST important? The significance of NIST's decision to endorse passkeys can't be overstated. It can be a real booster for the adoption of passkeys, especially in regulated industries like [banking](https://www.corbado.com/passkeys-for-banking) or [healthcare](https://www.corbado.com/passkeys-for-healthcare). Why does this matter so much? 1. **NIST is one of the Most Trustworthy Authorities**: NIST's guidelines are the benchmark for [digital identity](https://www.corbado.com/blog/digital-identity-guide) protocols worldwide. Its position influences not just the United States but also sets a precedent that international bodies often follow. Thus, the supplementary guidance, like other NIST guidelines, acts as a technical recommendation to adopt passkeys without hesitation. It is not legally binding on its own as NIST does not have the force of law behind them. However, federal agencies and contractors working with the [government](https://www.corbado.com/passkeys-for-public-sector) may be required to comply with these guidelines due to specific regulatory or contractual obligations that incorporate NIST standards. 2. **NIST’s Guidelines Have Global Impact**: The ripple effect of this decision is global. Around the world, organizations have awaited NIST's seal of passkey approval. See also our series on passkeys and [strong customer authentication](https://www.corbado.com/faq/sca-psd2-importance) (part 1, part 2, part 3 & part 4) that an official push for passkeys by authorities is often the last step for many organizations. Now, with this supplement, a crucial obstacle is cleared, paving the way for a surge in the adoption of passkeys. 3. **Passkeys Improve Security, Not Just UX**: The supplement details how synced passkeys align with AAL2 (before they would have been considered non-compliant in the context of [digital identity](https://www.corbado.com/blog/digital-identity-guide) guidelines), undermining that passkeys are not just a UX feature but also a step-up security measure. 4. **Rev 4 Clarifies the Risk Model**: By acknowledging the role of sync fabrics, Rev 4 balances usability with security. While synchronized passkeys unlock seamless user experiences, the guidance emphasizes that private keys must stay encrypted in transit and at rest, and that access to the sync service itself must be gated by AAL2-compliant multi-factor authentication. This ensures the ecosystem gains convenience without lowering assurance. This decision by NIST will help the passkey ecosystem overall. Passkeys are now officially aligning with the high standards of Authentication Assurance Levels. This can be seen as an indirect request for industries to move forward with adopting passkeys. ## 5. Analysis of the Supplement 1 NIST SP 800-63B Let’s have a more in-depth analysis of the new Supplement 1 [NIST SP 800-63B](https://www.corbado.com/faq/nist-sp-800-63b-supplement-passkey-adoption). ### 5.1 What are Authenticator Assurance Levels (AALs)? First of all, we need to understand what [Authenticator](https://www.corbado.com/glossary/authenticator) Assurance Levels are and what their impact is. **Authenticator Assurance Levels (AALs)** are part of NIST's framework for digital identity guidelines, defining the robustness of authentication processes. These levels measure the confidence in a user’s identity by assessing the strength and assurance of the authentication process. See the following **general definition** to learn more about the three levels: | | **AAL1** | **AAL2** | **AAL3** | | ---------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Key Characteristics** | Single-factor | Two-factor or Multi-factor | Multi-factor with hard cryptographic proof of identity | | **Example Use Cases** | | | | | **Sample Authenticators** | | | | | **Man-in-the-Middle resistance** | Required | Required | Required | | **Phishing Reistance** | Not required | Recommended | Required | | **Verifier-compromise resistance** | Not required | Not required | Required | | **Replay resistance** | Not required | Required | Required | | **Authentication intent** | Not required | Recommended | Required | #### 5.1.1 Why are Synced Passkeys AAL2-Compliant? In the following, you’ll find an overview of AAL2 characteristics and how synced passkeys fulfill them. | **Requirement** | **AAL2** | **Synced Passkeys** | | --------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Man-in-the-Middle Resistance | Required | **Achieved**: Synced passkeys ensure that all authentication data is transmitted through secure and encrypted channels. | | Verifier-Impersonation Resistance | Not required | **Achieved**: Synced passkeys generate key pairs that are uniquely tied to the originating domain (the relying party ID), preventing their misuse on any other site and preventing attempts by malicious websites to capture and misuse authentication data. | | Verifier-Compromise Resistance | Not required | **Achieved**: Synced passkey maintain only public keys on the server-side, which cannot be used for authentication on its own (successful logins always require the corresponding private key). Private keys, managed by the synchronization service, are always encrypted using approved encryption methods, and access to them is strictly controlled to prevent unauthorized use. | | Reply Resistance | Required | **Achieved**: Synced passkeys are designed to combat replay attacks by incorporating a unique, one-time-use nonce into each authentication action, ensuring that authentication cannot be reused in subsequent transactions. | | Authentication Intent | Recommended | **Achieved**: Synced passkeys necessitate a deliberate action from the user, such as entering a PIN or using a biometric (e.g. Face ID, Touch ID), to initiate the authentication process. This step serves as a demonstration of the user's active participation and intent to authenticate. | _Note that we left out “Records Retention Policy” and “Privacy Controls”, as they are required by all Authenticator Assurance Levels._ Another part of the supplement addresses further details concerning the configuration of synced passkeys. To fulfill AAL2 standards, synced passkeys must either initiate a local authentication event to access the locally stored private key or must be utilized alongside an additional authentication method (e.g. password or OTP) if a local authentication method is absent. Within the WebAuthn standard, this is denoted by the [User Verification](https://www.corbado.com/blog/webauthn-user-verification) flag found in the [authenticator](https://www.corbado.com/glossary/authenticator) data. #### 5.1.2 Why are Device-Bound Passkeys AAL3-Compliant? After assessing **synced passkeys as AAL2-compliant**, we now take a look at **device-bound passkeys** to understand why they are **AAL3-compliant.** From purely reading the special publication and the supplement, it’s not immediately obvious why synced passkeys are only AAL2-compliant, while [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) are AAL3-compliant (according to an [official statement by FIDO Alliance Executive Director & CEO Andrew Shikiar](https://fidoalliance.org/nist-cites-phishing-resistance-of-synced-passkeys-in-digital-identity-guidelines-update/)). The main reason we have identified that supports this distinction is that AAL3 requires very high confidence (not just high) that the claimant controls [authenticators](https://www.corbado.com/glossary/authenticator) bound to the subscriber's account. Additionally, AAL3 mandates the use of a hardware-based [authenticator](https://www.corbado.com/glossary/authenticator), which could be interpreted as being device-bound. ### 5.2 What are the New Requirements? Before the supplement, the authenticator’s ability to clone a cryptographic authentication key from one device to another was restricted. However, synced passkeys explicitly promote the sharing / cloning of passkeys throughout a [passkey provider](https://www.corbado.com/blog/passkey-providers). #### 5.2.2 General Requirements The following requirements are now applicable for synced passkeys that make them AAL2-compliant. 1. **Proper Cryptography:** All keys shall be created using recognized cryptographic methods. 2. **Private Keys Only Encrypted:** Private keys that are duplicated or transferred from a device shall be kept in a secure, encrypted state. 3. **Authentication Only with Private Keys on the Local Device:** Every authentication process shall carry out actions involving the private key on the local device. The private key is a cryptographic key that was either created on the device or retrieved from the synced cloud account. 4. **Cloud Account Access only for Verified Users:** Private keys synced in cloud accounts shall be safeguarded by access control systems, ensuring that only the verified user can access their own private keys in the cloud account. 5. **Cloud Account Access only via MFA:** Access by users to their private keys within the cloud account shall be safeguarded by MFA that is AAL2-compliant to keep the integrity of the authentication protocols that utilize these synced passkeys. 6. **Document & Communicate to Users:** These general requirements, along with any additional specific requirements for the deployment of synced passkeys, shall be formally documented and communicated. This includes publication on websites and in digital service policies where relevant. Revision 4 of SP 800-63B takes these same requirements and folds them into the main guideline. Earlier versions contained a flat prohibition on “cloning” authentication keys across devices, which implicitly ruled out [syncable passkeys](https://www.corbado.com/blog/device-bound-synced-passkeys). Rev 4 reframes that stance: syncing is permitted, but only when the sync fabric enforces strong encryption, MFA-protected access, and secure local execution of cryptographic operations. In other words, Rev 4 doesn’t lower the bar—it spells out exactly how synced passkeys must meet AAL2 security expectations. #### 5.2.3 Federal Enterprise Requirements Moreover, in federal enterprise scenarios, some additional requirements are in place (e.g. [government](https://www.corbado.com/passkeys-for-public-sector) contractors, [government](https://www.corbado.com/passkeys-for-public-sector) employees or mission partners but not government-to-consumer or public-facing use cases) 1. **Only Certified Devices:** Private keys used by the federal enterprise shall be kept in synced devices that have been certified to at least FISMA Moderate levels of protection or the equivalent (Whether an iPhone or [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) device is compatible with FISMA Moderate level of protection depends on its configuration and management within an organization. For example, implementing a mobile device management (MDM), either an [iOS](https://www.corbado.com/blog/webauthn-errors) or [Android MDM solution](https://scalefusion.com/android-mdm-solution) is a key factor. See below for more details). 2. **Use Mobile Device Management Software:** Devices, such as mobile phones, laptops, and tablets, which create, store, and sync passkeys holding federal enterprise private keys, shall be secured with [mobile device management](https://www.goworkwize.com/blog/mobile-device-management-benefits) software or equivalent device configuration measures. These protections ensure that passkey sync or sharing with unapproved devices is blocked. 3. **Regulated Access to Synced Cloud:** Access to the synced cloud shall be regulated through accounts managed by the agency, such as through a [centralized identity](https://www.corbado.com/blog/digital-identity-guide) and access management solution or platform-managed accounts, to ensure enterprise control over the private key lifecycle. As we have pointed out in previous articles, Apple and Google have gone to significant lengths to do so. 4. **Support Device Attestation:** [Authenticators](https://www.corbado.com/glossary/authenticator) that create private keys should support [attestation](https://www.corbado.com/glossary/attestation) capabilities. These capabilities can be used to confirm the authenticity and origin of the authenticator, such as through enterprise [attestation](https://www.corbado.com/glossary/attestation). ### 5.3 How Should WebAuthn Properties be Set? In the following, we analyze [WebAuthn server options](https://www.corbado.com/blog/webauthn-server-options-overview) and how they should be set if the [relying party](https://www.corbado.com/glossary/relying-party) is a federal agency, so that AAL2 threats can be mitigated appropriately. | **Flag** | **Description** | **Requirements & Recommendations** | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | User Present (UP) | This flag serves to validate user interaction with the authenticator, such as by pressing a button on a hardware security key that’s been connected to a USB port. | Federal agencies shall verify that the User Present flag has been activated, as it affirms the user's active participation, thus supporting the Authentication Intent. | | User Verified (UV) | This indicates that user verification has been performed on the authenticator by employing one of the designated verification methods. | Federal agencies shall acknowledge User Verified as a preferred status. All assertions shall be scrutinized to confirm the presence of the UV flag. This serves to identify whether the authenticator can be recognized as a multi-factor cryptographic tool. Absence of user verification prompts federal agencies to classify the authenticator as a single-factor tool by integrating a specific memorized piece of information to the authentication process. | | Backup Eligibility | Specifies if the authenticator has the capability to be synced with other devices, which implies the possibility of storing the passkey outside the original device. It’s crucial to understand that the ability to sync does not necessarily imply it has occurred. | Federal agencies may utilize this flag if they aim to enact policies limiting the use of synced passkeys. Such policies are crucial to differentiate between device-bound passkeys and synced passkeys. | | Backup State | Confirms whether a passkey has already been synced to another device. | Federl agencies may employ this flag if they wish to place limitations on the use of passkeys that are synced. For services facing the general public, it is advised against altering acceptance based on this flag to prevent negatively impacting user experience. However, within an enterprise setting, this flag can be instrumental in establishing restrictions on the use of synced passkeys for particular applications. | In the following, you find `PublicKeyCredentialOptions` that would indicate an AAL2-compatible passkey-login. ```json { "attestation": "none", "authenticatorSelection": { "authenticatorAttachment": "platform", "residentKey": "preferred", "userVerification": "required" }, "challenge": "AAABaB78HrIemh1jTdJICr_3QG_RMOhp", "excludeCredentials": [], "extensions": {}, "pubKeyCredParams": [ { "alg": -257, "type": "public-key" }, { "alg": -35, "type": "public-key" }, { "alg": -36, "type": "public-key" }, { "alg": -7, "type": "public-key" }, { "alg": -8, "type": "public-key" } ], "rp": { "id": "passkeys.eu", "name": "Passkeys Demo" }, "user": { "displayName": "Vincent", "id": "MTgwNDIxMjQtY3Jvc3Mx", "name": "vincent" } } ``` Here’s an **attestation object** that adheres to AAL2. ```json { "id": "D1-9HMdJF_2RgsT2u68qIljfvVmn-KMrLiGMW7TEuZM", "rawId": "D1-9HMdJF_2RgsT2u68qIljfvVmn-KMrLiGMW7TEuZM", "type": "public-key", "response": { "attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "08987058-cadc-4b81-b6e1-30de50dcbe96", "credentialID": "D1-9HMdJF_2RgsT2u68qIljfvVmn-KMrLiGMW7TEuZM", "credentialPublicKey": "pAEDAzkBACBZAQCdGJ5Pcr-L6GNC06WVYfauf0jQOtXoBDNJcuL8xBWmSAa0ewLDhjPjywQihznM2fL1jqXdZBs9cCFpFmZim_nS8R8wc5YPPc8Lk0SST4sPBekhFPHdwH_sop_KNfCVjVzHuKtsL7U9cI3wDShSPzyjlQ4Sc7lxLMEuceSM6SNJNQvHHRcLZQBSaIslNfHWPJ6JjHVGQvKPEhjdTA-dk6IgRll2_aFms3uOm13RttmloSVo32OZFzc8jYvVfEMGE6KsdDMDH53Id_5Ik460kGrqpLcvvOUHkUlyQVDzfWzzkBYdCH3Xbc7tHmxDxs9zFI5tjQiAPFka5FFCa-YzAEFLIUMBAAE" } }, "clientDataJSON": { "type": "webauthn.create", "challenge": "AAABaB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://passkeys.eu", "crossOrigin": false }, "transports": ["internal"], "publicKeyAlgorithm": -257 }, "authenticatorAttachment": "platform", "clientExtensionResults": {} } ``` ### 5.4 How is Attestation Affected by the NIST Supplement? Agencies might find it beneficial to get more details about the origins and features of the synced passkeys. In WebAuthn, certain [authenticators](https://www.corbado.com/glossary/authenticator) are equipped with [attestation](https://www.corbado.com/glossary/attestation) features that help identify the manufacturer and capabilities of the authenticator in question. For enterprise-level applications, it's advised that agencies should incorporate attestation that is supported by the [passkey providers](https://www.corbado.com/blog/passkey-providers). Ideally, this should be in the form of an enterprise attestation wherein the [Relying Party](https://www.corbado.com/glossary/relying-party) (RP) is able to request information that uniquely identifies the authenticator. However, attestation for widespread public applications should not be used. Insisting on attestation in these cases could potentially rejecting public users' synced passkeys that lack [attestation support](https://www.corbado.com/faq/why-some-platforms-do-not-support-attestation-for-passkeys). This could lead them towards alternative authentication methods that are less secure and more susceptible to [phishing](https://www.corbado.com/glossary/phishing), like SMS OTP. ### 5.5 New Threat Model and Mitigations The following table provides an overview of the new threat model for synced passkeys and how these threats can be mitigated. | **Threats & Challenges** | **Description** | **Synced Passkey Mitigations** | | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Risk of Unauthorized Sharing or Misuse of Private Keys | Synced passkeys allow the sharing of private keys across devices, leading to potential misuse. | | | Compromised Sync Infrastructure | The passkey sync service can be at risk if it's cloud-based and is connected to multiple devices. | | | Unauthorized Cloud-Based Sync Service and Recovery Access | The ability to recover synced keys through cloud-based account recovery poses a potential security issue. | | | Revocation Issues with Synced Passkeys | Central revocation of synced passkey access for multiple sites is difficult because these devices use unique, RP-specific keys, unlike traditional PKI systems. | | ## 6. Why Does the Supplement Come Up Now? When the SP 800-63B guidelines were initially released in 2017, critical technical specifications such as the CTAP and WebAuthn (collectively referred to as [FIDO2](https://www.corbado.com/glossary/fido2) when combined) had not been established, nor was there a mature, well-defined range of implementations. At that time, due to the available types of authenticators, the guidelines limited the ability to sync a key across devices for MFA. However, there has been a significant evolution within the past two years. Presently, most leading platform providers (e.g. Apple, Google) have adopted advanced, synced passkeys, which provide several advantages, such as enhancing resistance to [phishing attacks](https://www.corbado.com/blog/3ds-authentication-failed), the capacity to bind credentials to specific relying parties, removing the necessity to send passwords across networks, streamlining the process of account recovery, and allowing the use of various device-native biometrics and PINs as a second factor with the stored private key. Additionally, they provide a level of convenience that aligns with the growing trend of using multiple devices across different platforms. ## 7. What Does this Mean in Practice? Take, for instance, scenarios where a combination of a password and OTP has been used so far. With the updated guidance from NIST, a [synced passkey](https://www.corbado.com/blog/device-bound-synced-passkeys) is not only adequate for fulfilling AAL2 criteria but is superior. In nearly every implementation scenario, the introduction of synced passkeys marks a considerable advancement in security and user experience over the authentication methods currently in use, which are predominantly vulnerable to [phishing attacks](https://www.corbado.com/blog/3ds-authentication-failed) – be it passwords, OTPs or TOTPs. ## 8. What Do Other Governmental Agencies Do in Regards to asskeys? As we already mentioned above, NIST is the gold standard for providing guidance on new standards in the digital authentication space. Other regulatory bodies and organizations are yet to deliver clear statements but after this move by NIST it’s only a matter of time until others catch up (even the data-privacy- and -security-driven European and German bodies). Nevertheless, let’s have a brief look at the stance of the ENISA (EU), [NCSC](https://www.corbado.com/blog/ncsc-passkeys) (UK) and BSI (Germany) on synced passkeys. ### 8.1 European Union: ENISA (European Union Agency for Cybersecurity) ![ENISA Logo Passkeys](https://www.corbado.com/website-assets/enisa_logo_5cb6e793d1.png) No clear statement on passkeys (be it device-bound or synced) or WebAuthn in general yet by ENISA. However, they cleared [recognized FIDO as an authentication standard for eIDAS2](https://fidoalliance.org/the-eu-organizations-enisa-and-etsi-refer-to-fido-as-authentication-standard-for-eidas2/). ### 8.2 UK: NCSC (National Cyber Security Centre) ![NCSC Logo Passkeys](https://www.corbado.com/website-assets/ncsc_logo_2ff84f58ae.jpg) No clear statement on passkeys (be it device-bound or synced) or WebAuthn in general yet by [NCSC](https://www.corbado.com/blog/ncsc-passkeys). However, the [CTO Ollie Whitehouse predicts a great decline in passwords use within a decade](https://www.verdict.co.uk/news/passwords-will-see-material-decline-within-a-decade-says-uk-security-chief/). He also mentions that “passkeys could be the modern answer to passwords“. ### 8.3 Germany: BSI (Bundesamt für Sicherheit in der Informationstechnik) ![BSI Logo Passkeys](https://www.corbado.com/website-assets/bsi_logo_3410c1fdd8.jpg) In March 2024, the BSI pushed passkeys as the new standard for authentication via their social media channels. Besides, they published two major web pages [explaining passkeys to the general public](https://www.bsi.bund.de/dok/1107470) and also the [cryptography behind it](https://www.bsi.bund.de/dok/1108092). This recent push can be seen as recognition of passkeys but more details are yet to be published. ## 9. Conclusion The endorsement by NIST of synced passkeys as AAL2-compliant represents a major advancement in modern authentication. By recognizing synced passkeys, NIST not only enhances the security framework for digital identities but also paves the way for broader adoption across various sectors. Organizations across the globe, especially those in regulated industries, now have the confidence to integrate passkeys and roll them out to their users, thanks to the clear guidelines and standards set by NIST. Even in higher risk scenarios, the AAL3-compliance of device-bound passkeys provides a viable option now that is backed by NIST. We expect other authorities like ENIS, [NCSC](https://www.corbado.com/blog/ncsc-passkeys) and BSI to also come up soon with their own clear statements regarding the push for passkeys. Other standard and regulatory will follow the lead, subscribe to our [Passkeys Substack](https://passkeys.substack.com) to always be update.