U.S. Army lens
1994 → Q-DAY · Cryptographic readiness for the force

The road to Q‑Day

On 11 August 2015, NSA and the Committee on National Security Systems issued CNSS Advisory Memorandum 02-15, an advisory memo, warning against major new investment in the public-key cryptography that protects command and control (C2). Vendors and agencies were told to prepare for quantum-resistant algorithms. This timeline shows the paper-train from that memo to a cryptographically relevant quantum computer (CRQC). Each document adds a piece of the story of when the Quantum threat arose, where Army systems and the defense industrial base (DIB) sit in the gap, and what happens to warfighter advantage if we get the timing wrong. Harvest-now-decrypt-later (HNDL) gets the attention, but the sharper concern is quantum forgery: a CRQC does not just read yesterday's traffic. It can sign tomorrow's emails, forge credentials, spoof logs, and counterfeit software updates accepted as authentic in real time.

 
 
 
Document manifest · newest first

ID → Document

ID Date Document Phase Source

 

Requirements before transition

The Cost of Waiting

The expensive mistake is not “waiting to buy PQC.” It is waiting to understand and inventory the network, then rushing a transition on incomplete requirements. Calm time spent now on inventory, latency budgets, interoperability, and operator reality is cheap. The joint force has earned this lesson the honest way, through pathfinder programs that took on hard problems first: tactical transport with WIN-T, regional security with JRSS. Their experience is the department's institutional knowledge: when requirements are still being mapped during fielding, costs compound in budget, training, and time. PQC gets to start with that map already drawn.

Spend the early dollars on requirements, not on rushing the cutover. Before any cutover, close out:

  • Cryptographic inventory: where RSA/ECC actually lives
  • Application and legacy-network dependencies
  • Latency and throughput budgets when key sizes and handshakes grow
  • ICS / OT paths and constrained devices
  • Tactical operating conditions and operator cognitive load
  • Vendor support and crypto-agility commitments

Skip that work and the force pays twice: once in fielding that needs rework, again in redoing it under a tighter CRQC clock.

NO PANIC PANIC RESOURCES EXPENDED VENDOR HYPE map the network first: cheap, steady cutover without requirements: expensive, brittle
 
Left → right No panic now, full panic near Q-Day. Time to the threat runs left to right.
 
Teal curve · resources Cost and effort climb as you wait. Early requirements work is cheap; late cutover is not.
 
Red wave · mistakes Errors grow with the rush. Hurried migrations tend to miss apps, latency, ICS, and operational fit.
 
Amber dashes · vendor hype Solution pressure can outrun validated requirements as urgency rises. Buy to the inventory, not the pitch.
All curves are conceptual illustrations, not measured data.
Lessons · WIN-T Inc 2

Operational fit is a requirement too

WIN-T delivered genuinely hard capability: mobile, on-the-move tactical networking at a scale no one had fielded before. The lesson it left is about operational fit, not the technology or the professionals who built it. Rigorous operational testing did exactly what it exists to do, surfacing that early SNE and PoP nodes asked more of formations than the fight allows, and Army leadership acted on that truth with discipline: pause, redirect roughly $2.3B, and redesign the network approach. For PQC, the inheritance is clear: write tactical C2, mobility, and soldier cognitive load in as hard requirements from the start, so the force fields crypto it can fight with.

Lessons · JRSS

The hard requirements surface at migration scale

JRSS took on an enormous and worthy goal: consolidating security for a sprawling enterprise into a modern, standardized stack. The stack itself was capable; what the effort revealed is that application dependencies, legacy networks, industrial control / OT paths, and latency budgets only fully show themselves at migration scale. Oversight reviews captured those discoveries, and DISA worked steadily to close each gap as migrations proceeded, knowledge the department holds today only because JRSS went first. For PQC: larger keys and heavier handshakes press hardest on exactly those late-surfacing edges, and the JRSS experience is the map for finding them early.

These lessons are being applied, not just cited. The ideas above are under strong assessment in the current PQC implementation with appropriate discovery and validation tooling. Vendor and supply chain risk is gated through DoW ATLAS before capability is fielded.

Meanwhile the network keeps condensing: more function in less gear, more apps on shared paths, less slack for latency or complexity. That raises the stakes on requirements work: a rushed PQC cutover would face the same two categories of surprise (operational fit on one side, application, legacy, ICS, and latency dependencies on the other), compressed into tighter boxes. Inventory and requirements work is how the force sees those early. Sources: references.bib

DoW process · inside the execution window

What ATLAS is

ATLAS (Acquisition, Testing, and Licensing Authorization for Security) is the Department of War intake, tracking, and approval process for post-quantum cryptography solutions. It is how the 2029 migration stays coordinated: industry has one door in; Components get a shared map of what is approved and usable. It does not replace NIST standards, CNSA 2.0, or a program's own test and fielding work. It is the Department gate those solutions pass before they are tested, bought, or fielded.

How it fits · now

The Strategy window has a single door

The DoW PQC Strategy set the 31 December 2029 fence. ATLAS is the process that keeps that fence from becoming a pile of uncoordinated pilots. For industry it is the entry point for a new solution. For Components it is the tracking map of readiness and approved use.

Who does what

Component sponsors; vendor submits

A DoW Component sponsor initiates the request. The vendor submits one intake questionnaire per solution, with artifacts that show how algorithms, protocols, random numbers, and key management actually sit in the product. White papers are required. Marketing-only packets are declined.

What approval means

Reciprocal across the Department

Once a product is approved, that authorization holds for the approved scope and use case across DoW. A second Component does not restart intake for the same solution. ATLAS is not a design consultancy: it does not solicit missing detail or recommend architecture.

The questionnaire is on the DoW Forms host (CAC). Further detail is in the November 2025 DoW CIO memo. The .mil site is restricted to DoW CAC users; vendors do not receive access.

Living reference hubs

Undated sources, not on the timeline

These pages update continuously, so pinning them to a date would be false. They are the working surfaces of the migration.

Org Resource Source

 

U.S. ARMY LENS ON A JOINT / FEDERAL PAPER TRAIL · Q-DAY IS A POINT; ITS TIMING IS A BAND. THE UNCERTAINTY IS THE THREAT MODEL. · EDIT DOCS AND PHASES IN THIS FILE TO EXTEND THE TIMELINE.