Passkey
A passkey is a phishing-resistant credential based on public key cryptography and designed to replace passwords in user authentication flows.
- Synonym
- FIDO2 CredentialWebAuthn Credential
Definition
A passkey is a modern, phishing-resistant credential based on public key cryptography and designed to replace passwords in user authentication flows. It is generally created and stored in a secure authenticator, such as a platform authenticator on a device or a roaming hardware token, and uses private key possession plus local user verification when required. Because the private key never leaves the authenticator and authentication is origin-bound, passkeys significantly reduce the risk of phishing and credential replay.
What actually happens when you use a passkey?
A passkey changes a fundamental property of authentication: the user no longer proves their identity by sending a reusable secret to the service. Instead, authentication relies on public-key cryptography.
When the passkey is created, the authenticator generates a cryptographic key pair. The service keeps the public key, while the private key remains protected by the authenticator.
During authentication, the service sends a unique challenge. The authenticator uses the private key to sign that challenge, and the service verifies the result with the corresponding public key. The private key itself is never sent to the service.
This distinction matters. With a password, the user and the service ultimately depend on knowledge of a shared secret. With a passkey, the service verifies a cryptographic proof of possession.
How a passkey authentication works
User device / authenticator
Private key stays with the authenticator
Service (relying party)
Public key can be stored by the service
- 1
User device / authenticator
Login request
The user starts an authentication.
- 2
Service (relying party)
Authentication challenge
The service generates a unique cryptographic challenge.
- 3
User device / authenticator
Challenge sent to the authenticator
The authenticator receives the challenge for the correct service.
- 4
User device / authenticator
Signature with the private key
The authenticator signs the challenge using the private key associated with this credential.
- 5
Service (relying party)
Verification with the public key
The service verifies the signature using the public key registered during enrolment.
- 6
Service (relying party)
Authentication succeeds
If the cryptographic proof is valid and the required user verification conditions are met, authentication succeeds.
Text version of the diagram
1. Login request — The user starts an authentication. 2. Authentication challenge — The service generates a unique cryptographic challenge. 3. Challenge sent to the authenticator — The authenticator receives the challenge for the correct service. 4. Signature with the private key — The authenticator signs the challenge using the private key associated with this credential. 5. Verification with the public key — The service verifies the signature using the public key registered during enrolment. 6. Authentication succeeds — If the cryptographic proof is valid and the required user verification conditions are met, authentication succeeds. Private key stays with the authenticator. Public key can be stored by the service.
Why it matters
Passkeys are central to the move toward phishing-resistant authentication and modern passwordless strategies.
Passkeys are a great way to understand modern cryptography
Passkeys are interesting far beyond the disappearance of the password. They provide a concrete way to understand one of the foundations of modern cybersecurity: asymmetric cryptography.
A private key proves possession without being disclosed. A public key allows another system to verify the resulting cryptographic proof. The same fundamental concepts — public and private keys, cryptographic proofs and signatures — appear throughout cybersecurity.
This is why understanding public-key cryptography and PKI remains so useful for cybersecurity engineers. Passkeys reuse these cryptographic foundations, even though a passkey architecture should not be confused with a traditional X.509 Public Key Infrastructure built around certificate authorities and certificate chains.
Understanding the mechanism matters more than memorising the acronym. Once you understand why the private key must remain private, what a signature proves and what the public key can verify, FIDO2 and WebAuthn become much easier to reason about.
Password vs passkey
| Password | Passkey | |
|---|---|---|
| Proof used | Knowledge of a shared secret | Cryptographic proof of possession |
| What the service stores | A password verifier / hash | A public key |
| What the user sends as authentication proof | Information derived from a reusable secret | A signature generated for a challenge |
| Private credential | Must remain known and protected by the user | Private key remains protected by the authenticator |
| Phishing resistance | Can be entered into a malicious site | Credential is bound to the legitimate relying party/origin |
A passkey also helps explain how authentication is evolving
In our IAM training, we use another useful way of looking at authentication: distinguishing explicit, implicit and calculated mechanisms. This is not a replacement for the classic knowledge, possession and inherence categories. It is a way to understand the user experience and the decision process around authentication.
Explicit
An explicit mechanism requires a conscious authentication action from the user. Entering a password, typing a code received by SMS or approving an authentication request are typical examples.
- Password
- SMS code
- Mobile approval
Implicit
An implicit mechanism can establish part of the authentication proof without asking the user to manually provide a reusable secret. A private key associated with a device or authenticator is a good example: the cryptographic operation happens without exposing the key to the service.
- Device-bound private key
Calculated
Calculated signals come from context and behaviour. An identity system can evaluate information such as the IP address, login frequency, location, login time or user behaviour to estimate the risk of an authentication attempt.
- IP address
- Login frequency
- Location and time
- User behaviour
So, is a passkey explicit or implicit?
The answer is more interesting than choosing a single box.
The possession and use of the private key can be largely implicit: the user does not type the key, copy it or transmit it to the service. The authenticator performs the cryptographic operation.
However, the authenticator may still require local user verification, for example through a biometric gesture or a device PIN. That interaction is visible to the user, but the biometric data or PIN does not become a secret sent to the website.
A modern authentication journey can therefore combine cryptographic possession, local user verification and calculated risk signals. Authentication is becoming less about asking for one secret and more about establishing sufficient confidence for a particular access.
Reference standards
Passkeys are built on the FIDO2 ecosystem, combining WebAuthn for web applications and authenticator protocols such as CTAP. For implementation and normative details, refer to the primary specifications rather than product-specific documentation.
- FIDO Alliance — Passkeys
- W3C — Web Authentication (WebAuthn) Level 3— W3C Recommendation, 25 August 2026
- FIDO Alliance — Client to Authenticator Protocol (CTAP)
A passkey secures the login. What happens next?
A successful passkey authentication provides strong cryptographic proof at a specific moment. But once authentication succeeds, most applications establish a session so that the user does not need to authenticate again for every action.
From that point on, the application is no longer validating the passkey for every click. It is largely trusting the session that resulted from the authentication.
This distinction is essential. Protecting the authentication ceremony and protecting the resulting session are related problems, but they are not the same problem.
Authentication is a moment. Trust has a lifecycle.
Strong authentication does not mean permanent trust. The passkey creates a strong authentication event, then Access Management continues managing trust.
- 1
Passkey: strong proof
Enrolment
The credential or authenticator is associated with the identity.
- 2
Passkey: strong proof
Authentication
The user proves possession of the passkey and completes the required user verification.
- 3
Access Management: trust evaluation
Session
The application creates a trusted session.
- 4
Access Management: trust evaluation
Navigation
The user continues interacting with applications and resources.
- 5
Access Management: trust evaluation
Sensitive action
The risk can be very different from the risk observed during the original login.
- 6
Access Management: trust evaluation
Re-authentication / risk decision
The system can request stronger proof, evaluate additional context or terminate the session.
Login is not the end of access control
One of the limits of traditional authentication architectures is their static view of trust. The user authenticates successfully, and the resulting session may then remain trusted even though the context changes.
But context does change. The device can change state. The IP address can change. Behaviour can become unusual. The user can move from reading information to performing a sensitive transaction. The privileges attached to the identity can also evolve.
This is why modern Access Management should not treat authentication as a single binary event. Authentication establishes confidence. The architecture must then decide how long that confidence remains sufficient and when additional verification becomes necessary.
The context changes after login
1 / 3
Connection
Examples of signals
- • device
- • network
- • location
- • authentication method
- • identity context
2 / 3
Navigation
Examples of signals
- • behaviour
- • resources accessed
- • unusual navigation
- • changes in context
- • session characteristics
3 / 3
Transaction
Examples of signals
- • sensitivity of the action
- • amount or business impact
- • requested privilege
- • resource sensitivity
- • current risk level
A user can therefore authenticate legitimately and still reach a point where the initial level of confidence is no longer sufficient for the action being attempted. A modern authentication architecture can react by allowing the action, requesting additional verification, restricting the session or refusing the action.
What a passkey does not replace
Passkeys solve an important authentication problem extremely well. They should not be expected to replace the other controls required around an authenticated identity.
Session security
After authentication, applications commonly rely on session cookies or tokens. Protecting the credential therefore does not remove the need to protect, limit and monitor authenticated sessions.
Authenticator enrolment
Adding a new authenticator changes the future authentication capabilities of an account. Enrolment should therefore be treated as a security-sensitive identity event rather than as a simple user preference.
Account recovery
A strong authentication mechanism loses part of its value if account recovery relies on a substantially weaker process. Recovery, reset and help-desk procedures must therefore be designed with an assurance level consistent with the protected account.
Post-authentication behaviour
A legitimate authentication does not guarantee that every subsequent action is legitimate. Changes in permissions, unusual access to sensitive resources or behaviour inconsistent with the expected role can justify additional controls.
A passkey-ready architecture should also answer…
- How are new authenticators enrolled?
- How is account recovery performed?
- How long can an authenticated session remain trusted?
- What happens when the context or device changes?
- Which actions require step-up authentication?
- How are sessions revoked after a security event?
- How are sensitive authentication and recovery events logged?
- What happens when the observed behaviour no longer matches the expected user context?
Passkeys and adaptive authentication are complementary
A passkey can provide a very strong authentication mechanism while an adaptive authentication system decides when that proof is sufficient.
Adaptive authentication evaluates signals such as context, behaviour and risk. Depending on those signals, the system can maintain the current session, request additional verification or restrict access.
The two approaches therefore solve different parts of the same problem: the passkey strengthens the proof of authentication, while adaptive controls continuously evaluate whether the resulting level of trust remains appropriate.
Related glossary entries
Why passkeys still matter
None of these considerations reduce the value of passkeys. Removing reusable passwords from authentication eliminates an important class of credential attacks and provides a much stronger foundation for modern access architectures.
The point is simply that authentication is one stage in a longer trust lifecycle. The stronger that first stage becomes, the more useful it is to design the rest of the lifecycle with the same level of care.
The Ariovis perspective
A passkey is not interesting simply because it removes a password. It changes how proof of identity is established.
For us, understanding that mechanism is more useful than treating passwordless as a product feature. Authentication architecture should combine the appropriate cryptographic proof, user verification and contextual signals according to the risk of the journey.
The objective is not to make every authentication invisible. It is to avoid unnecessary friction when confidence is already sufficient, and require stronger proof when the context justifies it.
Related services
Go deeper: authentication is part of our IAM training
Our IAM training covers authentication mechanisms, public-key cryptography, FIDO2, Access Management and the distinction between explicit, implicit and calculated authentication signals.
Explore our IAM training →Common pitfalls
- A common oversight is ignoring account recovery, enterprise lifecycle management, and cross-device portability requirements.
Standards and protocols
- FIDO Alliance
- W3C WebAuthn
- FIDO2/WebAuthn
- CTAP2
Explore this category
Continue exploring modern authentication
Understand the credential
Strengthen the authentication
Thinking about deploying passkeys?
Understanding the technology is the easy part. Deploying it across a real information system raises a different set of questions.
Which populations should move first? Which applications already support modern authentication? What happens to legacy applications? How will users recover their accounts? Which authentication methods remain available during the transition? How should sessions and sensitive actions be handled after login?
This is where a passkey project becomes an authentication architecture project.
Is your authentication architecture ready for passkeys?
Review six areas before defining a passwordless trajectory.
No email, no form: your answers stay in your browser and are not sent anywhere.
Turn passkey interest into an authentication roadmap
We help organisations assess their current authentication architecture, identify realistic passwordless use cases and define a progressive target covering users, applications, enrolment, recovery, sessions and access policies.
The objective is not to replace technology for the sake of it. Existing capabilities should be understood first, then retained, extended or changed according to the target journeys.
Start with the authentication journey, not the product
A passwordless project should not begin with the assumption that the organisation needs to replace its identity platform.
The first questions are about users, applications, risk, enrolment, recovery, sessions and operational constraints. Existing capabilities may already cover part of the target.
Technology choices come after the authentication journeys and architecture have been understood.