Administrator’s Guide, Part 4: Phases of a Passwordless Rollout
Part of our Administrator's Guide to Passwordless blog series
If you’re considering passwordless authentication for your organization today, you’ve probably been thinking for a while about a holistic authentication strategy. Passwordless is a leap forward on the path to a strong and usable authentication system, consisting of many individual steps that you must navigate.
Let’s start by reviewing the high-level phases of the passwordless journey:
Phase 1: Establish Multi-Factor and Identify Passwordless Use Cases
Multi-factor authentication has been a critical component of strong authentication systems for more than a decade. Hopefully, you’ve already got this one — but if not, there are countless products that can help you mitigate the threats of password-based single-factor authentication.
Phase 2: Consolidate Authentication Workflows
A typical company runs hundreds of applications. Managing each application’s authentication methods and security policies quickly becomes untenable for administrators at this scale. Rather than attempt to augment the security of each application individually, Phase 2 focuses on consolidating authentication workflows into a place where the majority of the authentication events can be centrally managed.
This may take the form of single sign-on (SSO) or federated portals through standard protocols like Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). Even applications that aren’t web-based, such as SSH clients or remote desktop software, may be able to go passwordless by using a reverse proxy and client software that opens a passwordless web prompt. There are numerous products and services that will offer different experiences and features, and both the features you need and the protocols your applications support may dictate which products and services are suitable for your organization.
Phase 3: Increase Trust in Authentication
Next, focus on building a more comprehensive user authentication system and mitigating additional threats in your environment. Ensure user authentication is occurring from known and trusted devices with up-to-date software and operating systems. Detect anomalous user behavior and flag it for remediation. Identify safe conditions and risky behaviors and configure flexible policies that can reduce user friction without reducing security. Support for all of these things builds upon your work in Phase 2 and the selection of a vendor that supports the features you need.
Phase 4: Adopt Passwordless (We are here!)
Passwordless requires support from both your users’ access devices and your SSO portal or federation system. Microsoft, Apple, Google, and other system manufacturers have done an excellent job in rolling out access device support for passwordless, and security key manufacturers like Yubico, Feitian, and SoloKeys can help enable support for passwordless authentication on devices that don’t support it natively. SSO and federation providers are beginning to bring passwordless solutions online. If you’ve done the hard work in Phase 2 to consolidate your authentication workflows into a centralized authentication experience, you may be able to enable passwordless across the majority of your organization by simply switching it on. Your existing authentication and authorization policies, device trust, and configured settings should ideally transfer over and take effect right away.
Phase 5: Optimize Passwordless
Unless you’ve managed to consolidate every one of your applications into using the same federation solution, it’s likely you won’t be able to completely eliminate the use of passwords overnight. This is where having a layered security model with MFA, configurable policy, device trust, and adaptive authentication pays dividends. Your organization is only as safe as your weakest authentication method, so ensuring every authentication method is strong reduces your risk as you transition towards Pure Passwordless. The goal here is to aggressively continue consolidating authentication workflows into centralized auth solutions where passwordless support exists and begin the process of disabling password-based authentication.
This will be a protracted phase, as disabling passwords will highlight all sorts of corner cases where passwords may be used in your organization, such as new user onboarding, account recovery, and that one server in the basement that you don’t want to touch in case something goes terribly, terribly wrong. Certain applications and protocols will most likely not be able to adopt passwordless initially, so some of your users may need to keep a password around to use with these systems for a while.
Passwordless is exciting and promises both security and usability benefits. We mostly get the usability benefits in Phase 4 and the security benefits in Phase 5, but like anything, there’s a spectrum. So long as passwords remain an option, adversaries can apply the same attacks they use today to password-based auth methods. Adding passwordless auth as an option starts by making authentication easier. Removing passwords as an option makes authentication safer.
For frequent use, adding additional factors behind a password may have been deemed too much friction, but it may be more acceptable as an infrequent fallback when passwordless is the primary authentication method. Security benefits can also come simply from user habit migration. For example, users who become conditioned to passwordless authentication will find an unexpected push or a password entry field conspicuous, even if they’re still allowed as options. This is one of the few exciting breakthroughs in authentication technology where a more usable option is more secure as well!
However, it would be remiss to say everything will be roses. Let’s dig in to Phases 4 and 5 and discuss some of the challenges you are likely to face as part of passwordless adoption and how to manage them.
Your First Few Weeks of Passwordless
When you flip the switch and enable your first passwordless login, it’s probably going to feel unfamiliar. If you’ve read this guide and have a general understanding of how authenticator devices store and use credentials, you’ll probably be able to infer how things operate. Your users, on the other hand, may have no idea what they’re supposed to do. Passwordless login is supposed to be quicker and easier than using a password, but most people have years or even decades of experience using passwords. We know what to do when we see a password input form.
Your users will be old hats at passwordless in no time, but the first time seeing an unfamiliar prompt to scan a fingerprint or face can be unsettling. If a user thinks they’re entering their system password into a web form, being prompted to enter a PIN or local system password can be confusing or even suspicious. You’ll most likely want to evaluate the passwordless login flow yourself and work out a strategy for assisting your users through their first passwordless logins.
But before we even get to passwordless login, your users will need to enroll a credential or add an authenticator device to their account or profile. This can be just as confusing as a first login, if not more so. However, depending on your MFA configuration, your second-factor authentication method may be suitable, or nearly-suitable, for passwordless auth already.
If your users have adopted a WebAuthn-capable 2FA method such as Windows Hello, Touch ID, Face ID, Fingerprint/Face Unlock, or a FIDO2-certified security key and regularly use it as a second factor, your authentication provider may be able to use the same credentials for passwordless authentication if they support user verification. If not, then the simplest way to enroll a new passwordless device is to piggyback on top of a normal password-based auth and ask your users to enroll a device as part of their normal login process. This will probably feel pretty similar to how your users first enrolled their MFA devices after entering a password the first time. On next login, they’ll be able to use passwordless!
Now, imagine you’re a few weeks into your passwordless rollout and one of your users loses their first device. Even though their credential on the device should still be protected by a user verifying PIN or biometric step, we want to invalidate that credential as soon as possible because it’s now lost the something you have property. Your authentication provider should offer a control panel or other administrative console where you can view your users and see what devices they have enrolled. You should have a quick and easy way to invalidate the lost device and credentials through this interface. (In case you’re curious, each device is supposed to only have one credential per user account.) If you haven’t disabled passwords yet, your user should be able to use their password to enroll a replacement authenticator device the next time they try to log in.
Removing Passwords: Applications vs. Users
Throughout Phase 4, passwords remain a viable fallback option. Although these challenges in Phase 4 are likely to require lots of time, they’re more about helping your users acclimate to a new process than technical complications per se. You may wish to progressively roll out passwordless to smaller groups within your organization at first, to smooth the influx of help tickets and allow early adopters to share knowledge of passwordless with their peers.
Things get trickier as we move toward Phase 5 and start to remove passwords as an option. Any user who hasn’t acclimated to passwordless login will be stuck if they no longer have a password-based fallback. The goal of Phase 5 is to remove passwords from the environment to improve security, while minimizing new complications. Let’s explore a few complications that may come up as we remove passwords.
To start, not every application will be able to use passwordless. Take connecting to a wireless network for example. Unless you’ve rolled out client certificates to your fleet, the main WPA2 Personal and Enterprise authentication protocols expect either a pre-shared key, or a username and password. Not every protocol is web-based or can be proxied through a web-based gateway. Applications released years ago may never get updates that support SAML, OIDC, or other federation protocols. It’s likely that one or more additional applications or use cases in your environment may not be passwordless-capable, now or in the future. That’s okay. Each application from which you can remove passwords gains the security benefits.
Every user from which you can remove passwords is one fewer user who can be phished or introduce credential reuse into your organization. However, it’s much harder to completely remove passwords from users than to completely remove them from applications. If a user no longer has passwords, then they can’t fall back to a password if they lose their authenticator device. It becomes important that each user have two or more authenticator devices enrolled, so that they do not get locked out of their account. Once passwords are eliminated, your users will probably need to use passwordless authentication to enroll new devices.
Authenticator Management Considerations
Platform authenticators like Touch ID and Windows Hello are conveniently present on the access device but are also limited to being used on the specific platform they’re a part of. Let’s say you need to enroll a new device with a platform authenticator but no longer have a password. How do you bootstrap trust in your new device to get to where you can enroll its platform authenticator?
Roaming authenticators like security keys or mobile authenticators have the advantage that they can be used to authenticate across multiple machines. You can use a platform authenticator to enroll a roaming authenticator on one computer, then move the roaming authenticator to another computer and use it to enroll that computer’s platform authenticator.
It’s clear that the passwordless future involves lots of devices and a mix of both platform and roaming authenticators. However, increasing the number of authenticators introduces even further complications, as each authenticator must generate its own per-site credentials. Enrolling multiple devices with each of multiple websites will likely grow tiresome. You can partially alleviate this via federated login, centralizing login to a handful of sites or fewer. On the plus side, enrolling multiple devices gives your users the ability to self-remediate individual lost or stolen devices without losing access to their account.
Inevitably, some users will find themselves with one or more lost authenticator devices and no way into their account. You will need a recovery flow. There are many different recovery flows, including temporary passwords, recovery links, backup codes, and more. Your recovery flow may delegate the authentication decision to another provider, such as an email host, wherein if your user still has access to their email account, they may be able to self-remediate. If not, they may need to contact your help desk for an override. Recovery flows are also a potentially-viable option for bootstrapping trust across platform authenticators without a roaming authenticator to assist.
While it’s critical to have one or more recovery flows, know that the recovery flows you support, especially any self-remediation flows, are viable attack vectors. It doesn’t meaningfully improve your security posture to remove password-based authentication if your recovery flow isn’t ultimately stronger.
Your organization may likely reach Phase 4 quickly but spend years optimizing passwordless in Phase 5, which is to be expected. Over time, the passwordless space will expand to support additional applications and use cases, and someday, we hope, passwords will be a relic of the past.
If you’d like to see how Duo can help bring passwordless to your organization, visit the product page for our passwordless authentication solution.
Duo’s Passwordless Authentication Resources
Explore more of our Administrator's Guide to Passwordless blog series
Learn more about our passwordless authentication solution
Read our white paper, Passwordless: The Future of Authentication
Watch our webinar, How Duo is Making Passwordless Progress Easier
Watch a Threatwise TV video that discusses and demos Duo passwordless authentication
Read a Cisco blog by Product Marketing Manager Ted Kietzman explaining why passwordless is just one part of a holistic security strategy
Try Duo for Free
Want to test it out before you buy? Try Duo for free using our 30-day trial and get used to being secure from anywhere at any time.