WebAuthn In Enterprise Is Great and It Has Challenges

FIDO2 and WebAuthn hold great promise not only for consumers but for enterprise users as well. There are caveats however, and the challenges for IT departments are very different than for consumer websites.

A FIDO2 Security Key

What Is WebAuthn Again?

WebAuthn—short for Web Authentication—promises to fix authentication on the web with a strong, simple, and un-phishable standard. A while back, I wrote an article that explains how WebAuthn works as a consumer authentication technology. It explains the WebAuthn, the FIDO2 standards, and all the confusing acronyms related to them. If you haven’t read it yet, you should start there. 

Fundamentally, Web Authentication is an API for accessing public key credentials. Translation:  It allows websites to verify a cryptographic key stored on the users computer, phone or authentication device through a web browser.

The power of WebAuthn is not only its great security but also the flexibility – you can potentially use a device you already have (like a smartphone or computer) or an external authenticator like a USB security key.

Why Should Companies Care?

My previous article looked at WebAuthn from the perspective of a regular person and argued that the main benefit is great phishing-resistant security. Targeted phishing happens to also be a key challenge companies face, especially now with vastly expanded remote work. Strong authenticators, such as WebAuthn, can very effectively prevent even sophisticated, targeted man-in-the middle phishing from succeeding. 

WebAuthn and FIDO2 vs. U2F and FIDO

Yes, security people love acronyms—enough so that an acronym explainer is necessary. The FIDO security keys as we know them came out in 2014 when FIDO Alliance—started by Google and Yubico—released the U2F standard. The U2F protocol, and the security keys based on it, remain great phishing-resistant, second-factor authenticators.

The key differences between the newer FIDO2 WebAuthn and FIDO U2F are that WebAuthn promises us the option of strong passwordless authentication and also adds a number of new controls for single-device multi-factor authentication.

WebAuthn Authenticator Types and Attributes

The WebAuthn specifications are fairly complex, allowing many ways for authenticators to interact with users, browsers, operating systems, and websites.

Most people think of security keys plugged into a USB port when discussing Web Authentication, but there are other options too. WebAuthn breaks down authenticators along several different dimensions; I will focus on some key ones that have enterprise IT implications.

Is the authenticator a part of the client device?

Roaming authenticators are removable and can be used on different client devices, similar to how FIDO U2F authenticators have worked for years. A typical example of this would be a Yubikey security key.

Platform authenticators are usually not removable and are part of the client device, e.g. Touch ID on a MacBook.

Does the authenticator support user verification?

All WebAuthn authenticators are ‘something you have’, like the U2F keys that came before them. But with WebAuthn, they can also be multi-factor authenticators where the authenticator itself can verify ‘something you know’ like a PIN or ‘something you are’ like a fingerprint.

This matters because some security frameworks ask for multifactor authentication to be performed in a single step. The NIST SP 800-63-3 guidelines for federal government agencies define different authenticator assurance levels and corresponding allowed authenticator types. It defines a multi-factor authenticator as something you have, which has to be activated by something you know or something you are! Some WebAuthn authenticators can meet this requirement.

If you want to enforce this, your platform handling the WebAuthn must support the User Verification Flag.

Can I choose which authenticator a user registers?

WebAuthn is great because it’s an open standard and anyone can make authenticators for it. But, what if the enterprise wants to specify which authenticators it allows the users to use, making sure that they meet their specific security requirements? 

All WebAuthn authenticators have an identifier, which can be used by the website to infer what make and model the authenticator is, what certification level it has, and what kind of key protection it provides. And again, if you want to enforce this, your platform handling the WebAuthn must be able to do this.

In general, the websites – a.k.a. Relying Parties as they’re called in the spec – can require some authenticator characteristics when registering (creating credentials) and when authenticating (generating assertions). 

WebAuthn Challenges in Corporate Environments 

After talking to a number of IT professionals about key issues they faced when deploying WebAuthn in the corporate world, I created this list of challenges:

1. WebAuthn has to be supported by the browsers that we standardize on and the ones our users actually use—which are not always the same thing. 
2. We need WebAuthn authenticators that we can afford. 
3. We need to be able to deploy authenticators and get them in the users’ hands. 
4. We need to be allowed to deploy authenticators in the users' hands, complying with local laws and labor regulations.
5. We need to be able to enroll the users securely.
6. We need to be able to protect a critical mass of key applications—ideally all of them.
7. We need to secure the recovery flow when users lose their security keys or upgrade their laptop or phone acting as a platform authenticator.
8. We need to update our security policies to take advantage of them.
9. We need to update our audit and compliance programs to map to the assurance they give us—time to decide what fights to pick!
10. Our users need to learn how to use them. 
11. Our users need to want to use them; this means the whole process needs to be easier than the status quo.

No problem, right?! Just a couple of things we need to line up!

Can We Address These Challenges?

Yes, we can! Fine, that list does look daunting—but if you look through it, it's likely that there are no showstoppers.

Let’s start with browser support. As I mentioned in my earlier article, the browser support is getting better all the time. A common limitation used to be applications that use the operating system provided built-in browser views for modern authentication, and if those don't support FIDO2 and WebAuthn, you can be stuck. This was the case on Windows until the Windows 10 version 2004 release in June 2020, which enabled Windows Hello to be used as FIDO2 authenticator.

Affordability is getting solved too, as there are more inexpensive under-$20 security keys on the market and more devices have built-in WebAuthn compatible platform authenticators.

Protecting a critical mass of applications in the enterprise used to be one of the hardest problems, but the rapid adoption of modern single-sign-on solutions, like Okta and others, makes it easy to implement modern Webauthn-based MFA across all kinds of modern and legacy applications. 

And to address the training and usability, you may actually want to select the cheaper, less-functional basic security keys that only support U2F and FIDO2. This avoids needing to program the keys individually, making for less end-user training and confusion and avoiding accidental token codes being inserted in messages and documents. 

Many of the remaining issues can be solved within your own organization, such as mapping the audit and compliance controls and focusing on the actual security outcomes that are at the heart of them. Similarly, deciding how to enroll the users to the system to bootstrap the security is usually within your control. 

And now you have a checklist to mark your progress. Today is a great day to get started!