Operation Quiet Rollback.
A five-inject red-team tabletop exercise covering the structural pitfalls of a real hybrid PQC deployment.
Ninety minutes for an experienced room; two hours otherwise. The scenario is calibrated to surface the operational gaps that almost every hybrid PQC deployment hits: silent downgrade, MTU fragmentation, HNDL capture during the gap, IDS false positives, and a missing PKI dependency. Run it before any production hybrid deployment — not after.
An organization has just deployed hybrid TLS 1.3 (X25519 + ML-KEM-768) on its externally facing API gateway. The legacy internal load balancer does not support ML-KEM and silently negotiates classical-only cipher suites with the gateway. A network-position attacker begins passively recording all traffic. The blue team has been told "the deployment is complete" and has not yet been informed of the load-balancer gap.
The exercise covers five injects over a single working session. Each inject maps to a structural pitfall from the security-architects briefing. The objective is not to "win" — it is to surface which gaps the team can detect, which they would miss in production, and which controls (logging, MTU testing, PKI validation, IDS coordination) need to be added before deployment.
The room.
Four roles. Facilitator (1) — runs the clock, reveals injects, scores the debrief. Red team (1–2) — represents the network-position attacker; reads inject content aloud and pushes back when blue claims a detection that isn't actually wired. Blue team (4–6) — security operations, network engineering, identity, and PKI representation; their job is to respond to each inject. Observer (optional) — takes notes for the post-exercise writeup; does not participate.
Materials: the PDF (printed), five inject cards (cut from the PDF), one debrief scoring sheet per blue team member, a whiteboard or large notebook for the running incident log, and a timer. No live systems are required — this is a discussion exercise, not a fire drill.
Time budget
- 0 – 10 min. Facilitator reads the setup. Blue team is told only what's in the public-facing setup paragraph above; the load-balancer detail is withheld.
- 10 – 75 min. Five injects, twelve minutes per inject. Facilitator pauses after each one for blue-team response and red-team rebuttal.
- 75 – 90 min. Debrief. Score against the five questions. Identify the three highest-priority gaps.
What red reveals; what blue must catch.
The load balancer is silently classical-only.
Red team revealsWireshark capture shows that the TLS cipher suite negotiated between the API gateway and the internal load balancer is ECDHE-only on 40% of sessions. The hybrid ML-KEM exchange is not being used on those sessions. openssl s_client -cipher output confirms the load balancer offers only classical groups.
Blue team mustIdentify whether cipher-suite negotiation logging exists in the gateway. Determine whether anyone would notice this in production today. Articulate what alert or dashboard would have surfaced the gap. Pitfall: downgrade attack invisibility.
Adversary begins recording classical-only sessions.
Red team revealsBeginning at the moment of the partial deployment, the attacker is HNDL-capturing the classical-only traffic on the internal segment. The captures include API tokens, customer PII, and signed JWTs from the identity provider. The captures persist for the indefinite future.
Blue team mustIdentify which sessions are at HNDL risk. Determine whether session-level cipher-suite metadata is retained in logs for retroactive analysis. Decide whether to issue a retroactive risk advisory to the privacy and legal team. Pitfall: shadow cryptography on unprotected paths.
Vendor patch increases handshake beyond 1,500 bytes.
Red team revealsThe load-balancer vendor releases a PQC patch that raises the handshake size past the standard 1,500-byte Ethernet MTU on certain client paths. After the patch, intermittent connection failures appear for a subset of mobile clients. Stateful DPI in the path is silently dropping fragmented IP packets.
Blue team mustIdentify whether MTU was tested at every boundary in the path before the patch was deployed. Determine the rollback plan — and whether the rollback would re-introduce the classical-only condition from Inject 01. Pitfall: MTU fragmentation under DPI.
SIEM flags PQC traffic as anomalous.
Red team revealsThe IDS — which has not been updated since before the hybrid deployment — flags the PQC handshakes from a newly-rolled department as anomalous. The volume of alerts is high enough that security operations is now systematically ignoring the alert class, including a small number of genuine probe attempts hidden in the noise.
Blue team mustIdentify the change-ticket trail for the IDS signature update — was it part of the deployment checklist or omitted? Determine the path to whitelist legitimate PQC traffic at the correct signature level. Pitfall: firewall / DPI / IDS incompatibility.
Code-signing CA cannot issue ML-DSA.
Red team revealsAn emergency software release needs to ship in the next four hours. The internal code-signing CA does not yet support ML-DSA. Hot-fix is now blocked behind a PKI dependency nobody on the architecture team identified during the deployment planning.
Blue team mustIdentify whether the CA dependency was on the inventory before deployment. Determine the exception process — does it require classical signing, dual-cert, or a delay to the release? Document the decision for post-exercise review. Pitfall: PKI chain failure.
Five questions. Three actions.
The debrief is fifteen minutes and answers five binary questions about what happened during the exercise. The point is not to grade the team — it is to identify the three highest-priority control gaps to fix before the next production hybrid deployment.
Debrief scoring (Y/N)
- 01. Was the classical downgrade detected within the scenario timeframe?
- 02. Was a rollback plan executed without full session loss?
- 03. Did the HNDL exposure window have a defined response?
- 04. Were IDS rules updated as part of the deployment checklist?
- 05. Was the CA dependency identified during inventory?
Three or more Y answers indicates a deployment is reasonably defensible. Two or fewer indicates the deployment should not have shipped without the missing controls being added. Either way, the three lowest-scoring areas become the named work items for the next sprint — with owners, dates, and follow-up at the next quarterly review.
Tying the lesson back
- Each inject maps to a pitfall from the Security Architects briefing and the corresponding pitfall in the Enterprise Readiness whitepaper.
- The exercise demonstrates that "PQC-enabled" ≠ "PQC-protected" without operational completeness — the central thesis of the security-architects briefing.
- The five questions in the debrief are the deployment-readiness checklist for any future hybrid rollout.
The scenario is engineered to surface the same pitfalls documented in the Security Architects briefing and §12 of the Enterprise Readiness whitepaper. Use it after the Inventory Worksheet is current — the inventory tells you what's deployed; the tabletop tells you whether it's defensible.