Passkeys vs. Verifiable Credentials (VCs): Understanding Their Distinct Roles in Identity Management

Authentication is not just about “logging in”: it also enables the sharing of attributes. Distinguishing between identification and authentication means understanding the difference between claiming who you are and proving who you are.

In this context, two modern approaches, often grouped under the umbrella term passwordless, stand out: passkeys and Verifiable Credentials (VCs).

Although both approaches enable authentication without a username or password, they address different needs. Passkeys are designed solely to authenticate an already known user, whereas Verifiable Credentials (VCs) enable both identification and authentication simultaneously.

In this article, we will compare these two approaches to answer one key question:

“What are you trying to prove when authenticating?”

Why Rethink Authentication Journeys?

The article “Web Authentication and Decentralized Identity: The Challenges of a New Era of Digital Trust” specifically addresses the limitations of traditional authentication methods in the face of growing security and user experience requirements.

It highlights an operational reality: login journeys remain a major source of friction and revenue loss (complexity, forgotten passwords, password resets, and support requests), while also serving as an entry point for fraud and cyberattacks.

In this context, organizations are looking to replace password-based authentication mechanisms and their variants with more robust approaches. Recent investigations conducted by the website Zataz demonstrate that passwords remain a weak point in security.

Key numbers

Source: Zataz.com, a cybersecurity news website – Article by Damien Bancal, “One Billion French Credentials on the Dark Web” (article in French).

Against this backdrop, two modern passwordless authentication approaches are gaining traction, aiming to strengthen security while simplifying the user experience.

Passkeys: Device-Centric Authentication Proof

A passkey is a passwordless authentication method designed to answer the question: “Is the person using the authentication method really the one initiating the login?”

In practice, it relies on asymmetric cryptography, which uses a pair of keys (a mathematical value used by an algorithm to encrypt, decrypt, or digitally sign data):

• A public key, used to verify a digital signature (or establish encryption parameters). It can be freely shared and stored by the service provider.
• A private key, used to sign (or decrypt) data. It must remain strictly confidential and accessible only to its owner.

How It Works

Let’s consider the example of a user creating a passkey for their account on a website.

• During registration, after the user has identified themselves, the service asks their device to create a passkey for that specific account and website, according to the browser and operating system settings. The device generates a pair of cryptographic keys. To confirm registration, the user must unlock their device using an authentication method (e.g., fingerprint, PIN, etc.). The service stores the public key, while the private key remains securely protected on the device.

• During login, the user locally unlocks their authentication method on their device (smartphone or PC). In the background, the system generates cryptographic proof that allows the service to verify authenticity. The website can then establish the cryptographic link between the private key on the user’s device and the public key registered with the service, and, if the verification succeeds, complete the authentication process.

This approach is known as hardware-bound (tied to the device’s hardware): the private key is generated and protected by the device’s security mechanisms. As a result, it is never transmitted over the Internet or exported to the website in plaintext. The primary role of biometrics or a PIN is to locally unlock access to the private key.

The User Journey

When passkey authentication is implemented, the option is generally available in the user’s account settings. To activate it, the user must confirm registration by unlocking their device using a method such as a fingerprint, Face ID, or PIN.

For subsequent logins, there is no longer any need to enter a username or password: the user simply unlocks their device, and the system automatically generates the cryptographic proof required to grant access.

In many scenarios, the user experience is extremely straightforward, offering fast and seamless authentication, sometimes with cross-device support (e.g., authenticating on a laptop using a smartphone by scanning a QR code), and local verification through the device’s built-in security mechanisms.

Key Benefits

• Improved user experience: Eliminates the need to remember passwords, reduces password reset procedures, and enables a seamless login experience.
• Enhanced security: Provides greater resistance to phishing attacks (no reusable secrets) and reduces the risk of account compromise.
• Simplified integration: Relies on mature, widely supported standards, without requiring the development of a credential attestation model, as is the case with Verifiable Credentials (VCs).

Limitations

• Focused on authentication: A passkey proves possession of an authentication method but does not natively provide a mechanism for verifying attributes (roles, status, or certified affiliations). In other words, a passkey proves that a user has access to an account, but it does not, on its own, guarantee information such as a user’s role, organizational affiliation, status, or certified business-related attributes.

• Dependency on devices, browsers, and associated synchronization mechanisms: The user experience and portability may depend on synchronization services (iCloud, Google Password Manager, etc.), backup and recovery processes, and changes in the user’s device or operating environment.

• Does not meet eIDAS 2.0 requirements: As it stands, this authentication method does not address the requirements and obligations associated with the European Digital Identity Wallet (EUDI Wallet).

Verifiable Credentials (VCs): Identity Proof That Can Support Authorization

Verifiable Credentials (VCs) are part of a Self-Sovereign Identity (SSI) approach, in which users have a digital wallet containing signed and verifiable digital credentials. Here, the question is no longer simply “Are you the right user?” It also becomes:

• What certified information can you present?
• On what basis should access be granted?

How It Works

A Verifiable Credential (VC) is a digital proof that is:

• Issued by a trusted authority (issuer),
• Cryptographically signed,
• Stored in a digital wallet,
• Presented to a verifier, which checks its validity.

An initial credential can address a straightforward use case: for example, a membership credential that allows a user to access an account or customer portal.

It can also include attributes such as a role (e.g., buyer profile, seller profile), an affiliation (VIP group, etc.), active status, access rights, or an authorization level. This enables the service to apply authorization rules after verifying the credential.

In a standardized VC ecosystem, exchanges rely on protocols designed to support interoperability, particularly OpenID4VCI and OpenID4VP.

The User Journey

The user journey consists of two stages:

• Issuing verifiable credentials
• Presenting these credentials to a service upon request

When a user initiates the process (from a mobile application or an environment where they are already authenticated), they request and receive a Verifiable Credential (VC), which they store in their digital wallet. This step is generally performed only once (or when a credential needs to be renewed or the user’s status changes).

When the user wants to log in to a service from a PC, the service initiates a request for proof and displays a QR code. The user scans the QR code with their smartphone, which automatically opens the digital wallet. The user then selects and/or approves the required attributes (depending on the configuration), and the wallet shares verifiable proof with the service.

Once the credential has been verified, the user is identified and granted access based on the attributes presented:

• If the credential only confirms the user’s membership status, access is granted to the standard user area.
• If the credential also contains additional attributes (e.g., roles or permissions), the service can restrict access to specific areas or functionalities (B2B journeys, sensitive resources, restricted features, etc.).

This process must be repeated at each login.

In a same-device scenario, the user remains on their smartphone and initiates an action requiring authentication or authorization. The service requests proof, and the wallet directly presents the required attributes without the need to scan a QR code.

An additional two-step approach linked to the European Digital Identity Wallet (EUDI Wallet) can also be implemented:

• The user creates an account using their European digital identity.
• The system then issues a credential, such as a membership credential enriched with additional attributes, which is stored in the user’s wallet.

This approach enables users to reuse their digital identity and associated credentials for future logins, reducing reliance on manually entered credentials (usernames and passwords) while enabling more advanced authorization scenarios.

Key Benefits

• Authorization through verifiable credentials: This approach goes beyond simply confirming “you are authenticated” to establishing “you are authorized” through certified attributes. VCs can provide proof of attributes such as “member,” “employee,” “role,” or “access rights.” The service can therefore go beyond authentication: it verifies the credential and then grants access (or applies authorization rules) based on verifiable information.

• Portability through the digital wallet: Rather than relying on an authentication mechanism tied to a specific account and service, VCs are stored in a digital wallet. This enables credentials to be reused across different user journeys and interfaces, without being tied to a particular domain name, depending on the proof required.

• Data minimization and user control: The presentation of verifiable proofs can be designed to limit the amount of personal information disclosed.

• Readiness for the EUDI Wallet and 2027: Although the European Digital Identity Wallet (EUDI Wallet) is not the main focus here, it represents an important milestone. Aligning with SSI/VC mechanisms means preparing an architecture in which verifiable proofs and wallet interoperability are central to the digital identity experience expected by 2027.

Limitations

A Verifiable Credentials (VC) approach is not automatically plug-and-play. It is particularly relevant when business requirements go beyond simply eliminating passwords.

In particular, it requires:

• Defining the credentials and claims: Which attributes (claims) should be issued, at what level of granularity, under which validity rules, and in what format?
• Governance: Who is authorized to issue which credentials? How does the service verify their validity and compliance? How are trust lists managed?
• Credential lifecycle management: Expiration, renewal, revocation, and updates.
• More complex integration: Certain use cases require more extensive integration efforts.

In summary, the VC approach is particularly relevant when your requirements go beyond authentication and include verifying business-related attributes, managing access permissions, and preparing for a future built around digital wallets and interoperability.

Passkeys vs. Verifiable Credentials: What Does the Service Verify?

To compare these approaches, we need to shift our perspective. The question is not “Which technology is better?” but rather “What business objective are you trying to achieve?”

Criteria	Passkey	Verifiable Credential (VC)
Fundamental question	Proves possession of an authentication method. Are you the legitimate holder of this account?	Proves an identity or certified attribute. Can you prove who you are or demonstrate possession of a specific attribute?
What the service verifies	Passwordless login authentication.	Verifiable proof followed by access control (authentication and authorization).
Authorization management	Limited native capabilities.	Built into the approach.
Scope of use	Limited to a specific domain name.	Portable across multiple services and organizations.
Portability across user journeys and organizations	Dependent on an ecosystem (Apple, Google, etc.).	Designed for portability through digital wallets and verifiable credentials.
EUDI readiness	Not applicable.	Directly aligned with the wallet/VC approach.
Other use cases	Not applicable.	Yes. Proving one’s identity for travel, opening an account, renting a car, accessing a restricted website, etc.

Key Objectives to Consider Before Adopting a Solution

1. Authentication experience vs. identity and attribute verification: Is the objective solely to reduce login friction, or does it also involve verifying identity or attributes such as roles, status, access rights, or organizational affiliation?

2. Need for certified proofs: Are there user journeys or access scenarios that require certified evidence, such as regulated onboarding, B2B portals, or access to sensitive resources?

3. Privacy and data minimization: Is there a need to prioritize privacy and minimize the disclosure of personal data through mechanisms such as selective disclosure and user consent?

4. EUDI Wallet regulatory readiness: Does the organization need to prepare for the regulatory requirements associated with the European Digital Identity Wallet (EUDI Wallet) by the end of 2027?

5. Required levels of trust and digital sovereignty: What levels of trust and sovereignty are expected, whether in the authentication process itself, the ability to verify cryptographically signed credentials, or the nature of the technologies being deployed?

By clearly identifying these requirements, the most appropriate architectural approach will naturally emerge.

Passkeys or Verifiable Credentials: Define Your Primary Objective

In summary, although both passkeys and Verifiable Credentials offer passwordless solutions, they address different needs:

• If your primary objective is to eliminate passwords and reduce login friction, passkeys offer a pragmatic solution, particularly well suited to B2C and consumer-facing user journeys.

• If your objective includes verifying business-related attributes and preparing for a credential-based digital wallet ecosystem, the Verifiable Credentials approach delivers structural value. It becomes particularly important when user journeys require the verification of certified business information, such as subscriptions, Know Your Customer (KYC) identity verification, B2B access to restricted areas, or role management within a broader system.

The key question for organizations remains: Do you simply need to prove that someone possesses a valid authentication method, or do you also need to verify their business roles and attributes while preparing for the EUDI Wallet ecosystem (with 2027 as a key milestone)?

In other words, the real challenge lies in determining where authentication ends and verifiable credential validation begins, and defining the level of digital sovereignty your organization aims to achieve.