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 also clarifies what synced passkeys are, what hardware bound passkeys are, why older security keys are not the same as passkeys, and why the distinction matters when choosing a stronger sign in method.

You can also read the full explanation below.

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.

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.

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.

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 hardware bound passkeys. That is where much of the confusion begins.

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.

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.

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 hardware bound passkey are often mixed together even though they do not mean exactly the same thing.

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.

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 hardware bound passkeys is that synced passkeys can become available across more than one authorised device, while hardware 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 makes day to day use and recovery 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.

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 hardware bound passkeys or device bound passkeys.

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.

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 hardware 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.

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

Modern FIDO2 capable YubiKeys can be used to store hardware bound passkeys. Older keys may only support second factor authentication and may not support passkey storage. This is why the model and standards support matter.

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.

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.

Hardware 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.

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 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.

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.

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.

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.

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.

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.

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, hardware 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.

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.

The following sources may be useful if you would like to explore the standards, terminology, and real world examples in more detail.

Google: Security Keys Neutralized Employee Phishing

The mechanics of a sophisticated phishing scam and how we stopped it

What is a Passkey?

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
29 March 2026