Chapter 13 — Quantum and post-quantum security: risk scenarios | Technologist Quantum and post-quantum security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 13 — Quantum and post-quantum security: risk scenarios

Lesson map

Lesson 13 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Two kinds of risk"]
  N2["13.2 Scenario format"]
  N3["13.3 Silent fallback"]
  N4["13.5 Practical activity"]
  N5["13.7 From scenarios to runbooks"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Two kinds of risk"]
  N2["13.2 Scenario format"]
  N3["13.3 Silent fallback"]
  N4["13.5 Practical activity"]
  N5["13.7 From scenarios to runbooks"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX025"]

[Learning outcomes]
    |
    v
[13.1 Two kinds of risk]
    |
    v
[13.2 Scenario format]
    |
    v
[13.3 Silent fallback]
    |
    v
[13.5 Practical activity]
    |
    v
[13.7 From scenarios to runbooks]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) write implementable risk scenarios for quantum and migration risks; (2) include migration-induced risks such as outages and silent fallback; (3) rank scenarios using simple scales; and (4) link each scenario to controls and tests.

13.1 Two kinds of risk

Quantum risk is what happens if nothing changes: recorded traffic decrypted, signatures forged. Migration risk is what can go wrong while changing: outages from large handshakes, silent fallback to classical, certificate validation failures, performance regressions, key-management mistakes. Implementers own both and must not trade one blindly for the other.

KLS records both kinds in the same register with the same fields, so a reviewer can see when a plan reduces quantum risk by adding migration risk. Enabling hybrid on all listeners in one change, for instance, removes HNDL exposure quickly but raises the outage likelihood that staged rollout would keep low.

13.2 Scenario format

Each scenario names the asset, the event, the cause, the effect, how it would be detected, likelihood and impact on simple 1–5 scales, the control and the test that shows the control works.

The fields force decisions. A scenario without detection cannot be monitored; one without a test cannot prove its control works. KLS uses 1–5 scales with written anchors: likelihood 4 means "seen at least once in our estate or a peer's", impact 4 means "tier-1 data exposed or a customer-facing outage over an hour". Scores multiply to a rank that orders the backlog, and the anchors stop scores drifting between reviewers.

13.3 Silent fallback

The most dangerous migration risk is invisible: a configuration change, image rollback or new load balancer reverts to classical-only negotiation, and nothing breaks. Without monitoring of negotiated groups, it may persist for months. Every hybrid deployment needs an alert on fallback share.

At KLS it happened in exactly this way: a release restored an old ingress annotation and the portal's hybrid share fell from 93 % to 4 %. No customer noticed and no error was logged; only the share alert, added weeks earlier, showed it. KLS alerts when the share drops more than five points in an hour.

13.4 Worked example

Scenario: "Origin LB rollback restores classical-only TLS profile." Cause: emergency rollback to an old configuration. Effect: tier-1 shipment data again HNDL-exposed. Detection: hybrid-share alert from LB logs. Likelihood 3, impact 4. Control: TLS profile versioned separately from application config; rollback runbooks restore application only. Test: monthly drill rolling back the application and confirming the hybrid share stays above 95 %.

The control is the key decision. Versioning the TLS profile apart from application configuration means an emergency rollback of code cannot reach the cryptographic settings; the drill tests that separation monthly. A score of 12 placed this scenario in KLS's top three, above the quantum scenario for telemetry.

13.5 Practical activity

Write five scenarios for KLS — two quantum, three migration — and rank them.

Quantum examples: partner SFTP sessions recorded and later decrypted (HNDL), and the internal root forged after a quantum computer exists (forge-later). Migration examples: a proxy dropping large ClientHellos, silent fallback after a rollback, and a monitoring agent rejecting an ML-DSA chain. For each, fill every field of the format: asset, event, cause, effect, detection, likelihood, impact, control and test. Rank by likelihood times impact and explain in one sentence why the top scenario outranks the others. Expect a migration scenario to come first.

13.6 Common errors and limits

Ignoring migration-induced risk.
Scenarios without detection.
Controls without tests.

In KLS's first register every scenario was a quantum one; the proxy outages and silent fallback that actually happened in staging were missing. Several scenarios said "impact: high" with no way to detect the event, which made them impossible to monitor. And controls such as "profile versioned separately" were claimed without a drill, so nobody knew whether a rollback really left the profile untouched. A scenario list is a hypothesis about failure; without detection and tests it cannot be checked.

13.7 From scenarios to runbooks

The highest-ranked migration scenarios each deserve a runbook: the symptoms an operator will see, the first three checks, the safe rollback, and who to call. A runbook for "hybrid share dropped on a tier-1 listener" might say: check the last deployment and ingress annotations; compare the live TLS profile hash with the approved one; restore the approved profile without rolling back application code; confirm recovery on the dashboard; open a problem ticket. Runbooks written before the event shorten outages and reduce the temptation to disable post-quantum settings in a hurry.

Review the scenario list after every incident and every major platform change; new hops and new vendors introduce new ways for fallback or failure to occur.

Exercises

EX025 — Scenario. Write a full scenario for "partner SFTP client cannot negotiate hybrid KEX". Rubric: 3 = all fields present and coherent.
EX026 — Detection. Propose detection for silent fallback on the office VPN. Rubric: 3 = data source, metric, threshold.

Synthesis

Implementable scenarios cover quantum and migration risks, with detection, controls and tests; silent fallback deserves special attention because nothing visibly breaks.

Continue studying — chapter 13 of 30

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →