A Roadmap to Zero Trust Architecture

Traditional network architecture was built with the concept of a perimeter network where once someone was on the network, there was an implicit level of trust. The shift toward cloud hosting, remote work and other modernization has created challenges with a traditional perimeter network architecture.

These challenges can be addressed by implementing a Zero Trust Architecture, which ensures that all traffic in and out of a business is verified and authorized. Implementing a Zero Trust Architecture can be done in steps without disrupting employee productivity and connectivity.

This roadmap was built by security experts to provide a vendor agnostic Zero Trust architecture and example implementation timeline. The timeline assumes that an organization is beginning their Zero Trust journey from scratch, but is meant to be useful for all organizations.

There are seven major components to organizational security that need to be considered when it comes to implementing a comprehensive Zero Trust Architecture. Your implementation order does not need to match how they are listed in the component and reference architecture sections below.

Components of a Zero Trust Architecture

Users

Establish a corporate identity
Enforce MFA for all applications

Endpoints and Devices

Implement MDM/UEM to control corporate devices
Implement endpoint protection
Inventory all corporate devices, APIs and services

Internet Traffic

Block DNS requests to known threats
Block threats behind SSL/TLS

Networks

Segment user network access
Use Internet backbones for branch to branch connectivity
Close all inbound ports open to the Internet for application delivery

Applications

Monitor inbound emails and filter out phishing attempts
Inventory all corporate applications
Zero Trust policy enforcement for Applications

Publicly addressable
Privately addressable
SaaS applications
Non-browser apps (SSH, RDP, SMB, thick clients)

Protect applications from Layer 7 attacks (DDoS, injection, bots, etc)
Enforce HTTPS and DNSsec

Data Loss Prevention and Logging

Establish a process to log and review traffic on sensitive applications
Define what data is sensitive and where it exists
Stop sensitive data from leaving your applications (e.g. PII, CCNs, SSNs, etc)
Identify misconfigurations and publicly shared data in SaaS tools
Establish a SOC for log review, policy updates and mitigation
Stay up to date on known threat actors

Steady State

Employ a DevOps approach to ensure policy enforcement for all new resources
Implement auto-scaling for on-ramp resources

Reference Architecture

This is a reference guide that explains each function in a Zero Trust Architecture along with recommended vendors for each function.

Level of effort scale:

🔧 - Small effort; this can be done by an individual or small team

🔧🔧 - Medium effort; this will require a team and advanced preparation

🔧🔧🔧 - Large effort; this will require multiple teams and a project plan

Users

Users include employees, contractors and customers. To implement zero trust, an organization must first have an accurate picture of who should actually be trusted, and with what — otherwise known as Identity. Then it must establish a way to securely authenticate the identity of its users.

Establish a corporate identity

Level of effort	🔧🔧 - Medium
Team(s) involved	The team responsible for your identity provider (typically security or IT) The admins who manage internal apps used by employees and partners
Product(s)	Microsoft Azure AD, Okta, Ping Identity PingOne, Onelogin
Summary	A unified corporate identity is required to accurately authenticate and authorize user access to corporate applications. A consistent corporate Identity will make granular policy enforcement for your applications more seamless. Additional points to consider: Is your company active in M&A? How will you consolidate identity stores? Do you have any non-web based authentication protocols in use (e.g. active directory, ntml, kerberos)
Steps	Add all corporate users to the identity provider These values can often be synchronized from an HR system like Workday, ADP, etc Verify that each user’s information is correct Send new users registration information to set up login credentials

Enforce multi-factor authentication for all applications

Level of Effort	Basic MFA: 🔧 - Small Hardkey MFA: 🔧🔧 - Medium
Team(s) involved	The team responsible for your identity provider (typically security or IT) The admins who manage internal apps used by employees and partners
Product(s)	Identity providers: Microsoft Azure AD, Okta, Ping Identity PingOne , Onelogin Application Reverse Proxies: Microsoft Azure AD App Proxy, Akamai EAA, Cloudflare Access, Netskope Private Access, Zscaler Private Access (ZPA) Hard Keys: Yubico
Summary	Multi-Factor Authentication (MFA) is the best protection against stolen user credentials via phishing or data leaks. Most MFA can be enabled directly in an IdP. For applications not directly integrated with your IdP consider using an Application Reverse Proxy in front of the application to enforce MFA.
Steps	Alert internal users to upcoming MFA enforcement. Provide options to sign up for SMS or App-based authenticators Enable MFA in your IdP Enable Application Reverse Proxy in front of applications not integrated with your IdP (Bonus) Distribute Hardware keys to employees via Mail or In Person distribution (Bonus) Enforce Hardware key only MFA for your most sensitive applications

Endpoints and Devices

Endpoints and Devices include any device, API or software service within an organization or that have access to organizational data. Organizations must first understand their full set of devices, APIs and services. Then Zero Trust policies can be implemented based on the context of the device, API and service.

Implement mobile device management

Implement endpoint protection

Inventory devices, APIs and services

Level of Effort	🔧 - Small
Team(s) involved	Security team IT Team
Product(s)	Device Inventory: VMWare Carbon Black, Crowdstrike, Oomnitza, SentinelOne API/Service inventory: Cloudflare Application Connector, Zscaler Private Access (ZPA)
Summary	Endpoint protection software and asset management software can be used to track all devices that have been distributed to users. An accurate list of devices should be maintained to track which devices are valid and should have access to specific applications. APIs and services should also be detected and maintained in an inventory. Network scanning can be leveraged to identify newly seen APIs and software services that can communicate over an internal or external network.
Steps	Install the Endpoint Protection Software on users’ machines using MDM Install the API/Service scanner within your network

Internet Traffic

Internet Traffic includes all user traffic destined for websites outside of an organization’s control. This can range from business related tasks to personal website usage. All outbound traffic is susceptible to malware and malicious sites. An organization must establish visibility and control over user traffic destined for the Internet.

Block DNS requests to known threats or risky destinations

Level of effort	🔧 - Small
Team(s) involved	IT team with access to either router or machine configuration Security team
Product(s)	DNS Filtering: Cisco Umbrella DNS, Cloudflare Gateway, DNSFilter, Zscaler Shift
Summary	DNS filtering can be applied via router configuration or directly on a user machine. It is one of the fastest ways to protect users from known malicious websites.
Steps	DNS Filtering: Update DNS resolution configuration on your office wifi to point to the appropriate DNS resolution service. This can be used to block known malicious sites

Block or isolate threats behind SSL/TLS

Time Required	🔧🔧 - Medium
Team(s) involved	IT team with access to either router or machine configuration Security team
Product(s)	TLS Decryption: Cloudflare Gateway, Netskope Next Gen SWG, Zscaler Internet Access (ZIA) Isolated Browsers: Cloudflare Browser Isolation, Zscaler Cloud Browser Isolation
Summary	Some threats are hidden behind SSL and cannot be blocked through only HTTPS inspection. To further protect users, TLS decryption should be leveraged to further protect users from threats behind SSL.
Steps	TLS decryption: Ensure the correct client software is installed on a user machine Check for any VPN or other software that might interfere with the outbound web traffic on the device Configure the root certificate on the device for TLS decryption Enable policies of when to avoid decrypting user traffic This should be done for sites that use certificate pinning Some companies also bypass decryption for user’s personal traffic (e.g banking, social media, etc)
	Browser Isolation: Browser isolation can be deployed via the on-device client software or via an isolation link. Both approaches should be considered.

Network

Networks include all public, private and virtual networks within an organization. Organizations must first understand their existing set of networks and segment them to prevent lateral movement. Then, Zero Trust policies can be created that granularly control which segments of a network that users, endpoint and devices can access.

Segment user network access

Level of effort	🔧🔧🔧 - Large
Team(s) involved	Security team IT Team
Product(s)	Zero Trust Network Access (ZTNA): Cloudflare Zero Trust (Access and Gateway used together), Netskope Private Access, Zscaler Private Access (ZPA)
Summary	Users can generally access an entire private network using a VPN or while in the office network. A Zero Trust framework requires that users only have access to specific segments of the network required to complete a given task. Zero Trust Network solutions allow users to access a local network remotely but, with granular policies based on user, device and other factors.
Steps	Make the private network available to the ZTNA Typically an application connector, GRE or IPSec Tunnel Install the ZTNA client on user devices using MDM Set policies to segment user access across the private network

Use broadband Internet for branch to branch connectivity

Level of effort	🔧🔧🔧 - Large
Team(s) involved	Network engineering team IT Team
Product(s)	Cloudflare Magic WAN, Cato Networks, Aryaka FlexCore
Summary	Connectivity between private network locations (eg. data centers and branches) has generally been established using Multi-Protocol Label Switching (MPLS) lines or other forms of private links offered by telecom providers. These MPLS links are typically expensive, and as commodity Internet has become higher quality, organizations can provide the same level of secure access by routing traffic over the Internet via secure tunnels at a fraction of the cost.
Steps	Choose two MPLS-connected locations to start with. These locations will need some form of Internet connectivity. Establish a pair of redundant Anycast GRE or IPsec tunnels over your Internet circuits to your cloud WAN provider’s edge network. Verify health and connectivity between those tunnels. Test performance (throughput, latency, packet loss, jitter) of traffic workloads as similar as possible to production traffic. Change routing policies to migrate production traffic from MPLS to Internet tunnels Repeat at next MPLS-connected location Decommission MPLS circuits

Close all inbound ports open to the Internet for application delivery

Level of effort	🔧 - Small
Team(s) involved	Network engineering team
Product(s)	Zero Trust Reverse Proxies: Akamai EAA, Cloudflare Access, Netskope, Zscaler Private Access (ZPA)
Summary	Open inbound network ports can be found using scanning technology and are a common attack vector. Zero Trust Reverse Proxies allow you to securely expose a web application without opening any inbound ports. The DNS record of the application is the only publicly visible record of the application. And the DNS record is protected with Zero Trust policies. As an added layer of security, internal/private DNS can be leveraged using a Zero Trust Network Access Solution (more details below).
Steps	Install Reverse Proxy application connector — typically a daemon or virtual machine somewhere in the same network Connect the Reverse Proxy Application to the application connector Close all inbound port on the private network with a firewall rule

Applications

Applications include any resource where organizational data exists or business processes are performed. Organizations must first understand the applications that exist and then establish Zero Trust policies for each application or, in some cases, block unapproved applications.

Monitor email applications and filter out phishing attempts

Level of effort	🔧 - Small
Team(s) involved	The team responsible for your email provider configuration (typically IT)
Product(s)	Cloud Email Security: Cloudflare Area 1 Email Security, Mimecast, TitanHQ Browser Isolation: Cloudflare Browser Isolation, Zscaler Cloud Browser Isolation
Summary	Email is one of the few communications channels that attackers have unfettered access to your employees. Deploying a secure email gateway is a critical step to ensure that malicious or untrusted emails do not reach your employees. Additionally, security teams should consider an option to quarantine links in an isolated browser that are not suspicious enough to completely block.
Steps	Configure your domain's MX records to point to the secure email gateway service Monitor for false positives in the first few weeks (Bonus) implement a link based browser isolation approach for borderline suspicious email links.

Inventory all corporate applications

Zero Trust policy enforcement for Applications

Level of effort	For most critical applications: 🔧 - Small For all applications: 🔧🔧🔧 - Large
Team(s) involved	Security team Application development team IT team
Product(s)	Zero Trust Reverse Proxies: Azure App Proxy, Cloudflare Access, Netskope Private Access, Zscaler Private Access (ZPA) Zero Trust Network Access (ZTNA): Cloudflare Access, Netskope Private Access, Zscaler Internet Access (ZIA) CASB: Cloudflare CASB, Netskope CASB, Zscaler CASB Remote Browser Isolation: Cloudflare Browser Isolation, Zscaler Cloud Browser Isolation
Summary	Applications must be protected with Zero Trust policies that consider a user identity, device and network context before authenticating and authorizing access. Applications should have granular policies that enforce least privilege, especially for applications that contain sensitive data. There are three major application types and the Zero Trust security model varies for each type. The major application types are: Private self-hosted applications (addressable only on the corporate network) Public self-hosted applications (addressable over the Internet) SaaS applications Note: If device context or compliance status is a required security policy then typically on-device client software is required.
Steps	Private Self-Hosted Applications: Build an encrypted tunnel between the application and Zero Trust policy layer. Typically this will be an “application connector”, GRE or IPSec tunnel Make the private DNS resolver available for users of the ZTNA device client Build policies based on user, device and network context to establish who can access the application Public Self-Hosted Applications: Move the authoritative DNS or a CNAME record to the Application Reverse Proxy Ensure all inbound ports for closed for the application’s network Build policies based on user, device and network context to establish who can access the application SaaS Applications: There are a few different options to enforce Zero Trust policies for SaaS applications Identity Proxy Cloudflare, Netskope, and Zscaler provide Identity Proxies that allow the same policy enforcement as a reverse proxy self hosted application. This does require that the Identity Proxy is set up as the SSO provider of the SaaS application Remove the existing SSO integration to the SaaS app, if present Integrate the Identity proxy with the SaaS application Ensure the correct SAML attributes are sent for user creation and updates Create policies based on the user, device and network context Secure Web Gateway and Single Sign On The other approach is to use an existing Single Sign On provider to control which users can and cannot access the SaaS application. Then the Secure Web Gateway, with a dedicated IP address, can be used to ensure that only users from managed devices with traffic inspection can access the SaaS application. Add the SaaS application to the SSO provider Create policies to enforce which users are authorized Add the IP address of the Secure Web Gateway instance to the SaaS application’s IP Allow List (most SaaS apps support IP allowlists in their base security settings) Create Secure Web Gateway policies that control which users can access the SaaS application

Protect applications from Layer 7 attacks (DDoS, injection, bots, etc)

Level of effort	🔧 - Small
Team(s) involved	Security team Application development team
Product(s)	Akamai, AWS, Azure, Cloudflare, GCP
Summary	Any self-hosted application is susceptible to Layer 7 attacks including DDoS, Code Injection, Bots and more. Security teams should deploy a Web Application Firewall and DDoS protection in front of all self-hosted applications, privately and publicly addressable.
Steps	Add any public application’s authoritative DNS record Enable the Web Application Firewall and DDoS protection

Enforce HTTPS and DNSsec

Level of effort	🔧 - Small
Team(s) involved	Security team Application development team
Product(s)	Akamai, AWS, Azure, Cloudflare, GCP
Summary	Any self-hosted web application should leverage HTTPS and DNSSec. This prevents any potential for packet sniffing or domain hijacking.
Steps	Add any public application’s authoritative DNS record Set HTTPS to strict and enable DNSSEC

Data Loss Prevention and Logging

Once you have established all the Zero Trust elements of your architecture to this point, your architecture will be generating large volumes of data on what’s happening inside your network. At this point, it’s time to implement Data Loss Prevention and Logging. These are a set of processes and tools that focus on keeping sensitive data inside of a business and flagging any potential opportunities for data leakage. Organizations must first understand where their sensitive data exists. Then they can establish Zero Trust controls to block sensitive data being accessed and exfiltrated.

Establish a process to log and review traffic on sensitive applications

Define what data is sensitive and where it exists

Prevent sensitive data from leaving your applications

Level of effort	🔧🔧🔧 - Large
Team(s) involved	Security team IT Team Compliance/Legal team
Product(s)	In-line Data Loss Prevention (DLP): Cisco Umbrella, Cloudflare Gateway, Netskope Next Gen SWG, Zscaler Internet Access (ZIA)
Summary	In-line DLP solutions inspect user traffic and file uploads/downloads for sensitive data. The sensitive data is available in well known predefined lists (e.g. PII, SSNs, Credit Cards, etc) or specific patterns can be manually configured by an administrator. DLP controls should be enabled for sensitive applications and can be expanded for all user traffic.
Steps	Install the client software from the DLP provider Ensure there is no existing VPN or other tool that will disrupt connectivity Ensure TLS decryption is enabled and a root certificate is present on each user machine Enable DLP controls Monitor for DLP block events and verify if it is valid or a false positive

Identify misconfigurations and publicly shared data in SaaS tools

Level of effort	🔧 - Small
Team(s) involved	Security team
Product(s)	API based Cloud Access Security Broker (CASB): Cloudflare CASB, DoControl, Netskope, Zscaler CSPM
Summary	CASBs integrate with major SaaS applications via an API integration. The CASB will then scan the SaaS application for known security misconfiguration and data that has been publicly shared. A security team should establish a regular cadence to review CASB findings.
Steps	Connect each SaaS application via the provider’s API integration instructions Run scans for each SaaS application Review the scan results and begin remediation in each SaaS application where appropriate

Establish a Security Operations Center (SOC) for log review, policy updates and mitigation

Stay up to date on known threat actors

Level of effort	🔧 - Small
Team(s) involved	Security team
Product(s)	Threat Intelligence providers: Cloudflare Radar, CISA, OWASP
Summary	There are multiple providers focused on compiling a list of known threat actors and malicious websites. These threat feeds can be automatically loaded into a Secure Web Gateway to protect users from attacks.
Steps	Connect threat feed into Secure Web Gateway Enable threat protection in DNS and HTTP filtering

Steady State

Once you have built out your Zero Trust architecture for all the other elements of your organization, there are a set of actions you can take to move your organization to a Zero Trust steady state, ensuring consistency with the architecture moving forward.

Employ a DevOps approach to ensure consistent policy enforcement for all new resources

Level of effort	🔧🔧🔧 - Large
Team(s) involved	Security team Application development team
Product(s)	Infrastructure automation: Ansible, Puppet, Terraform
Summary	Infrastructure automation tools allow developers to automatically deploy Zero Trust security as part of their application development pipeline. Establish internal testing that will trigger if an application is deployed with Zero Trust Reverse Proxy protection.
Steps	Define a standard policy for new applications Add tests in the application deployment process that require Zero Trust Reverse Proxy protection

Example implementation timeline

Every Zero Trust Architecture deployment is unique but there are a common set of steps that most projects follow. This is a recommended timeline for a business getting started on a Zero Trust Architecture implementation.

Timeline	Goal	Relevant Products
Phase 1	❑ Deploy global DNS filtering	Cisco Umbrella DNS, Cloudflare Gateway, DNSFilter, Zscaler Shift
	❑ Monitor inbound emails and filter out phishing attempts	Security Email Gateways: Cloudflare Area 1 Email Security, Mimecast, TitanHQ Browser Isolation: Cloudflare Browser Isolation, Zscaler Cloud Browser Isolation
	❑ Identify misconfigurations and publicly shared data in SaaS tools	Cloudflare CASB, DoControl, Netskope CASB, Zscaler CSPM
Phase 2	❑ Establish corporate identity	Microsoft Azure AD, Okta, PingOne, Onelogin
	❑ Enforce MFA for all application	Identity providers: Microsoft Azure AD, Okta, PingIdentity PingOne, Onelogin, Duo Application Reverse Proxies: Azure AD App Proxy, Akamai EAA, Cloudflare Access, Netskope Private Access, Zscaler Private Access (ZPA)
	❑ Enforce HTTPS and DNSsec	Akamai, AWS, Azure, Cloudflare, GCP
	❑ Block or isolate threats behind SSL	TLS Decryption: Cloudflare Gateway, Netskope Next Gen SWG, Zscaler Internet Access (ZIA) Isolated Browsers: Cloudflare Browser Isolation, Zscaler Cloud Browser Isolation
	❑ Zero Trust policy enforcement for publicly addressable applications	Zero Trust Reverse Proxies: Azure App Proxy, Cloudflare Access, Netskope Private Access, Zscaler Private Access (ZPA)
	❑ Protect applications from layer 7 attacks (DDoS, Injection, Bots, etc)	Akamai, AWS, Azure, Cloudflare, GCP
	❑ Close all inbound ports open to the Internet for application delivery	Akamai EAA, Cloudflare Access, Netskope Private Access, Zscaler Private Access (ZPA)
Phase 3	❑ Inventory all corporate applications	Secure Web Gateway and CASB’s with Shadow IT discovery: Cloudflare Gateway, Microsoft Defender for Cloud Apps, Netskope Next Gen SWG, Zscaler Internet Access (ZIA)
	❑ Zero Trust policy enforcement for SaaS applications	Zero Trust Network Access (ZTNA): Cloudflare Access, Netskope, Zscaler Private Access (ZPA) CASB: Cloudflare CASB, Netskope CASB, Zscaler CASB
	❑ Segment user network access	Cloudflare Zero Trust (Access and Gateway), Netskope Private Access, Zscaler Private Access (ZPA)
	❑ Zero Trust Network Access for privately addressable applications	Cloudflare Access, Netskope Private Access, Zscaler Internet Access (ZIA)
	❑ Implement MDM/UEM to control corporate devices	Mac: Jamf, Kandji Windows: Microsoft Intune
	❑ Define what data is sensitive and where it exists	DataDog, Splunk, SolarWinds
	❑ Send out hardware based authentication tokens	Hard Keys: Yubico
	❑ Stay up to date on known threat actors	Cloudflare Radar, CISA, OWASP
Phase 4	❑ Enforce hardware token based MFA	Hard Keys: Yubico
	❑ Establish a SOC for log review, policy updates and mitigation	N/A
	❑ Implement endpoint protection	VMWare Carbon Black, Crowdstrike, SentinelOne, Microsoft Windows Defender
	❑ Inventory all corporate devices, APIs and services	Device Inventory: VMWare Carbon Black, Crowdstrike, Oomnitza, SentinelOne API/Service inventory: Cloudflare Application Connector, Zscaler Private Access (ZPA)
	❑ Use broadband Internet for branch to branch connectivity	Cloudflare Magic WAN, Cato Networks, Aryaka FlexCore
	❑ Establish a process to log and review employee activity on sensitive applications	Secure Web Gateway (SWG): Cisco Umbrella, Cloudflare Gateway, Netskope, Zscaler Internet Access (ZIA) Security Incident and Event Monitoring (SIEM): DataDog, Splunk, SolarWinds
	❑ Stop sensitive data from leaving your applications (e.g. PII, credit cards, SSNs, etc)	Cisco Umbrella, Cloudflare Gateway, Netskope Next Gen SWG, Zscaler Internet Access (ZIA)
	❑ Employ a DevOps approach to ensure policy enforcement for all new resources	Ansible, Puppet, Terraform
	❑ Implement auto-scaling for on-ramp resources	Load balancers: Akamai, Cloudflare Infrastructure automation: Ansible, Puppet, Terraform

A Roadmap to Zero Trust Architecture

Transform your network and modernize your security

Questions about Zero Trust?

Components of a Zero Trust Architecture

Reference Architecture

Users

Establish a corporate identity

Enforce multi-factor authentication for all applications

Endpoints and Devices

Implement mobile device management

Implement endpoint protection

Inventory devices, APIs and services

Internet Traffic

Block DNS requests to known threats or risky destinations

Block or isolate threats behind SSL/TLS

Network

Segment user network access

Use broadband Internet for branch to branch connectivity

Close all inbound ports open to the Internet for application delivery

Applications

Monitor email applications and filter out phishing attempts

Inventory all corporate applications

Zero Trust policy enforcement for Applications

Protect applications from Layer 7 attacks (DDoS, injection, bots, etc)

Enforce HTTPS and DNSsec

Data Loss Prevention and Logging

Establish a process to log and review traffic on sensitive applications

Define what data is sensitive and where it exists

Prevent sensitive data from leaving your applications

Identify misconfigurations and publicly shared data in SaaS tools

Establish a Security Operations Center (SOC) for log review, policy updates and mitigation

Stay up to date on known threat actors

Steady State

Employ a DevOps approach to ensure consistent policy enforcement for all new resources

Example implementation timeline