Apple, Microsoft, or Google: Whose platform authenticator rules our passkey future?

Follow ZDNET: Add us as a preferred source<!–> on Google.

ZDNET’s key takeaways

• Passwords are on track to be replaced by passkeys as a more secure login credential.
• There are three types of authenticators: platform, virtual, and roaming.
• Apple, Microsoft, and, to some extent, Google are the main providers of platform authenticators.

Coming soon to a website or application near you (if it hasn’t already) will be the opportunity to login with a passwordless passkey instead of the typical user ID and password. 

The three big ideas behind passkeys are:

• They cannot be guessed (the way passwords can – and often are).
• The same passkey cannot be reused across different websites and apps (the way passwords can).
• You cannot be tricked into divulging your passkeys to malicious actors (the way passwords can).

Also: How passkeys work: Going passwordless with public key cryptography

Why are these three ideas so important? Because we humans are our own worst enemies when it comes to keeping our online accounts secure. According to recent research, 98% of users still clicked on emails that were designed to scam them, despite receiving cybersecurity training that comprehensively covered the risks of poor password hygiene and the threats of social engineering and phishing.

Due to its roots in public key cryptography (see ZDNET’s primer on the role of public key cryptography in making passkeys work), the passkey standard makes it possible to login to a website or app (collectively referred to as the “relying party”) without the need to input your secret (your password) in order to complete the login process. In fact, the passkey standard enables relying parties to eliminate passwords altogether. 

However, once relying parties start to make passkeys available as a login option to their users, those users will need to familiarize themselves with passkeys and how best to utilize them. In addition to reading ZDNET’s six-part series on how passkeys work, it’s important to understand the role of the authenticator during typical passkey workflows (i.e., passkey registration ceremonies and passkey authentications) and what to consider when choosing one or more authenticators (yes, you can work with more than one). 

In this second part of ZDNET’s series on passkey authenticators, I discuss the platform authenticator. 

Platform authenticators: Apple vs. Microsoft (and maybe Google)

The passkey experts interviewed by ZDNET vary in their definition of a platform authenticator, and these differences largely have to do with what exactly constitutes a “platform.” As described in part 1 of this series, a passkey is a FIDO2-compliant credential (governed by the FIDO Alliance). The FIDO2 specification comprises two standards: the World Wide Web Consortium’s WebAuthn standard and the FIDO Alliance’s Client-to-Authenticator Protocol (CTAP) specification. 

The W3’s WebAuthn specification says, “we refer to authenticators that are part of the client device as platform authenticators” and that “authenticators being implemented on-device are called platform authenticators.” Technically, this is referring to situations where a device’s built-in security hardware (the Secure Enclave for Apple devices, Trusted Platform Module for Windows, etc.) plays a role in the passkey creation, retrieval, and authentication processes discussed, respectively, in Part 3, Part 4, and Part 5 of ZDNET’s six-part series on how passkeys work. 

Also: Why the road from passwords to passkeys is long, bumpy, and worth it – probably

Whereas platform authenticators typically rely on hardware to handle certain passkey-related public key cryptography tasks, non-platform authenticators rely on software or hardware that isn’t permanently soldered onto the motherboard of your desktop or mobile computing device. The platform can therefore be thought of as the device, its hardware, and its operating system. 

If software is present that can involve the local security hardware in any public key cryptography tasks associated with creating and securely storing passkeys, that software is essentially considered to be a platform authenticator. To the extent that such authenticators are essentially built into the various operating systems, one main advantage of platform authenticators (and their associated password/credential management capabilities) is their cost: They’re free. 

iCloud Keychain: Apple’s platform authenticator

For example, Apple’s iCloud Keychain is a service built into the MacOS and iOS operating systems for securely storing confidential information such as user IDs, passwords, credit card numbers and, of course, passkeys. Through the operating system, iCloud Keychain interoperates with the security hardware (including Apple’s Secure Enclave) found in all MacOS-based systems and iOS-based devices. 

Also: I’m ditching passwords for passkeys for one reason – and it’s not what you think

The first frame of the GIF screenshot below shows how, at the moment I went to register a new passkey for a website that supports passkeys, the operating system (MacOS) sprang to life with a dialog asking me to enable iCloud Keychain. Once enabled, iCloud Keychain can take on the role of your platform authenticator (if you work with Apple’s platforms). The second frame of the GIF screenshot shows the operating system requesting my biometric information (in my case, Touch ID) to store a newly created passkey in my iCloud Keychain. 

Although Apple’s Secure Enclave hardware plays a randomization role in passkey genesis, passkeys themselves are neither created nor stored in the Enclave (contrary to much of what is written about passkeys on Apple platforms). Instead, each passkey is software-generated and independently encrypted, and stored in the iCloud Keychain, which is then synced to Apple’s iCloud and from there to the user’s other Apple devices.

The distinction between syncable versus non-syncable passkeys is important to consider during an individual or organizational migration to the passwordless technology. 

With user IDs and passwords, a relying party typically provides you with a single set of credentials, regardless of whether you’re logging in through its website or app. No such limitation exists for passkeys. But just because you can enroll multiple passkeys for a given relying party doesn’t mean you should. Keeping track of multiple passkeys can add a fair amount of complexity to your credential management strategy. However, when passkeys are syncable to your other Apple devices the way they are through Apple’s iCloud Keychain, the same passkey (for a specific relying party) can be used as a login credential from any one of those devices. 

Also: Your passkeys could be vulnerable to attack, and everyone – including you – must act

In contrast to syncable passkeys, a non-syncable passkey is one that cannot exist on multiple devices simultaneously after having been synced to those devices through a central cloud. Non-syncable passkeys are bound to a specific device (and are therefore sometimes referred to as “device-bound”). In some cases, this could be a specific computing device, such as a desktop computer or smartphone; in other cases, it could be a roaming authenticator.

Apple’s iCloud can also serve as a recovery hub in case a user needs to recover their Keychain due to device loss, theft, or destruction. 

This moment, when an operating system is governing both passkey creation and storage, is a clear example of where iCloud Keychain and the MacOS operating system are acting together as a platform-based credential manager and FIDO2-compliant authenticator. 

In transition: Microsoft’s Edge-based password manager

In the Microsoft world, the primary example of a platform authenticator involves Windows Edge as the browser-based credential manager, Windows as the operating system, and Windows Hello subroutines as the orchestrators of the user’s authenticator and credential management activities (even when the brand “Windows Hello” does not show up in the user experience). 

The screenshot below shows where I used Microsoft Edge on a Windows 11 Pro-based HP notebook to register a passkey with the relying party PayPal.com. The resulting dialog essentially shows how, at that moment, a “Windows Security” operating system process is engaging the notebook’s Trusted Platform Module (TPM) on behalf of Windows Hello to complete the passkey registration ceremony. In my case, I’ve configured Windows to require a PIN instead of a biometric for TPM-related operations.

–>

At a high level, the passkey registration and storage workflow on Windows is similar to that of Apple’s operating systems. Like Apple’s iCloud Keychain, Microsoft operates a central cloud service through which user IDs and passwords can be synchronized across all supported platforms. However, until recently, passkeys generated using Microsoft Edge could not be synced through the same cloud.

Also: Microsoft Authenticator won’t manage your passwords anymore – or most passkeys

In contrast to how passkeys are mainly software-generated and encrypted on Apple platforms, Windows previously relied on a system’s TPM hardware for encrypting passkeys (after which they’d get stored elsewhere on the local device in a secure file). Once generated, only the TPM that was used to encrypt a passkey could subsequently decrypt it for usage during a passkey authentication ceremony. As such, there was no way to sync them.

<!–>

However, in November 2025, Microsoft began to move towards a more flexible architecture, where passkeys can be synced across any devices running the Edge browser version 142 or later. (Edge runs on Windows 10, Windows 11, Windows Server, MacOS, iOS, Android, and Linux.) However, at the time this article was written, that syncing capability was limited to Windows 10 systems and above, according to a Microsoft spokesperson. That same spokesperson told ZDNET, “We are targeting end of calendar year for iOS and will be subsequently followed on Android and MacOS.” 

Unlike Apple, where all passkeys are syncable, Windows users will have the option of creating both syncable passkeys and device-bound passkeys. Whereas the public/private key pairs associated with device-bound passkeys are tied to the system’s underlying TPM, the Microsoft spokesperson told ZDNET that public/private key pairs associated with syncable passkeys will derive their root of trust from a secure, hardware-backed enclave in Microsoft’s cloud and will be encrypted using Hardware Security Module (HSM)-based keys.  

Also: How to set up and use passkeys across your iPhone, iPad, and Mac

Another key difference in Microsoft’s architecture is that, via a soon-to-be-shipped Windows Password Management plug-in, Microsoft is essentially turning its authenticator into an operating system-offered service. This service, in addition to Edge, can support passkey registration and authentication ceremonies running in the context of Windows-native applications, as well as other browsers, such as Firefox.  

For example, when attempting to use the Windows-native LinkedIn application to authenticate with LinkedIn’s servers, the native application can call the OS service to see if a passkey is available to complete the authentication. Likewise, if that same user wants to login to LinkedIn through Firefox, Firefox can issue a similar call to the service. This architecture is a clear example of how a passkey authenticator can exist as a distinct component in the stack of technologies that collaborate to produce a variety of end-to-end passkey user experiences.

Meanwhile, similar to the Edge component of Microsoft’s vision, passkey syncing is also built into the password manager and authenticator found in Google’s Chrome web browser across the many platforms it supports.

Google’s Chrome: Neither fish nor fowl?

Speaking of Chrome, there is one gray area regarding the definition of a platform authenticator. As suggested earlier, the general idea of a platform authenticator is that the authenticator is built into the platform that you’re using. As described above, the concept of a platform is often assumed to encompass the operating system and the local system’s hardware. But, it could be argued that the browser-based authenticator built into Google’s Chrome is also a platform authenticator. After all, even though users have to download Chrome in order to use it on certain devices (perhaps qualifying it as a virtual authenticator), it is also built into Android devices. 

Also: How to sync passkeys in Chrome across your Android, iPhone, Mac, or PC (and why you should)

Either way, it’s important to note that in most cases involving platform authenticators, the resulting passkeys are syncable passkeys (as opposed to non-syncable). 

In the next part of ZDNET’s four-part series on passkey authenticators, we’ll cover the virtual authenticator. 

–>

Source: Robotics - zdnet.com