At a glance
- The risk: Zero Trust can become a collection of security products while gaps between identity, devices, networks, applications, and data still permit unsafe access.
- The governance implication: The five pillars need common decision rules, consistent enforcement, and accountable owners—not five disconnected projects.
- The leadership takeaway: Start with high-consequence business workflows, define who can deny or revoke access, and govern every exception to the same standard.
Zero Trust is often introduced as an architecture programme or a technology purchase. The consequential business decision is more specific: under what conditions should an identity, device, application, or workload be allowed to reach a resource—and who has authority to deny, step up, or revoke that access?
That decision matters because modern access paths cross cloud services, remote devices, APIs, third parties, and data platforms. A strong control in one domain can be undermined by a weak assumption in another.
The executive challenge is not to “trust no one.” It is to make access decisions using sufficient evidence, enforce them close to the resource, and ensure that exceptions cannot quietly become permanent trust.
The Five Pillars Protect Different Parts of the Decision
CISA’s Zero Trust Maturity Model Version 2.0, published in April 2023, organizes Zero Trust around five pillars: identity, devices, networks, applications and workloads, and data. It also identifies visibility and analytics, automation and orchestration, and governance as cross-cutting capabilities.
The CISA model was developed as a roadmap for United States federal agencies. It is not a universal mandate for every enterprise, but its structure is useful because each pillar contributes evidence to the same access decision.
1. Identity
Identity covers who or what is requesting access, the strength of authentication, the privileges assigned, and the lifecycle of those privileges. The governance question is not only whether MFA is enabled; it is whether the identity has the right authority for this resource and action. That distinction is explored further in Why MFA Isn’t Enough.
2. Devices
A valid identity may still operate from a compromised, unmanaged, or unsupported device. Device health, management status, configuration, and security signals should influence whether access is allowed, restricted, or challenged.
3. Networks and Environments
Network location should not create automatic trust. Segmentation, encrypted communication, traffic controls, and policy enforcement reduce the ability of a compromised identity or workload to move freely between resources.
4. Applications and Workloads
Applications, APIs, services, and machine identities need their own authorization and policy controls. A user-facing login does not protect a back-end service if service accounts, tokens, or application permissions grant broader access than intended.
5. Data
Data is where business consequence becomes tangible. Classification, access policy, encryption, monitoring, and usage restrictions should reflect the sensitivity and purpose of the information—not merely the system in which it happens to reside.
Five Pillars Cannot Operate as Five Separate Projects
NIST SP 800-207, finalized in August 2020, describes Zero Trust as a shift from static, network-based perimeters toward protection focused on users, assets, and resources. It states that trust should not be granted implicitly because of network location or asset ownership.
That principle is lost when each pillar is implemented independently. An identity team may deploy strong authentication, while an application still accepts an overprivileged token. A device platform may identify an unhealthy endpoint, while a network path continues to allow access. A data platform may encrypt information, while classification is too weak to determine who should use it.
Illustrative scenario: a finance employee authenticates with phishing-resistant MFA from a managed laptop, but an old reporting application allows broad exports through a service account that is not evaluated by the same policy. No individual control is necessarily broken. The exposure exists in the handoff between pillars. This is a hypothetical example, not a reported client case.
The governance requirement is therefore integration: common policy inputs, consistent decision logic, enforcement at relevant control points, and evidence that a denied or revoked decision propagates across the access path.
Begin With the Business Decision, Not the Product Map
A Zero Trust roadmap should begin with high-consequence workflows and resources. In a regulated organization, those may include privileged administration, payment release, customer-data access, model deployment, production changes, or third-party connectivity.
For each workflow, leaders should define the subject, device or workload, target resource, permitted action, required assurance, and conditions that trigger denial, step-up authentication, or session revocation. This converts an architectural principle into an explicit business rule.
NIST describes migration to Zero Trust as an incremental journey rather than a wholesale replacement of infrastructure. That supports a risk-led sequence: protect the highest-value resources and most consequential decisions first, then expand based on evidence and dependency readiness.
The application layer deserves particular attention because business rules are often enforced there. As discussed in Why Most Companies Fail at Application Security, accountability needs to enter while architecture and release decisions can still be changed—not after weak access paths have become operational dependencies.
Zero Trust Needs an Owner Who Can Say No
A policy engine can issue an allow or deny result, but leadership still determines the policy, acceptable evidence, exceptions, and consequences. Those are governance decisions.
Each critical workflow needs a business owner accountable for the outcome, technical owners responsible for enforcement across the five pillars, and a risk authority able to challenge assumptions. Someone must also have explicit authority to disable an unsafe path, revoke access, or delay a release when the evidence is insufficient.
Exceptions should identify the decision owner, business rationale, scope, compensating controls, expiry date, and closure evidence. Without those conditions, “temporary” access can become an undocumented trust relationship.
Useful measures include the percentage of critical workflows covered by integrated policy enforcement, stale privileged access, unmanaged-device exceptions, applications or service identities outside central policy, high-value data without adequate classification, and time to revoke access after a material risk signal. These measures show whether Zero Trust changes decisions—not merely whether tools have been deployed.
Questions for Leadership
- Which high-consequence business actions still rely on network location, device ownership, or a legacy application as an implicit trust signal?
- Who owns the access outcome across identity, device, network, application, and data controls—and who can stop access when the signals conflict?
- Which Zero Trust exceptions have no clear expiry, compensating control, or evidence that the underlying weakness will be removed?
Closing Thought
The five pillars are not the outcome of Zero Trust. They are the evidence and enforcement domains that support a business decision. Zero Trust becomes real when leaders know what must be protected, what evidence is sufficient, who owns the exception, and who can say no.
Sources and Further Reading
- NIST SP 800-207, Zero Trust Architecture — final guidance published August 2020.
- CISA Zero Trust Maturity Model Version 2.0 — April 2023 federal-agency roadmap defining five pillars and three cross-cutting capabilities.
- NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications — final guidance published September 2023.
Related Beyond1n0 analysis: Why MFA Isn’t Enough: Strengthening Application Authentication and Why Most Companies Fail at Application Security—and How to Fix It.
About Gary Cheung
Gary writes about information risk, AI governance, and executive accountability. For a discussion about an AI decision or its governance, contact Beyond1n0.
