Passkeys are the future of signing in. Here's how they work.

This is the first in a series on passkeys, written to help non-identity administrators get familiar with passkeys, what they do, and their importance in the future of IT.

My mother, who is not a technology person, often asks what I do for a living, and I have to find a way to explain technical things in a non-technical way. She recently asked me about passkeys, and I approached it by explaining passwords.

For as long as there have been accounts, passwords have been how you prove you're you. Because you can’t show your ID to a website, we settled on a secret passphrase instead. It worked well enough for a long time.

It doesn't anymore. People reuse the same password across dozens of sites, so one breach unlocks all of them. Passwords get typed into convincing fake login pages. And for anyone running IT, they generate an endless queue of reset tickets. We've made passwords longer, stranger, and more annoying, and attackers have kept up anyway.

Enter passkeys.

Wait, there’s something even more secure?

As a matter of fact, yes. Passkeys are far more secure and usable in proving who you are to any application that asks for it. But, more secure means harder to use, no? I keep hearing that a longer password is more secure, but it makes it so much harder to remember!

Stick with me here, mom. Passkeys are based on public-key cryptography, which means there are actually two keys: a private key that only you have and can use, and a public one that anyone can.

They are unique to each application, so you don't have to worry about someone using your passkey to access other services. And unlike passwords, device-bound passkeys (the kind Iru uses) are impossible to share. There's nothing to type, read aloud, or copy. No more phone calls trying to trick you into sharing a password!

Passkeys are a form of multi-factor authentication (MFA). As a quick reminder, MFA is a security process that requires two or more proofs of identity before letting you log into an account or system. Passkeys cover both. The passkey itself, that private key on your device, is the first proof. Unlocking it is the second, and you do that with:

• Biometrics: Fingerprint scans or facial recognition (like Face ID or Windows Hello)
• Device PIN or pattern: A numerical code or swipe pattern used to unlock your phone or computer

Proving your identity

Think of them as two separate physical keys that work on a different side of the same lock. When you use a passkey to log into a site, you give the site your name and it sends the identification request back. The identification request comes with the aforementioned lock.

When your computer receives the request, it uses the private key to initially secure the lock. Once secured, your computer sends the request back to the website. The site then uses the public key to release the lock, thereby proving you are you.

This works because only the private key could lock it in the first place, and the paired public key can unlock it. If you weren’t who you say you are, your device would have been unable to lock the request, thereby stopping the login. Still following?

Further, these passkeys are associated with the specific service they are registered with. This means, for example, a passkey created for Notion can only be used with Notion. This specificity enables passkeys to be phishing resistant (look out for part 2, where we explain this in more detail).

As secure as it gets

Of course, this is radically simplified, but what I am describing is a process where a private key is used to digitally sign a nonce, and a public key is used to validate the signature and prove identity. No secret information, like a password, is ever passed back and forth in this transaction (or even needed). That's the whole protocol, and it's the reason passkeys are phishing-resistant rather than merely phishing-aware.

For you, the practical upshot is this: there's nothing for your users to create, nothing for them to remember, and nothing for you to reset.

Iru Identity binds passkeys to a trusted, managed device, so the "something you have" factor is a Mac you already control. That's passwordless MFA without a second app, a hardware token, or another thing to lose.

Part 2 looks at what's wrong with passwords and traditional MFA, and why passkeys are both more secure and easier to use. Until then, if you'd like to see passwordless MFA running on a managed Mac, book a demo.