Are passkeys and security keys the same thing?

Passkeys and security keys are related, but they are not the same thing. This causes confusion because the same YubiKey or built in device authenticator may be described in different ways depending on how it is being used.

This guide explains the difference in plain language. It outlines what passkeys are, what security keys are, where FIDO2 fits in, what synced and device bound passkeys mean, and why the distinction matters when choosing a stronger sign in method.

Watch the short video version of this guide

passkeys vs security keys video placeholder

You can also read the full explanation below.

Browse this guide

This guide explains the difference between passkeys and security keys, how they relate to FIDO2, what synced and device bound passkeys mean, and how these choices affect security and recovery.

Use the links below to jump to the sections most relevant to your question.

The short answer

No. A passkey is not the same thing as a security key.

A passkey is a sign in credential used for passwordless authentication. A security key is a physical device used to help prove that the person signing in is really the authorised user. Some modern security keys can store passkeys, but not all of them can.

This is one reason the terms are often mixed together. A YubiKey can be a security key, a place to store passkeys, or both, depending on the model and how it is configured.

What a passkey actually is

A passkey is a modern sign in credential based on public key cryptography. Instead of typing a password, the service checks whether your device can prove that it holds the correct private key.

In simple terms, a passkey is something used to sign in, not a product you buy. It is the credential itself. The credential is normally released only after you unlock the device or authenticator holding it, for example with a PIN, fingerprint, face recognition, or a physical touch.

Each passkey is built around a public key and a private key.

A passkey is also not the same thing as a password. A password is a secret the user types into the website or app. A passkey works differently, because the important secret stays on the user’s device or authenticator and is not handed over in the same way.

What public and private keys are, and what a cryptographic key looks like

In this context, a key does not mean a physical key. It means a piece of digital information used by a security system.

A cryptographic key is not usually something meaningful to a person. If you could see one, it would normally appear as a long string of letters, numbers, and symbols, or simply as a block of data stored by software. It is usually generated automatically by the device, browser, app, or authenticator rather than chosen by the user.

That does not mean it is a hidden message waiting to be read. It is better to think of it as a digital value that the system uses in a security process. Its job is not to make sense to a person. Its job is to let the device or service perform the correct security action.

A passkey is built around two linked keys called a public key and a private key.

The public key is the part that can be shared safely with the website or online service. The service stores it on record for that account.

The private key is the secret part that stays on the user’s device or authenticator. It is not shared with the service. That is why it is called private.

The easiest way to picture this is to imagine a secret stamp in a children’s game.

The private key is like the secret stamp that stays with the child. The child does not hand the stamp to the teacher.

The public key is like the teacher’s safe checking reference. It lets the teacher recognise whether the correct secret stamp was used, without needing to hold the secret stamp itself.

When the child is asked to prove they still have the correct stamp, the teacher gives them a fresh blank card. The child stamps the card and gives it back. The teacher checks the result against the safe reference.

If the stamped result is correct, the teacher knows the child has the right secret stamp. If the result is wrong, the check fails.

That is very similar to what happens when a passkey is used for sign in.

The website or service sends the device a fresh challenge. The device answers that challenge using the private key stored on it. The service then checks that answer using the public key it already has on record.

If the answer matches what the service expects, the service knows the correct private key is present. The important point is that the service can validate the answer without receiving the private key itself.

This is one of the main differences from a password. With a password, the user types the secret directly into the website or app. With a passkey, the important secret stays on the device or authenticator and is used only after local approval, such as a PIN, biometric unlock, or touch.

That is one of the main reasons passkeys are stronger than ordinary passwords. The most important secret stays with the user’s device or authenticator instead of being typed into the service each time.

What a security key actually is

A security key is a physical authenticator. It is usually a small USB, USB C, NFC, or Lightning device that you can carry with you and use during sign in.

Some security keys are older second factor devices and do not store passkeys. They are mainly used as an additional authentication factor after a password has already been entered. Some newer FIDO2 capable security keys can also store device specific or device bound passkeys. That is where much of the confusion begins.

A hardware security key does not automatically mean passkeys are being used. The same physical key may sometimes be used for older second factor methods, one time codes, smart card related functions, or FIDO2 passkeys, depending on the service, the protocol, and the way the key has been configured.

Why this page uses YubiKeys in its examples

We use YubiKeys in the examples on this page because they are the hardware security keys we have used directly when preparing and reviewing this guidance.

Some of the practical observations on this page are based on direct use of our own YubiKey devices, including the models, firmware, and application settings in use during testing. Behaviour may differ between security key vendors, between YubiKey models, between firmware versions, and between platforms or applications.

Other hardware security key vendors are also available, and the same general principles may apply depending on the standards and features supported by the device.

If you want a more detailed guide on how YubiKeys fit into Microsoft Intune and Microsoft Entra ID, including attestation, AAGUID restrictions, Conditional Access, and rollout planning, see our guide on How YubiKeys work and how to configure them in Intune and Entra ID.

That is why this guide uses YubiKeys as practical examples rather than as a claim that only one vendor or one hardware family can support these standards.

Why people mix up passkeys and security keys

The confusion usually happens because people describe the same sign in process from two different angles.

One person may focus on the credential and say they are using a passkey. Another may focus on the physical device and say they are using a security key. Both may be looking at the same sign in event, but they are describing different parts of it.

This is why a clear distinction helps. A passkey is the credential. A security key is the device that may hold or protect that credential.

The confusion becomes greater when the same hardware key may be used in different ways depending on the standards it supports and how the account is configured. That is why terms such as passkey, security key, FIDO2 key, synced passkey, and device bound passkeys are often mixed together even though they do not mean exactly the same thing.

Where FIDO and FIDO2 fit in

FIDO stands for Fast IDentity Online. It is the name used for a family of open authentication standards designed to reduce reliance on passwords and support stronger sign in methods. FIDO2 is the modern standard used for passwordless sign in, including passkeys. In simple terms, FIDO is the wider standards family, while FIDO2 is the modern part most people mean when they talk about passkeys and newer passwordless sign in today.

FIDO2 helps explain why passkeys and some newer hardware security keys are related. When a hardware key supports FIDO2, it may be capable of storing and using passkeys. When a key does not support FIDO2, it may still be useful for stronger authentication, but it should not automatically be described as a passkey device.

This is another reason the wording matters. Saying that all security keys are passkeys would be inaccurate. Saying that some FIDO2 capable security keys can store passkeys is more precise.

What synced passkeys are

Some passkeys are designed to move between a user’s devices through a cloud based account ecosystem such as Apple, Google, or Microsoft. These are commonly called synced passkeys.

One of the main distinctions between synced passkeys and device bound passkeys is that synced passkeys can become available across more than one authorised device, while device bound passkeys stay tied to one registered device or authenticator.

They are convenient because a passkey created on one authorised device may also become available on another authorised device linked to the same account. This often makes day to day use and some recovery scenarios easier for many people, especially in lower risk consumer scenarios.

The trade off is that the private key is no longer limited to one single physical authenticator in the same strict sense. For many users this is an acceptable and practical balance, but it is important to understand that convenience and assurance are not always the same thing.

That convenience also affects recovery, because access may still be possible from another authorised device in the same ecosystem if one device is lost, replaced, or stops working.

What happens if a synced passkey device is replaced or stops working

If a user relies on synced passkeys, access may still be possible from another authorised device linked to the same account ecosystem, such as Apple, Google, or Microsoft. In many cases, the user can still sign in from that other authorised device and then create or enrol a passkey on the replacement device.

This is one of the practical differences between synced passkeys and device bound passkeys. With synced passkeys, recovery may be easier because the passkey can become available across more than one authorised device. With device bound passkeys, access depends more directly on the specific registered authenticator that holds the credential.

The exact recovery path still depends on the service, the platform, and what other sign in or recovery methods remain available on the account. It is better not to assume that every service will offer the same fallback options in every situation.

In simple terms, synced passkeys can make replacement and recovery easier because another authorised device may still allow sign in, while security key only sign in depends more heavily on having the registered key or a backup key available.

What device bound passkeys are

Other passkeys stay tied to one specific device or one specific hardware authenticator and are not copied across devices through cloud syncing. These are often called device bound passkeys. In some cases they are stored on a built in device authenticator, and in other cases they are stored on a physical security key.

This model is usually better suited to higher assurance environments because access depends on the physical device or authenticator that was registered in advance. If that device is not present, the passkey cannot simply be pulled from a synced cloud store on another device.

That stronger binding usually improves control and resistance to remote compromise, but it can also make enrolment, recovery, and day to day flexibility less convenient.

Why the wider terminology still causes confusion

The terminology is still unsettled in everyday use, and vendor language is not always introduced in a reader friendly order. People often hear about passkeys, discoverable credentials, FIDO2 keys, synced passkeys, device bound passkeys, and hardware tokens as if they were all interchangeable.

They are not interchangeable. They overlap, but they do not mean the same thing.

The simplest way to understand it is this. Start by asking where the credential lives. If it can move between devices through a cloud account, it is a synced passkey. If it stays on one registered device or one hardware authenticator, it is a device bound passkey. If the device is simply helping with a second factor after a password, it may be a security key without being a passkey at all.

Can a YubiKey store passkeys

Yes, some YubiKeys can store passkeys, but not every hardware security key can do this.

Modern FIDO2 capable YubiKeys can be used to store device bound passkeys. In that case, the credential is bound to the physical key itself rather than being synced across a cloud account to several authorised devices.

Older keys may only support second factor authentication and may not support passkey storage. This is why the model, firmware, and standards support matter. If the passkey is stored on a physical security key, the user can still carry that key between compatible computers or phones, but the credential itself remains tied to that authenticator rather than being synchronised through a cloud account.

In practice, this means a YubiKey may be used in more than one way. It can act as a second factor, as a place to store a passkey, or as both depending on the account, the service, and the capabilities of the key.

Which option is more secure in different situations

That depends on the environment, the risk, and what problem you are trying to solve.

Synced passkeys are often a strong and practical improvement over passwords for everyday users. They improve usability, reduce password reuse, and make phishing harder in many real world situations.

Device bound passkeys generally offer higher assurance because they keep the credential tied to a specific registered device or authenticator. This is often preferable for organisations with stricter security requirements, privileged accounts, regulated environments, or a lower tolerance for account recovery risks tied to cloud syncing.

The important point is not that one model is always right and the other is always wrong. The important point is understanding the trade off between convenience and tighter control.

Why passkeys and modern security keys are called phishing resistant

Passkeys and modern FIDO2 security keys are often described as phishing resistant authentication methods because they are designed to avoid one of the biggest weaknesses of passwords and one time codes. With older sign in methods, a user can often be tricked into typing a secret into the wrong place. With passkeys, the sign in process is based on a cryptographic key pair, and the credential is tied to the real website or service domain. That means the user is not handing over a reusable password that can simply be collected and replayed later.

A passkey uses a public key and a private key. The public key is registered with the service, while the private key stays on the user’s device or authenticator. This is also why passkeys are often described as phishing resistant: the private key stays on the user’s device or authenticator, works only with the legitimate site or app, and is only used after local user approval such as a PIN, biometric unlock, or touch. Because the private key is not typed into a website and is not shared with the service in the same way as a password, the sign in method is much harder to phish.

This does not mean every other risk disappears. It means the authentication step itself is far more resistant to common phishing attacks than passwords, SMS codes, or other older methods. That is why organisations such as Microsoft and CISA recommend phishing resistant authentication for higher risk accounts and environments.

Real incidents that show why phishing resistant methods matter

Real incidents help show why phishing resistant authentication matters in practice. In Google’s well known deployment of hardware security keys for employees, Brian Krebs reported that the company saw no successfully phished work related employee accounts after requiring physical security keys.

Cloudflare also described a 2022 phishing campaign in which some employees entered credentials into a fake site, but the attacker could not complete the login because the FIDO security keys were bound to the legitimate service and would not authenticate to the phishing domain.

This does not mean every other risk disappears, but it does show why strong origin bound authentication materially changes what a phishing attacker can achieve. Microsoft’s Digital Defense Report also explains that passkeys are phishing resistant because the private key stays on the user’s device, works only with the legitimate site or app, and requires local user approval such as a PIN or biometric unlock.

Why this still matters if session cookies are stolen

Even when the sign in method is strong, a user can still face risk after sign in if an attacker steals a live session token or session cookie from the device. Microsoft describes token theft as an attack where a threat actor replays a token that was already issued to a user, even after that user has completed multifactor authentication.

In practical terms, the attacker is not stealing the passkey itself at that point. They are stealing proof of an already authenticated session. This matters because attackers increasingly try to bypass strong sign in controls by stealing tokens or session cookies after authentication, rather than by defeating the passkey itself.

A simple way to picture this is to think of sign in and session access as two different stages. The passkey helps protect the front door by making the sign in much harder to phish. A stolen session cookie is more like someone stealing a valid visitor badge after the person is already inside. The badge may then be replayed to gain access without repeating the original sign in challenge. Microsoft and CISA both describe cookie or token theft as a real way attackers can bypass protections that were satisfied earlier in the sign in process.

That is one reason passkeys and security keys should be seen as part of a wider security model rather than a single complete answer. They make phishing much harder at login, which is extremely valuable, but device security, browser security, session protection, and sensible account controls still matter after the user has signed in.

Practical points when using hardware security keys

Passkey behaviour is not identical across all services. The sign in choices, fallback options, and recovery steps available to the user may differ depending on the account provider and the platform involved.

If hardware security keys are being used for important accounts, it is common to register more than one key. One key is usually carried for day to day use, while a second key is stored safely as a backup. This reduces the risk of losing access if the main key is lost, damaged, or misplaced.

Keeping at least two registered security keys can be sensible in case one is lost or damaged, especially where access to important accounts depends on physical possession of the key.

This is different from the recovery model often seen with synced passkeys. If a passkey is stored only on a physical security key or other device bound authenticator, access may depend on that registered authenticator being available. If it is lost, damaged, reset, or unavailable, the user may need a second registered security key or another approved recovery method that was set up in advance.

A common question is what happens if a key is forgotten while travelling or left at home. In a higher security model, that inconvenience is part of the design. If the account requires the registered key, access may not be possible unless another approved recovery method or backup key has already been set up. The strength of the method comes partly from the fact that physical possession of the registered authenticator matters.

This is one reason it is important not to confuse convenience with control. Synced passkeys may make account recovery and device replacement easier, while device bound passkeys usually give stronger physical control but can make recovery more dependent on preparation in advance.

Some hardware security keys can also be protected locally with a PIN, depending on the feature being used. This means possession of the key alone may not always be enough. The user may also need to know the correct local PIN before the key can be used, which adds another layer of protection if the key is lost or misplaced.

A related point on some YubiKeys is that different applications on the same key use different protections. The OATH application can be protected with an OATH password in Yubico Authenticator so that stored one time password accounts cannot be viewed or used without unlocking that feature first. Passkeys, by contrast, use the separate FIDO2 application on the YubiKey. When a passkey sign in asks for a PIN, that is typically the FIDO2 PIN used for User Verification, not the OATH password. Yubico also provides an alwaysUV setting for FIDO2, which can make the key prompt for user verification on every authentication and registration.

A related point on some YubiKeys is that the same key can support more than one authentication function. One example is the OATH application, where OATH stands for the Initiative for Open Authentication. This includes one time password methods such as TOTP, meaning Time based One Time Password, and HOTP, meaning HMAC based One Time Password. These are one time code methods, not passkeys. The OATH application can be protected with an OATH password in Yubico Authenticator, while passkeys use the separate FIDO2 application on the YubiKey.

This distinction matters because people sometimes see a key prompting for a code, a PIN, or an app unlock and assume it is all the same security system. It is not. One time password methods such as TOTP and HOTP are not passkeys, even when they are stored on the same physical key.

This reflects the wider passkey model, where the private key stays on the device and is only used after the user unlocks it locally with a PIN or biometric method.

Passkey behaviour is not identical across all services, platforms, browsers, security keys, or firmware versions, so the exact prompts and recovery options a user sees may vary.

Practical guidance

If the goal is simpler sign in for personal use across several devices, synced passkeys may be a sensible and practical option. If the goal is stronger control for important accounts, privileged users, or more security sensitive environments, device bound passkeys deserve serious consideration.

The best choice depends on what is being protected, how recovery should work, and whether convenience or stronger physical control matters more in that setting. The most useful first step is to be clear about the terminology, because many misunderstandings begin before the real decision has even been identified properly.

For business use, it is sensible to review authentication in the context of the wider environment, including device security, recovery processes, account roles, and how access is managed over time. In business environments, the right choice is often shaped as much by recovery and account administration as by the sign in method itself.

For business use, it is also important to separate questions about the sign in method from questions about device management, identity policy, recovery planning, and access control, because those are related but not identical decisions.

What this technology does not mean

Passkeys and modern security keys greatly improve the sign in process, but they do not remove every other risk around a signed in session, a compromised device, or insecure recovery methods. They improve authentication significantly, but they still sit inside wider systems involving devices, cloud accounts, recovery methods, users, and policies.

A security key does not automatically mean passkeys are being used. A passkey does not automatically mean a hardware key is involved. And a move away from passwords does not remove the need for sensible account management, secure devices, and layered security.

This is not a permanent checklist. Technology, platform behaviour, recovery options, and security controls continue to evolve, so authentication choices should be reviewed over time as part of a wider layered security approach.

It also does not mean every Windows sign in scenario works in the same way, because local accounts, Microsoft accounts, and Microsoft Entra managed sign in are different models.

Using passkeys, security keys, Intune, or Microsoft Entra does not mean every password path disappears from every Windows sign in scenario. Microsoft states that Conditional Access authentication strengths are evaluated only after the initial authentication, so they do not stop a user entering a password at the first sign in prompt. Microsoft also states that Windows Passwordless Experience does not affect the initial sign in experience or local accounts, and does not prevent password use through the Other user option on the lock screen.

Further Guidance and Support

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
17 April 2026