Apple, Microsoft, or Google: Who Will Own Your Passkey Future?

November 16, 2025 seanhackacademy

If you have logged into anything recently, you have probably seen the new button that promises a passwordless life. “Use a passkey” appears, you tap it, your phone asks for your face or fingerprint, and somehow you are in. No password, no code from a text, no remembering which version of your dog’s name you used for this site.

Behind that slick experience, something important is happening. The move from passwords to passkeys does not just change how you log in. It quietly hands a lot of power to whoever runs the authenticator that lives on your device. Right now that effectively means Apple, Microsoft, and, in a more complicated way, Google.

We are not just choosing a new login method. We are choosing who sits between us and almost every account we care about.

Why passkeys change the rules

Passkeys are built on public key cryptography. Instead of you sending a secret password to a website, your device proves you are you by using a private key that never leaves your device, while the site holds the matching public key.

The big promises are simple.

The credential cannot be guessed the way a password can.
The same credential cannot quietly be reused on a different site.
You cannot be tricked into typing your passkey into a fake site in the same way you can be tricked with a password.

This matters because people are still terrible at passwords. Even after security training, plenty of users still click on phishing emails and reuse the same weak password across work, banking, and social media. Passkeys are partly an admission of defeat. If we cannot fix human behaviour, we can at least design a system that does not depend on it quite as much.

The catch is that someone has to generate, store, and present those passkeys on your behalf. That “someone” is the authenticator.

What exactly is a platform authenticator?

Authenticator is the umbrella term for the thing that holds your passkeys and uses them when a site asks you to log in.

There are three broad families.

Platform authenticators, built into the device and operating system you already use.
Roaming authenticators, such as hardware security keys you plug in or tap.
Virtual authenticators, often implemented in software or in a browser based password manager.

Standards bodies like the FIDO Alliance and the WebAuthn working group define the protocols that sit underneath all of this. In practice, you do not see those standards. You see the operating system and the browser.

A platform authenticator is the built in one. It talks to the secure hardware on the device, such as the Secure Enclave on an iPhone or the Trusted Platform Module on a Windows laptop. It stores and protects your passkeys and usually syncs them through the vendor’s cloud so you can use the same credential on your phone, tablet, and laptop.

The advantage is obvious. It is already there, it is free, and the user experience is smooth. The downside is also obvious. You are now deeply tied to whoever runs that platform.

Apple: the seamless, all in model

On Apple devices, the platform authenticator is wrapped into iCloud Keychain. If you use Safari on a Mac, iPhone, or iPad and a site offers a passkey, you will see an operating system dialog inviting you to save that passkey in your iCloud account. From then on, Face ID or Touch ID will unlock that credential whenever you need it.

Behind the scenes, the secure hardware in the device helps with randomness and key protection. The actual passkey lives in iCloud Keychain, encrypted and synced across your Apple devices. Crucially, Apple treats all its passkeys as syncable. You do not have to think about which device has which key. If you are signed into your Apple ID and Keychain is on, your passkeys follow you.

That has big benefits for ordinary users and for organisations trying to move staff away from passwords. One passkey per service, available on every Apple device you own, with built in recovery if your phone is lost or destroyed.

It also has big consequences.

Your login life now depends on a single Apple ID and on Apple’s cloud service always being reachable. Moving off Apple platforms becomes harder, because your entire library of passkeys is bound up with Apple’s ecosystem. The ease is real, but so is the lock in.

Microsoft: a more flexible, messier transition

On the Windows side, the picture is more complicated because Microsoft is in the middle of a shift.

Historically, passkeys on Windows were tied tightly to the Trusted Platform Module in each machine. The TPM encrypted the private key, and only that specific chip could decrypt it again. That gave strong device level security, but it also meant the passkey could not be synced across devices. Each Windows device was an island.

More recently, Microsoft has started to move towards a cloud backed model. Using the Edge browser, newer versions now support syncing passkeys across compatible Windows systems, with plans to bring that sync to other platforms over time. Cloud based hardware security modules provide the root of trust for synced keys, while device bound keys still lean on the local TPM.

There is a design choice here that looks very different from Apple’s approach. Windows users will be able to have both syncable passkeys and device bound passkeys, depending on policy and preference. That split may appeal to security conscious organisations that want some credentials to be absolutely tied to a particular machine, while others can roam.

On top of that, Microsoft is turning its authenticator into an operating system service. A Windows app or a non Edge browser like Firefox will be able to ask the OS whether there is a passkey available for a given site, and the OS will handle the ceremony with the user, regardless of the front end. That nudges Windows toward a model where the platform authenticator is not just a feature of Edge, but a shared service inside the OS.

The upside is flexibility. The downside is complexity. Users need to understand which passkeys are where. Developers have to think about different code paths. And Microsoft is still catching up to Apple on the smoothness of cross device syncing.

Google: the browser shaped wildcard

Then there is Google, which straddles both sides of the fence.

On Android, Google provides a built in password and passkey manager that behaves like a platform authenticator. It talks to the device hardware, integrates with the OS, and syncs credentials through your Google account.

In Chrome, the same manager appears as a browser feature across Windows, MacOS, Linux, iOS, and Android. You can save a passkey in Chrome on one machine and use it on another, as long as you are signed into the same Google account.

So is Chrome’s authenticator a platform authenticator or a virtual one? In a sense it is both. On Android it feels like part of the platform. On other systems it behaves more like a portable layer that sits on top of whatever the underlying OS is doing.

For users, the distinction is mostly invisible. What matters is that Google has a credible shot at becoming the default passkey provider simply because Chrome and Android are everywhere. That raises its own questions about concentration of power and the privacy of having so much of your credential life running through a single advertising funded company.

So who “wins” the passkey war?

The answer is probably not a dramatic knockout. Instead, it will be decided by habit and convenience.

People who mostly live in Apple land will drift into iCloud Keychain without a second thought.
Office workers who spend their days in Windows will be nudged into Microsoft’s authenticator as their companies adopt it.
Anyone who treats Chrome as their entire computing world may end up effectively living in Google’s system, regardless of which device they are on.

The real risk is not that one company will destroy the others. It is that we will treat the choice of authenticator as a technical detail instead of what it really is, a strategic decision.

If your passkeys live in one vendor’s cloud, you are trusting that vendor to keep you logged in, to handle recovery correctly, to respect your privacy, and to let you leave if you want to. For enterprises, the stakes are even higher, because the authenticator becomes part of identity and access management for an entire workforce.

How to think about your own passkey strategy

As passkeys become more common, it is worth asking a few simple questions, whether you are an individual or an IT decision maker.

Do I want my passkeys to sync across devices, or should some of them be tied to a single device?
If I lose a device or an account, what is the recovery story? Who controls that process?
Do I need my passkeys to work across different operating systems and browsers, or am I happy to stay inside one ecosystem?
How comfortable am I with this vendor seeing metadata about where and how I log in, even if they cannot see the keys themselves?

There is no single right answer. Apple’s model favours simplicity and tight integration. Microsoft is aiming for more knobs and switches, at the cost of extra complexity. Google is weaving its browser and mobile platform into a cross platform fabric that may quietly wrap around everything.

The important thing is not to let these decisions happen purely by default. Passwords are finally on their way out, and that is a good thing. But what replaces them will shape who really controls our digital identities for the next decade or more.

Photo Credit: DepositPhotos.com