Target Level Zero Trust is due by fiscal year 2027. Cryptographic agility is due by 2030 and 2031. Both require the same architecture.
At A Glance
- DoD/DoW Zero Trust Strategy: Target Level implementation due by September 30, 2027; Advanced Level by 2032.
- DoW PQC Strategy: systems must support PQC or be phased out by December 31, 2030; must use PQC by December 31, 2031.
- The PQC strategy explicitly warns against treating a PQC proxy as a permanent substitute for upgrading the underlying system.
- Legacy weapons platforms, embedded systems, and OT with decade-plus lifecycles can’t uniformly hit either deadline through direct upgrade alone.
The Department of War is running two countdowns at once: the DoW Post-Quantum Cryptography Strategy, the department’s plan for migrating to cryptography that can withstand attacks from quantum computers, requires systems to support PQC or be phased out by December 31, 2030, and to actually use PQC by December 31, 2031. Meanwhile, the department is mid-execution on a separate deadline: Target Level Zero Trust, due by the end of fiscal year 2027.
Treating those as two separate programs gets you two inventories, two sets of architecture reviews, and two competing line items on the same modernization budget. But the mandates are actually the same architecture problem, just arriving on two different clocks.
What Does the DoW’s PQC Strategy Require?
The strategy defines quantum resistance across the whole mission thread; success means vulnerable algorithms and protocols are retired across the full data pathway and lifecycle. NIST’s standardized primitives (ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures) cover the math, but the DoW’s own strategy separates the operational lift into three areas: session secrecy, identity and PKI, and protocol-path compatibility. (For a full breakdown of how those three pillars work and why they don’t migrate on the same timeline, see PQC Doesn’t Need a Network Forklift.)
The DoW document goes further: it explicitly rejects a PQC proxy as an end state. A gateway or wrapper that adds quantum-resistant transport without the underlying PKI, controllers, and endpoints becoming crypto-agile is only a staging step toward compliance. The strategy calls for inventory, modernized PKI, interoperable commercial solutions, and cryptographic agility that shortens the time and cost of the next change. It’s essentially an architecture mandate wearing a cryptography label.
Why Does This Land on Top of the Already-Running Zero Trust Deadline?
DoD’s Zero Trust Strategy requires “Target Level implementation” (91 of 152 mapped activities) by the end of fiscal year 2027, with Advanced Level activities due by 2032. Every DoW component and Defense Industrial Base partner is already being scored against that roadmap.
Zero Trust implemented as topology, like VLANs, subnet segmentation, or a firewall policy labeled “Zero Trust,” does nothing for PQC readiness. It still routes first and checks identity second, so every device in that path remains a PQC dependency.
Zero Trust implemented as identity-first reachability does the opposite. It already defines an authorized identity-to-service connection instead of a network path. In essence, a program that gets Zero Trust architecture right for FY2027 has built most of what PQC compliance needs for 2030 and 2031 without much extra work.
Why Identity-First Reachability Satisfies Both Mandates at Once
Identity-First Reachability™ makes a service unreachable until an authorized identity, policy, and posture check clear: there’s no route, no session, and no listening surface before that. Elsewhere, I’ve compared it to Diagon Alley, where the entrance stays concealed as an ordinary wall until you tap the right sequence of bricks with a wand.
That same primitive answers both mandates simultaneously. For Zero Trust, it satisfies the application/workload and network/environment pillars the DoD roadmap scores against. For PQC, it gives the strategy the exact migration unit it needs: an authorized service connection that can carry a cryptographic boundary without dragging the rest of the network into the same change window. NetFoundry delivers this through OpenZiti, a PKI-native fabric that separates control from the data plane. That matters especially for mission environments, since a controller can run locally where sovereign, disconnected, or tactical-edge operation requires it instead of depending on a distant service to authorize every local flow.
What About Legacy Weapons Systems and OT That Can’t Be Upgraded?
A gateway doesn’t make an old PLC, embedded controller, or legacy weapons platform PQC-native. If that system’s local connection still runs vulnerable cryptography, the weakness is still there, and the DoW strategy is explicit that a proxy can’t be the permanent answer.
What a gateway changes is exposure. Place an identity-first boundary close to the legacy system, remove ambient network reachability to it, and require an authorized identity-to-service relationship through that boundary, so an attacker on the same subnet still can’t reach the old protocol directly. As the application becomes capable, that cryptographic boundary can move inward, gateway to host to SDK, shrinking the classical segment on a schedule you control.
How Should a Mission Owner Sequence This?
The DoW rightly starts with inventory, but inventory doesn’t have to be a multi-year pause before anything moves.
- Select a mission thread. Prioritize long-lived data, mission impact, and systems that are hardest to replace directly.
- Map dependencies against both roadmaps at once. Identify session cryptography, identity and certificate chains, and which components terminate or inspect the protocol path, then check the same list against the Zero Trust pillars you’re already scored on.
- Place the cryptographic boundary and document it. For legacy systems, start at the nearest practical gateway and record the remaining classical segment and the plan to move it inward.
- Remove the bypass path. Replace ambient network access with identity-, posture-, and policy-based reachability so the boundary can’t simply be routed around.
- Introduce hybrid-PQC and capture evidence once. The same interoperability, performance, and policy evidence supports both the Zero Trust scorecard and PQC compliance reporting, one migration satisfying two mandates.
Close Both Gaps With One Architecture Decision
One architecture decision closes both gaps instead of running Zero Trust and PQC as two competing modernization programs chasing the same infrastructure budget. NetFoundry is a leader in Secure Workload Connectivity, built by the founders of OpenZiti, the open-source zero trust platform the DoW’s own commercial and DIB partners already run on. Identity-First Reachability™ gives a mission thread one architecture that moves it toward both the FY2027 Zero Trust target and the 2030/2031 PQC deadline, including for OT, embedded, and legacy weapons systems that can’t be recompiled on anyone’s timeline.
Choose one mission thread. Prove the cryptographic boundary can move. Then scale what works across the rest of the roadmap. Talk to NetFoundry before these two deadlines turn into two separate multi-year programs competing for the same funding.
Frequently Asked Questions
What are the DoW’s PQC migration deadlines?
The DoW Post-Quantum Cryptography Strategy requires systems to support PQC or be phased out by December 31, 2030, and to be using PQC by December 31, 2031, unless otherwise noted in the strategy.
Does the DoW’s PQC strategy overlap with the DoD Zero Trust Strategy deadline?
Yes. DoD’s Zero Trust Strategy requires Target Level implementation — a baseline set of 91 mapped activities — by the end of fiscal year 2027, ahead of both PQC deadlines. An architecture built identity-first for Zero Trust compliance covers much of what the later PQC deadlines require.
Can a PQC-capable proxy or gateway satisfy the DoW’s mandate on its own?
Not on a permanent basis. The DoW strategy is explicit that a PQC proxy is a staging step, not an end state — the underlying PKI, controllers, and endpoints still need to become crypto-agile over time. At NetFoundry, we treat a gateway as a documented boundary with a plan to move inward, not a substitute for that work.
What happens to legacy weapons systems and OT that can’t be upgraded directly?
An identity-first gateway can remove ambient network reachability to the legacy system and require an authorized identity before any connection forms, which shrinks the attack surface immediately. It doesn’t make the legacy system’s own cryptography quantum-safe — that segment stays explicitly documented until the boundary can move to the host or application.
How does identity-first reachability help meet both deadlines at once?
It changes the unit both mandates ultimately care about — from a network path to an authorized identity-to-service connection. That same unit satisfies Zero Trust’s application/workload and network/environment pillars and gives PQC a migration boundary that can move service by service instead of requiring an estate-wide refresh.
