FIDO Passkey Announcement – What’s it Mean for the Enterprise?

Horacio Zambrano | May 19, 2022

Parsing through the Apple, Microsoft and Google announcement related to enhanced FIDO standard support

Last week, just before World Password Day on Cinco de Mayo (I’ll admit there were two reasons to celebrate on that day), Apple, Google and Microsoft jointly announced their intention to further extend their support for the FIDO passwordless standard. This was a meaningful announcement because 1) it’s not often these 3 big power players get together and agree on anything, and 2) there is a clear precedent to what was announced such that real products may be available soon that demonstrate the promise of the standard for the average consumer. 

What is the significance of this announcement?

Let me start by explaining the referred to precedent first. As backdrop, the announcement was an extension of support for the FIDO passwordless standard that all the players already supported. Those that follow the space would know that Apple was the last of these big 3 vendors to join the FIDO initiative in Feb of 2020, but it’s been impressive how fast it’s made-up ground since then. In fact, its announcement of a “passkey” feature last year at its WWDC was arguably a more innovative step than we’d seen from Google and Microsoft when it comes to end-to-end seamless interoperability. To make a complicated story simple, the passkey turns a smartphone itself into something akin to a FIDO security key, and uses the iCloud device chaining concept to create portability of the FIDO private key that is stored securely in an Apple device. Many enterprise passwordless authenticators already hold FIDO private keys, but the announcement extends this to imply that the passkeys are managed by the device platforms themselves, that they are universal across the vendor’s platforms and portable across multiple devices. 

The significance of this announcement is that Google and Microsoft, both owners of cloud services, native and cloud apps and platforms/devices, are also now working with Apple on this concept to enable more seamless experiences for consumers. For those of us that know the FIDO architecture intimately well, details remain rather hazy on how the private keys can work across platforms from the different vendors given the need for a corresponding matched public key, but we’ll assume for now that this is what makes this announcement special, as opposed to a typical lock-in into one ecosystem.

Read about the “Security Benefits of Passwordless”
Download Whitepaper

What are passkeys and how are they different than FIDO2 security keys?

Passkeys are essentially a slightly watered-down form of FIDO2 security key. I say watered down because FIDO2 security keys like those from Yubico and Feitian typically bind the private key to a specific hardware device. For the sake of usability and ease of portability, passkeys relaxed this strict requirement, and as hardcore security architects know, this introduces the possibility of interception and malicious use of that key upon portability.  Nonetheless, the probability of this happening is low (more so due to the human component as opposed to the technical one), and likely worth the net benefit tradeoff overall of less password use. Net-net, the announcement is a step in the right direction toward a ubiquitous passwordless future. 

Passkeys will benefit consumers more than enterprises. 

Apple’s announcement clearly positions the enhanced support and joint collaboration squarely for consumers, and this was my first reaction as well even before reading the actual release. Knowing the complexity and requirements that we have seen with our customers in the enterprise, and being a FIDO2-compliant platform ourselves, the lack of detail in the original articles I read for how certain big problems seen in the enterprise would be addressed led me to be skeptical of its impact in an enterprise setting. 

Once I read the actual Apple press release, it was refreshing to see that these behemoths are not overselling the promise of this announcement by being absolutely clear it is for consumer access to apps and cloud services. Because these vendors own the predominant mobile platforms and key browsers with which we connect to the web, it is possible for them to make a severe dent in the societal password problem using these elements. So much for World Password Day being a celebration of passwords. 

Why are the enterprise authentication benefits limited?

So without further ado, let me get to the point of this blog, what do passkeys and the joint collaboration announced last week mean for the enterprise, specifically for employee or workforce authentication? Unfortunately, not much, other than the fact that it’s a long-term net positive because as consumers the more we all get used to frictionless access to our consumer apps and services, the more we’ll expect it from our enterprise IT organizations and accept new solutions from them. And secondly, it’s great validation for the FIDO standard and the work the FIDO Alliance is doing as the unanimous winner as THE standards body for passwordless everywhere, across B2C and B2B. 

The reasons we feel passkeys will not change enterprise authentication, and still make Secret Double Octopus the leading choice for workforce passwordless authentication are the following:

Desktop MFA is an important part of the workforce passwordless promise and the Big 3 story doesn’t connect there – A true passwordless enterprise solution must encompass the endpoint to fully achieve the promise of passwordless authentication, which is that end users never have to remember passwords in their day-to-day work experience (a concept we call Full Passwordless). In fact, with recent TSA regulatory pressure on specific industries and cyber insurance mandates, desktop passwordless MFA has more support today than ever. 

Achieving a complete solution for desktops is not easy, and requires being able to support offline use cases, OS requirements for local passwords need in disk encryption, and reproducing part of the native credential provider stack in Windows and MacOS. Microsoft has architected Windows authentication to take place through either certificates or passwords, so enabling enterprise desktops to work with passkeys from an iPhone or Android phone would be a major change to enterprise Windows architecture. 

With respect to Macs the picture is just as complex. Apple requires a local password for FileVault disk encryption, which most enterprises turn on for enhanced security. The changes required to the OS to circumvent a local password requirement to work with passkeys are no less substantial. Many enterprises still sync the Mac password with the network password in AD.  Once passkeys are enabled on the Mac endpoint, how will network logins facilitated through user directories and things like Kerberos tickets work?

Who will provide the FIDO server? – A FIDO private key matches to a public key upon authentication, and these public keys are established upon enrollment into a FIDO passwordless system. Perhaps the simple answer to this question is anyone can or any 3rd party vendor like SDO could provide the FIDO server and deposit private keys on a Google or Apple phone as a passkey. But there are added complexity and interfaces that would need to be addressed for 3rd party vendors to leverage a native authenticator and the keychain-type constructs.  

If third parties are not enabling this, then it implies the Big 3 will have to offer the type of features SDO and other passwordless specialists have enabled for the enterprise. On the desktop these include things like offline support, presence detection or lock on walk-away, not to mention heterogenous parity and support.  Will Microsoft have a compelling solution for Apple Mac with FileVault enabled for example? At the moment, many questions arise that make the enterprise picture incomplete when discussing the concept of passkeys and a cross portable FIDO key cryptography in an enterprise environment. 

Enterprises want solutions that build on existing IAM infrastructure, especially SAML-based SSO – Whilst passkeys and the extended FIDO support across these vendors are a benefit to consumers who visit many types of applications, important enterprise applications are often corralled for governance workflows and administration in SSO portals. MDMs play a role in provisioning native mobile applications and EUMs in enabling VDI or virtual application access. How are these workflows going to change with portable passkeys?

The list continues onto other use cases like VPN and legacy on-premises applications. Many enterprises enable their VPN over RADIUS where FIDO keys have limitations for most vendors. It took SDO years to develop a patented architecture and specialized solution for these complex use cases.  How do passkeys with their portability and interoperability across the Big 3 answer these requirements and work with the underlying enterprise infrastructure that must be coordinated. 


In summary, workforce passwordless authentication must work easily and intuitively, and to achieve that it takes ingenious engineering and man-years of work for interoperability. The enterprise passwordless market is like many others that have thrived, one where major platform vendors provide solutions tailored for their infrastructure. It is the third parties that also come in for innovation to establish feature parity across heterogeneous environments. 

The announcement from last week already represents major progress if the Big 3 are collaborating in making their platforms interoperable across the world wide web for consumers. Unfortunately, enterprise environments have many more levels of complexity that must be dealt with before the passkey initiative from the Big 3 can be seen as a transformational solution for workforces. 

At SDO, we see the announcement as an important development and validation in the step toward a world without passwords, but we think it also reaffirms our opportunity to be the right solution for the enterprise market as workforces increasingly go passwordless.