Forrester ZTX Explained: Seven Domains for Implementing Zero Trust

Implementing Zero Trust requires more than authenticating users. Organizations also need to consider devices, networks, applications, and the data those applications handle.

Forrester Research’s Zero Trust eXtended (ZTX) Ecosystem is a framework for translating Zero Trust principles into technology selection, implementation, and operations. It organizes security capabilities into seven core domains and helps organizations connect those capabilities to control access to important resources.

This article draws on The Forrester Wave™: Zero Trust eXtended Ecosystem Platform Providers, Q3 2020, published on September 24, 2020, and Forrester’s public explanation of ZTX. The controls and implementation steps below are illustrative recommendations, rather than a translation of the report or an official Forrester compliance checklist. The report’s historical vendor ratings are not presented as current product rankings.

What problem does ZTX address?

Zero Trust avoids granting unconditional access simply because someone is on an internal network or has already signed in. Access decisions consider the resource, the user’s permissions, device condition, and other relevant context. Access is limited to what is needed.

That principle still leaves practical questions: Where should an organization start? Which capabilities should it connect? How should it use its existing investments?

ZTX helps organizations:

• Identify sensitive data and the people, devices, and systems that use it.
• Map existing controls and find gaps in coverage or integration.
• Select technologies that support their security objectives.
• Connect security analysis to access decisions and incident response.
• Improve the implementation as business needs and infrastructure change.

Buying a product does not complete Zero Trust. The capabilities need to share useful information and produce effective controls across the environment.

The seven core ZTX domains

These domains are sometimes described as seven requirements. They are best understood here as areas to address when designing and operating a Zero Trust environment.

Domain	Key question
Identity Security	Who is requesting access, and what are they allowed to do?
Device Security	Which device is being used, and does its condition meet policy?
Network Security	Which connections are allowed, and how is lateral movement limited?
Workload/Application Security	Which systems are running, and what can they access?
Data Security	What information needs protection, and how may it be used?
Security Visibility and Analytics	What is happening, and what does it reveal about risk?
Security Automation and Orchestration	How does the organization act on identified risk?

Terminology varies across the report: identity is also described as people/identity or people/workforce security, and application protection is included in workload security. The correct English term for the data domain is Data Security.

A useful way to understand the framework is to treat people, devices, networks, workloads, and data as the areas being protected, with visibility, analytics, automation, and orchestration supporting them across domains.

1. Identity Security

Establish who is requesting access and manage their permissions. A legitimate identity should receive only the access needed for its role.

The scope includes employees, contractors, and administrators. Service identities also need lifecycle and permission management, overlapping with workload security.

Example controls:

• Centralize identity management and update access when people join, change roles, or leave.
• Use multifactor authentication (MFA), favoring phishing-resistant methods such as passkeys where appropriate.
• Use single sign-on (SSO) to apply consistent authentication and access policies.
• Grant least-privilege access and review permissions regularly.
• Separate administrative access from routine work and use privileged access management (PAM) to control elevated sessions.
• Use device condition and suspicious sign-in activity to trigger additional authentication, deny access, or revoke sessions.

For example, an accounts payable employee might access invoice processing functions without receiving access to HR records or infrastructure administration.

2. Device Security

Identify devices and incorporate their security condition into access decisions. A valid user account does not make a compromised device safe.

Example controls:

• Maintain an inventory of computers, smartphones, and other business devices.
• Use mobile device management or unified endpoint management (MDM/UEM) to manage settings, updates, and lost devices.
• Deploy endpoint detection and response (EDR) to detect suspicious activity and isolate affected endpoints.
• Patch operating systems and applications.
• Require disk encryption, screen locking, and appropriate local privileges.
• Restrict access from devices that are unmanaged, unpatched, or missing required security controls.

For example, a managed and compliant computer may access a business application, while an unmanaged personal device is prevented from downloading sensitive records.

3. Network Security

Allow necessary connections and limit an attacker’s ability to move between systems.

Example controls:

• Discover communication flows and define the connections each system needs.
• Use microsegmentation to restrict communication between applications or workloads.
• Apply firewall rules and cloud network controls to deny unnecessary connections.
• Use Zero Trust network access (ZTNA) to provide access to specific authorized applications.
• Encrypt connections using TLS or other appropriate protocols.
• Monitor DNS and outbound traffic for malicious connections or data exfiltration.

For example, a web server may communicate with a designated application service while being unable to connect freely to unrelated servers or management interfaces.

Segmentation and encryption alone are insufficient. They need to work with identity, device context, and application authorization.

4. Workload/Application Security

Protect running systems and control what they can access. Workloads include virtual machines, containers, and serverless functions.

Example controls:

• Inventory applications, services, owners, and dependencies.
• Give services distinct identities and limit their permissions and destinations.
• Use short-lived credentials and secrets management instead of shared passwords or embedded keys.
• Use mutual TLS (mTLS) where appropriate to authenticate services, alongside explicit authorization of permitted operations.
• Enforce authorization within applications to prevent access to another user’s records.
• Assess vulnerabilities, scan dependencies and container images, and monitor runtime behavior.
• Use web application firewalls (WAFs) and API gateways as supporting controls against malicious requests.

For example, a reporting service may read the records needed to generate reports without being allowed to change customer information or access unrelated databases.

5. Data Security

Understand where data resides, how sensitive it is, and how it may be used, stored, and shared.

Example controls:

• Discover sensitive records, credentials, and confidential documents, and assign owners.
• Classify data and define permissions for reading, modifying, and sharing it.
• Encrypt data at rest and in transit, and control access to encryption keys.
• Use data loss prevention (DLP) to detect or restrict inappropriate transfers.
• Review public exposure, external sharing, and download permissions in SaaS and storage services.
• Minimize collection and retention, and delete data according to defined schedules.
• Audit data access and maintain tested backups to support recovery from destruction or alteration.

For example, permission to view individual customer records need not include permission to export the entire customer database or share it externally.

Encryption does not prevent misuse by an account that can decrypt the data. Authorization and monitoring remain necessary.

6. Security Visibility and Analytics

Collect evidence across domains and use it to identify risk. Storing logs is only the beginning; the information needs to support detection and decisions.

Example controls:

• Aggregate authentication, endpoint, network, application, and data access logs.
• Use security information and event management (SIEM) to correlate events.
• Compare activity with normal user and device behavior.
• Detect sequences such as a suspicious sign-in followed by a large data download.
• Add asset and permission context to assess impact and priority.
• Monitor logging gaps, synchronize clocks, protect log integrity, and tune detection rules.

For example, a suspicious sign-in combined with an endpoint infection alert can justify a higher-priority investigation than either event alone. Logs may contain personal or sensitive information, so their access and retention also need controls.

7. Security Automation and Orchestration

Turn analysis into coordinated action. Automation executes individual tasks; orchestration connects multiple tasks using defined conditions and sequencing.

Example controls:

• Use security orchestration, automation, and response (SOAR) or equivalent workflows to execute response procedures.
• Isolate an endpoint or restrict access following a validated EDR detection.
• Revoke sessions and require fresh authentication when an account may be compromised.
• Automate ticket creation, notifications, and evidence collection.
• Require approval for high-impact actions and expand automation gradually.
• Verify that actions succeeded and define reversal and recovery procedures for false positives.

For example, a workflow can detect a suspicious sign-in, retrieve endpoint and access context, revoke sessions when defined conditions are met, and notify the response team.

How the seven domains work together

Consider an employee accessing a customer information application remotely.

Stage	Main domain	Example implementation
Verify the user	Identity	Authenticate with MFA and check required business permissions
Evaluate the device	Device	Check management status, updates, and security controls
Limit connectivity	Network	Permit access to the required application
Authorize operations	Workload/Application	Enforce the user’s permissions within the application
Control data use	Data	Restrict record access and downloads
Analyze activity	Visibility and Analytics	Correlate authentication and data access events
Respond to risk	Automation and Orchestration	Trigger additional authentication, session revocation, isolation, or notification

This is an illustrative flow, not a fixed sequence that runs only once. Risk can change during an active session, and controls should respond accordingly.

Additional evaluation criteria: usability, APIs, and future infrastructure

The 2020 Forrester Wave includes three additional criteria within its Current offering category. These are useful lenses for assessing whether a platform can be operated, integrated, and developed over time; they should not be confused with three additional core ZTX domains.

Manageability and Usability

Complex administration can cause mistakes, while excessive friction can encourage users to bypass controls.

Example practices and evaluation questions:

• Provide clear views of policies, assets, and alerts.
• Separate administrative roles and record and approve relevant configuration changes.
• Test policies on a small scope before broad enforcement.
• Reduce user friction with SSO and usable authentication.
• Provide understandable denial messages, support procedures, and recovery paths.

APIs

APIs connect identity, endpoint, analytics, and response capabilities. Their existence is less useful than their ability to support the specific information exchanges and actions an organization needs.

Example practices and evaluation questions:

• Check whether APIs support device risk retrieval, session revocation, and policy updates.
• Review documentation, integrations, event notifications, and usage limits.
• Protect API credentials and limit their scope and lifetime.
• Design retries, duplicate-action prevention, and audit logging.
• Define access behavior and manual procedures when integrations fail.

Protecting an application’s own APIs also belongs within workload and application security.

Future State of Zero Trust Infrastructure

This criterion was added to the 2020 evaluation. Organizations can use it as a prompt to consider whether an implementation will support future architecture and operating requirements.

Example practices and evaluation questions:

• Define a target environment covering on-premises systems, cloud services, and SaaS.
• Consider how controls will extend to new applications and working practices.
• Assess whether existing security investments can support phased adoption.
• Review integration plans, scalability, roadmaps, and migration options.
• Plan for cost, staffing, operational effort, and business continuity during failures.

A practical way to use ZTX

The following is an implementation approach for using the seven domains, rather than an official Forrester sequence.

1. Choose what to protect. Identify important data, business processes, and owners.
2. Map access and dependencies. Document who accesses each resource, from which devices, through which applications and connections.
3. Assess all seven domains. Identify existing controls, missing capabilities, and integration gaps.
4. Start with a focused scope. Prioritize high-risk areas such as administrative access or critical applications.
5. Test the path from detection to action. Verify logging, detection, policy decisions, and enforcement.
6. Measure and improve. Track unnecessary privileges, detection and response time, false positives, support requests, and operational effort.

Assign owners, scope, exceptions, and verification methods to each control. The objective is to allow necessary access and respond to changing risk, with the seven domains serving as a guide to coverage and integration.

References

• Forrester Research, Chase Cunningham, The Forrester Wave™: Zero Trust eXtended Ecosystem Platform Providers, Q3 2020, September 24, 2020 (supplied report). Source for the seven domains, additional evaluation criteria, and emphasis on integration and phased adoption.
• Forrester: The Tao Of Zero Trust — Primary explanation of the purpose of ZTX and sustained implementation.
• Portnox: What is a Zero Trust Extended Framework — Related explanatory article.
• Cisco Japan Blog: Zero Trust eXtended Ecosystem Platform Providers, Q3 2020 — Japanese commentary on the 2020 report.