Applying Zero Trust Principles to Protect Controlled Unclassified Information
Author: Leonard Esere, Senior Security Architect
Date: April 2026
Organization: Aeolitech
Abstract
The traditional network-perimeter security model is fundamentally incompatible with today's distributed, cloud-centric environments where Controlled Unclassified Information (CUI) flows across contractor networks, government clouds, and remote endpoints. Zero Trust Architecture (ZTA), as defined by NIST Special Publication 800-207 and operationalized by the Department of Defense Zero Trust Reference Architecture Version 2.0 (2022), reframes the security problem: rather than trusting users and devices by virtue of network location, every access request is evaluated continuously against a policy engine that considers identity, device posture, data sensitivity, and behavioral context.
This whitepaper draws on direct experience supporting Authority to Operate (ATO) packages at Los Alamos National Laboratory (LANL), contributing to MITRE ATT&CK-based threat modeling, and building CUI-handling systems under DoD Secret and DoE Q clearance constraints. It provides security architects and compliance practitioners with a practical, technically grounded guide to implementing Zero Trust in CUI environments — mapping the seven DoD Zero Trust pillars to NIST SP 800-171 controls, specifying implementation patterns for identity-aware proxy, microsegmentation, and continuous verification, and explaining why the DoD's FY2027 deadline for 91 target capabilities represents not merely a compliance milestone but a security necessity.
Table of Contents
1. The Compliance Imperative — Why CUI Environments Need Zero Trust
2. NIST SP 800-207 — The Canonical ZTA Framework
3. DoD Zero Trust Reference Architecture 2.0
4. The Seven Pillars — Architecture and Implementation
5. Zero Trust Capability Execution Roadmap — 91 Capabilities by FY2027
6. Mapping Zero Trust to NIST SP 800-171 Controls
7. Practical Implementation Patterns
8. Why CUI Environments Specifically Benefit from Zero Trust
9. Implementation Pitfalls and Lessons Learned
10. Conclusion and Path Forward
1. The Compliance Imperative
The regulatory context for CUI protection has never been more demanding. DFARS clause 252.204-7012 requires contractors to implement all 110 controls in NIST SP 800-171 as a baseline condition for DoD contracts. The Cybersecurity Maturity Model Certification (CMMC) 2.0 elevates those same controls into a third-party verified standard, with CMMC Level 2 (the threshold for most CUI environments) requiring an independent C3PAO assessment for sensitive defense contracts.
Underneath both frameworks lies a tacit assumption that compliance alone is insufficient: the adversary community — state-sponsored threat actors including those catalogued in MITRE ATT&CK under groups APT10, APT41, and Volt Typhoon — routinely compromises organizations that check every compliance box but rely on implicit network trust. The SolarWinds supply chain attack, the Microsoft Exchange HAFNIUM exploitation campaign, and the 2020 Defense Industrial Base data exfiltrations all exploited trusted network positions. Perimeter-based defenses, by design, cannot stop a threat already inside the wire.
Zero Trust is not a product or a single technology. It is an architectural philosophy, articulated in policy, enforced through controls, and validated through continuous monitoring. For CUI environments, it translates directly into a security posture that assessors can evaluate, that reduces the blast radius of a breach, and that maps naturally onto the control families in NIST SP 800-171.
2. NIST SP 800-207 — The Canonical ZTA Framework
Published by NIST in August 2020 (authored by Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly), NIST Special Publication 800-207, Zero Trust Architecture, provides the vendor-neutral definitional foundation for ZTA in U.S. government and contractor environments.
The Seven Tenets of ZTA
SP 800-207 does not define "Zero Trust" as a product category. It defines it through seven tenets that any compliant architecture must embody:
| # | Tenet | Practical Meaning for CUI |
|---|-------|--------------------------|
| 1 | All data sources and computing services are resources | CUI data stores, APIs, cloud services, and IoT devices all require resource-level protection |
| 2 | All communication is secured regardless of network location | TLS 1.2+ minimum everywhere; no cleartext CUI transit on any network segment |
| 3 | Access to individual resources is granted on a per-session basis | Short-lived tokens, time-bound sessions; no standing privilege to CUI systems |
| 4 | Access is determined by dynamic policy | Identity + device posture + behavioral context evaluated at every request |
| 5 | The enterprise monitors and measures integrity and posture of all assets | Continuous device health checks; EDR telemetry feeds policy engine |
| 6 | Authentication and authorization are dynamic and strictly enforced | No implicit re-use of prior authentication; each access request re-verified |
| 7 | The enterprise collects telemetry and uses it to improve security posture | SIEM + UEBA + continuous monitoring feeds policy refinement |
Core Architecture Components
SP 800-207 defines three core enforcement components that translate the tenets into a deployable architecture:
- Policy Engine (PE): The brain of ZTA. It ingests signals — identity assurance level, device posture, threat intelligence, behavioral analytics — and renders an access decision (allow, deny, or challenge).
- Policy Administrator (PA): Executes the PE decision by creating or terminating session credentials, tokens, or keys.
- Policy Enforcement Point (PEP): The actual gate between the requester and the resource. In practice, this may be an identity-aware proxy, a cloud access security broker (CASB), or a network micro-perimeter.
The data plane — traffic between subjects and resources — passes through the PEP. The control plane — policy decisions — runs through the PE/PA pair. Separating these planes is architecturally significant: it means the policy logic is centralized and auditable, not embedded in individual network devices.
3. DoD Zero Trust Reference Architecture 2.0
The DoD Zero Trust Reference Architecture Version 2.0, produced jointly by DISA and NSA and published in 2022, operationalizes NIST SP 800-207 within the DoD Information Enterprise (DODIN). The document defines 152 Zero Trust activities organized across seven pillars and two maturity tiers: Target Level (91 activities, required by the end of FY2027) and Advanced Level (an additional 61 activities).
Critically, the ZT RA 2.0 is explicitly applicable to the Defense Industrial Base (DIB) — not just DoD components. Contractors handling CUI on DoD contracts should treat the architecture as a reference model for their own ZTA implementations, even when their regulatory obligation is framed as NIST SP 800-171 / CMMC compliance rather than a DoD ZT mandate.
The four strategic goals articulated in the DoD Zero Trust Strategy (October 2022) are:
1. Zero Trust Culture Adoption — organizational and workforce readiness
2. DoD Information Systems Secured and Defended — technical implementation
3. Technology Acceleration — deploying ZT-enabling technologies at pace with threats
4. Zero Trust Enablement — governance, policy, and acquisition alignment
4. The Seven Pillars — Architecture and Implementation
The DoD Zero Trust framework organizes its 152 activities into seven pillars. Data sits at the center; the other six pillars exist to protect it.
Pillar 1: User
What it means: Continuous authentication and authorization of every human and non-human (service account, API key, machine identity) entity.
Key controls: Multi-factor authentication (MFA), Privileged Access Management (PAM), identity governance and administration (IGA), just-in-time (JIT) privilege elevation.
800-171 alignment: 3.5 Identification and Authentication (3.5.3 MFA, 3.5.5 identifier management), 3.1.6 least privilege.
Implementation note: For CUI environments, phishing-resistant MFA (FIDO2/WebAuthn or PIV/CAC) is the appropriate target. SMS-based OTP does not satisfy the spirit of continuous verification for sensitive environments.
Pillar 2: Device
What it means: Real-time assessment of every device's security posture before and during access. Only compliant devices access CUI resources.
Key controls: Mobile Device Management (MDM), Endpoint Detection and Response (EDR), Comply-to-Connect (C2C) frameworks, Trusted Platform Module (TPM) attestation.
800-171 alignment: 3.1.18 control connection of mobile devices, 3.14.6 monitor systems to detect attacks, 3.4 configuration management baseline.
Implementation note: Device posture signals (patch level, EDR agent status, disk encryption state, certificate validity) should feed directly into the Policy Engine, creating a dynamic trust score that can reduce access privileges when posture degrades mid-session.
Pillar 3: Network and Environment
What it means: Micro- and macro-segmentation eliminate implicit trust between network zones. CUI systems sit in named segments with explicit allow-listed ingress/egress.
Key controls: Software-Defined Networking (SDN), microsegmentation (host-based firewall policies at the workload level), encrypted inter-service communication, software-defined perimeter.
800-171 alignment: 3.13.1 boundary protection, 3.13.2 network architecture principles, 3.13.3 role separation, 3.13.5 communication through managed interfaces.
Implementation note: Flat networks where any host can reach any CUI system remain the most common and most exploited gap assessors find. Microsegmentation tools (Azure Network Security Groups with application security groups, Guardicore/Akamai Guardicore Segmentation, Illumio) enforce east-west isolation even when perimeter controls have been bypassed.
Pillar 4: Application and Workload
What it means: Applications are protected individually at the API and service level. Access is granted per-application, not per-network segment.
Key controls: Identity-aware proxy (IAP), API gateway with OAuth 2.0 / OIDC, DevSecOps security gates in CI/CD pipelines, container image scanning.
800-171 alignment: 3.1.2 limit system access to authorized transactions, 3.13.8 encryption of CUI during transmission, 3.4.5 define, document, approve and enforce physical and logical access restrictions.
Implementation note: An identity-aware proxy (Google BeyondCorp IAP model, or Azure AD Application Proxy / Entra Private Access) decouples network access from application access entirely. A user on an untrusted network can still access an authorized CUI application if their identity and device posture pass policy — and conversely, a user on the trusted LAN can be denied access if their device is non-compliant.
Pillar 5: Data
What it means: Data is tagged, classified, and protected at the object level — independent of where it resides. Data-centric security means the protection travels with the data.
Key controls: Data Loss Prevention (DLP), Information Rights Management (IRM), CUI tagging per NARA CUI Registry categories, encryption at rest and in transit, data access logging.
800-171 alignment: 3.13.11 FIPS-validated cryptography, 3.13.16 protect CUI at rest, 3.8.6 protect portable storage, 3.1.22 control CUI posted to publicly accessible systems.
Implementation note: Microsoft Purview (formerly AIP/MIP) in GCC High environments supports NARA CUI category labels and can enforce document-level encryption that persists even when CUI is exfiltrated from the protected environment.
Pillar 6: Visibility and Analytics
What it means: Comprehensive telemetry from all pillars feeds a SIEM and User/Entity Behavior Analytics (UEBA) engine. Anomalies trigger automated responses.
Key controls: SIEM (Microsoft Sentinel, Splunk Enterprise Security), UEBA, threat intelligence integration, Security Operations Center (SOC) procedures.
800-171 alignment: 3.3 Audit and Accountability (all nine controls), 3.14.6 monitor systems, 3.14.7 identify unauthorized use.
Implementation note: "Visibility" without actionability is log storage. The gap between log collection and threat detection is often where CUI environments fail assessments: logs exist, but no one reviews them and no alerts are configured. See the companion whitepaper Audit Logging for NIST 800-171 for implementation detail.
Pillar 7: Automation and Orchestration
What it means: Security responses are automated through playbooks and SOAR platforms. Policy changes propagate automatically. Repetitive analyst tasks are eliminated.
Key controls: Security Orchestration, Automation and Response (SOAR), Policy Decision Point (PDP) automation, API-driven policy enforcement, machine learning-driven anomaly response.
800-171 alignment: 3.6 Incident Response (3.6.1 incident handling capability), 3.14 System and Information Integrity.
Implementation note: In a CUI environment, automation does not mean no human oversight — it means that humans are alerted to the right events and that routine decisions (blocking a device that failed a compliance check, rotating a compromised credential) happen in seconds rather than hours.
5. Zero Trust Capability Execution Roadmap — 91 Capabilities by FY2027
The DoD Zero Trust Capability Execution Roadmap (v1.1) translates the ZT RA 2.0 into a time-phased delivery plan. The key numerical facts:
| Level | Activities | Capabilities | Deadline |
|-------|-----------|-------------|---------|
| Target | 91 | 45 | End of FY2027 (Sept 30, 2027) |
| Advanced | +61 (152 total) | +3 (48 total) | Beyond 2027 (notionally 2032) |
As of September 2025, reporting from DoD CIO indicated the Department was on track to meet the FY2027 deadline, having defined all Target and Advanced capability outcomes. The roadmap organizes the 91 Target activities across the seven pillars with fiscal-year-specific milestones. For contractors and DIB partners, the practical implication is:
- FY2025: MFA enforcement universal; EDR on all CUI-connected endpoints; macro-segmentation baseline.
- FY2026: Service mesh with mutual TLS (mTLS); microsegmentation for CUI workloads; DLP for CUI data classification.
- FY2027: Full behavioral analytics; automated threat response (SOAR); complete data pillar DLP deployment.
Organizations that treat the FY2027 deadline as a DoD-only concern misread the regulatory direction. The CMMC 2.0 program and the broader federal contractor compliance ecosystem are moving toward explicit ZTA requirements. Implementing now builds competitive advantage and reduces the compliance sprint cost.
6. Mapping Zero Trust to NIST SP 800-171 Controls
NIST SP 800-171 does not use the phrase "Zero Trust," but many of its 110 controls are natural expressions of Zero Trust principles. The following table maps the most significant convergences:
| Zero Trust Principle | NIST 800-171 Control | Control Text |
|---------------------|----------------------|--------------|
| Identity-centric access | 3.5.3 | Use multifactor authentication for local and network access |
| Least privilege | 3.1.5 | Employ the principle of least privilege |
| Continuous verification | 3.1.6 | Use non-privileged accounts or roles when accessing non-security functions |
| Microsegmentation | 3.13.1 | Monitor, control, and protect communications at external boundaries |
| Encrypted communications | 3.13.8 | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission |
| Data-centric security | 3.13.11 | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI |
| Visibility and monitoring | 3.3.1 | Create and retain system audit logs |
| Device posture | 3.14.6 | Monitor systems to detect attacks and indicators of potential attacks |
| Automated response | 3.6.1 | Establish an operational incident-handling capability |
| Behavioral analytics | 3.14.7 | Identify unauthorized use of organizational systems |
The most impactful observation from LANL ATO work and MITRE-aligned threat modeling: the controls that Zero Trust addresses most directly — 3.5.3 (MFA), 3.13.1 (boundary protection), 3.13.8 (encryption in transit), and 3.3.1 (audit logging) — are also the controls that CMMC assessors cite most frequently as deficient. Implementing Zero Trust architecture does not generate compliance as a side effect; rather, it creates the structural conditions under which sustained, verifiable compliance becomes achievable.
7. Practical Implementation Patterns
Identity-Aware Proxy
An identity-aware proxy (IAP) sits in front of all CUI-bearing applications and enforces authentication at the application layer, independent of network location. The pattern:
1. Remove all direct network paths to CUI applications from the internet and from general-purpose internal networks.
2. Route all access through the IAP — users authenticate to the IAP with phishing-resistant MFA; the IAP evaluates device posture signals from the MDM/EDR; if the policy passes, a time-limited token grants access to the specific application.
3. Log every access decision — approved, denied, and challenged — to the SIEM.
4. Session monitoring — the IAP continuously re-evaluates posture signals; a device that fails a compliance check mid-session has its access revoked.
In Azure GCC High environments, this pattern is implemented through Microsoft Entra ID Conditional Access + Azure AD Application Proxy (or Entra Private Access for on-premises apps), with Intune enforcing device compliance policies as inputs to Conditional Access rules.
Microsegmentation
Traditional VLANs and ACLs cannot prevent lateral movement within a segment. Microsegmentation applies allow-list policies at the individual workload level:
1. Discover and classify all CUI workloads — identify every server, container, and service that stores, processes, or transmits CUI.
2. Define allow-list policies — each CUI workload can receive connections only from explicitly authorized sources (by identity, device, and port/protocol). Default deny.
3. Enforce host-based — Azure Network Security Groups at the NIC level, or host-based firewall rules pushed from a centralized policy engine.
4. Validate with network flow analysis — tools like Microsoft Defender for Network or Guardicore map observed traffic and flag violations of the defined policy.
Continuous Verification
Continuous verification means the policy engine re-evaluates trust throughout the session, not just at login:
- Token lifetimes: Access tokens for CUI applications should have short lifetimes (15–60 minutes) with automatic re-evaluation required for renewal.
- Device posture re-check: If a device's EDR agent becomes non-responsive or a high-severity vulnerability is detected mid-session, the session is terminated or downgraded.
- Behavioral anomaly triggers: UEBA detects unusual access patterns (accessing CUI at 3 AM from a new location, bulk download of CUI files) and triggers step-up authentication or session termination.
Data-Centric Security
Data-centric security attaches protection to the data object rather than the container:
- Classify and tag: Every CUI document is tagged with its NARA CUI category at creation (e.g., CUI//SP-CTI for Controlled Technical Information). Microsoft Purview sensitivity labels automate this in GCC High environments.
- Encrypt at object level: IRM/document-level encryption ensures that even if a CUI document is exfiltrated, it cannot be opened outside of authorized applications by authorized identities.
- DLP enforcement: Cloud DLP (Microsoft Purview DLP, Google DLP) enforces policies that prevent CUI from being emailed to personal accounts, uploaded to unauthorized cloud services, or copied to removable media.
8. Why CUI Environments Specifically Benefit from Zero Trust
CUI environments have several characteristics that make them uniquely well-suited to Zero Trust:
1. Heterogeneous user populations. CUI environments often include government employees, prime contractors, subcontractors, and support personnel — each with different roles, devices, and risk profiles. Zero Trust's attribute-based access control handles this heterogeneity naturally; perimeter-based security cannot.
2. Cloud-hosted CUI. DFARS-compliant cloud environments (Azure GCC High, AWS GovCloud) have eliminated the physical perimeter as a meaningful security boundary. Zero Trust was designed for exactly this context.
3. Remote work. The post-pandemic baseline for most contractors is a hybrid workforce. VPN-based remote access creates a single point of failure and an implicit trust grant to a remote device. Zero Trust replaces VPN with identity and device-posture-based access that provides stronger security without the bottleneck.
4. Contractual auditability requirements. DFARS 252.204-7012 requires contractors to preserve forensic evidence and provide rapid cyber incident reporting. Zero Trust's comprehensive telemetry — every access decision logged, every session recorded — creates the forensic foundation that DFARS mandates.
5. Reduced scope for CMMC assessments. A well-implemented Zero Trust architecture, with strong microsegmentation and data-centric controls, reduces the CUI system boundary. A smaller, better-protected assessment scope means lower cost, faster assessments, and fewer findings.
9. Implementation Pitfalls and Lessons Learned
Drawing from ATO support work at LANL and DoD Secret-level system implementations, the following pitfalls recur:
Pitfall 1: Identity sprawl without governance. Organizations deploy MFA but do not govern service accounts and machine identities. Adversaries exploit unmanaged service accounts that never have MFA and never expire. Solution: complete identity inventory including non-human identities, with automated lifecycle management.
Pitfall 2: Microsegmentation deployed only at the perimeter. Network segmentation that only separates the CUI enclave from the internet but allows flat east-west traffic within the enclave fails the moment an attacker pivots from a workstation to a CUI server. Solution: enforce microsegmentation at the workload level, not just at VLAN boundaries.
Pitfall 3: "Compliant" logging without actionable alerts. Many organizations implement 800-171 3.3.1 by enabling logs and retaining them. Assessors will ask: "Who reviews these logs? What alerts fire? Show me the last ten incidents that log review detected." Solution: pair logging with SIEM rules, scheduled review, and documented response procedures.
Pitfall 4: Policy drift. Zero Trust policies are deployed correctly at day one and never revisited. New applications are added outside the IAP; new devices bypass MDM; exceptions accumulate into permanent holes. Solution: continuous monitoring with automated policy compliance reports; quarterly ZTA policy reviews.
Pitfall 5: Treating Zero Trust as a project with an end state. Zero Trust is a continuous program, not a one-time deployment. The FY2027 Target Level is a milestone, not a finish line.
10. Conclusion and Path Forward
Zero Trust Architecture represents the most consequential shift in federal cybersecurity practice since the adoption of FISMA. For CUI environments specifically, it addresses the most prevalent attack patterns, creates the forensic and monitoring foundations that DFARS requires, and maps directly onto the NIST SP 800-171 controls that CMMC assessors will evaluate.
The DoD's FY2027 mandate for 91 target capabilities is an aggressive timeline — but the architecture it prescribes is achievable for organizations that approach it programmatically: assess current state against the seven pillars, prioritize identity and device controls (the highest-leverage early investments), implement microsegmentation for CUI workloads, and build the visibility infrastructure that makes continuous improvement possible.
Aeolitech supports clients across the full Zero Trust implementation lifecycle — from initial gap assessment against the DoD ZT RA 2.0 to full CMMC Level 2 assessment readiness. Organizations that begin this journey now will be better positioned to win and retain DoD contracts, respond faster to incidents, and defend against the threat actors that target the Defense Industrial Base.
About the Author
Leonard Esere is a senior security architect with over a decade of experience securing classified and CUI environments. His work spans Authority to Operate (ATO) package development at Los Alamos National Laboratory (LANL), threat modeling aligned to the MITRE ATT&CK framework, and system security engineering under DoD Secret and DoE Q clearance requirements. He has led security architecture work for systems processing information subject to DFARS 252.204-7012 and has direct experience with PCI DSS compliance on large-scale computing infrastructure including the Frontier supercomputing program. His technical focus areas include Zero Trust Architecture, identity and access management, and cloud security for regulated workloads.
References
1. National Institute of Standards and Technology. (2020). NIST Special Publication 800-207: Zero Trust Architecture. https://doi.org/10.6028/NIST.SP.800-207
2. Department of Defense. (2022). DoD Zero Trust Strategy. https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-ZTStrategy.pdf
3. Defense Information Systems Agency / National Security Agency. (2022). DoD Zero Trust Reference Architecture Version 2.0. https://dodcio.defense.gov/Library/
4. Department of Defense CIO. (2024). DoD Zero Trust Capability Execution Roadmap v1.1. https://dodcio.defense.gov/Portals/0/Documents/Library/ZT-ExecutionRoadmap-v1.1.pdf
5. National Institute of Standards and Technology. (2021). NIST Special Publication 800-171 Rev. 2: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. https://doi.org/10.6028/NIST.SP.800-171r2
6. Department of Defense. (2025). DTM 25-003: Implementing the DoD Zero Trust Strategy. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dtm/DTM%2025-003.PDF
7. CISA. (2023). Zero Trust Maturity Model Version 2.0. https://www.cisa.gov/zero-trust-maturity-model
8. MeriTalk. (2025, September 10). Pentagon to Release Updated Zero Trust Strategy by End of Year. https://www.meritalk.com/articles/pentagon-to-release-updated-zero-trust-strategy-by-end-of-year/
9. National Archives and Records Administration. CUI Registry. https://www.archives.gov/cui
10. Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012. Safeguarding Covered Defense Information and Cyber Incident Reporting. https://www.acquisition.gov/dfars/252.204-7012
Take the Next Step
CUI environments face an increasingly sophisticated threat landscape and an increasingly demanding compliance environment. If your organization needs help mapping its current security posture to the DoD Zero Trust Reference Architecture, preparing for a CMMC Level 2 assessment, or building a Zero Trust implementation roadmap, Aeolitech's security architecture team is ready to assist.
Contact Aeolitech to schedule a Zero Trust gap assessment or to discuss your CMMC compliance program.