A Post-Quantum Threat-Modeling Playbook: Inventory, Attack Trees, Controls, and a CI Gate

The preceding articles framed the post-quantum migration as a threat-modeling problem and examined its distinctive threats: harvest-now-decrypt-later, downgrade, and the migration's own attack surface. This final article assembles them into a method — a repeatable playbook that any team can run to threat-model its migration end to end. The six steps are inventory, shelf-life ranking, adversary modeling, attack-tree construction, control mapping, and a continuous-integration gate, and together they turn the scattered concerns of the series into a single governed loop. Run this way, the migration is not a one-time swap but a maintained security program, which is exactly what a transition spanning years against a patient adversary requires.

The six-step method

The playbook is a loop of six steps. First, inventory: build both a cryptographic bill of materials, cataloging every algorithm, key, and certificate, and a data-at-risk inventory of confidential flows and stores. Second, rank by shelf-life: score each data asset by the margin between its required protection lifetime plus migration time and the time to quantum, surfacing the harvest-now-decrypt-later priorities. Third, model the adversary: name both the passive collector with future capability and the active on-path downgrader, on their different clocks.

Fourth, build attack trees: for each high-priority asset, enumerate how an adversary could reach it — recording classical traffic, forcing a downgrade, exploiting a combiner failure, weaponizing bloat into denial, or slipping through a key-management gap. Fifth, map controls: pair every attack path with a concrete countermeasure, from hybrid key exchange to fail-closed policies to vetted combiners. Sixth, gate: encode those controls as automated checks in continuous integration that fail the build on any regression, so the protections stay in place as the system evolves.

The steps form a loop rather than a line because the inputs change: the quantum estimate shifts, the estate evolves, new assets appear, and new attacks are discovered. Re-running the loop keeps the analysis current, and the continuous-integration gate holds the line between runs. This is the same governed-loop discipline the migration methodology applied to execution, here applied to the threat analysis itself, so that the two dovetail into one program.

Building attack trees

The analytic heart of the playbook is the attack tree. For a chosen high-value asset — say a long-retention confidential archive — the root of the tree is the adversary's goal, reading the asset, and the branches are the distinct ways to achieve it. Each branch corresponds to one of the series' threats: harvest the traffic now and decrypt later, force a downgrade to breakable classical cryptography, exploit a flaw in the hybrid combiner, deny service through bloat to disrupt or force fallback, or exploit a transitional key-management gap. The tree makes the paths explicit and comprehensive rather than leaving them implicit.

Decomposing each branch to leaves clarifies exactly what an attacker must do and therefore what must be prevented. The harvest branch leaf is: the traffic is protected only by classical cryptography at recording time. The downgrade branch leaf is: the system silently falls back to classical when the post-quantum path is blocked. The combiner-failure leaf is: a bespoke combiner fails to bind the transcript. Each leaf is a concrete condition, and preventing it is a concrete control, which is what the next step maps.

Attack trees also prioritize and communicate. The branches with the shortest paths to the goal — the easiest attacks — get attention first, and the tree is a clear artifact for reasoning and review, showing stakeholders how each threat connects to the asset. Building trees from the highest-priority assets identified in the ranking step focuses the effort where the shelf-life-versus-quantum math is most adverse, connecting the whole method back to the anchor threat.

Mapping threats to controls

Every leaf of every attack tree is paired with a countermeasure, producing the threat-to-control mapping that is the playbook's actionable output. The harvest threat is countered by deploying hybrid post-quantum key exchange now for at-risk data, so recorded traffic is not classically protected. The downgrade threat is countered by authenticated negotiation and a fail-closed post-quantum-required policy, so the post-quantum path cannot be silently stripped. The combiner-failure threat is countered by using a vetted, standardized combiner rather than custom code.

The remaining migration-surface threats map likewise. Bloat-driven denial is countered by denial-of-service defenses sized for the larger post-quantum artifacts; transitional key-management gaps are countered by algorithm-agnostic, tested key management with confirmed hardware support. The table gathers these pairings. Its value is that it leaves no threat without an assigned control and no control without a threat it addresses, which is the discipline that turns a list of worries into a defensible plan.

This mapping is also where the earlier series connect. The controls are precisely the mechanisms those articles developed — the robust combiner, the hybrid exchange, the ephemeral keys, the fail-closed policy, the crypto-agile key management — now indexed by the threats they counter. The threat-modeling series identifies the threats; the migration and implementation series supply the controls; and the mapping is the bridge between them, ensuring the migration's engineering choices are driven by an explicit threat analysis rather than convention.

Gating the controls

Identifying controls is not enough; they must stay in place as the system changes, and the mechanism is a continuous-integration gate. Each control becomes an automated check that runs on every change and fails the build if the control is absent or regressed: no non-post-quantum configuration for data classified at-risk, no silent classical fallback for such data, only the vetted combiner in use, denial-of-service limits present, key management conforming to the algorithm-agnostic pattern. The gate converts the threat model's conclusions into enforced invariants rather than documented intentions.

This gating mirrors the regression gate the migration methodology recommended for execution and the constant-time gate the implementation series recommended for side channels, unifying them: the threat model, the migration, and the implementation all end in continuous-integration checks that prevent backsliding. A migration that has been threat-modeled, controlled, and gated is one whose security posture is maintained automatically, so that a later change cannot silently reintroduce a harvestable flow, a downgrade path, or a hand-rolled combiner.

The gate also makes the whole program auditable. A reviewer can see, in the continuous-integration configuration, exactly which threats are being defended and confirm the checks are active, turning the threat model from a document that ages into a living control enforced on every commit. This is what makes the playbook a program rather than an exercise: its conclusions are encoded where they cannot be quietly forgotten.

The living loop, and the agent platform

The playbook is a living loop, not a one-time analysis. The quantum estimate moves, re-ranking the shelf-life priorities; new assets and flows appear, needing inventory and trees; new attacks are published, adding branches; and the gate must be updated as controls evolve. Re-running the loop on a regular cadence, and whenever a significant input changes, keeps the threat model aligned with reality over the years a migration spans. A stale threat model silently mis-defends as the ground shifts, which is why the loop, and the discipline of re-running it, is the point.

This aligns the playbook with the practice guidance the standards bodies have published, which describe the same inventory-driven, prioritized, controlled, and governed approach to the migration. Following an established method rather than improvising means inheriting its structure and its lessons, and the six-step loop is a concrete instantiation of that guidance focused on the threat-modeling dimension. The threat model and the migration program are two views of one governed effort.

For autonomous AI systems the playbook applies directly and with high stakes. Run the loop over the AI platform: inventory the model channels, agent-identity keys, and long-retention training-data archives; rank the archives to the top by shelf-life; model the passive collector harvesting model and agent traffic and the active attacker probing the agent mesh for downgrades; build attack trees to the training data and identity roots; map controls — hybrid key exchange, fail-closed post-quantum channels, vetted combiners, denial-of-service defenses, agile key management; and gate them in the platform's continuous integration so no agent or service can ship without them. Because AI infrastructure is being built now, with its most valuable assets — training data — being recorded now, running this playbook over the agent platform is not a future task but a present one, and it is the culmination of the entire post-quantum analysis: a threat-modeled, controlled, and continuously-gated migration of the cryptography that will protect AI systems into the quantum era.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

pqc_threat_modeling_playbook:
  step_1_inventory: [cbom, data_at_risk]
  step_2_rank: shelf_life_margin
  step_3_adversary: [passive_collector, active_downgrader]
  step_4_attack_trees: per_high_priority_asset
  step_5_controls: map_every_leaf
  step_6_gate: ci_fail_on_regression
loop:
  re_run_on: [quantum_estimate_change, new_assets, new_attacks]
alignment: nist_practice_guidance

Glossary

Threat-modeling playbook

A repeatable six-step loop: inventory, shelf-life ranking, adversary modeling, attack trees, control mapping, and a continuous-integration gate.

Attack tree

A structure whose root is the adversary's goal and whose branches are the distinct paths to it, decomposed to concrete leaf conditions to prevent.

Threat-to-control mapping

The pairing of every attack path with a countermeasure, ensuring no threat is unaddressed and no control unjustified.

Continuous-integration gate

Automated checks encoding the controls, failing the build on any regression so protections stay enforced as the system evolves.

Living loop

Re-running the playbook as the quantum estimate, estate, and known attacks change, keeping the threat model aligned with reality.

Practice-guide alignment

Following the standards bodies' inventory-driven, prioritized, controlled, governed migration approach rather than improvising a method.

References

1. Shostack, Threat Modeling: Designing for Security (Wiley, 2014)
2. NIST SP 1800-38, Migration to Post-Quantum Cryptography (practice guide)
3. NIST IR 8547, Transition to Post-Quantum Cryptography Standards (2024)
4. Mosca, Cybersecurity in an Era with Quantum Computers (IEEE Security & Privacy, 2018)
5. IETF draft-ietf-tls-hybrid-design, Hybrid Key Exchange in TLS 1.3