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:
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?
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:
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:
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.
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:
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.
Consider a normal phishing email.
You receive something that appears to come from Microsoft:
“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):
login.microsoftonline.com, your browser offers your Microsoft passkey.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.
For years, we've tried to solve phishing partly through awareness:
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.
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.
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.
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:
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.
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).
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.
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:
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.
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:
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:
Passkeys change the attack surface. They don't remove the need for monitoring it.
Compare what happens during common cyberattacks when an account is protected by a traditional password versus a cryptographic passkey:
Select an attack scenario to see how traditional passwords compare with passkey cryptography:
Because passwords have a fundamental usability problem.
We're asking people to create secrets that are:
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.
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:
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.
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:
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.
The technical standards, cryptographic specifications, and identity guidelines referenced in this episode are grounded in documentation from the W3C, FIDO Alliance, NIST, and CISA:
Have a question or a suggestion? Prepare an email below. Feedback is private and is sent only when you press Send in your email app.
Likes and claps are your personal reactions on this device.
You can also email Poorna directly.
Your feedback stays private. Nothing is sent from this page automatically.