The Journey to Zero Trust

The Zero Trust concept has been around for a while now, and the rise of remote work related to COVID lockdowns supercharged the Zero Trust conversation.  Many organizations had to scramble to enable employees to work remotely but did not have technology environments that were prepared for it.  As a result, technology groups often were forced to implement and now manage a mishmash of VPN, BYOD, VDI, and other solutions to keep people productive.  Now there is a need to streamline and clean up these environments but also retain the advantages of easy access to resources wherever people are working.  Zero Trust is an excellent way to accomplish that but getting there can be a bit intimidating.  (See my colleague Keith’s blog here for more in this topic.)

The Maturity Model

Today, I would like to introduce a maturity model for Zero Trust that outlines both what the framework includes and the Microsoft solutions that address the requirements.  This shows what solutions are needed for an organization to move from the Traditional column to an Advanced or Optimal configuration.  Most organizations will have elements of their environment in two or even all three columns as they progress through the journey. 

The most crucial element to bringing the Zero Trust approach to life is that Zero Trust really should be an intentional goal and addressed through actions defined on your overall technology roadmap.  Once you get there, future application and system decisions will also need to be designed around the framework, often using the same tools and approaches outline in the maturity model.  

So, let us have a look at the maturity model:

TraditionalAdvancedOptimalExample Solutions:


-On-premises identity provider is in use

-No SSO is present between cloud and on-premises apps

-Visibility into identity risk is very limited

-Cloud identity federates with on-premises system

-Conditional access policies gate access and provide remediation actions

-Analytics improve visibility

-Password-less authentication is enabled

-User, device, location, and behavior is analyzed in real time to determine risk and deliver ongoing protection

-Azure AD/AD Sync

-MFA with CA

-Password-less/MS authenticator

-Defender for Identity

-LAPS (local admin password solution)

-Defender for Office 365

-Azure AD Identity Protection

-Privileged Identity Management/RBAC


-Devices are domains joined and managed with solutions like Group Policy and Config Manager

-Devices are required to be on the network to access data

-Devices are registered with cloud identity provider

-Access only granted to cloud managed and compliant devices

-DLP policies are enforced for BYO and corporate devices

-Endpoint threat detection is used to monitor device risk

-Access control is gated on device risk for both corporate and BYO devices

-Azure AD


-Defender for Endpoint

-Windows Update for Business

-Corporate app store

-Secure configuration baselines



-On-premises apps are accessed through physical networks or VPN

-Some critical cloud apps are accessible to users

-On-premises apps are internet-facing and cloud apps are configured with SSO

-Cloud shadow IT risk is assessed; critical apps are monitored and controlled

-Apps are available using least privilege access with continuous verification

-Dynamic control is in place for all apps with in-session monitoring and response

-Defender for Office 365

-VPN (w/CA) & split tunneling

-Defender for Cloud Apps

-Azure AD Application Proxy


-Principle of Least Privilege


-Permissions are managed mutually across environments

-Configuration management of VMs and servers on which workloads are running

-Workloads are monitored and alerted for abnormal behavior

-Every workload is assigned an app identity

-Human access requires Just-In-Time

-Unauthorized deployments are blocked, and alert is triggered

-Granular visibility and access control are available across all workloads

-Defender for Cloud Apps

-Defender for Endpoint


-Secure configuration baselines

-PIM for al admin access

-Defender for Cloud/Azure Arc


-Few network security perimeters and flat open network

-Minimal threat protection and static traffic filtering

-Internal traffic is not encrypted

-Many ingress/egress cloud micro-perimeters with some micro-segmentation

-Cloud native filtering and protection for known threats

-User to app internal traffic is encrypted

-ML-based threat protection and filtering with context-based signals

-All traffic is encrypted

-Network segmentation/802.1X


-Azure Networking groups and firewalls

-Sentinel SIEM/SOAR

-SMB encryption (on-prem)


-Access is governed by perimeter control, not data sensitivity

-Sensitivity labels are applied manually, with inconsistent data classification

-Data is classified and labeled via regex/keyboard methods

-Access decisions are governed by encryption

-Classification is augmented by smart ML models

-Access decisions are governed by a cloud security policy engine

-DLP policies secure sharing with encryption and tracking

-Microsoft Preview

-Data inventory



-Data Loss Prevention

-Retention policies

-Principle of least privilege

-Sentinel SIEM & SOAR

This chart shows the securable elements in the left column and the relevant Microsoft solutions to secure those elements in the right columnOrganizations should evaluate how they are securing each of the elements (Identities, Devices, Network, Data, etc.) and place their current technology and controls in the appropriate colored column.  The further to the right you are, the closer you are to your Zero Trust goal for that element. 

Identifying the End of Your Journey

If an organization has controls deployed as described in the blue column, that will indicate that it has completed the journey to Zero Trust.  As you can see, many of the Microsoft cloud solutions that you have in your environment today are applicable to Zero Trust if deployed the right way.  Some other points to note:

  • While the model includes this security controls layers you would expect (like the Defender products, SIEM, SOAR, and MFA), note that the compliance functions in Purview (content labeling, encryption, and DLP) are also needed.  These Information Protection functions are really another security layer in addition to helping meet compliance needs.  (For more discussion in this, see my earlier blog on the topic here.)
  • The Trust model requires much of what Microsoft includes in E5 licensing.  It continues to build the case for using the advanced E5 features available to further automate security requirements.  It can be hard to get there without them since both security and compliance controls are needed to round out data protection and visibility.
  • There are some Azure features that would also be needed to complete the implementation: 
    • Azure Networking features such as virtual networks, network and application security groups, and Azure firewall to establish micro-segmentation. 
    • Azure AD Application Proxy to help secure legacy apps without native SSO or MFA support. 
    • Sentinel SIEM and SOAR to aggregate events and automate responses to alerts.
  • As described in Chris Stegh’s earlier blog post, there is not a way to truly secure your environment without having controls in place over both identity AND devices.  MFA is certainly critical, but no longer adequate on its own.


Given the depth and interaction of the solutions listed here, you can see that Zero Trust can only realistically be achieved through being intentional and building an architecture to achieve it.  Once that is complete, however, securing future systems and data becomes much easier as you incorporate them into the design and have them leverage your existing security and control structure. 

Tom Papahronis

Tom Papahronis

Strategic Advisor - Enabling Technologies