Your Zero Trust program can stall before it starts. This happens when identity, cloud, network, data, and endpoint teams fund disconnected controls.
A single-platform purchase can also dictate the architecture. That can create coverage gaps, duplicate spend, and weak board reporting.
A framework needs accountable owners, measurable outcomes, and clear integration choices. Without them, it becomes another security diagram.
Forrester’s Zero Trust eXtended (ZTX) turns “never trust, always verify” into an operating program. It covers users, devices, workloads, networks, data, analytics, and automation.
This Forrester Zero Trust Model: Executive Tech Guide for CISOs maps seven pillars to owners, controls, measures, and a 30/90/180-day plan. It also compares ZTX with NIST SP 800-207 and federal guidance.
The main risk is not a missing tool. It is buying tools before setting ownership and architecture.
Is Forrester ZTX the right operating model?
Forrester’s Zero Trust eXtended, or ZTX, fits firms with fragmented security work. It brings identity, cloud, network, endpoint, data, and development teams into one model.
ZTX does not replace architecture design, regulatory duties, or business risk decisions. It helps teams organize the work those decisions require.
Zero Trust began at Forrester Research through John Kindervag’s challenge to perimeter security. The old model trusted users inside the corporate network more than outsiders.
ZTX rejects that assumption. Think of a secure office where each room checks a badge, device, and purpose.
ZTX is a capability map, not a shopping list. One vendor may support several domains, but its suite cannot create shared ownership.
A suite also cannot fix poor policy or prove lower exposure. Those outcomes need clear operating decisions.
ZTX connects seven protection domains: users, devices, workloads, network, data, visibility and analytics, and automation and orchestration. It helps most in hybrid work, multi-cloud estates, mergers, and independent business units.
The most frequent error is treating multi-factor authentication, or MFA, as the entire program. MFA checks more than one identity proof.
A passkey plus a device signal is one example. MFA is needed, but it cannot control an overprivileged cloud workload.
It also cannot protect a public API or sensitive data on an unmanaged laptop. Identity is the front door, not the whole building.
ZTX should not be the first major program for a company lacking basic facts. The company must first identify critical applications, privileged accounts, and sensitive data stores.
Start with asset inventory, centralized identity and access management (IAM), and usable security logs. IAM is the system that manages who can access company resources.
Automating trust decisions without those facts is like adding badge readers before finding valuable rooms. You need to know where cash, records, and production equipment are kept.
For a U.S. Enterprise, first fund a 30-day review of crown-jewel services and access paths. Do not start with a broad request for a “Zero Trust platform.” Name each asset owner, user type, device state, data type, policy gap, and business impact.
That choice defines the scope. The next task is to assign the seven domains to teams that can operate them.
Map seven ZTX pillars to owned controls
Each ZTX pillar needs one accountable executive, a minimum control set, and proof of lower access risk. The CISO owns the program result.
The CISO cannot own every technical action across IT, cloud, data, and engineering. Each team must own its part.
The seven pillars work like connected gears. A strong identity check loses value when an unmanaged device can copy data.
Network segmentation helps limit movement between systems. It cannot protect a workload with an exposed secret.
Analytics can find suspicious activity only when teams join logs from identity, endpoints, cloud, and applications. Missing logs create blind spots.
| ZTX pillar | Business objective | Control evidence | Accountable owner |
|---|
| Users | Verify people and service identities | Phishing-resistant MFA, PAM, access reviews | IAM leader |
| Devices | Allow trusted endpoint access | Managed coverage, EDR health, encryption | CIO or endpoint lead |
| Workloads | Protect applications and machine identities | Workload identity, secrets control, API policy | Cloud and app engineering |
| Network | Limit unneeded connections | ZTNA, segmentation, verified flows | Network leader |
| Data | Protect sensitive information | Classification, encryption, DLP | Data owner |
| Visibility and analytics | Detect risky behavior | XDR telemetry, detection coverage | SOC leader |
| Automation and orchestration | Respond at machine speed | Tested containment playbooks | Security operations |
Which controls should come first?
Start with phishing-resistant MFA for privileged users and just-in-time privileged access. Add managed-device posture and strong controls around one critical workload.
Just-in-time access grants an elevated role for a short task window. It avoids leaving administrator rights active for months.
Major specialist sources repeatedly advise securing privileged identity before broad network redesign. A stolen administrator session can bypass many network controls when privileges remain excessive.
Microsegmentation limits which systems can communicate. Think of locked interior doors inside a building.
It works after teams map application links, name exception owners, and test rollback. It fails when teams apply it blindly to thousands of flows.
A common case involved a Chicago manufacturer separating production-support services. The team had not documented a legacy reporting link.
The first policy blocked an overnight batch process and delayed shipment data. Leaders then felt pressure to disable controls.
A limited pilot with flow discovery would have found that dependency first. Pilot evidence protects both security and operations.
The pillar map gives every team a role. Next, place the framework beside NIST and federal guidance correctly.
Use ZTX, NIST, and federal guidance differently
Forrester ZTX, NIST SP 800-207, and federal Zero Trust guidance work together. They should not be treated as interchangeable.
ZTX organizes enterprise capabilities. NIST explains architecture principles, while federal guidance sets U.S. agency expectations.
NIST Special Publication 800-207 defines a policy decision point. This component decides whether access should be allowed.
It also defines a policy enforcement point. This component applies the decision.
These concepts matter for architecture. They do not tell a CISO who owns data classification or pilot funding.
| Reference | Best use | What it cannot decide | U.S. Private-sector fit |
|---|
| Forrester ZTX | Capabilities, ownership, investment sequence | Exact technical architecture | High |
| NIST SP 800-207 | Policy architecture and continuous verification | Program governance and priorities | High |
| Federal Zero Trust Strategy | Agency targets and federal alignment | Commercial risk appetite | Conditional |
Is NIST 800-207 sufficient alone?
NIST SP 800-207 is not enough by itself for an enterprise program. It explains access decisions but does not create a RASCI model.
It also does not create a board report or 180-day delivery plan. Those need business ownership.
The publication remains a key architecture reference. The National Institute of Standards and Technology Computer Security Resource Center hosts official NIST publications and updates.
Federal targets apply directly to agencies. They can also matter through customer contracts and government supply-chain duties.
FedRAMP duties, customer security terms, and DoD supply-chain expectations can change the decision. Most commercial firms should ask which federal practice lowers material risk.
A CISO should use ZTX to run the program, NIST to test architecture, and federal guidance to assess duties. This split avoids costly compliance theater.
Use risk to set the next priority. Tools should follow that choice, not make it.
Prioritize access paths by business risk
The first Zero Trust investment should protect the access path with the highest combined risk. Consider business impact, exposure, and weak controls.
A product category is not a priority. A risky access path is.
An access path is the full route from requester to resource. It includes identity, device, network route, application, data, and permission.
Consider a contractor using an unmanaged device to reach a production cloud console. That one path may need better MFA, device checks, and just-in-time privilege.
It may also need ZTNA, logging, and faster offboarding. ZTNA gives app access without opening the whole network.
Score each candidate from 1 to 5 for asset value, external exposure, and privilege level. Also score third-party access, unmanaged devices, and lateral-movement potential.
Prioritize paths scoring 18 to 30. Do this before funding paths that are only easy to deploy.
Which use cases usually rank first?
Privileged workforce access often ranks first. So do third-party access, cloud administration, exposed APIs, and unmanaged-device access.
Machine identities also need equal attention. Workloads often keep broad permissions long after projects end.
A machine identity is a credential for an application, script, or service. It is not tied to a person.
It may access cloud resources at all hours. Excess permissions therefore create serious risk.
Evaluate Google, Microsoft, Zscaler, Palo Alto Networks, CrowdStrike, and other providers against the priority path. Do not use a generic feature list.
Score IAM and EDR links, telemetry quality, policy portability, and nonhuman identity support. Also score performance, outage design, admin effort, and three-year operating cost.
Ask each shortlisted provider to enforce one real access path during a 30 to 60-day pilot. Require evidence of policy coverage, user friction, support tickets, log quality, rollback time, and operating effort. A strong demo cannot prove a policy will work across a legacy estate.
Most guides oversimplify platform consolidation. One platform can reduce integration work, but it can also create control-plane dependence.
It can also make policy export hard. Choose a platform only when shared telemetry improves measured risk outcomes.
Risk-ranked use cases make spending defensible. A timed plan turns those choices into delivery.
OT needs a different adoption pattern. Safety, uptime, vendor limits, and legacy protocols can outweigh a normal IT rollout.
Start by mapping remote-maintenance paths, engineering workstations, jump hosts, and enterprise-to-industrial connections. Use strong identity and time-bound remote access before changing production traffic.
Use passive discovery when active scans could disrupt fragile assets. Passive discovery watches traffic without probing systems.
OT segmentation should create controlled links between zones. It also needs recovery steps and plant-owner approval.
Do not force every controller into an IT-style agent model. Reduce unneeded access while preserving safe operations and incident response.
Forrester Wave reports can help compare the market. They are point-in-time evaluations, not a Zero Trust architecture blueprint.
Use them to review vendor direction, integration breadth, and category strengths. Relevant categories include IAM, endpoint security, and cloud workload security.
They also cover network segmentation, data protection, analytics, and automation. They cannot replace pilot evidence from your own priority paths.
Market consolidation can make an integrated platform appealing. A leading category position does not prove policy portability or outage resilience.
It also does not prove support for legacy apps or lower three-year costs. The next section turns risk choices into a timed plan.
Build a 30, 90, and 180-day ZTX plan
A credible ZTX plan finds critical access paths in 30 days. It proves controls by 90 days and scales tested patterns by 180 days.
The plan should show what will change, who will run it, and what proof unlocks funding. Funding gates prevent broad spending without evidence.
Days 0 through 30: establish facts
Identify crown-jewel services, privileged roles, sensitive data stores, and third parties. Identify unmanaged devices and cloud workloads too.
Set a baseline for MFA coverage, standing privileges, managed assets, detection time, and critical policy exceptions. A baseline shows whether risk is actually falling.
Create a small steering group led by the CISO and CIO. Include IAM, network, cloud, data, app engineering, and legal or compliance.
Include two business owners. Their first decision is one or two pilots protecting material access paths.
Days 31 through 90: prove the controls
Pilot phishing-resistant MFA, privileged access management, ZTNA, or workload segmentation. Use a defined population and application.
Measure completion rates, user support demand, denied-access accuracy, detection coverage, and rollback time. These measures show both protection and service impact.
In practice, the lesson is simple: measure user experience alongside security coverage. When legitimate access fails often, teams create exceptions.
Those exceptions often become permanent attack paths. Friction that goes unmeasured becomes hidden risk.
Days 91 through 180: scale patterns
Publish reference patterns for workforce access, third parties, cloud workloads, APIs, and sensitive data. Expand only designs that met pilot security and service targets.
Then automate repeatable actions. Examples include disabling compromised accounts and isolating unhealthy endpoints.
Keep enterprise-wide microsegmentation and wholesale tool replacement outside the first 180 days. Make an exception only when an urgent threat demands it.
Large changes without dependency data can cause expensive service outages. Those outages may exceed the immediate risk reduction.
The plan works only when leaders know who can decide, approve, and challenge each action. Governance gives the plan its force.
Govern ZTX with RASCI, not a CISO silo
Zero Trust needs a RASCI model. The CISO cannot control identity, network, cloud, data, application design, and business operations alone.
RASCI means Responsible, Accountable, Supporting, Consulted, and Informed. It makes decision rights visible.
Responsible means the team doing the work. Accountable means the leader who owns the result.
Only one person should be Accountable for a decision. Multiple accountable owners delay urgent exception approvals.
Who owns the major decisions?
The CISO is Accountable for risk outcomes, security principles, and escalation. The CIO is Accountable for technology delivery and continuity.
IAM is Responsible for lifecycle, MFA, PAM, and access reviews. Cloud and network teams are Responsible for enforcement.
Data owners approve classification and permitted use. Application leaders own workload identity, secrets, API permissions, and safe deployment patterns.
Business owners approve time-limited risk acceptance. They understand the service impact of delaying a control.
Each exception needs a named business owner and compensating controls. It also needs an expiry date from 30 to 90 days.
Each exception also needs a remediation owner. Security validates residual risk but should not quietly accept it for the business.
A monthly operating review should resolve blockers and review pilots. A quarterly board report should show residual risk and high-risk exceptions.
The board report should also show investment choices and reduced standing access. It should show whether detection delays are falling.
A practical RASCI matrix should accompany the ZTX security model and cover each decision level. Team-level charts alone are not enough.
For example, the CISO owns risk thresholds and exception governance. The CIO owns service continuity and delivery funding.
IAM owns MFA, privileged access, and identity lifecycle controls. Network and cloud leaders own policy enforcement.
Application engineering owns workload identities and API authorization. Data owners approve data-use rules, while business leaders approve time-limited risk acceptance.
Learn more
Here are some additional resources on this subject:
