The Department of War’s Zero Trust Target Level deadline may be September 30, 2027, but for agencies responsible for device security, the practical deadline comes much sooner.
That is because some of the hardest Zero Trust controls sit inside the Device pillar, and many of those activities are scheduled early enough that they need to be operational, integrated, and producing evidence in 2026. Waiting until the final year to address device trust creates avoidable risk: procurement delays, integration gaps, incomplete baselines, missing telemetry, and limited time to demonstrate measurable progress.
For Zero Trust leaders, the implication is clear. Device trust cannot be treated as a late-stage compliance exercise. It is one of the early dependencies that determines whether the rest of the architecture can make reliable access, authorization, monitoring, and response decisions.
The FY2027 Deadline Can Create a False Sense of Runway
DoW Components are expected to reach Target Level Zero Trust by the end of FY2027. On paper, that may sound like there is still time. In practice, the Device pillar has a different clock.
The DoW Zero Trust Capability Execution Roadmap lays out a multi-year implementation timeline, and the Device pillar is effectively front-loaded. Multiple Target Level device activities are expected to be implemented and matured across FY2024 through FY2026. That makes 2026 the critical year to operationalize device controls, close visibility gaps, and begin producing measurable evidence of progress.
This matters because device trust is not something that can be switched on at the end of a program. Agencies need time to:
- Discover and classify devices across heterogeneous environments;
- Identify gaps in existing device health tooling. Existing tools often don’t reach the depth required by the Target Level mandates;
- Establish known-good hardware and firmware baselines;
- Integrate posture signals into enforcement workflows;
- Tune policies for mission impact;
- Validate reporting and evidence collection; and
- Mature operations around continuous compliance.
The 2027 mandates are already in place. But while a policy can be signed today, a trustworthy device program takes time to build. We can’t wait until the deadline to begin.
The Hardest Device Controls Are Not Paperwork Exercises
Some Zero Trust activities can begin with policy updates, process definitions, or configuration changes in mature enterprise platforms. Device-pillar activities are different. Many of them require agencies to know whether each device is actually trustworthy, not merely whether it is enrolled in a management tool or has an endpoint agent installed.
That distinction becomes important in activities such as:
- Device Health Tool Gap Analysis;
- NPE/PKI, Device under Management;
- Implement C2C/Compliance Based Network Authorization;
- Implement Application Control and File Integrity Monitoring tools;
- Integrate NextGen AV tools with C2C;
- Deny Device by Default Policy;
- Managed and Limited BYOD and IoT Support;
- Implement Asset, Vulnerability and Patch Management tools;
- Implement UEDM or equivalent tools;
- Enterprise Device Management;
- Implement EDR tools and integrate with C2C; and
- Implement XDR tools and integrate with C2C.
These activities are difficult because they move beyond visibility into enforcement. They ask agencies to make decisions based on device condition: whether a device should be allowed onto the network, whether it should receive a certificate, whether it should access an application, whether it should be quarantined, and whether its posture should influence incident response or risk scoring.
Some of these activities have useful analogies in other fields. Comply to Connect (C2C) has precedent in the context of Criminal Justice Information Systems (CJIS) requirements. Law enforcement agencies throughout the U.S. must validate the integrity of firmware in any computer that accesses CJIS systems. But assuring that squad cars don’t connect to CJIS data if they aren’t compliant is a nontrivial problem. Multiply it across all the other types of devices and restricted data sources and you begin to see the scope of the challenge this pillar poses.
Those decisions require reliable signals. If the device telemetry is incomplete, the enforcement logic will be incomplete too.
Why Device Trust Is a Zero Trust Dependency Chain
The Device pillar should not be viewed as a checklist of unrelated controls, but as a chain of dependencies. First, agencies need to know what devices exist. Then they need to know whether those devices are under management. Next, they need to understand each device’s health, configuration, firmware integrity, vulnerability exposure, and patch posture. Only then can they make risk-based access decisions and continuously enforce policy.
A simplified progression looks like this:
1. Know the device.
Build accurate device inventory, identify unmanaged or unknown assets, and understand where existing health tools lack visibility.
2. Trust the device.
Verify device integrity, establish known-good baselines, monitor for drift, and understand vulnerabilities or insecure configurations below the operating system.
3. Enforce based on device trust.
Feed device posture into C2C, NAC, ZTNA, UEM, IdP, PAM, and other access-control workflows so authorization decisions reflect actual risk.
4. Operationalize the evidence.
Export device-trust context into SIEM, XDR, SOAR, ITSM, vulnerability management, and compliance reporting workflows so security teams can act on the data and demonstrate progress.
This sequence is why the schedule matters. If agencies are still working through basic device visibility in late FY2027, they will not have enough time to mature the downstream enforcement, analytics, and automation activities that depend on that visibility.
The Hidden Challenge Is Below the Operating System
Most agencies already have some combination of endpoint protection, EDR, vulnerability scanning, configuration management, mobile device management, and asset inventory. Those tools are necessary, but they do not always answer the deeper device-trust questions that Zero Trust depends on.
A device may appear compliant at the operating-system layer while still carrying risk in firmware, hardware components, BMCs, boot processes, security processors, network interfaces, or other layers below the OS. These layers can affect whether the device is truly in a known-good state, whether it has drifted from baseline, whether it contains vulnerable firmware, and whether it should be trusted for sensitive workflows.
That is the below-the-OS gap.
Traditional tools often focus on what the operating system can see. Zero Trust device decisions increasingly require evidence about the device itself: firmware and component inventory, hardware roots of trust, known-good integrity verification, vulnerability and patch posture, and drift detection.
This is where device trust becomes more than endpoint management. Agencies need authoritative signals that can support access decisions, compliance reporting, threat detection, and remediation across the full device stack.
Why 2026 Is the Window to Act
The Device pillar’s front-loaded schedule means 2026 is not a planning year. It is an execution year.
Agencies that act now can use 2026 to establish baselines, integrate telemetry, refine policies, and build evidence before the FY2027 deadline. Agencies that wait risk discovering too late that their existing endpoint and management tools do not provide the depth of device trust required for Target Level outcomes.
The practical work should start with five priorities.
1. Identify device-health visibility gaps.
Start by comparing current tooling against the Device pillar activities. Determine which assets, firmware layers, unmanaged devices, network devices, servers, BYOD, IoT, or NPEs are not adequately covered.
2. Establish known-good device baselines.
Do not wait until enforcement is required to define what “trusted” means. Establish baseline expectations for hardware, firmware, configurations, vulnerabilities, and patch posture.
3. Extend vulnerability and patch management below the OS.
Firmware vulnerabilities and insecure configurations can create risk that traditional scanners miss. Target Level progress requires a more complete view of device exposure.
4. Integrate device-trust signals into enforcement workflows.
Device telemetry becomes more valuable when it informs C2C, NAC, ZTNA, UEM, IdP, PAM, EDR, XDR, SIEM, SOAR, and ITSM workflows. The goal is not another dashboard. The goal is better authorization, detection, prioritization, and response.
5. Produce evidence continuously.
Target Level readiness is not just a matter of implementation. Agencies need measurable evidence that controls are operating, telemetry is current, baselines are enforced, and exceptions are understood.
How Eclypsium Helps
Eclypsium helps agencies accelerate progress toward DoW Zero Trust Target Level activities by providing authoritative device-trust signals that traditional OS-level tools often miss.
These signals include firmware and component inventory, integrity verification against known-good baselines, vulnerability and patch posture, and drift detection. They can be managed directly within the Eclypsium platform or integrated into C2C, NAC, ZTNA, UEM, SIEM, XDR, SOAR, ITSM, and other enterprise workflows.
That support is especially relevant to the Device pillar, where agencies must move from basic endpoint visibility to continuous device compliance and authorization. It also supports related outcomes in User, Application and Workload, Automation and Orchestration, and Visibility and Analytics, where device posture can enrich access decisions, vulnerability workflows, incident response, threat intelligence, and compliance evidence.
The point is not that any single platform “solves” Zero Trust. The point is that Zero Trust decisions are only as trustworthy as the signals behind them. For the Device pillar, those signals need to include the layers of the device that traditional endpoint tools may not see.
The Device Pillar Is A Prerequisite For Achieving The Others (So You Should Do It First)
The end of FY2027 remains the formal Target Level deadline. But for the Device pillar, agencies should plan as though the decisive work happens in 2026.
That is when device inventories need to become authoritative. That is when known-good baselines need to be established. That is when firmware and component risk needs to become visible. That is when device posture needs to begin flowing into access, monitoring, and response workflows. And that is when agencies need to start producing the evidence that shows real Target Level progress. In our eyes, the hardest Device controls are front-loaded, so the time to act is now.
