--- url: 'https://www.corbado.com/blog/digital-credentials-passkeys' title: 'Digital Credentials & Passkeys: How they align & differ' description: 'Understand how passkeys and digital credentials complement each other, creating trusted, phishing-resistant digital identities.' lang: 'en' author: 'Vincent Delitz' date: '2025-05-25T21:26:17.698Z' lastModified: '2026-03-27T07:01:32.752Z' keywords: 'digital credentials vs. passkeys' category: 'Digital Credentials' --- # Digital Credentials & Passkeys: How they align & differ ## Quick Summary: Passkeys vs. Digital Credentials - **Passkeys: For Secure Logins.** They prove who you are (authentication) and fight [phishing](https://www.corbado.com/glossary/phishing) effectively. - **Digital Credentials: For Verifiable Proof.** They prove facts about you (attestation, e.g. your ID, skills) and you control what's shared. - **How they align:** Both use strong cryptography for better security and a smoother user experience compared to passwords. - **How they differ:** Passkeys are primarily for accessing services. [Digital Credentials](https://www.corbado.com/blog/digital-credentials-api) are for providing verified information about yourself. | | **Passkeys** | **Digital Credentials** | | :----------- | :------------------------------- | :------------------------------------ | | **Action** | 👤 Logging into sites/apps | 📜 Showing verified info (ID, skills) | | **Phishing** | ✅ Strong (site-specific keys) | ⚠️ Varies (presentation is key) | | **Status** | 👍 Widely adopted & standardized | 💡 Emerging & evolving | ## Key Facts - **Cryptographic attestation** separates digital credentials from passkeys: passkeys prove who you are while credentials prove what is true about you via signed claims. - Passkeys have **95%+ adoption** as of May 2025; digital credentials are below 1% adoption with issuance and presentation protocols still fragmented across standards. - Passkeys resist phishing via **origin-bound keys** tied to specific sites. Digital credential phishing resistance varies based on presentation protocol design and context. - Both technologies share the same **secure hardware layer** (TPM, Secure Enclave, Android StrongBox) letting platforms protect both passkey and credential private keys without separate chips. - Under **eIDAS 2**, the EU Digital Identity Wallet uses a WebAuthn pseudonym key for default login and Verifiable Credentials only for legally required attribute disclosure. ## 1. Introduction The digital world is changing fast. This change is happening not only because traditional passwords and shared secrets keep failing, but also because attacks like [phishing](https://www.corbado.com/glossary/phishing) and AI-driven deepfakes are getting much better and harder to spot. These advanced threats can fool even careful users and make old ways of checking identity unreliable. This clearly shows that digital cryptographic proof is the only truly safe way to confirm who someone is. In this tough situation, we urgently need more secure, user-friendly, and _cryptographically verifiable_ ways to interact online. This need has made two key technologies important: - passkeys, which are already widely used and - [digital credentials](https://www.corbado.com/blog/digital-credentials-api), which are just starting out. These technologies don't rely on claims that humans check - which are increasingly easy to fake - but instead use machine-verifiable cryptographic proof to build real trust. ### 1.1 Why passkeys exploded in 2023-24 Passkeys saw a big jump in use during 2023-2025, thanks to strong support from major companies like Apple, Google and Microsoft, plus the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance). Based on the W3C WebAuthn standard, passkeys are a basic change from weak, shared secrets. Instead of passwords, they use public-key cryptography. Here, a private key, stored safely on the user's device, signs challenges from the [relying party](https://www.corbado.com/glossary/relying-party) (RP). This proves the user has the key without showing the key itself. This cryptography makes passkeys very hard to phish - a big plus, as [phishing attacks](https://www.corbado.com/blog/3ds-authentication-failed) get trickier, sometimes using deepfakes to look more real. Because a passkey is tied to the specific website or app it was made for, users can't accidentally use it on fake sites. This is a common problem with older login methods that are open to such advanced tricks. Passkeys also stop password reuse and the dangers of [credential stuffing](https://www.corbado.com/glossary/credential-stuffing) after data breaches. More than just security, passkeys make logging in much better: it's faster, often just needing a biometric scan (like [Face ID](https://www.corbado.com/faq/is-face-id-passkey) or fingerprint), so users don't have to remember or type long passwords. This mix of better security and ease of use has made them popular quickly. ### 1.2 Digital Credentials At the same time, [digital credentials](https://www.corbado.com/blog/digital-credentials-api), often kept in [digital identity](https://www.corbado.com/blog/digital-identity-guide) [wallets](https://www.corbado.com/blog/digital-wallet-assurance), have become much more talked about. The EU [Digital Identity](https://www.corbado.com/blog/digital-identity-guide) [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) (EUDI [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)) is a good example of this trend. Unlike passkeys, which are mainly for _authentication_ (proving _who_ you are by showing you control a private key), digital credentials (based on standards like W3C Verifiable Credentials (VCs) or ISO [mdocs](https://www.corbado.com/glossary/mdoc)) are about _cryptographically verifiable attestation_ (proving _what_ is true about you with digitally signed claims). Being able to strongly verify these claims is important, especially now that deepfakes can create convincing fakes of traditional evidence. Without cryptographic checks, even experts can find it hard to tell what's real. They let people digitally carry and show verified info - like their name, birth date, driver's license, education, or job certificates - in a way that's cryptographically secure, respects privacy (by letting users share only what's needed), and can be checked by machines. The rise of both these technologies isn't a coincidence. It shows a wider move in the industry away from centralized, password-based identity systems to a more decentralized, user-focused model built on cryptographic trust. Passwords are a known weak spot in online security. Old ways of sharing identity details are often clunky, unsafe, or share too much data, harming [user privacy](https://www.corbado.com/faq/ensure-gdpr-compliance-with-passkeys). Passkeys fix the authentication weakness directly. Digital credentials deal with sharing attributes securely and with user control. Both use similar cryptography and increasingly depend on platform integration and secure hardware, showing a joint effort to make our digital identity systems much better. ### 1.3 Core question: How do the two technologies meet in real-world flows? While passkeys handle the "login" and digital credentials handle "proving attributes," they use similar cryptographic basics and play complementary parts in setting up trusted digital interactions. This is something we really need, as current threats like tricky [phishing](https://www.corbado.com/glossary/phishing) and deepfakes make older, non-cryptographic ways of checking identity unsafe. This brings us to the main question: How do passkeys and digital credentials connect, and how can they work together in everyday user situations? This article explores this synergy. We will examine their differences and similarities, the protocols that enable them, their shared reliance on secure hardware, and how they can interlock in scenarios like user onboarding, login with [step-up authentication](https://www.corbado.com/glossary/step-up-authentication), and device migration. We will also touch upon how emerging browser standards like the [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) aim to bridge these worlds. This piece focuses specifically on the _interplay_ between these technologies, complementing the more in-depth technical exploration of the Digital Credentials API already available. ## 2. Passkeys & Digital Credentials in one Picture To understand how passkeys and digital credentials can work together, it's essential first to grasp their distinct characteristics and the technological layers that underpin them. ### 2.1 Side-by-side table: purpose, crypto primitives, UX The following table provides a high-level comparison: | Feature | Passkeys | Digital Credentials | | :---------------------------------------------- | :------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Primary Purpose** | Authentication (Proving _who_ you are by demonstrating control of a private key) | Attestation/Authorization (Proving _what_ is true about you via signed claims; can also be used for authentication) | | **Core Technology** | FIDO2 Standards | W3C Verifiable Credentials, ISO mdocs (e.g., 18013-5, 18013-7), OpenID4VC (OID4VP/OID4VCI) | | **Data Conveyed** | Cryptographic proof of key possession (Assertion) | Signed Claims/Attributes (e.g., Name, Date of Birth, Address, Qualification, Age over 18) | | **Typical Interaction** | Login / Sign-in / Authentication | Presenting Proof / Sharing Data (e.g., Age verification, KYC check, showing a license, proving a qualification) | | **Key Cryptography** | Asymmetric Key Pair: Private key signs authentication challenges. | Asymmetric Key Pairs: Issuer private key signs VCs; Holder private key signs presentations. | | **User Experience Goal** | ✅ Fast, frequent, low-friction login | ✅ Secure, selective, consent-based data sharing | | **Device Binding** | ❌ mostly synced (in progress) | ✅ Issuer controlled (sensitive keys device-bound) | | **Phishing Resistance** | ✅ High (Origin-bound credentials prevent use on fake sites) | ❌ Variable (Presentation flow matters; VC data itself is verifiable but presentation context can be phished if not careful. Protocol design (e.g., origin binding in APIs) aims to mitigate this). | | **Trust Anchor / Source of Truth** | ✅ RP's binding of identity to public key during registration; Authenticator security. | ✅ Issuer's authority & cryptographic signature; Issuer's public key infrastructure. | | **Standardization Maturity / Interoperability** | ✅ High (WebAuthn/CTAP2 well-adopted) | ❌ Mixed (VC data model stable; Presentation/Issuance/API protocols evolving, fragmentation exists) | | **Offline Capability** | ❌ None | ✅ Yes (Designed for offline presentation, e.g., mDL via NFC/BLE) | | **Revocation Mechanism** | ✅ RP deletes public key record; User removes from authenticator. | ✅ Issuer publishes status (e.g., status lists); Verifier checks status; Holder deletes VC. | | **Enrollment Friction** | ✅ Low (Often integrated into login/signup) | ❌ High (Separate wallet setup) | | **Adoption Rate (May 2025)** | ✅ 95 %+ | ❌ < 1 % | This comparison highlights that while both leverage cryptography for trust, their primary functions and typical usage patterns differ significantly. Passkeys are optimized for frequent, secure authentication, while digital credentials excel at providing verifiable attributes with user consent. ### 2.2 WebAuthn Layer (CTAP 2 and Advanced Trust Signals) Passkeys are brought to life through the interaction of several key standards: - **WebAuthn (Web Authentication):** This [W3C standard](https://www.w3.org/TR/webauthn-3/) defines the JavaScript API that web applications use to interact with [authenticators](https://www.corbado.com/glossary/authenticator) for registering (`navigator.credentials.create()`) and authenticating (`navigator.credentials.get()`) passkeys. It acts as the bridge between the [Relying Party](https://www.corbado.com/glossary/relying-party)'s web application and the user's browser or operating system. WebAuthn extends the W3C's general [Credential Management API](https://www.w3.org/TR/credential-management-1/). - **[CTAP (Client to Authenticator Protocol)](https://fidoalliance.org/specs/fido-v2.2-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html):** Defined by the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), CTAP specifies how the client (browser or OS) communicates with the [authenticator](https://www.corbado.com/glossary/authenticator) device. This could be a [platform authenticator](https://www.corbado.com/glossary/platform-authenticator) built into the device (using secure hardware like a TPM or [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) or a roaming [authenticator](https://www.corbado.com/glossary/authenticator) like a USB [security key](https://www.corbado.com/glossary/security-key) or even a phone acting as an [authenticator](https://www.corbado.com/glossary/authenticator) for another device. CTAP2 is the version aligned with [FIDO2](https://www.corbado.com/glossary/fido2) and passkeys, supporting various transports like USB, NFC, and Bluetooth Low [Energy](https://www.corbado.com/passkeys-for-energy) (BLE). - **Advanced Trust Signals & Device Binding (Considerations for Synced Passkeys):** As passkeys evolved to become syncable across devices ("multi-device credentials"), Relying Parties (RPs) sometimes needed to identify the specific physical device used during authentication for risk assessment. Early ideas, like the `devicePubKey` and `supplementalPubKeys` extensions, tried to solve this but were later dropped. The FIDO Alliance's trust signal working group is now developing replacements. The main idea here is that an authenticator with a [synced passkey](https://www.corbado.com/blog/device-bound-synced-passkeys) could _also_ create and use a second key pair that's tied to the device. During authentication, the authenticator could then provide signatures from both the main synced key and this second device-bound key. This would let RPs recognize a specific trusted device. This could mean less friction (e.g., skipping extra challenges) even if the main passkey is synced across many devices, all without losing the main benefit of synced passkeys: usability across devices. While there's no final standard for this yet, such a feature would meet a key need for RPs requiring high assurance, letting them better spot new device use or meet internal [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA) rules. ![webauthentication layer](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/webauthentication_layer_5d44167576.png) ### 2.3 Digital-Credentials Layer (OpenID 4 VP/VCI, ISO 18013-7) Similarly, the digital credential ecosystem relies on a set of protocols and emerging APIs to function: - **Digital Credentials API:** This is an [emerging W3C specification effort](https://github.com/WICG/digital-credentials) aiming to extend the navigator.credentials.get() API to allow web applications to request [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) from a user's [digital wallet](https://www.corbado.com/blog/digital-wallet-assurance) in a standardized way. It serves a similar purpose to WebAuthn but focuses on VCs instead of passkeys. - **OpenID for Verifiable Presentations (OpenID4VP):** This defines a protocol, built on [OAuth 2.0](https://www.corbado.com/glossary/oauth2), for how a Verifier (the RP requesting credentials) can request VCs from a Holder's [Wallet](https://www.corbado.com/blog/digital-wallet-assurance). Key elements include the presentation_definition (specifying required credentials and claims), the Wallet acting as an authorization server, and the vp_token carrying the [Verifiable Presentation](https://www.corbado.com/glossary/verifiable-presentation) back to the Verifier. - **OpenID for Verifiable Credential Issuance (OpenID4VCI):** Complementing [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp), this standardizes how an [Issuer](https://www.corbado.com/glossary/issuer) delivers VCs to a Holder's Wallet, again using [OAuth 2.0](https://www.corbado.com/glossary/oauth2) mechanisms. It involves concepts like Credential Offers, pre-authorized or authorization code flows, and dedicated credential endpoints. - **ISO Standards (e.g., ISO/IEC 18013-7, ISO/IEC 23220):** These international standards are particularly significant for mobile driving licenses (mDLs) and other types of mobile documents (mdoc). [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) defines the core [mDL](https://www.corbado.com/blog/mobile-drivers-license) data structure and offline presentation (NFC, BLE), while [ISO 18013-7](https://www.corbado.com/glossary/iso-18013-7) and 23220 specify online presentation mechanisms, including REST APIs and integration profiles with [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) (Annex B of 18013-7). Platforms like [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay) and Apple Wallet leverage these ISO standards. ![Layers digital credentials](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/digital_credential_layers_new_94dff37b9e.png) ### 2.4 Shared building blocks (public/private keys, Secure Enclave, StrongBox) Despite their different purposes and protocols, passkeys and digital credentials share fundamental building blocks: - **Asymmetric Cryptography:** Both rely heavily on public-private key pairs. Passkeys use the private key to prove possession during authentication. Digital credentials use the [issuer's](https://www.corbado.com/glossary/issuer) private key to sign the credential, ensuring its authenticity and integrity, and the holder might use their private key to sign a presentation containing the credential. - **Secure Hardware:** Protecting the private keys is important. Both technologies benefit immensely from secure hardware components integrated into modern devices: - **TPM (Trusted Platform Module):** A dedicated chip often found in laptops and desktops, providing secure key generation, storage, and cryptographic operations. It's commonly used by platform [authenticators](https://www.corbado.com/glossary/authenticator) like [Windows Hello](https://www.corbado.com/glossary/windows-hello). - **Secure Enclave:** Apple's hardware-based key manager, isolated from the main processor on iPhones, iPads and Macs, used to protect sensitive data including passkey private keys. - **Android Keystore System / StrongBox Keymaster:** [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) provides a hardware-backed Keystore, often implemented using a dedicated secure processor (StrongBox Keymaster), offering strong protection for cryptographic keys on [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) devices. While some password managers use the name "Strongbox", the underlying secure hardware element provided by the OS is the key enabler here. The use of the _same_ secure hardware elements (TPM, [Secure Enclave](https://www.corbado.com/glossary/secure-enclave), [Android's](https://www.corbado.com/blog/how-to-enable-passkeys-android) hardware-backed Keystore) for both passkey operations and potentially for securing the private keys within digital [wallets](https://www.corbado.com/blog/digital-wallet-assurance) creates significant synergy. Platforms don't need separate secure chips for each function. Instead, they can use a single, strong hardware base and related operating system APIs (like those for the [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Keystore or Apple's [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) to strongly protect both authentication credentials (passkeys) and [attestation](https://www.corbado.com/glossary/attestation) credentials (VCs). This makes development easier, improves security consistency, and uses existing platform investments well. Furthermore, the browser's Credential Management API (`navigator.credentials`) is a key organizing layer. First extended by WebAuthn for passkeys, it's now being further extended by the [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) for VCs. This points to a clear plan: give RPs one main way to ask for different credentials, and give users a familiar way to pick them (like through [Android's](https://www.corbado.com/blog/how-to-enable-passkeys-android) credential manager or built-in browser password managers). This would hide the complex technical details of protocols like CTAP, OID4VP, and ISO, making things easier for developers and users. ## 3. Relying Party View: Integrating Passkeys & Digital Credentials From a [Relying Party](https://www.corbado.com/glossary/relying-party) (RP) perspective, understanding how to integrate and leverage passkeys and digital credentials effectively is crucial for enhancing security, improving user experience, and meeting regulatory requirements. This section analyzes how RPs can deploy these technologies across different common scenarios and ecosystems. ### 3.1 Ecosystem Scenario Comparison The optimal integration strategy for passkeys and digital credentials varies significantly based on the specific use case and its associated risk profile and requirements. The following table provides a high-level comparison across common scenarios: **Ecosystem Scenario Comparison** | Scenario | Goal | Passkey Role | VC Role | Friction Tolerated | Device Binding? | | :--------------------------- | :------------------------------ | :-------------------------- | :--------------------------------------------------------- | :------------------- | :--------------------- | | **E-Comm / General** | Speed & Base Security | ✅ Primary Login (2FA) | none | 🟢 Low | ❌ No | | **High Assurance / MFA** | Strong Auth & ID Proofing | ✅ Primary Login (2FA) | 🆔 KYC / Onboard / Recovery | 🟡 Medium | ❌ No | | **Payment Auth** | Fast & Secure Payment Conf. | ✅ Primary Login (2FA) | 🆔 KYC / Onboard / Recovery | 🟢 Very Low | ❌ No | | **Banking (Non-SCA)** | High Security / Fraud Reduction | ✅ Primary Login (2FA) | 🆔 KYC / Onboard / Recovery | 🟡 Medium | ❓ Optional | | **EU SCA Compliance** | Regulatory Compliance | ✅ Core SCA Factor | 🆔 KYC / Onboard / Recovery | 🔴 Higher (Mandated) | ✅ Yes | | **EU EUDI Wallet mandate**\* | Regulatory Compliance & Privacy | ✅ Pseudonym Key (WebAuthn) | 🆔 PID (Person ID Data) / Qualified Attributes (On Demand) | 🟡 Medium | ✅ Yes (WSCD Attested) | **Legend:** - **VC Role :** Describes the role during the _main interaction_, acknowledging VCs are often used for initial onboarding/[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) across scenarios. - **Device Binding?:** Refers to the need for explicit device binding beyond standard passkey origin binding, particularly relevant for synced passkeys. - **EU EUDI Wallet mandate**: This scenario reflects requirements under the upcoming [eIDAS](https://www.corbado.com/glossary/eidas) 2 regulation, expected to apply \~36 months after final implementing acts enter force (likely late 2020s). This comparison provides a quick overview; the following sections delve into the specifics of each scenario from the RP's integration perspective. ### 3.2 Single-Factor Scenarios (e.g. E-Commerce, General Services) - **Goal:** Fast, low-friction access with good baseline security. - **Likely Flow:** - **Primary Authentication:** Passkeys will dominate. Their phishing resistance and seamless UX (often just a biometric/PIN) make them ideal for replacing passwords in frequent login scenarios. - **Digital Credentials Role:** Minimal for core login. VCs might be used _optionally_ post-login for specific actions like age verification (e.g., buying restricted goods), personalization based on verified attributes (e.g., loyalty status), or expedited profile completion during initial signup. - **Interplay:** Passkey handles the core login; VCs are reserved for optional, attribute-based interactions. ### 3.3 Multi-Factor Authentication (MFA) & Identity Verification Scenarios (e.g. Government, Insurance, Funds) - **Goal:** High assurance login and, where necessary, verified identity [assertion](https://www.corbado.com/glossary/assertion). - **Likely Flow:** - **Passkeys as Self-Contained 2FA/MFA:** Passkeys inherently fulfill [two-factor authentication](https://www.corbado.com/blog/passkeys-vs-2fa-security) requirements when [user verification](https://www.corbado.com/blog/webauthn-user-verification) (PIN/biometric) occurs during the login ceremony. They combine: - **Possession:** Proof of control over the private key. - **Knowledge/Inherence:** [User verification](https://www.corbado.com/blog/webauthn-user-verification) via PIN or biometrics. This makes [passkey login](https://www.corbado.com/blog/passkey-login-best-practices) itself a strong, phishing-resistant MFA method, sufficient for many high-assurance scenarios without needing a separate second step purely for achieving [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security). - **Step-Up for Identity Verification (One-Time):** The main need for an extra step with Digital Credentials comes when the service must _explicitly verify identity_ beyond just authenticating a returning user. This kind of strong, cryptographic check is vital when deepfakes can convincingly forge visual or document-based ID. Only digital cryptographic proof from a trusted source can then reliably confirm an attribute. This might be needed: - During initial onboarding. - For specific high-risk actions requiring confirmed identity attributes. In these cases, the RP requests a specific [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) (e.g. a PID, national ID credential) presentation from the user's wallet after the [passkey login](https://www.corbado.com/blog/passkey-login-best-practices). - **Identity for Recovery:** Once a user's identity has been strongly verified (e.g., via a VC presentation step-up), this verified identity information could potentially be leveraged in secure account recovery flows. For example, if a user loses all their passkey [authenticators](https://www.corbado.com/glossary/authenticator), presenting a high-assurance identity credential could be part of a process to regain access and enroll new passkeys. - **Interplay:** Passkeys provide robust, self-contained [2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security)/MFA for authentication. VCs are used strategically for explicit [identity verification](https://www.corbado.com/blog/digital-identity-guide) when required, and this verified identity can also support secure account recovery mechanisms. ### 3.4 Payment Scenarios (Low Friction) - **Goal:** Streamlined, secure checkout or [payment](https://www.corbado.com/passkeys-for-payment) initiation, minimizing user friction. - **Likely Flow:** - **Authentication for Payment:** Passkeys are ideal for authenticating the user _to_ their [Payment Service Provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) (PSP) account (e.g., [PayPal](https://www.corbado.com/blog/paypal-passkeys)) or directly within the [merchant's](https://www.corbado.com/glossary/merchant) checkout flow. This replaces passwords and provides a fast, secure confirmation for initiating the [payment](https://www.corbado.com/passkeys-for-payment). - **Onboarding/KYC:** VCs remain crucial during the _onboarding_ or account setup phase with the [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) or [merchant](https://www.corbado.com/glossary/merchant), providing verified identity information (KYC/AML checks) necessary to enable [payment](https://www.corbado.com/passkeys-for-payment) capabilities in the first place. - **Transaction Friction Concerns:** Introducing a separate [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) presentation step _during_ the core payment authorization flow (requiring interaction with a [digital identity](https://www.corbado.com/blog/digital-identity-guide) wallet) would add significant friction compared to a seamless passkey confirmation step. This disruption to the user experience would likely harm [conversion rates](https://www.corbado.com/blog/logins-impact-checkout-conversion) and is therefore unsuitable for typical low-friction payment scenarios. - **Interplay:** Passkey secures the authentication for the payment act itself. VCs handle the necessary, often one-time, [identity proofing](https://www.corbado.com/blog/digital-identity-guide)/[KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) required to establish the payment account, but are kept out of the critical, friction-sensitive payment confirmation step. (The complex topic of using digital credentials directly _as payment instruments_, including how different wallet types and emerging browser APIs might enable or interact with such payment-specific VCs, is explored in detail in our upcoming complementary article: Digital Credentials and Payment. ### 3.5 Financial Institution Scenarios (Outside SCA) - **Goal:** Secure [banking](https://www.corbado.com/passkeys-for-banking) access with a significant reduction in fraud, particularly phishing-related, by upgrading from legacy authentication methods. - **Likely Flow:** - **Replacing Legacy MFA:** Many FIs currently rely on passwords combined with phishable second factors like SMS OTPs. Passkeys offer a vastly superior alternative, providing strong authentication that is inherently resistant to phishing in a single user gesture. - **Primary Login with Passkeys:** Adopting passkeys for primary login immediately enhances security due to their phishing resistance. The cryptographic nature of passkeys mitigates the most common attack vectors that plague traditional credentials. - **Risk-Based Step-Up - Careful Consideration of Device Signals:** For higher-risk operations (e.g. large transfers, changing contact details), FIs may consider step-up verification. While device-binding signals associated with passkeys are an option, their necessity should be carefully evaluated. The phishing resistance of the primary passkey authentication itself heavily mitigates many risks. - **Outcome-Based Security & Fraud Reduction:** The significant reduction in phishing risk achieved by passkeys is a critical factor. An outcome-based approach to security, focusing on the strength and phishing resistance of the authentication method, can lead to substantial fraud reduction. The weight of a phishing-resistant factor like a passkey is considerably higher than adding more phishable factors. This must be central to an FI's strategy when migrating from older methods. - **VCs for Onboarding/Identity Proofing:** As in other scenarios, VCs remain essential for robust initial [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding)/AML and for securely updating customer identity attributes using verified information, establishing a trusted foundation for the [banking](https://www.corbado.com/passkeys-for-banking) relationship. - **Interplay:** Passkeys serve as a powerful, phishing-resistant primary authentication method, drastically reducing fraud risk from legacy systems. Device signals for step-up are a tactical option. The inherent strength of passkeys should inform a risk-based security posture, potentially reducing over-reliance on additional, less phishing-resistant factors. VCs provide foundational identity assurance. ### 3.6 EU EUDI Wallet Mandate Scenario (Future Requirement) - **Goal:** Comply with [eIDAS](https://www.corbado.com/glossary/eidas) 2 regulations (Art 5f) requiring acceptance of the EU Digital Identity Wallet by specific Relying Parties (public bodies, large private entities in regulated sectors, VLOPs), enabling both privacy-preserving pseudonym login and high-assurance identity/attribute verification when legally required. - **Likely Flow:** - **Pseudonym Login (Default):** The user initiates login. The RP requests authentication via the EUDI Wallet. The wallet uses its built-in "pseudonym key" – a hardware-bound, RP-scoped WebAuthn [resident key](https://www.corbado.com/blog/webauthn-resident-key-discoverable-credentials-passkeys) stored in the device's certified secure element (WSCD) – to authenticate the user. This provides strong, SCA-compliant authentication (possession + [user verification](https://www.corbado.com/blog/webauthn-user-verification)) while keeping the user's civil identity pseudonymous by default. - **Step-Up for Identity/Attributes (Legally Required):** If and only if the RP has a specific legal basis under Union or national law (e.g., [PSD2](https://www.corbado.com/blog/psd2-passkeys), AML, [telecom](https://www.corbado.com/passkeys-for-telecom) registration) to require [identity verification](https://www.corbado.com/blog/digital-identity-guide) or specific attributes, it initiates a second step. The RP requests a presentation (via [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp)) of the necessary Person Identification Data (PID) or Qualified [Attestation](https://www.corbado.com/glossary/attestation) of Attributes (QAA) from the wallet. The user must explicitly consent to share this identified data. - **Wallet & RP Authentication:** The flow involves mutual authentication. The RP authenticates itself to the wallet (based on its official registration), and the wallet attests its authenticity and the credential's validity to the RP, leveraging the secure hardware (WSCD) and associated certification infrastructure. - **Interplay:** The EUDI Wallet acts as a unified authenticator. Its integrated WebAuthn passkey (pseudonym key) handles the standard login, offering strong, privacy-preserving authentication. The [wallet's](https://www.corbado.com/blog/digital-wallet-assurance) VC capabilities are invoked selectively for explicit, legally mandated identity or attribute disclosure, ensuring data minimization by default. ## 4. Strategic Considerations for RPs Navigating this evolving landscape requires strategic planning. Here are key considerations for Relying Parties (RPs). ### 4.1 Keep collecting passkeys For RPs, the main action today should be to enable and encourage passkey use for authentication. Passkeys are standardized, widely supported by platforms, and offer immediate, big benefits in security (phishing resistance) and user experience (faster, easier logins). This means less reliance on passwords and insecure MFA methods like SMS OTPs. It can also lower support costs from [password resets](https://www.corbado.com/faq/passkeys-reduce-password-resets-otp-costs) and account recovery. Aiming for wide passkey use sets up a modern, secure base for user authentication. While adoption might be slow at first, teaching users about the benefits beforehand and making signup easy can help get them started. ### 4.2 Addressing SCA Compliance Gaps: The PayPal Example While passkeys themselves offer a significant step towards robust authentication and can meet [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA) requirements, some organizations may have internal compliance frameworks with even stricter interpretations or specific concerns, particularly regarding synced passkeys. For Relying Parties (RPs) facing such scenarios where compliance departments seek further assurances, it's useful to know that additional measures can complement passkey deployments. These can help address perceived SCA gaps or satisfy those heightened internal requirements. One common strategy is to leverage device trust signals, an approach taken by services like [PayPal](https://www.corbado.com/blog/paypal-passkeys). [PayPal](https://www.corbado.com/blog/paypal-passkeys), for instance, allows users to mark a device as "remembered" as described on their [help page](https://www.paypal.com/is/cshelp/article/what-are-the-payment-services-directives-strong-customer-authentication-and-remembered-device-help718): > "A remembered device is a personal web or mobile browser, or mobile device used to get > into your PayPal account that we remember after we successfully confirm your identity. > This makes it easier to log in, pay, and take other actions with your PayPal account > because the device works as one of the two factors needed for SCA." This means that if a user logs in with their password (something they know) from a remembered device (something they have), PayPal may consider this sufficient for SCA in many cases. However, they also state, "There might be instances where we still ask you for another verification to ensure your account is secure." This could involve sending a one-time passcode via SMS or prompting for confirmation via the PayPal app. This approach allows for a smoother user experience on trusted devices while still providing mechanisms for [step-up authentication](https://www.corbado.com/glossary/step-up-authentication) when risks are higher or regulations demand it. RPs can consider similar models, where a combination of primary authentication (like a passkey) and device trust (potentially managed outside of WebAuthn's direct mechanisms if needed) can help bridge SCA compliance gaps. However, for a more integrated and standardized approach to device-specific trust signals within the WebAuthn framework itself, attention turns to ongoing developments in that space. ### 4.3 Monitor Successors to discontinued WebAuthn Extensions for stronger Device Binding Regarding such WebAuthn-integrated approaches for stronger device trust, RPs in high-security environments should understand the history and future direction. Past WebAuthn extension proposals, like `devicePubKey` and `supplementalPubKeys`, aimed to provide these device-specific trust signals. These were attempts to address the security considerations of synced passkeys, which, while offering crucial usability for mass adoption, introduce different risk profiles (e.g. reliance on cloud account recovery) compared to device-bound keys. The idea behind such extensions was to let RPs get an extra layer of assurance by checking a signature from a key specifically bound to the physical device being used, _even when the main passkey itself is synced_. Although these specific extensions (`devicePubKey` and `supplementalPubKeys`) have been discontinued, the challenge of obtaining stronger device-binding signals for synced passkeys persists. RPs should therefore monitor the development and standardization of _follow-up solutions_ in this space. Such solutions could help RPs better judge risk (e.g., telling a login from a known, trusted device from a newly synced one) without forcing all users to use less convenient [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific). This context presents RPs with a more complex choice than just "synced vs. device-bound." Synced passkeys ( [AAL2](https://www.corbado.com/blog/nist-passkeys)-compliant) offer the most convenience and best chance for adoption, vital for consumer apps. [Device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) (possibly [AAL3](https://www.corbado.com/blog/nist-passkeys)) give the highest assurance but can be harder to use. The goal of the discontinued extensions was to find a middle way - improving security for synced keys by adding back a device-specific trust signal. This could help reduce some risks if the cloud sync is compromised, without losing all the convenience of syncing. RPs should therefore look for _follow-up solutions_ that aim to do this. The best strategy will depend on an RP's specific risk tolerance, user base, and how mature any new standards become. ### 4.4 Digital Credentials: RP Consideration for Device Binding and Wallet Transition Beyond the specific mechanisms within WebAuthn for device trust, some Relying Parties (RPs) - particularly those in sectors like [banking](https://www.corbado.com/passkeys-for-banking), [insurance](https://www.corbado.com/passkeys-for-insurance) and payment services - are beginning to evaluate digital credentials (Verifiable Credentials or VCs) as a complementary or even next-step, component in their identity and security strategies. A significant factor driving this interest is the robust device binding often associated with digital credentials, especially when managed within secure digital identity [wallets](https://www.corbado.com/blog/digital-wallet-assurance). These wallets can leverage hardware-backed security (like Secure Enclaves or TPMs) to protect the credentials and the private keys used to present them. [Issuers](https://www.corbado.com/glossary/issuer) and wallet providers can also enforce policies that make certain high-value credentials inherently device-bound, offering a level of control that is attractive for high-assurance scenarios. It's crucial to recognize that while this enhanced device-binding capability is a compelling feature for these RPs, the _primary purpose_ of digital credentials (attestation of attributes and claims) is distinct from that of passkeys (user authentication). Passkeys confirm _who_ the user is, while digital credentials confirm _what is true about_ the user. Despite this fundamental difference in purpose, the strong security characteristics of wallet-held VCs make them an area of active consideration for RPs seeking to layer additional assurances. This naturally leads the discussion towards the providers of these digital identity wallets and the ecosystem that enables the issuance, storage, and presentation of such credentials. ## 5 Presenting Digital Credentials via Wallets for Identity Attestation While passkeys offer direct authentication, digital credentials (VCs) are managed and presented to Relying Parties through digital identity wallets. These wallets, whether native platform solutions (like Apple Wallet, [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) or third-party applications (such as the EUDI Wallet), are evolving to use emerging browser standards like the Digital Credentials API for smoother online [identity verification](https://www.corbado.com/blog/digital-identity-guide) (e.g. age checks, sharing [digital ID](https://www.corbado.com/blog/digital-identity-guide) attributes). The detailed mechanics of different wallet types, specific platform strategies for VC integration (including Apple's [mDoc](https://www.corbado.com/glossary/mdoc) focus for browser interactions versus [Android's](https://www.corbado.com/blog/how-to-enable-passkeys-android) broader OpenID4VP support via its Credential Manager), how these wallets facilitate attribute [attestation](https://www.corbado.com/glossary/attestation), and the entirely separate considerations for any payment functionalities are complex topics. These are explored in-depth in our upcoming complementary article on Digital Credentials and [Payments](https://www.corbado.com/passkeys-for-payment). This current article maintains its focus on the foundational interplay between passkeys for authentication and the general role of digital credentials for attesting attributes. ## 6. Conclusion Passkeys and digital credentials, while different in their main purpose, represent two pillars of a modern, more secure, and user-focused digital identity future. Understanding how they relate and can support each other is key for building the next wave of online services. ### 6.1 Action items: Based on the current state and trajectory of these technologies, two key actions stand out for Relying Parties: - **Deploy passkeys everywhere today:** The standards are mature, platform support is widespread, and the benefits over passwords are clear and substantial. Make passkeys the default target for user authentication to enhance security and usability immediately. - **Add wallet step-up where AML/KYC matters:** For processes requiring higher assurance or specific verified attributes – such as meeting Anti-Money Laundering (AML) / Know Your Customer (KYC) regulations, performing reliable age verification, or confirming professional qualifications – integrate [Verifiable Credential](https://www.corbado.com/glossary/verifiable-credential) presentation flows to obtain cryptographically verifiable attributes, which are indispensable for trusting identity and claims in an era of sophisticated digital forgeries and deepfakes. Use the [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) where feasible, but implement robust QR/deep link fallbacks to ensure cross-platform reach until the API stabilizes. This provides targeted high assurance without burdening every login. ### 6.2 Long-term Outlook: Device-to-Device Transfer and consolidated Browser APIs Looking ahead, we can expect more convergence and improvements: - **Improved Credential Portability:** Device-to-device transfer methods will likely get better. This might go beyond the CTAP 2.2 cross-device authentication for passkeys to include smoother ways to move VCs between wallets, though standardization here is not as far along. - **Consolidated Browser APIs:** The Digital Credentials API will probably mature and be more consistently supported across browsers. This will offer RPs a more standard way to request both passkeys and VCs through navigator.credentials. - **Unified User Experience:** Ultimately, users should see less of a technical difference between authenticating with a passkey and presenting attributes with a VC. Platform credential managers and wallets will likely manage these interactions smoothly behind the scenes. They will use shared cryptographic tools and secure hardware, letting users simply approve requests with familiar biometric or PIN prompts, no matter if a passkey or a VC is used. Furthermore, concepts like [Continuous Passive Authentication](https://www.corbado.com/blog/continuous-passive-authentication) (CPA), which constantly verifies users in the background using behavioral biometrics and other signals, could further enhance this seamless security, potentially working alongside active authenticators like passkeys. Getting to this integrated future will need more work on standards, how platforms support them, and how apps use them. By using passkeys now and thoughtfully adding digital credentials, organizations can be ready for this shift to a digital world that's passwordless and gives users more control over their data. ## Frequently Asked Questions ### How do passkeys and digital credentials work together in a banking or financial services login flow? In banking, passkeys handle primary login by providing phishing-resistant authentication in a single biometric gesture, replacing SMS OTPs. Digital credentials serve a separate role during initial KYC/AML onboarding to cryptographically verify customer identity attributes. The two technologies address distinct phases of the customer relationship rather than competing for the same function. ### When should I trigger a Verifiable Credential step-up instead of relying on passkey authentication alone? Verifiable Credential step-up is appropriate when a service must explicitly verify identity attributes beyond authenticating a returning user, such as during initial onboarding, AML/KYC compliance, age verification or confirming professional qualifications. Passkey authentication alone suffices for routine login. Adding a VC presentation step during frequent interactions like payment confirmation introduces friction that harms conversion rates. ### How does the EU EUDI Wallet integrate passkeys with digital credentials in a single authentication flow? The EUDI Wallet uses a hardware-bound WebAuthn pseudonym key stored in the device's certified secure element (WSCD) for standard login, providing SCA-compliant authentication without revealing the user's civil identity. Verifiable Credentials such as PID or Qualified Attestations of Attributes are presented only when a relying party holds a specific legal basis under eIDAS 2 to request identity disclosure. ### Why were the WebAuthn devicePubKey and supplementalPubKeys extensions discontinued and what should relying parties do now? The devicePubKey and supplementalPubKeys extensions were discontinued despite their goal of providing device-specific trust signals for synced passkeys. The FIDO Alliance trust signal working group is developing replacement solutions. Relying parties should monitor these developments, as successors would allow distinguishing logins from known trusted devices versus newly synced ones without forcing users onto less convenient device-bound passkeys. ### What is the difference between how passkeys and digital credentials use secure hardware on mobile devices? Both passkeys and digital credentials rely on the same secure hardware components: Apple's Secure Enclave, Android's StrongBox Keymaster and TPMs on laptops. Passkeys use this hardware to protect the private key that signs authentication challenges. Digital credential wallets use the same hardware to protect the holder's private key used to sign Verifiable Credential presentations, enabling consistent security across both credential types from a single hardware base.