What Is DoD Zero Trust? Framework, Pillars & FY2027

The Department of War (DoW, formerly the Department of Defense) signed its Zero Trust Strategy on October 21, 2022, and ordered every component to reach Target Level zero trust by the end of fiscal year (FY) 2027. DoD Zero Trust verifies every access request as if an adversary were already inside. A user’s location doesn’t confer trust, and neither does a device’s or network segment’s location.

For SaaS vendors and Defense Industrial Base (DIB) contractors, the framework shapes security requirements products must meet for DoW programs. A service that can’t run inside a Federal Risk and Authorization Management Program (FedRAMP)-authorized, zero-trust-aligned cloud boundary may not meet the requirements of a program working toward FY2027.

Key Takeaways

• DoD Zero Trust assumes breach. The DoD Zero Trust Reference Architecture v2.0 (September 2022) treats every user and device as untrusted. Workloads receive the same treatment, and controls are designed to contain an adversary already inside the network.  
• Seven pillars, 152 activities. The DoD Zero Trust Capability Execution Roadmap v1.1 (2022) organizes 45 capabilities and 152 activities across User, Device, Applications and Workloads, Data, Network and Environment, Automation and Orchestration, and Visibility and Analytics.  
• Two deadlines govern rollout. Target Level (91 activities) is due by the end of FY2027; Advanced Level (all 152) is due by FY2032.  
• Vendors are in scope. The Strategy names the DIB, and DoW cloud procurement uses FedRAMP and applicable impact-level authorizations aligned to the same framework.

DoD Zero Trust Assumes the Network Is Already Compromised

DoD Zero Trust is the department’s cybersecurity framework for designing systems on the assumption that the adversary is already inside them. The DoD Zero Trust Strategy, signed by the DoD CIO on October 21, 2022, states the premise without qualification: “Our adversaries are in our networks, exfiltrating our data, and exploiting the Department’s users.” Its companion document, the DoD Zero Trust Reference Architecture v2.0 (September 2022), prepared by the Defense Information Systems Agency (DISA) and the National Security Agency (NSA), supplies the design rules.

The model this retires granted broad trust to anything that made it past the firewall, an approach the Reference Architecture says has repeatedly shown limited value against well-resourced adversaries. Instead, the architecture applies continuous multi-factor authentication, micro-segmentation, end-to-end encryption, endpoint security, and analytics to Data, Applications, Assets, and Services (DAAS), the four resource categories it is built to protect.

Three Principles Drive Every DoD Zero Trust Decision

The Reference Architecture v2.0 lists five tenets; three of them settle most day-to-day design questions. Least privilege runs through all three, embedded in the verification tenet rather than listed separately.

1. Never trust, always verify

Access is denied by default. Every device, user, application, workload, and data flow is authenticated and explicitly authorized using multiple attributes and dynamic policy, and the architecture calls for continuous verification through multi-factor authentication instead of a single login. A session that was valid an hour ago earns nothing on the next request.

2. Assume breach

The second tenet, Assume Breach, directs operators to defend resources assuming an adversary already has a presence inside the environment. The first tenet, Assume a Hostile Environment, extends that assumption of breach to insiders. All users and devices, inside or outside the environment, are treated as untrusted. The same rule applies to applications. Controls are judged by how far an attacker can travel after a compromise.

3. Least privilege

The Strategy grounds authentication and authorization policies in least-privilege access, and the Reference Architecture builds least privilege into the verification tenet itself. Users and devices receive the minimum access their task requires. The same rule applies to workloads, and every grant is re-evaluated as the transaction changes. The Zero Trust Execution Roadmap v1.1 also carries it as capability 1.7 in the User pillar.

The remaining two tenets, Scrutinize Explicitly and Apply Unified Analytics, supply the mechanics: multi-attribute confidence scoring for each access and logging of every transaction across DAAS. Seven pillars turn those mechanics into assignable work.

Seven Pillars Organize All DoD Zero Trust Capabilities

The Strategy defines the DoD Zero Trust (ZT) Framework as a blueprint “based on the seven DoD Zero Trust Capability Pillars.” The DoD Zero Trust Capability Execution Roadmap v1.1 (2022) breaks those pillars into 45 capabilities and 152 activities. Each activity is assigned to either the Target or Advanced level.

SaaS products may be evaluated against Applications and Workloads capabilities and relevant requirements across other pillars. The Reference Architecture says its capabilities “aim to prevent lateral movement, validate good software practices, and segment the application into discrete highly contained secured areas.”

Authority to Operate (ATO) becomes continuous only at the Advanced level: capability 3.5 places both of its continuous ATO requirements there, so they are not due until FY2032. A program’s security review may examine how the product authenticates users and handles logs. It will also determine whether the product runs inside an authorized cloud boundary.

DoD Zero Trust Rolls Out in Two Mandatory Phases Through 2032

The Strategy sets two maturity levels with two deadlines.

Target Level, end of FY2027

The Strategy directs that “Components must achieve the intended Target level outcomes of each DoD Zero Trust Capability and execution enabler no later than the end of FY2027.” Target Level is 91 of the 152 activities, defined as the required minimum set of outcomes needed to protect the department’s data, applications, assets, and services.

The September 30, 2027 date remains in force. In July 2025, the department issued Directive-Type Memorandum (DTM) 25-003, “Implementing the DoD Zero Trust Strategy.” It directs components to reach Target Level across all unclassified and classified systems, including national security systems.

Advanced Level, FY2032

The Strategy defines Advanced Level as the complete set of identified ZT capability outcomes and activities that support adaptive responses to cybersecurity risk and threats and offer the highest level of protection. It covers all 152 activities, adding the remaining 61 Advanced activities to the 91 Target activities.

The Execution Roadmap v1.1 sets the deadline at FY2032. Once a component reaches Target Level, the Zero Trust Portfolio Management Office monitors continued compliance and guides the move to Advanced. Advanced work includes host-level process micro-segmentation with real-time access decisions and fully automated control testing. It also includes continuous ATO (cATO).

The two levels are not evenly split by pillar; the Strategy notes that some capabilities are satisfied at Target while a few are strictly Advanced, so a product that satisfies a program in 2027 will face a higher bar as that program moves toward FY2032.

DoD Zero Trust Requirements Extend to Contractors and Software Vendors

The Strategy names the DIB directly and says stakeholders across DoD, including the DIB, must embrace and execute zero trust. Components must apply the framework to all new and legacy information systems, including the commercial cloud services those systems run on.

For SaaS products, that obligation may include applicable cloud authorization requirements. DoW programs procure cloud services under the DoD Cloud Computing Security Requirements Guide (SRG) V1R6 (December 2025), which sorts workloads into impact levels:

• Impact Level 4 (IL-4). For Controlled Unclassified Information (CUI) in any system not designated a national security system (NSS), however sensitive the CUI.  
• Impact Level 5 (IL-5). Reserved for unclassified national security systems. Since DISA’s July 2025 SRG update, higher-sensitivity CUI alone no longer qualifies a workload for IL-5; the system must carry a formal NSS designation.  
• DISA IL-4 provisional authorization. Applies DoW-specific controls beyond the federal requirements applicable to a service categorized Moderate or High under Federal Information Processing Standards (FIPS) 199.

Depending on the workload and program requirements, a product may need to operate in an appropriately authorized cloud environment that meets the applicable impact-level requirements as the DoW program works toward Target Level.

Vendors have two paths to get there. The traditional path is building a compliant cloud boundary in-house, which costs up to \$3.5 million and takes 12 to 36 months to reach authorization. The alternative is inheritance: deploying the application into a cloud environment that already carries FedRAMP authorization and adopting the underlying controls it maintains, which compresses both the timeline and the cost.

An Inherited Boundary Compresses the Path to Target Level

David McKeown, the department’s deputy CIO at the time, described the department as heavily partnering with commercial cloud providers to reach Target Level. That partnership model makes inheritance viable for vendors: instead of standing up a boundary from scratch, a SaaS product deploys into one a cloud service provider already operates under FedRAMP authorization and inherits the security controls the provider maintains.

Knox Systems runs a pre-authorized FedRAMP boundary that removes work the vendor would otherwise have to do:

• Boundary engineering. No need to design, build, and document a compliant cloud architecture; the boundary already exists.  
• Control implementation. The majority of NIST SP 800-53 Rev5 controls are inherited from Knox rather than implemented and evidenced by the vendor.  
• Independent assessment. The underlying boundary has already passed assessment by a FedRAMP-recognized independent assessor (formerly called a 3PAO), so vendor scope is limited to application-layer controls.  
• Continuous monitoring. Knox’s automated platform maps and tracks controls after authorization, replacing the monthly reporting stack a vendor would otherwise build and staff.  
• Impact-level alignment. The boundary is engineered to the DoD SRG, so IL-4 workloads and, once Knox’s IL-5 authorization is complete, IL-5 national security system workloads slot in without a separate infrastructure authorization effort.

The result is that vendor engineering time can stay on the pillar-specific work a DoW program will actually review, such as how the product authenticates users, authorizes workloads, protects data, and produces logs, rather than on cloud infrastructure the department already knows how to evaluate.

Turn the FY2027 Deadline into an Authorization Head Start

Programs will keep selecting vendors that can already show a FedRAMP-authorized, zero-trust-aligned boundary over those still assembling one. Inheritance makes that posture reachable within the FY2027 window.

Knox Systems is the FedRAMP-as-a-Service platform behind that model, with a boundary already supporting Moderate, High, and IL-4, and IL-5 on the way, enabling vendors to reach authorization in roughly 90 days at about 90 percent less cost than a traditional in-house build.

Book a demo to map a product’s authorization path against a DoW program’s FY2027 timeline.

FAQs About DoD Zero Trust

Can a SaaS Product Be Evaluated Under More Than One Pillar?

Yes. Applications and Workloads may be the primary pillar, but requirements can also apply across User, Device, Data, Network and Environment, Automation and Orchestration, and Visibility and Analytics. Applicability depends on the product’s functions and the program’s requirements.

Does Zero Trust Implementation Automatically Create an ATO?

No. Zero Trust defines the security architecture and operating controls, while an ATO is a separate authorization decision. A product must still meet the authorization and cloud-boundary requirements applicable to its workload and program.

Who Determines the Required Cloud Impact Level?

The workload and the procuring program determine which impact-level requirements apply. The deciding factor is usually whether the system is formally designated a national security system: non-NSS systems handling CUI stay at IL-4 regardless of sensitivity, while IL-5 requires NSS designation.

What Should a SaaS Vendor Prepare for a Program Security Review?

A vendor should be ready to demonstrate how the product authenticates users, authorizes workloads, protects data, segments resources, and produces security logs. It should also identify the authorized cloud boundary in which the product will operate.

‍