U.S. Army lens
2015 → 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, not a directive, warning against major new investment in the public-key cryptography that protects command and control (C2) and telling vendors and agencies to prepare for quantum-resistant algorithms. This is the paper trail from that memo to a cryptographically relevant quantum computer (CRQC): what the department believed at each point about post-quantum cryptography (PQC), 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.

 
 
 
Document manifest · newest first

ID → Document

ID Date Document Phase Source

 

Working assumptions

  • ▸ A peer adversary fields a CRQC in the 2030-2035 band, and does not announce it.
  • ▸ Harvest-now-decrypt-later against Army and Joint traffic is already underway.
  • ▸ The lattice math behind ML-KEM / ML-DSA (and CNSA 2.0 for NSS) holds.
  • ▸ DoW 2030 / 2031 deadlines are the Army planning fence, not the civilian 2035 glidepath.

Proven assumptions

  • ▸ "Migration takes a decade+", proven: standards alone took 2016→2024.
  • ▸ "Candidates can fail late", proven: SIKE and Rainbow broken during the competition, SIKE on a laptop.
  • ▸ "Mandates outpace tooling", proven: inventories were ordered (M-23-02) before discovery tools matured.
  • ▸ "The hard problem is the force, not the desk", evidenced: DoW moved ahead of civilian 2035 because platforms, DIB, and NSS cannot wait.
Requirements before transition

The Cost of Waiting

The expensive mistake is not “waiting to buy PQC.” It is waiting to understand 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 learned this lesson before: when capable programs field ahead of fully mapped requirements (tactical transport with WIN-T, regional security with JRSS), costs compound in budget, training, and time, and the people closest to the mission carry the friction.

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

The lesson is about operational fit, not the technology or the people who built it. Operational testing found early SNE and PoP nodes hard to employ in the fight units actually fight, complex enough that commanders preferred to operate without them. Oversight reviews later questioned the procurement basis, and the Army made the hard, right call: halt, redirect roughly $2.3B, and redesign the network approach. For PQC: if tactical C2, mobility, and soldier cognitive load are not written as hard requirements, the force will field crypto it has to work around.

Lessons · JRSS

The hard requirements surface late if you let them

JRSS fielded a capable security stack; the challenge was everything around it. Application dependencies, legacy networks, industrial control / OT paths, and latency budgets surfaced during migration rather than before it. Oversight reviews documented unmet user needs, training gaps, and incomplete requirements and test plans, and DISA worked fixes as migrations slowed to close the gaps. For PQC: larger keys and heavier handshakes press hardest on exactly those late-surfacing edges.

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 are linked in the document manifest and lesson citations above.

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