Why most Zero Trust roadmaps fail before they start
The DoD Zero Trust Strategy, published in November 2022, mandated that all DoD components achieve Target-Level Zero Trust by fiscal year 2027. That deadline created a wave of Zero Trust roadmap documents - PowerPoint slides, Word docs, SharePoint pages - most of which describe the destination without charting a realistic path to get there.
A Zero Trust roadmap is not a restatement of NIST 800-207 principles. It is not a vendor marketing deck rebranded with your program name. It is a sequenced, milestone-driven plan that says: here is where we are today, here is what we are changing and in what order, here is how we will know when each capability is implemented, and here is how implementation affects our Authority to Operate.
Most programs fail at the sequencing problem. Zero Trust touches identity, devices, network, applications, data, workloads, and automation - the seven pillars from the DoD reference architecture. You cannot do everything at once, and the order matters because some capabilities are prerequisites for others. Starting with network segmentation before you have an authoritative identity store is backwards. Trying to implement data-layer controls before you know what data you have is backwards. The roadmap has to reflect a logical dependency sequence, not an alphabetical list of capabilities.
What the seven pillars actually mean in practice
The DoD Zero Trust Reference Architecture defines seven pillars. Understanding what each one means operationally is the starting point for sequencing.
User is the identity pillar. Every user must be verified through multi-factor authentication, and access must be continuously validated - not just at login but throughout the session. In practical terms, this means a compliant MFA solution, an authoritative identity provider (usually connected to your CAC/PIV infrastructure), and conditional access policies that evaluate device compliance, location, and behavior at the time of access.
Device covers all endpoints that connect to the network. Every device must be known, registered, and assessed for compliance. This means device management - MDM or UEM - and the ability to enforce posture checks before granting access. Unmanaged personal devices should not have access to CUI systems.
Network addresses how traffic flows. The goal is microsegmentation - breaking the network into small zones with explicit access policies between them, rather than a flat network where a compromised workstation can reach everything. This is infrastructure-heavy work, often the most disruptive pillar to implement.
Application and workload covers how applications authenticate users and talk to each other. Application-level controls, API security, and workload identity for service-to-service communication all live here. The shift is from "on the network, therefore trusted" to "authenticated and authorized at the application layer regardless of network location."
Data is the hardest pillar. You need to know what data you have, classify it, and implement controls at the data level - not just at the perimeter. This requires data discovery, classification tagging, and data loss prevention or information rights management tooling. Most programs are years away from mature data-layer controls.
Visibility and analytics is the logging and monitoring pillar. Zero Trust assumes breach. The detection capability needs to be in place to see anomalous behavior, correlate events, and respond. This means a functioning SIEM, centralized log aggregation from all pillar activities, and a SOC or alerting capability that actually reviews the output.
Automation and orchestration is the maturity capability. Automated policy enforcement, orchestrated response to security events, and machine-speed decision making about access requests. This is the advanced end of the maturity model.
How to sequence implementation when you can't do everything at once
The DoD Zero Trust Reference Architecture defines two tiers: Target Level and Advanced Level. Target Level is the 2027 mandate. For most programs starting from a traditional perimeter-based architecture, Target Level means getting the foundational capabilities in each pillar to a defined maturity threshold.
Start with User and Device. These two pillars are prerequisites for almost everything else. Without a working identity store and an MFA requirement, you have no foundation for conditional access policies, no basis for device trust, and no way to enforce least-privilege access. Get CAC/PIV authentication working across all systems, implement MFA for any accounts that do not use hardware tokens, establish your authoritative identity provider, and get device management deployed to all managed endpoints.
Move to Network and Application together, because they interact. Network microsegmentation is easier to implement when you have already defined application access policies. The rule for each network segment should be: what needs to talk to what, and why? Application-level authentication and API security enforcement can be implemented in parallel by application teams while network teams work on segmentation.
Data and Visibility come next. Data classification is ongoing - you will not finish it before moving on - but you need a classification policy and a toolset deployed. Logging and SIEM integration should be built in parallel with every capability you deploy. Every new control generates logs; the SIEM should be ingesting those logs from day one.
Automation and orchestration is the long-term maturity work. Automated policy enforcement requires mature policies first. Do not try to automate things you have not yet stabilized.
How to map NIST 800-207 to your roadmap
NIST Special Publication 800-207, Zero Trust Architecture, is the foundational standards document. The DoD Reference Architecture is built on it. The seven DoD pillars correspond to the tenets and components in 800-207, though the framing is different.
The key 800-207 tenets that should drive your milestone definitions:
All resources are treated as resources regardless of network location. Milestone: are all applications and services accessible only through authenticated sessions, regardless of whether the user is on the corporate network or remote?
Access is determined dynamically based on identity, device health, and other attributes. Milestone: do your access policies evaluate more than just username and password?
The network is hostile. Milestone: are you logging all traffic, not just external traffic? Are you treating internal traffic with the same scrutiny as external?
Use these tenets as acceptance criteria for each milestone in your roadmap. "Implemented MFA" is not a Zero Trust milestone. "All user access to sensitive applications requires MFA with continuous session validation and device compliance check" is a Zero Trust milestone.
Tracking Zero Trust progress in Jira or similar tools
A Zero Trust roadmap needs to be trackable, not just documented. The mistake most programs make is keeping the roadmap in a static document that gets updated quarterly by someone who copies the current slide deck.
In Jira, structure the roadmap as an Epic per pillar. Within each Epic, create Stories for each capability target. Tag each Story with the DoD ZT Activity number from the Reference Architecture - there are 91 activities across Target and Advanced levels, and tracking by activity number gives you a way to report progress against the DoD standard.
Each Story should have: the specific capability being implemented, the system or boundary it applies to, acceptance criteria drawn from the DoD ZT Reference Architecture activity description, the implementing team, and the target completion date. When a Story is closed, the completion is documented in the system of record, not in someone's memory or a slide that gets overwritten.
Use a dashboard to show pillar-level completion percentages. At the Target Level, the DoD has defined 152 activities. Tracking completed activities as a percentage of total gives leadership a meaningful progress metric that ties directly to the compliance mandate.
What the RMF intersection looks like
Zero Trust implementation is not separate from your Risk Management Framework process - it should be integrated into it. Every new Zero Trust capability you implement affects your system's security posture and potentially your control implementation.
When you implement MFA, update your IA-2 control implementation statement in your System Security Plan. When you implement network microsegmentation, update SC-7 boundary protection and SC-32 information system partitioning. When you deploy a SIEM and centralize logging, update AU-2 through AU-12. Zero Trust implementation is security control implementation, and your SSP should reflect it.
If you are implementing Zero Trust capabilities across an AO boundary, new capabilities may require a change request to your ATO. Coordinate with your ISSO and AO representative before deploying significant infrastructure changes. Some programs have had Zero Trust implementations delayed because the SIEM or microsegmentation infrastructure was deployed without an ATO update and the AO required a pause for documentation.
The positive side of the RMF integration: Zero Trust capability implementation generates evidence for your continuous monitoring program. Properly configured, your SIEM logs, your device compliance reports, and your access policy enforcement data are all POA&M closure evidence and continuous monitoring artifacts. Build that evidence collection into the implementation from the start.
FAQ
Q: Where does the DoD Zero Trust mandate come from? A: The DoD Zero Trust Strategy published in November 2022 established the mandate. It directs all DoD components to achieve Target-Level Zero Trust across all systems by FY2027. CISA Zero Trust Maturity Model guidance and Executive Order 14028 provide the broader federal context.
Q: What is the difference between Target Level and Advanced Level Zero Trust? A: Target Level represents the baseline DoD mandate - 91 activities that must be implemented to meet the 2027 deadline. Advanced Level represents the more mature, automation-driven Zero Trust posture with an additional 61 activities. Most programs should be focused on Target Level first.
Q: Do we need a separate Zero Trust ATO? A: There is no standalone Zero Trust ATO. Zero Trust capabilities are implemented within your existing authorization boundary and reflected in your SSP updates. If you are deploying new infrastructure - a PAM system, a SIEM, a new network segmentation fabric - those may require ATO updates or new authorizations depending on your AO's requirements.
Q: How do we handle legacy systems that cannot support modern authentication? A: Legacy systems that cannot natively support MFA or modern identity protocols need to be wrapped - a gateway or proxy that enforces Zero Trust policy at the boundary, even if the legacy system itself cannot participate. Application-level gateways and privileged access workstations are common compensating controls. Document these as accepted risks or compensating controls in your SSP.
Q: What should a Zero Trust roadmap document include? A: Current state assessment against the 152 DoD ZT activities, target state by pillar with completion dates, sequencing rationale explaining the implementation order, RMF touchpoints showing how each capability maps to NIST controls, resource requirements by phase, and a progress tracking mechanism tied to your project management tool.
Q: How do contractors support Zero Trust implementation for a government customer? A: Contractors typically support implementation in several ways: gap assessments against the DoD ZT Reference Architecture activities, architecture design for specific pillars, tool selection and procurement support, implementation and configuration of Zero Trust tools, SSP updates and RMF documentation, and training for government personnel. The scope varies by contract but the work is concrete and technical, not advisory.