Series Part of Cybersecurity for Everyone · Episode 06 of 10
View 10-Part Syllabus →
Episode 06 · Authentication & Public-Key Cryptography · October 1, 2026 · 7 min read

Are Passkeys Finally Going to Kill Passwords?

PRIVATE KEY 1. CHALLENGE 2. SIGNED PROOF WEB SERVICE PUBLIC KEY pk_secp256r1 AUTHENTICATED No Password Stored FIDO2 / WebAuthn: Phishing-Resistant · Zero Shared Secrets
Episode 06 Passkeys FIDO2 & WebAuthn Public-Key Crypto Phishing Resistance · 7 min read
💬 Feedback
0
Shared Secrets
Private key stays locked in local hardware; nothing for phishers to steal
>80%
Breach Infiltration
Data breaches involving stolen or reused credentials according to Verizon DBIR
Origin-Bound
Protocol-Level Defense
Browser verifies destination domain before providing cryptographic proof

Passwords have been around for so long that most of us don't really question them anymore.

Create an account. Make a password. Forget the password. Reset it. Get told the new password needs an uppercase letter, a number and a special character.

Then try to remember which version you used.

You sit down at your desk or pick up your phone, brace yourself for the usual obstacle course, and then notice another option appearing on Google, Microsoft, Apple, GitHub and other services:

Create a passkey
Sign in securely using Face ID, fingerprint, or screen lock on this device.
Continue →

Instead of typing a password, you might unlock your phone with Face ID, use your fingerprint, Windows Hello or your device PIN.

A checkmark flashes. You're in.

It feels almost too simple.

If you've spent the last twenty years being told that cybersecurity requires friction, complexity, and memorisation, your immediate reaction is probably skepticism: “Wait, is that really it? How can that be safe?”

But underneath that simple login is a completely different approach to authentication — and one that could eventually make passwords far less important.

So what exactly is a passkey, why is it considered more resistant to phishing, and does it really mean passwords are on their way out?

What Exactly Is a Passkey?

A passkey isn't just a password stored on your phone.

Traditional passwords rely on a shared secret. You know the secret. The website knows the secret (or stores a mathematical hash of it). Every time you log in, you transmit that secret across the internet to prove who you are.

Whoever knows the secret can impersonate you. If an attacker intercepts it, tricks you into typing it on a fake page, or steals it from a breached database, your account is compromised.

Passkeys throw out the shared secret model entirely. They use asymmetric public-key cryptography, built on the open FIDO2 and W3C WebAuthn standards.

When you create one, two related cryptographic keys are involved:

🌐 The Public Key
Stored openly on the servers of the service you're signing into. It is not a secret. Anyone can see it, and compromising it does not give an attacker your login credentials.
🔒 The Private Key
Remains permanently under the control of your device's dedicated security chip (like Apple Secure Enclave, Google Titan M2, or a Windows TPM) or passkey provider. It never leaves the device.

When you sign in, the service sends a challenge — a random mathematical puzzle.

Your device uses the private key to sign the challenge and prove that it has the correct credential. The server uses your public key to verify that signature.

The private key itself doesn't need to be sent to the website.

From the user's side, however, most of this is invisible. You might simply see:

“Use Face ID to sign in”

You approve it, and you're in.

That's one reason passkeys are interesting. The technology underneath is stronger, while the experience can actually be simpler.

Face ID Isn't Your Passkey

This is worth clearing up because it's easy to misunderstand.

If you use Face ID, a fingerprint or Windows Hello when signing in with a passkey, your biometric information isn't becoming your website password.

The biometric check normally happens locally on your device.

It's authorising the device to use the passkey.

A simple way to think about it is:

Passkey = your cryptographic credential (locked in the hardware enclave)
Face ID / fingerprint / PIN = how you unlock that credential locally

The website doesn't need to receive your fingerprint or a picture of your face. It only receives a cryptographic signature proving that the challenge was solved.

TRADITIONAL PASSWORDS ⚠️ Transmits Shared Secret "MySecretP@ssword2026" Vulnerable: Interception & Phishing ✗ Whoever tricks you into typing it owns your account. PASSKEY ARCHITECTURE 🔒 Challenge Signed Locally Private Key NEVER Leaves Chip Phishing-Resistant by Protocol ✓ Zero credentials transmitted across the network.

Where Passkeys Become Really Interesting: Phishing

Consider a normal phishing email.

You receive something that appears to come from Microsoft:

Urgent Security Notification

“Your Microsoft 365 session has expired. Sign in again to continue.”

You click the link.

The website looks convincing.

Microsoft logo. Familiar colours. Normal-looking login page. HTTPS.

But the domain isn't actually Microsoft's.

With password authentication, the attacker's goal is straightforward: Get you to enter your username and password.

Once you've entered them, you've potentially handed over a reusable credential.

Passkeys change that.

A passkey is associated with the legitimate website or service for which it was created. It isn't a secret that you can simply type into another website.

A fake Microsoft page can copy Microsoft's appearance.

It can copy the logo.

It can copy the login screen.

It can even have HTTPS — as we discussed in Episode 05.

But copying the appearance of Microsoft doesn't give that website the cryptographic identity of Microsoft.

When a web page asks to authenticate with a passkey, the request is handled by your browser and operating system, not by the web page itself.

The browser checks the exact domain in the address bar (the Relying Party identifier):

  • If you are on login.microsoftonline.com, your browser offers your Microsoft passkey.
  • If you are on microsoft-account-check.example, the browser sees the domain mismatch. It will not offer the passkey.

And because you don't know the private key yourself — it is a 256-bit mathematical string inside a chip — you cannot be tricked into typing it into the phishing box even if you want to.

That's one of the reasons passkeys are considered phishing-resistant.

This Removes One of Our Biggest Human Problems

For years, we've tried to solve phishing partly through awareness:

Check the URL
Don't click links
Spot spelling errors
Verify authenticity

Those are still useful habits.

But humans make mistakes.

People check emails while travelling, working, talking to someone else or looking at a phone screen for a few seconds.

Security works better when it doesn't depend entirely on someone noticing one incorrect character in a domain name.

Passkeys move part of that responsibility into the authentication technology itself.

That's an important improvement.

They Also Deal With Password Reuse

There's another very common problem.

You create a good password. Then you use it somewhere else. And eventually it ends up protecting several accounts.

If one service is breached and credentials are exposed, attackers can try those credentials against other services. This is credential stuffing.

It works because passwords are reusable secrets.

Passkeys largely remove that particular behaviour because the credential is specific to the service.

You aren't creating one memorable secret and then deciding whether to reuse it.

Each service gets its own cryptographic credential.

That means there isn't one password that can be stolen from one service and then automatically tried against ten others.

What Happens If a Website Is Breached?

Passkeys also change what's stored on the service side.

With conventional passwords, responsible services should store password hashes rather than plaintext passwords. But stolen password databases can still be valuable to attackers, particularly when weak or reused passwords are involved.

With passkey authentication, the service stores the public key.

The private key needed to authenticate remains under the control of the user's authenticator or passkey provider.

And the public key isn't supposed to be secret.

So compromising the server-side public key doesn't give an attacker the equivalent of your private authentication credential.

That's a very different security model from passwords.

But Passkeys Don't Solve Everything

This is where some of the discussion around passkeys becomes misleading.

Passkeys can significantly improve authentication security. That doesn't mean they eliminate account takeover.

Suppose your account supports a passkey but also has:

  • “Use password instead”
  • “Send verification code via SMS”
  • An insecure automated account recovery process

An attacker doesn't necessarily need to attack your passkey.

They may look for another route into the account.

This is particularly important for organisations. There's little benefit in deploying extremely strong phishing-resistant authentication if an attacker can bypass it through a poorly protected recovery process.

The entire authentication lifecycle matters, not just the login button.

What If You Lose Your Phone?

This is probably one of the first practical questions people have about passkeys.

Passkeys don't necessarily exist on only one physical device.

Depending on the implementation, they can be synchronised through a passkey provider (such as Apple iCloud Keychain, Google Password Manager, or 1Password) and made available across a user's devices.

There are also device-bound approaches where the credential remains strictly associated with a particular physical authenticator (like a hardware security key).

☁️ Synced Passkeys (Multi-Device)
End-to-end encrypted and synced across your ecosystem. If you lose your phone, you restore them via your Apple ID or Google Account.
🔑 Device-Bound (Hardware Keys)
Permanently locked to a physical security key (like a YubiKey). Highest assurance against cloud compromises, but requires a physical backup key.

For normal users, synchronisation makes passkeys much more practical.

But recovery still matters.

If you lose access to your devices and your passkey provider, you need a secure method of getting back into your accounts. And whenever a recovery process exists, attackers may try to target it.

What About Session Stealing?

This is where Episode 04 connects directly with passkeys.

A passkey protects the authentication process.

But once you've successfully authenticated, a website will usually establish a session so you don't need to authenticate again every time you open another page.

If an attacker compromises your device and manages to steal usable session material, that's a different problem.

They haven't necessarily stolen your passkey.

They may be targeting the authenticated session created after the passkey did its job.

So passkeys don't eliminate:

  • Malware
  • Infostealers
  • Malicious browser extensions
  • Session hijacking
  • Compromised endpoints

This distinction matters.

Passkeys make credential theft much harder. They don't make every account-takeover technique disappear.

A stronger front door doesn't automatically secure everything happening inside the house.

Now Look at It From a SOC

Imagine a user receives a phishing email containing a fake Microsoft login page.

From the SOC (Security Operations Center) side, we might have several pieces of telemetry:

📧 Email Gateway
Suspicious link delivered to employee inbox.
🌐 Web & DNS Filter
Connection to a newly registered lookalike domain.
💻 Endpoint EDR
Browser navigation and script execution on the URL.
🆔 Identity Provider
Authentication requests following the visit.

With traditional password authentication, one major concern is whether the user submitted credentials and whether those credentials were subsequently used.

With a properly implemented passkey, that part of the attack becomes much harder because the phishing site can't simply collect a reusable password.

But the investigation doesn't end there.

The analyst would still want to know:

  • Whether anything was downloaded or executed on the endpoint
  • Whether another authentication method (like password fallback) was attempted
  • Whether account recovery settings were altered
  • Whether unusual session or token activity followed

Passkeys change the attack surface. They don't remove the need for monitoring it.

Interactive Authentication & Attack Inspector

Compare what happens during common cyberattacks when an account is protected by a traditional password versus a cryptographic passkey:

🛡️ Passkey vs. Password Threat Inspector

Select an attack scenario to see how traditional passwords compare with passkey cryptography:

So Why Is the Industry Moving Towards Them?

Because passwords have a fundamental usability problem.

We're asking people to create secrets that are:

  • Long enough to be secure
  • Unique for every single account
  • Difficult to guess
  • And somehow easy to remember

Password managers have helped enormously with this problem, and MFA adds another important layer.

But passkeys take a different approach.

Instead of trying to make people better at managing passwords, they reduce the need for people to manage passwords at all.

And importantly, convenience doesn't necessarily come at the expense of security.

Signing in with Face ID can be easier than typing a password while also being considerably more resistant to traditional credential phishing.

That's an unusual combination in cybersecurity.

Are Passwords Actually Going to Disappear?

Probably not anytime soon.

There are simply too many existing systems built around them.

Legacy applications, older websites, business systems, recovery processes and devices aren't going to change overnight.

For some time, we'll probably continue seeing a mixture of:

• Password only (older, declining systems)
• Password + MFA (the current common baseline)
• Password or Passkey (the current bridge phase)
• Passkey default (rapidly growing for modern services)

The more interesting question isn't whether every password disappears.

It's whether passwords stop being the default way most people authenticate.

That transition has already started.

So, Are Passkeys Finally Going to Kill Passwords?

Maybe — but probably very slowly.

Passwords have survived decades of attempts to improve authentication.

Passkeys are different from many previous authentication improvements because they don't simply add another security layer on top of a password.

They can remove the password from the authentication process altogether.

That's the important part.

The future of authentication may not depend on people creating increasingly complicated passwords and becoming increasingly good at spotting fake login pages.

Instead, your device can cryptographically prove that it holds the correct credential for the correct service.

Passkeys won't stop every cyberattack.

They won't eliminate malware.

They won't eliminate session theft.

And they won't fix weak account recovery.

But they address two of the biggest weaknesses we've lived with for years:

Passwords can be stolen, and people can be tricked into giving them away.

If passkeys continue becoming easier to use and more widely supported, passwords may not suddenly disappear.

We may simply start needing them less and less.

And eventually, that might be enough to make them irrelevant.

Episode 06 — The Takeaway
  • Passkeys replace shared secrets with public-key cryptography. The website holds only your public key; your private key stays locked in local hardware.
  • Biometrics are local gatekeepers, not passwords. Face ID and fingerprints unlock the hardware enclave on your device; biometric data is never transmitted to websites.
  • Phishing resistance is enforced by your browser. A passkey is bound to the genuine domain. A deceptive lookalike domain cannot trigger your authentic passkey.
  • Passkeys secure the front door, not the entire house. They do not prevent post-login session theft via infostealers, nor do they fix weak SMS/email password recovery fallbacks.

Sources & Further Reading

The technical standards, cryptographic specifications, and identity guidelines referenced in this episode are grounded in documentation from the W3C, FIDO Alliance, NIST, and CISA:

🌐
W3C Web Authentication (WebAuthn) Level 3
The official standard defining the API for public-key authentication credentials in browsers, origin binding (Relying Party ID), and authenticator interactions.
Read W3C WebAuthn Specification ↗
🔑
FIDO Alliance — Passkeys Overview
Architectural specifications and security considerations for multi-device credentials, synced authenticators, and hardware security keys.
Explore FIDO Alliance Passkeys ↗
🛡️
CISA — Implementing Phishing-Resistant MFA
Explains why traditional password + SMS/OTP MFA is vulnerable to Adversary-in-the-Middle (AiTM) proxies, and why FIDO2/WebAuthn is considered the gold standard for authentication defense.
Read CISA Phishing-Resistant MFA Guide ↗
📜
NIST Special Publication 800-63B — Digital Identity Guidelines
Detailed requirements for Authenticator Assurance Level 3 (AAL3), verifier impersonation resistance, and cryptographic key management.
NIST SP 800-63B Guidelines ↗
💻
Google Security Blog — The Beginning of the End of the Password
Telemetry and case study documenting consumer passkey adoption, 50% faster authentication speeds, and complete elimination of credential phishing vectors.
Read Google Security Blog ↗
🍏
Apple Platform Security — Passkeys Architecture & Secure Enclave
Technical specification detailing hardware key storage, biometric authorization via Touch ID/Face ID, and end-to-end encrypted iCloud Keychain escrow.
Apple Passkeys Security Guide ↗
🏢
Microsoft Learn — Passwordless Authentication with FIDO2 & Passkeys
Architecture reference covering Windows Hello, hardware security keys, and cross-platform mobile passkey enrollment for cloud directories.
Microsoft Entra Passwordless Docs ↗
📊
Verizon — 2024 Data Breach Investigations Report (DBIR)
Primary industry benchmark analyzing credential compromise rates, identifying stolen and reused credentials as the leading web application attack vector.
Verizon DBIR Report ↗
🔐
Yubico — Threat Modeling for Passkeys: Synced vs. Device-Bound
Technical whitepaper assessing assurance differences between multi-device cloud-synchronized passkeys and physical FIDO2 hardware tokens.
Yubico Passkeys Whitepaper ↗
📐
IETF RFC 9334 — Remote ATtestation ProcedureS (RATS) Architecture
Foundational protocol standard describing cryptographic attestation workflows for hardware authenticators and trusted execution environments.
Read RFC 9334 Standard ↗
Next Episode in Series · Episode 07

The Fake Recruiter in Your LinkedIn Inbox

Not everyone messaging you about an exciting remote opportunity is legitimate. How threat actors weaponize job inquiries, deploy trojanized assessments, and how the SOC investigates.

Read Episode 07 →