Post 2 of 4
A Practical Guide for InfoSec Professionals, Aspiring CISOs, and New Security Leaders
In the first post of this series, I walked through what zero trust actually is, why it matters more now than ever, and how to build the executive and board support needed to fund and sustain it. If you have not read that post yet, I recommend starting there. The business case and the organizational alignment have to come before the architecture — every time.
Now we get into the substance. Zero trust is not a single technology, a single product, or a single policy. It is a coordinated architecture built across five distinct domains that security practitioners call pillars. Understanding these pillars is not optional background knowledge. It is the foundation of every decision you will make when assessing your current posture, building your roadmap, and communicating progress to leadership.
CISA’s Zero Trust Maturity Model organizes zero trust implementation around these five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Running underneath all five is a set of three cross-cutting capabilities — Visibility and Analytics, Automation and Orchestration, and Governance — that tie the whole architecture together. In this post I am going to walk you through each pillar in depth, give you the practitioner’s perspective on what each one actually demands, and help you understand how they interact. Because they do interact — and that interdependency is something a lot of zero trust implementations underestimate until it bites them.
ABOUT THIS SERIES
- Post 1: Zero Trust 101 — What It Is, Why It Matters, and How to Win Executive Support
- Post 2: The Five Pillars — Identity, Devices, Networks, Applications, and Data (you’re here)
- Post 3: The Maturity Model — Assessing Where You Are and Planning Where You Need to Go
- Post 4: Building and Executing Your Zero Trust Roadmap
Why the Pillar Model Matters
Before we go pillar by pillar, I want to say something that does not get said enough: the pillar model is not a checklist. It is a framework for thinking about where trust decisions are made in your environment — and where the assumptions behind those decisions are currently going unexamined.
Every pillar represents a category of assets, interactions, and access decisions that your organization makes every day, usually without much scrutiny. When a user logs in from a new device and gets access to the same resources they always have, that is an implicit trust decision being made in the Identity and Devices pillars. When an application can talk to any other application on the internal network without restriction, that is an implicit trust decision in the Networks and Applications pillars. When sensitive data can be downloaded by anyone with the right folder permissions regardless of where they are or what device they are on, that is an implicit trust decision in the Data pillar.
Zero trust does not eliminate these decisions. It makes them explicit, informed, and continuously re-evaluated. Each pillar is a domain where you will identify those implicit assumptions, challenge them, and replace them with verified, least-privilege controls. That is the work. It is not glamorous. But it is consequential.
Pillar One: Identity
Identity is where zero trust begins, and for good reason. In the current threat landscape, identity is the most commonly exploited attack surface. Attackers who want access to your environment almost never need to break in through technical vulnerabilities anymore. They steal credentials, abuse trust relationships, and exploit the implicit assumption that an authenticated user is a safe user. That assumption is wrong. Authentication tells you someone knows the password. It does not tell you whether that person is who they claim to be, whether their account has been compromised, or whether the access they are requesting is appropriate in this specific context.
The zero trust Identity pillar requires agencies and organizations to move well beyond simple username-and-password authentication. At a minimum, this means deploying multi-factor authentication across all users and access points. But CISA’s Maturity Model pushes significantly further — toward phishing-resistant MFA using standards like FIDO2 and Personal Identity Verification, continuous validation of identity even after initial authentication is granted, and dynamic risk assessments that evaluate the likelihood an identity has been compromised in real time.
What this looks like in practice: rather than granting access based on a successful login at the start of a session, a mature zero trust identity implementation continuously evaluates behavioral signals throughout the session. Is the user accessing resources they have never accessed before? Are they downloading unusual volumes of data? Are they connecting from a new location or at an unusual time? These signals inform dynamic access decisions — not just at the door, but continuously throughout the interaction.
Identity stores are also part of this pillar. Many organizations have fragmented identity environments — on-premises Active Directory, cloud identity providers, legacy systems with their own authentication mechanisms, contractor accounts managed separately. Zero trust requires integrating and rationalizing these stores so that every identity in your environment is visible, managed, and subject to consistent policy. That consolidation is harder than it sounds in large enterprises, but it is foundational to everything that follows.
Pillar Two: Devices
A verified identity on an unmanaged, compromised, or non-compliant device is not a secure access decision. It is a risk you are accepting without acknowledging it. The Devices pillar closes that gap by requiring that the security posture of every device be assessed as part of every access decision — not just at the time the device was enrolled, but continuously throughout its operational lifecycle.
Think about what this means for the actual complexity of your environment. You have managed corporate laptops and desktops. You have corporate mobile phones, some managed through MDM and some that slipped through. You have servers and cloud virtual machines. You have IoT devices on the plant floor, in conference rooms, and in facilities. You have contractor and BYOD devices that touch your systems but are not under your control. You have networking equipment, printers, and other infrastructure that may offer limited options for visibility and security enforcement. Each of these device categories presents a different risk profile and requires a different approach.
At the Traditional maturity stage, most organizations are doing little more than maintaining a manual inventory of physical devices with limited compliance visibility. A mature zero trust Devices posture looks very different: a comprehensive, near-real-time inventory of all network-connected devices and virtual assets, automated compliance monitoring, integrated threat protection, and resource access decisions that incorporate real-time device risk analytics. If a device has an unpatched vulnerability, an outdated OS, or an anomalous behavioral pattern, that risk should directly influence what that device is allowed to access — automatically, without waiting for a human to notice and intervene.
Supply chain risk is also part of this pillar. The SolarWinds attack was a device and software supply chain attack at its core. Zero trust maturity in the Devices pillar includes understanding the provenance of your hardware and software, tracking development and update cycles, and building operations that can tolerate supply chain failures without cascading impact across your environment.
Pillar Three: Networks
The traditional network security model put all the emphasis on the perimeter: build high walls, trust what is inside, and defend the edge against what is outside. That model has been irrelevant for years. Cloud adoption, remote work, SaaS applications, and third-party access have dissolved the edge that model depended on. But the bigger problem is what implicit network trust enables when an attacker does get inside: lateral movement. Free, unimpeded access to everything that lives on the same network segment, available to anyone with valid network credentials or a compromised endpoint.
The Networks pillar of zero trust is fundamentally about eliminating that lateral movement capability before attackers can exploit it. It starts with segmentation — moving away from large, flat network architectures with minimal internal restrictions and toward micro-segmented environments where every workload and application has its own defined connectivity profile. In a mature zero trust network, no system can talk to another system by default. Connectivity is explicitly authorized, narrowly scoped, and dynamically managed based on application profiles and policy.
Traffic encryption is also a core element of this pillar. In a traditional environment, it is common to encrypt traffic crossing the perimeter while leaving internal east-west traffic unencrypted on the assumption that it is “safe.” Zero trust rejects that assumption. All traffic — including internal communication between systems — should be encrypted. You cannot trust what you cannot verify, and you cannot verify unencrypted traffic.
Network resilience rounds out this pillar. A zero trust network architecture should not simply redistribute risk — it should reduce it while also building proportionate resilience. Workloads should be configured to manage availability demands dynamically. Resilience mechanisms should extend beyond mission-critical applications to protect the broader environment. And the architecture should incorporate continuous monitoring and automated telemetry correlation across all network environments, providing the situational awareness that makes zero trust enforcement possible at scale.
Pillar Four: Applications and Workloads
The Applications and Workloads pillar is where zero trust principles meet the systems your business actually depends on. Every application your organization runs — whether it is on-premises, in the cloud, or on mobile devices — is both a business asset and an attack surface. Zero trust in this pillar means applying continuous verification to application access, integrating threat protections directly into application workflows, and building secure development and deployment practices that treat security as a foundational requirement rather than an afterthought.
Application access in a zero trust model is fundamentally different from traditional approaches. Rather than granting access based on network location or static role assignments, access decisions incorporate a full context of signals: identity, device posture, behavioral patterns, time and location, data sensitivity, and more. Expiration conditions mean that access is not permanent — it is granted for a session, for a task, or for a defined period, and it is re-evaluated continuously throughout.
One of the most significant shifts this pillar requires is in how organizations think about application accessibility. The traditional approach keeps sensitive applications on private networks, accessible only through VPN or other perimeter controls. CISA’s Maturity Model pushes organizations toward making applications accessible over public networks to authorized users — treating every application as if it is internet-facing and applying commensurate security controls. This requires strong authentication, granular access controls, and robust threat protection, but it also enables a more flexible, user-friendly access model that supports the way modern workforces actually operate.
Secure application development and deployment is also critical here. DevSecOps practices, CI/CD pipelines with integrated security testing, immutable workloads, and the removal of standing developer access to production environments all contribute to a posture where code deployment is automated, auditable, and hardened against tampering. Application security testing should not be a gate at the end of the development process — it should be integrated throughout, with automated testing running continuously against deployed applications in production.
Pillar Five: Data
Data is what attackers are ultimately after. Every other pillar in the zero trust architecture exists, at some level, to protect data. And yet data is often the pillar that receives the least mature treatment in enterprise security programs. Organizations that have invested heavily in identity controls and network segmentation frequently have minimal visibility into their data — where it lives, how it is classified, who can access it, and whether it is moving in ways that suggest exfiltration.
The Data pillar starts with inventory. You cannot protect data you do not know exists. Most large organizations have data scattered across on-premises file shares, cloud storage environments, databases, endpoint devices, email systems, and a dozen different SaaS applications — much of it undocumented, uncategorized, and unmonitored. A zero trust approach to data requires first building a comprehensive, continuously updated inventory of all agency or enterprise data, then categorizing and labeling it according to sensitivity, and finally applying access controls and protections that are proportionate to that classification.
Data access controls in a zero trust model are dynamic and attribute-based. Rather than simple role-based permissions that give users broad access to data categories, access decisions incorporate identity, device posture, application context, data classification, and time-limited conditions. Someone with the right role might have access to a data category in general, but whether they can access a specific dataset at a specific moment depends on the full context of the request — and that context is continuously re-evaluated.
Data encryption is another foundational element. At a Traditional maturity stage, most organizations encrypt some data in transit and minimal data at rest, with ad hoc key management practices that create their own vulnerabilities. A mature zero trust Data posture encrypts all data at rest and in transit across the enterprise, applies encryption to data in use where feasible, and enforces least-privilege principles for key management enterprise-wide. Cryptographic agility — the ability to transition to new encryption standards without massive disruption — is increasingly important as quantum computing advances make some current standards vulnerable.
Data loss prevention closes the loop. If everything else in your zero trust architecture fails and an attacker gains access, DLP controls are your last line of defense against bulk exfiltration. A mature DLP posture continuously monitors data access and movement patterns, employs predictive analytics to identify suspected exfiltration before it completes, and dynamically blocks suspicious transfers without requiring human intervention for every alert.
The Three Cross-Cutting Capabilities
No individual pillar can achieve zero trust in isolation. The five pillars need to communicate with each other, share signals, and coordinate access decisions in real time. That coordination is enabled by three cross-cutting capabilities that CISA’s Maturity Model places at the foundation of the entire architecture.
Visibility and Analytics
You cannot enforce zero trust without visibility. Every access decision — whether it is about an identity, a device, a network connection, an application request, or a data access — depends on real-time information about the current state of the enterprise. Visibility and Analytics is the capability that produces, aggregates, and analyzes that information. It encompasses security logging across all pillars, correlation of telemetry across multiple sources, behavioral analytics, anomaly detection, and the analytical infrastructure that transforms raw event data into actionable security intelligence.
At the Traditional maturity stage, most organizations collect limited logs with minimal correlation or analysis. A mature Visibility and Analytics capability provides comprehensive, enterprise-wide monitoring with centralized, dynamic analysis — including behavior-based analytics that can detect subtle anomalies that rule-based detection would miss entirely. This capability does not just support zero trust enforcement. It is also the foundation of your incident detection and response capability, your threat hunting program, and your ability to demonstrate security posture to regulators and auditors.
Automation and Orchestration
Zero trust at scale is not possible without automation. The volume of access decisions, policy enforcement actions, threat responses, and configuration changes required to operate a mature zero trust architecture exceeds what any human team can manage manually. Automation and Orchestration is the capability that operationalizes zero trust at enterprise scale — automating identity orchestration, device compliance enforcement, network policy updates, application access decisions, and data protection controls across the entire environment.
This capability also covers security response. When an anomalous behavior pattern triggers an alert, a mature zero trust architecture should not wait for a human analyst to review it, make a decision, and implement a response. It should automatically execute pre-defined response playbooks — isolating the affected device, revoking the suspicious session, blocking lateral movement, and notifying the appropriate team — in the time it takes an analyst to open the alert ticket. The humans stay in the loop for high-stakes decisions, but the routine response actions happen automatically.
Governance
Governance is what keeps the entire architecture accountable and aligned with the organization’s risk posture, regulatory requirements, and business objectives. It encompasses the definition, enforcement, and continuous review of security policies across all five pillars and all three cross-cutting capabilities. Without strong governance, zero trust implementations drift — policies become outdated, exceptions accumulate, and the architecture gradually reverts to a state of implicit trust through entropy and organizational inertia.
A mature Governance capability fully automates enterprise-wide policy enforcement with dynamic updates, incorporates contextual information from multiple sources into access policy decisions, and ensures that the right people, processes, and technology are in place to support mission requirements, risk management objectives, and compliance obligations. Governance also ensures that zero trust implementation stays aligned with the business — that security controls support operational objectives rather than obstructing them, and that the program can demonstrate value in terms leadership cares about.
How the Pillars Work Together
Here is something I want you to internalize before we move on to the Maturity Model in the next post: a zero trust access decision is not made by any single pillar. It is the product of signals from multiple pillars evaluated together in real time.
When a user requests access to a sensitive application, the policy enforcement point draws on the Identity pillar to verify who they are and assess their current risk score. It draws on the Devices pillar to evaluate whether their device is compliant, managed, and free of known threats. It draws on the Networks pillar to understand where the request is originating and whether the connection is encrypted and appropriately routed. It draws on the Applications and Workloads pillar to determine what specific access is being requested and what the application’s sensitivity requires. And it draws on the Data pillar to understand what data would be exposed if access is granted and whether the classification of that data is appropriate for this request context. All of this happens in milliseconds, invisibly to the user, producing an access decision that is genuinely informed by the full security context of the request.
That is what a mature zero trust architecture actually looks like in operation. It is elegant when it works. Getting there requires deliberate, sequential investment across all five pillars simultaneously — not because you complete one before starting another, but because each pillar’s controls are most valuable when they can share signals with the others. That is the design insight that separates organizations that implement zero trust controls from organizations that implement a zero trust architecture.
I have watched a lot of organizations spend significant money on zero trust capabilities and end up with something that looks like zero trust on paper but functions like a patchwork of disconnected controls in practice. The difference almost always comes down to whether the team understood the pillars as an integrated architecture or as a shopping list. Each pillar matters. The cross-cutting capabilities matter more. And the connections between them matter most of all. As you build your program, keep asking the question: how does what I am doing in this pillar make every other pillar smarter? When your controls are sharing signals, your access decisions become more accurate. When your architecture is integrated, your visibility improves. And when your governance is functioning, the whole system stays coherent over time. That is what zero trust actually delivers — not any individual control, but the emergent security posture that results from controls that work together.
Post 3: The Maturity Model — Assessing Where You Are and Planning Where You Need to Go →