We hear an awful lot about Zero Trust security these days. For some, Zero Trust may be a relatively new concept; for others, it is a term that sounds simple enough but can come at a high cost.

Today’s thought leadership points to Zero Trust as one of the top methods for protecting an organization’s identities, assets, and data. But while there is a lot of information, making sense of it all may be a different story.

It is why I caught up with Derek Morgan, who is a Senior Cloud Solutions Architect with Applied Information Sciences. Morgan has been a vocal advocate of Zero Trust and authored a fascinating piece on the topic. I jumped on a call with Morgan to better understand what Zero Trust means and how close we are to a passwordless future.

[Our conversation has been edited for clarity and length]

Brennen Schmidt: How about starting with the basics? In its simplest terms, how would you describe Zero Trust?

Derek Morgan: It starts with understanding the three core concepts of Zero Trust – verify explicitly, use least-privileged access, and always assume breach.

Verify explicitly is about understanding how you are authenticating users, how you authorize them, and how you can identify individual users. Identities are highly targeted assets within organizations. It is essential to ensure that when you verify those identities, you use a powerful authentication method, such as second-factor, commonly known as Multi-Factor Authentication (MFA).

Second, it is essential to understand the concept of least-privileged access for all identities, both privileged and non-privileged. For example, say you want to access a particular resource. The organization should be able to define permissions or roles necessary to access that specific resource at a given time. With the overall focus on content, data, and applications, organizations with an identity governance framework can help establish the correct permissions and roles to enable identities to access resources.

Finally, we come to the concept of always assuming a breach. The reality is that endpoints will not reach a 100% hardened state. It may be more realistic to think endpoints may reach a threshold of 70% while still making it an organizational goal to reach 90%. This situation leaves devices vulnerable to various attack vectors where malicious actors can access an endpoint or an identity at any given moment. Always assuming a breach means security teams are validating whether an event or incident has occurred through manual intervention or automation.

Schmidt: Let us dive deeper into the concept of the identity state you just mentioned with always assuming breach. What does this mean?

Morgan: In other words, identity state helps security practitioners understand and confirm if there are any user or sign-in risks. If there is a risk, the user would no longer have access to the resource.

For example, suppose a device’s threat level is high because malware has been detected. Always assuming breach means the device would be unable to access specific resources. Another example is a security practitioner receiving an alert for an identity logging into Microsoft 365 from Los Angeles, California; six minutes later, that same identity logging in to Microsoft 365 from Moscow, Russia. Always assuming a breach means specific security measures will take place, such as Multi-Factor Authentication for validation and resetting the identity’s password.

In short, organizations of all sizes should focus on the six pillars of zero trust: identities, devices, data, apps, infrastructure, and networks. When it comes to passwordless, the primary focus should be the first and most critical pillar: identity.

Schmidt: What role does Zero Trust play in the shift toward going “passwordless”? Are we at a point where remembering all those passwords is no longer necessary?

Morgan: When it comes to going passwordless, it is vital to think back to the first and critical pillar: identity. Understanding just how essential identity is can help us understand just how valuable it is for threat actors to exploit.

We have seen many sophisticated examples of how malicious actors have exploited users. This includes extracting their password using social engineering techniques. While complex passwords and the use of password managers may be viable solutions, we see they cannot eliminate the threat of exploitation entirely. Overall, technology cannot resolve the first attack vector for identity exploitation – the human being.

Securing identity comes down to minimizing the attack surface or the plane of attack. Passwords are vulnerable to attacks, such as brute force, dictionary attacks, phishing campaigns, or a combination. Using commonly used passwords make it easy for threat actors to guess a password. However common or complex, an exploited password of a privileged or non-privileged identity can become a financial nightmare for any organization.

Schmidt: What kind of tools are in place to help support passwordless?

Morgan: Organizations using Microsoft 365 can move toward passwordless by leveraging the Microsoft Authenticator app. The app is a secure way of enabling users to authenticate their identity. The app presents a second-factor authentication on the user’s device and can use technologies like Apple Face ID or Android biometrics to help prove the user is who they say they are without needing a password.

Another example is logging in to a Windows 10 or 11 endpoint via Windows Hello for Business. The beauty of Windows Hello for Business is that it leverages biometrics or PIN to enable access to the endpoint without requiring the user to provide a password.

Another option is to leverage a FIDO2 security key. This option lets users, for example, use a web browser to log in to their email client by entering their email address into the web form. From there, the user is prompted to use their physical FIDO2 security key to complete the authentication process.

Yubico’s YubiKey is an example of this FIDO2 technology. Based on what the organization’s IT department defines as the requirement, a user may be prompted to insert their physical security key into the device, then use their thumbprint as a biometric. The user is authenticated only once the IT organization’s requirements have been met.

Schmidt: What kind of business value can the move toward passwordless offer to large and small organizations?

Morgan: By definition, passwordless leverages authentication methods which are more difficult to exploit. With the difficulty of exploiting identities enforced with second-factor authentication, there may be significant IT and organizational costs.

But we are seeing many examples in IT service management where the use of passwordless has significantly reduced the time and resources required for resetting passwords. In addition, we also see cost savings in the form of reductions in security incidents, third-party forensics investigations, and insurance claims for business operational damages.

Schmidt: While this sounds like a great business strategy under ideal circumstances, it also sounds like a rather large and potentially expensive undertaking. What are some simple steps that you recommend that IT might want to think about presenting to IT leaders to consider approaching this path?

Morgan: Taking the fast route while trying to encompass this entire strategy is unrealistic. Rolling out Zero Trust and passwordless must take place in steps over time.

Leaders need to ask themselves some key questions: What kind of infrastructure do I have in place now? What kind of third-party solutions and applications is supporting the organization? Where am I using a password?

Organizational leaders will want to pay specific attention to legacy apps and system support, given they may not fit into their organization’s passwordless strategy. Another critical step is to understand the user experience and what the customer journey looks like.

Going passwordless might make sense from a security perspective, but it can be highly disruptive to end users. Change management must be considered when evaluating a chosen solution. This includes thinking about the various devices end users might have grown accustomed to using, ranging from desktops to mobile devices.

Schmidt: Earlier, you mentioned the importance of considering third-party providers. Why should this be a key focus for organizations thinking about going passwordless?

Morgan: It all comes down to creating an offering, which includes developing a deeper understanding of the full impacts of going passwordless. One tip I would offer would be for business and IT leaders to think about the core problem they are trying to solve, supported by clearly defined requirements.

Compliance with the identity provider is only part of the puzzle regarding infrastructure, network, and applications. Decision-makers should also consider how users and customers might be leveraging Software-as-a-Service (SaaS) solutions, such as Salesforce, ADP, or Workday.

Focusing on the user can help organizations choose the best approaches to either phase out an existing legacy identity provider, migrate to a new one, or explore a hybrid approach to support a mix of application requirements that require passwords.

Schmidt: I want to channel an organization that might have yet to fully shift to the cloud. What potential pitfalls might someone in business or technology leadership wish to consider if they still need to support legacy applications?

Morgan: There are cases where a legacy system may not support a passwordless strategy. Take Windows Server 2008 or some other operating system that is no longer supported. Creating an inventory of applications can help organizations identify technologies that fall into this category.

From there, the organization is in a much better place to draft a plan with a future timeline. It is essential always to consider the reality that some legacy systems may sometimes fall outside the scope as part of a passwordless strategy.

In either case, leaders should understand that a passwordless strategy will take time. Sorting through the challenges of using a mix of modern and legacy applications and systems could take months, if not years, in the implementation journey.

Schmidt: On that note, I would imagine these modern and legacy systems could span the entirety of the organization, whether it is Finance, HR, or IT. Suppose you are on the technical side and want to broach this conversation with your colleagues across these different groups. What kind of advice can you share that might work well for them to at least get the conversation started?

Morgan: When it comes to engaging senior leadership and defining business units, groups, or functional groups, it all starts with the conversation. Set time aside to sit down with them to understand exactly what their business does and unpack their unique needs.

While technology is the conversation’s focus, remember that this conversation’s success lies in creating a two-way relationship. Get the conversation going by leaning in to understand the business challenges they might be experiencing.

It usually becomes clear early on in these conversations that both the business side of things and the technology provider need a full understanding of the application. Everyone might know what the technology does, but it is only from a single perspective.

It is why zooming out to focus on the bigger picture is so important to shape a meaningful conversation. Those in technical roles might want to bring an architectural design to the table to help articulate where a particular application fits in the organization’s IT and operations model.

Make sure to focus only a little on the technology, though. It is about understanding how users access systems today so you can help make things easier for them while supporting data safeguards to keep their information safe.

It all comes down to establishing and maintaining the relationship with your stakeholders. I usually see things fall through the cracks when the dialogue starts breaking down. Focus on maintaining that two-way relationship and understanding exactly how the application works. You will soon be on your way to crafting and executing a user-centric passwordless strategy.