Background
The Microsoft passwordless strategy guidance has existed since 2018, and since then it’s continued to be a solid document. You can view the full doc here, Password-less strategy – Windows security | Microsoft Docs, but where the focus usually lands is on the four step graph at the top of that page:
When discussing the strategy with organizations, the focus is usually on Step 1 – develop (deploy) password replacement offerings, and the technology involved, such as Windows Hello for Business, FIDO2 security keys, and MS Authenticator App passwordless sign-in. Afterall, the strategy is provided as a stepped approach, so you start with the first step, and then move on.
There are three primary issues with the approach:
- Organizations look at this as a reinforcement that passwordless must be deployed in a waterfall approach.
- Application authentication modernization is not emphasized strongly enough, and subsequently organizations do not right-size the efforts required.
- Organizations do not emphasize the pluralization on offerings, and potentially focus on the requirement of one-size-must-fit-all.
While issue three is not specific to this approach as designed, many organizations will take the waterfall approach with a single solution, and then box themselves into only deploying one solution, slowing down progress.
The Waterfall Approach Problem
While there have been great strides made organization wide, many still tend to suffer in that security and infrastructure teams still operate in a waterfall approach when it comes to managing identity platforms, products, and projects. A solid Identity Program or expert consultants can help rectify this, but not every organization has access to these. And sometimes, of course, organizations will simply point to the Microsoft docs and just take it all as literal guidance, with little desire to deter. From firsthand discussions with customers I’ve encountered all too often the desire to look at this as a serialized, singular method to tackle passwordless.
For organizations that have been on other identity journeys in Azure AD, they likely will have seen similar problems in their approach to deploying things like MFA or conditional access policies – if you wait for a collective 100% of all problems to be resolved, you will move the needle 0%.
In the case where a picture is worth a thousand words – some organizations will look at this diagram and disregard all of the details within the associated docs. While it’s likely they aren’t the candidate to be reading this, it’s worth noting.
The Application Authentication Modernization Problem
A very common issue within organizations is that they successfully reach mass deployment of passwordless with most user personas, but when the project is “done” they realize that there is still a lot of work to accomplish to be able to fully realize a passwordless environment.
For some organizations, this can result in passwordless being viewed as a failure. Focus will shift to organizations asking questions as to why LDAP or RADIUS do not support passwordless authentication, instead of asking why the organization wants to continue to depend on 20+ year old protocols that are inherently more insecure than modern counterparts.
Sometimes this issue is because organizations effectively look at passwordless deployments solely as that first step. The focus is just on the technology, on the identity provider, and not on the broader ecosystem. And while general consensus is that users will use the path of least resistance, which usually is passwordless, if they still have to use their password at times, there is a lower ROI as passwords are still exposed and subsequently users are still susceptible to password-based attacks such as phishing or password-spray.
Other times, the issue is that organizations just simply don’t know where to start. Application modernization projects can be some of the most costly, complex, and time consuming projects, that can become overwhelming at a rapid pace if not managed properly. It’s important that organizations understand the value and long-term return in application authentication modernization.
The Single Solution Problem
The single solution problem isn’t specifically a problem with the current strategy. Afterall, the strategy indicates password replacement offerings. They common story for many organizations is this:
We want to deploy passwordless. Let’s deploy Windows Hello for Business, then we’ll deploy FIDO2, then we’ll deploy Authenticator App passwordless sign-in.
And the problem then becomes that organizations will focus solely on one method, and will not leave the opportunity to parallel thread progress. Reality is that all three mechanisms are relatively lightweight to deploy from a technical perspective, and end up consuming very little end-user cycles for initial enrollment, but organizations may take a FUD apprehensive approach, when they should instead give users options.
To some, this may feel strange, as we’ve been wrongfully engrained by past actions in believing that users should not have choice, but be forced into a certain model – which ultimately leads users into inventing patterns of negative behavior to circumvent doing something they would rather not. For these organizations, they need to stop viewing end users as the opposition, but instead as their customers, even in the terms of workforce identity.
Of course, counter to this point, there are organizations who are deterministic in saying that they require one solution to cover all solutions. While there are initiatives underway, such as passkey, and FIDO2 support is becoming broadly adopted by operating systems, the ecosystem is vastly different than 15 years ago when the single solution mindset worked. Where we only had to previously solve for a small and fixed set of criteria, with cloud sprawl and users wanting to access everything from everywhere all the time, we have to tackle this challenge with a growth mindset. And in this case that includes solving the problem with solutions that best fit the platforms.
Customers will ask things like why doesn’t Microsoft make Windows Hello for Business for iOS, even though Microsoft does not own the operating system. Focus instead should be made on the rich ecosystem on iOS and Android devices to support brokered authentication with the Authenticator App or Company Portal. When these are combined with Authenticator App paswordless sign-in, users can have a simple passwordless experience on those devices with ease. For the many organizations that encounter end users wanting to access things like email from personal Windows computers, it’s counterintuitive to security to not provide users with a FIDO2 security key and the ability to use such, so that their password is not exposed on devices or in environments with a low level of assurance.
An Agile Refresh to the Passwordless Strategy
Our problems are stated. But what does the solution look like?
Within this strategy, nothing that Microsoft already recommends is gone, but we emphasize the application side of the equation, and we shift the focus to an iterative methodology that naturally lends to a more agile approach for deployments.
Note that this can be considered an addendum to the existing strategy, and is not written to fully replace the existing recommendations. Therefore, it’s still worth reading the Microsoft documentation, Password-less strategy – Windows security | Microsoft Docs.
Passwordless Steps Reduced to Three
During my time at Microsoft, one of the most confusing bits to customers was Step 4, Eliminate passwords from the identity directory.
The confusion comes out of the mixed messaging and likely reality that passwords will continue to exist, in some form, for a long while to continue.
Active Directory has finished baking, and the closest mechanism to having no password is Smart Card Required for Interactive Logon, or SCRIL, where Active Directory effectively manages the users password in a way that renders the password useless and unknown to the end user. When SCRIL is enabled, users are rendered passwordless because:
- Their password is managed by Active Directory and they do not know it
- The user is no longer asked by Windows to change their password
- Domain Controllers disallow passwords for interactive authentication
- The password is set to a 128 random bit of data and can include non-typable characters
SCRIL, then, is the ultimate goal for our Active Directory based user accounts. Additional benefits of SCRIL include:
- Hybrid users are supported, and users become passwordless in Azure AD
- Users, still having a password, are able to still comply with corporate password policies that may be required by cybersecurity companies or industry regulations
- The technology is not new, SCRIL has existed in Active Directory at least since Windows Server 2003, to support organizations previously deploying traditional smartcards within their environments.
For a deeper dive into SCRIL, hybrid users, and password policy enforcement, take a look at this article, Living in a Passwordless World: Password Management – Eric on Identity.
Circular Design to Indicate an Iterative Approach
In case it isn’t apparent at this point, I’ll say it again. We want to work these efforts for passwordless in ways that allow for agile deployment, adopting in a way that best suits the organization and allows for passwordless progress.
Whether you call them waves, rings, phases, or something else, it’s important that organizations identify user personas to target and deploy in a way that provides the path of least resistance and builds inertia for progress. For many organizations this should look like dogfooding passwordless, with infrastructure and security teams deploying the mechanisms to themselves first, along with their Service Desk personnel. This is the reminder that organizations always find more success with technology changes when they involve their Service Desk early in the process. Organizations should also look for champions, perhaps providing opportunity for users to opt-in to new passwordless experiences. Many times organizations will focus cycles on the users who won’t want to move, instead of focusing on the users who have a hunger for technology and change. Those users can be key to building that organizational inertia, for finding those non-IT voices to champion progress, and building momentum to topple down those that resist change solely for the sake of such.
The iterative approach can not only be used against user personas in the organization, but against the different passwordless mechanisms as well. We don’t want to lock users or the organization into a single-track mindset that only one passwordless method is suitable or feasible to use. And instances may be encountered where there is the desire to deploy multiple approaches, but one method is deployed faster than the other. An example may be deploying Windows Hello for Business first, as a means to then make bootstrapping easier for FIDO2 security keys.
Application Authentication Modernization Parallel but Separate Effort
As most identity projects go these days, workstreams are rarely single-threaded, at least if you are looking to achieve success in a reasonable amount of time.
Here we have said application authentication modernization is as important as deployment of the passwordless methods themselves. This may be different for every organization, depending on a mixture of several factors, including:
- Age of the organization – Older organizations are likely to have more legacy applications still persistent.
- Types of applications – Organizations with several line-of-business (LOB) applications may have a more varied array of authentication mechanisms existing, or if the organization has several applications running in on-premises deployments, vs organizations that primarily consume SaaS applications in a cloud, which likely already support modern forms of authentication.
- Number of applications – Again organizations can vary greatly in how many applications they have deployed. Efforts to modernize 10 applications likely will take less time than 100 applications.
- Application user personas and user base – Contradicting the number of applications, if an organization has 10 applications but 100,000 users per application, it may take longer to modernize authentication vs an organization with 100 applications but only 10 users accessing each application.
Now you may read this and wonder how to prioritize applications for modernization and what the options are – a follow-up article will eventually be linked here to dive further into that.
As critical as the modernization of applications, is the ability to separate out efforts to modernize those applications. Organizations may find themselves in situations where they enroll certain user personas for passwordless well before their full application catalog supports it, but organizations should also feel empowered to start modernizing applications as soon as they are identified, so that users can benefit from passwordless authentication as soon as they are enrolled.
Start Application Authentication Modernization First
To further emphasize the importance, the arrow for application modernization actually starts a bit before passwordless deployment on purpose. While the reality is that many applications will be starting these in tandem as a passwordless initiative, it’s important to understand that support for modern authentication will benefit the application regardless of which methods of passwordless are used. There are several other benefits of application modernization, not just limited to passwordless, including:
- Ability to leverage Azure AD technologies for authentication, such as
- Conditional Access
- Device Compliance Requirements
- Azure AD Identity Protection
- Microsoft Defender for Cloud Apps
- Decouples application from legacy identity stores, setting it up to be closer to running in a cloud-native PaaS environment
- Support for Azure AD Application Proxy
As we continue to shift towards cloud-native solutions designed to be accessed by everyone from everywhere, it is not just solving for passwordless anymore, and organizations can find themselves either ahead of or behind the ball with supporting modern forms of authentication, such as SAML or OpenID Connect (OIDC).
Final Thoughts
Passwordless deployments, for many organizations, are a litmus test for how well the organization adopts to organizational change and technology advancements. They also are a potential pain point between the C-suite and technology staff, in both directions. Organizations can suffer from technology staff not properly articulating the business value in going passwordless, and what business assets passwordless will protect – these days it’s more than just implementing “all the things” without any concern for the relative value to the business. On the other hand, passwordless is a complex topic that is tough to translate and isn’t always well received by the C-suite. Considering that some organizations still suffer from executives who don’t want MFA because it’s a burden, we have a lot of organizational change that needs to happen across the board. When organizations can implement passwordless to the further extent possible, the net effect is the organization is that much more protected than implementing nothing at all.
About this posts featured image
The chosen photo is the work of Clay Banks, used under the Unsplash license.
One Response