What Government Contractors Must Implement Under the DoD's September 2023 Zero Trust Strategy and Reference Architecture

The Department of Defense published its zero trust reference architecture in September 2023, establishing a framework for how defense networks and information systems must be secured. For contractors supporting DoD systems or handling Controlled Unclassified Information, this architecture defines capabilities that must eventually be in place. The challenge for contractor leadership is not technical complexity but organizational: who owns the strategy, who decides implementation sequence, and how progress gets measured against an outcome-focused requirement.

What Zero Trust Means for Defense Contractors

Zero trust is an architectural approach that assumes no user, device, or network segment is inherently trustworthy. Instead of protecting a perimeter and trusting everything inside it, zero trust requires continuous verification of identity, device posture, and authorization before granting access to data or systems. For contractors, this represents a shift from credential-based access to policy-driven, risk-informed authorization decisions at every connection point.

The DoD's reference architecture outlines specific capabilities contractors supporting federal information systems will need to demonstrate. These include identity federation, device health attestation, encryption in transit and at rest, micro-segmentation, and continuous monitoring. The architecture does not prescribe specific products but defines outcomes: that access decisions are made dynamically based on verified attributes, that data remains protected regardless of network location, and that anomalous behavior is detected and responded to rapidly.

Why This Matters to Contractor Leadership Now

The zero trust reference architecture intersects with existing contractor obligations under CMMC and NIST SP 800-171. While CMMC establishes baseline security practices, zero trust defines the architectural approach that will eventually underpin those practices. Contractors cannot wait for explicit mandates to appear in contract language. The architecture signals the direction of DoD requirements, and organizations that begin aligning their security posture now will face less disruption when specific contractual obligations are formalized.

The business consequence of inaction is not immediate contract loss but gradual obsolescence. As the DoD refines its zero trust implementation across its own systems, the expectation for contractor environments will rise correspondingly. Organizations that continue to operate perimeter-centric security models will find themselves explaining gaps during audits, responding to findings during assessments, and ultimately competing at a disadvantage for contracts where zero trust alignment is evaluated as part of vendor capability.

Implementation Timeline and Contractor Obligations

The DoD has not published universal compliance deadlines for contractors. Instead, zero trust capabilities are being incorporated into contract requirements incrementally, often as modifications to existing agreements or as evaluation criteria in new procurements. Some contracts already reference the architecture explicitly; others incorporate its principles through technical requirements that implicitly demand zero trust capabilities.

Contractors should expect that CMMC Level 2 and Level 3 assessments will increasingly evaluate whether security controls are implemented in a manner consistent with zero trust principles. An organization might technically satisfy a NIST 800-171 control through perimeter defenses, but assessors are beginning to ask whether those controls would remain effective if the perimeter were compromised. The question is shifting from compliance with a checklist to demonstration of architectural resilience.

Key Capabilities Contractors Must Address

The reference architecture organizes zero trust into several capability pillars. Each represents an area where contractor organizations must evaluate current state and plan implementation:

• Identity and access management: User and device identities must be verified continuously, not just at initial login. This requires federation with authoritative identity sources, multi-factor authentication at every access decision, and the ability to revoke or adjust privileges dynamically based on risk signals.
• Device security: Every device accessing DoD information must be inventoried, assessed for compliance with security baselines, and monitored for behavioral anomalies. Contractors need visibility into device posture and the ability to deny access to non-compliant endpoints.
• Network and environment security: Micro-segmentation replaces the assumption that all systems inside a network can trust each other. Contractors must implement least-privilege network access, encrypt data in transit between segments, and monitor lateral movement.
• Application and workload security: Applications must authenticate users and authorize specific actions, independent of network location. Contractors need to deploy applications that enforce policy at the application layer, not merely at the network perimeter.
• Data security: Controlled Unclassified Information must remain protected through its lifecycle, whether at rest, in transit, or in use. Contractors must classify data, apply encryption appropriately, and prevent unauthorized exfiltration through policy enforcement.
• Visibility and analytics: Continuous monitoring, logging, and correlation of security events across all capability pillars allows detection of threats that evade individual controls. Contractors must aggregate telemetry and have processes to act on anomalies.
• Automation and orchestration: Manual processes cannot scale to the continuous verification zero trust demands. Contractors need automated policy enforcement, incident response workflows, and configuration management aligned to zero trust principles.

These capabilities are interdependent. Strong identity management is ineffective if devices are unmanaged. Network segmentation provides limited protection if applications trust any authenticated user. Contractors must approach zero trust as a coherent architecture, not a collection of independent projects.

Relationship to Identity and Access Management Strategy

Identity and access management sits at the center of zero trust architecture. In a perimeter-based model, once a user authenticates to the network, they gain broad access to resources. Zero trust inverts this: every resource access is a distinct authorization decision that considers user identity, device state, requested resource, and contextual risk factors.

For contractors, this means their IAM strategy must evolve beyond directory services and VPN credentials. The organization needs centralized identity governance that integrates with every application and system handling CUI. Access policies must be defined based on roles, data classification, and device compliance status. Multi-factor authentication must extend beyond initial login to high-risk transactions or access to sensitive data.

The technical implementation often involves federated identity protocols, integration with cloud identity providers, and policy engines that evaluate attributes in real time. But the strategic question is organizational: who defines what constitutes appropriate access, who monitors for privilege creep, and who authorizes exceptions when operational needs conflict with least-privilege principles. Without executive ownership of IAM as a governance function, zero trust implementation defaults to infrastructure projects that lack strategic coherence.

Who Inside the Organization Is Accountable

Most defense contractors assign CMMC compliance to an IT director or compliance officer. This individual manages technical implementation, coordinates assessments, and tracks control status. That structure is insufficient for zero trust, which is not a compliance checklist but an architectural transformation that affects every system touching DoD information.

Adequate ownership requires an executive who can make risk decisions, allocate budget across competing priorities, and adjudicate conflicts between security requirements and operational needs. This role answers questions no project manager can resolve: whether to retire a legacy application that cannot integrate with modern IAM, whether to accept the operational friction of device compliance checks, whether to delay a contract pursuit because the security architecture is not yet defensible.

In larger organizations, this responsibility may sit with a Chief Information Security Officer. In mid-sized contractors, it often falls to the Chief Operating Officer or General Counsel by default, neither of whom has the bandwidth or technical context to provide effective oversight. The result is a strategy gap: technical staff implement controls, leadership remains accountable for contract compliance, but no one owns the translation between DoD architectural expectations and business decisions about what to build, what to buy, and what to remediate first.

Organizations that address this gap often bring in [virtual CISO leadership](/vciso/) to provide executive-level strategy, governance, and risk decision-making without the overhead of a full-time internal executive. The vCISO owns the roadmap, represents the security position to leadership and auditors, and provides continuity across implementation projects that span quarters or years.

Leadership Considerations and Decision Points

Leadership must make several foundational decisions before technical implementation begins:

• Scope definition: Which systems and data fall under zero trust requirements? Contractors often support both DoD contracts and commercial work. The organization must decide whether to implement zero trust architecture only for CUI-handling systems or to adopt it enterprise-wide for operational simplicity.
• Implementation sequence: Zero trust cannot be implemented simultaneously across all capability pillars. Leadership must prioritize based on contract obligations, current architecture gaps, and available budget. The sequence determines what gets resourced first and what risks remain accepted in the interim.
• Build versus buy decisions: Some capabilities can be purchased as cloud services; others require integration work or custom policy development. Leadership must decide which aspects of zero trust to procure as managed services and which to build internally, balancing cost, control, and speed to capability.
• Risk acceptance: Not every system will achieve full zero trust alignment immediately. Leadership must document which gaps are accepted, for how long, and under what compensating controls. This requires a risk register, review cadence, and accountability for reducing accepted risk over time.
• Vendor and partner alignment: Many contractors rely on third-party service providers for IT infrastructure or application hosting. Leadership must determine whether current vendors can support zero trust requirements or whether the architecture demands a change in service providers.

These are not technical questions delegated to IT. They are business decisions with compliance, cost, and competitive implications that require executive judgment.

Measuring Progress Without Clear Mandates

One challenge contractors face is the absence of a binary compliance standard for zero trust. CMMC provides clear control requirements; zero trust does not. Organizations need internal metrics to track maturity and demonstrate progress during audits or contract reviews.

Useful metrics include the percentage of applications integrated with centralized IAM, the percentage of devices under continuous compliance monitoring, the time to detect and respond to anomalous access patterns, and the reduction in privileged access accounts. These are outcome measures, not implementation checklists. They tell leadership whether the architecture is achieving its purpose: reducing the likelihood and impact of unauthorized access to DoD information.

Progress reporting should be structured for an executive audience. Leadership does not need to know that multi-factor authentication was deployed to seventeen applications; they need to know what percentage of CUI is now protected by continuous verification, what residual risk remains, and when the next milestone reduces that risk further. This requires someone who can translate technical implementation status into risk language.

Common Implementation Pitfalls

Several patterns cause zero trust initiatives to stall or deliver limited value:

Treating zero trust as a product purchase rather than an architecture. Vendors market zero trust solutions, but no single product delivers the full capability set. Contractors who buy a tool without defining policy, integrating identity, or redesigning network segmentation achieve partial implementation that does not materially reduce risk.

Implementing controls without governance. Technology can enforce policy, but someone must define what the policy should be. Organizations that deploy zero trust capabilities without clear data classification, access policy documentation, or exception processes create compliance mechanisms with no strategic direction.

Underestimating operational impact. Zero trust changes how users access systems and how IT troubleshoots issues. Contractors that roll out strict device compliance checks or session time limits without user training and change management face resistance, shadow IT workarounds, and help desk overload that degrades security rather than improving it.

Losing continuity across fiscal years. Zero trust implementation spans multiple budget cycles. When leadership changes or priorities shift, projects lose momentum. Without consistent executive ownership, the architecture becomes a series of disconnected initiatives rather than cumulative progress toward a defensible posture.

What Leadership Should Do Next

Organizations supporting DoD contracts should take the following steps to establish accountability and begin aligning with zero trust requirements:

• Assign executive ownership for security strategy. Identify who will make risk decisions, approve architecture changes, and represent security posture to leadership and auditors. This cannot remain an IT director's collateral duty.
• Conduct a zero trust capability gap assessment. Document current state across identity, device, network, application, data, and monitoring capabilities. Identify which systems handle CUI and which gaps create the most risk in a zero trust framework.
• Define implementation priorities aligned to contract obligations. Sequence capability delivery based on which contracts have the most restrictive requirements, which systems present the most risk, and which technical dependencies must be addressed first.
• Establish governance for access policy and data classification. Before implementing technology, document who owns decisions about what data is sensitive, who should have access, and under what conditions access is revoked.
• Create a risk register for accepted gaps. Leadership cannot remediate everything immediately. Document which zero trust capabilities are not yet in place, what compensating controls exist, and when gaps will be closed.
• Build an executive reporting cadence. Establish quarterly reviews where progress against zero trust maturity is reported in risk terms leadership can act on, not technical implementation status.

For organizations that lack internal security leadership at the executive level, this is the decision point where a conversation about [virtual CISO services](/vciso/) is warranted. The role provides the strategic ownership, governance structure, and reporting discipline that transforms zero trust from an IT initiative into a managed business risk. Heights Consulting Group offers confidential consultations to defense contractor leadership evaluating how to close this gap. Reach out when you are ready to discuss your organization's accountability structure and what adequate ownership looks like for your contract portfolio.