Skip to content

CONCEPT Cited by 1 source

Time to react to a relevant quantum event

Definition

Time to react to a relevant quantum event is the urgency metric Meta uses to organise the PQC Migration Levels ladder. It measures how quickly an organisation can respond to a sudden change in the quantum landscape — the shorter the time, the better the organisation's position.

The levels are laddered in terms of how rapidly they allow an organization to respond to a quantum threat. The shorter the time to react to a relevant quantum event the better. (Source: sources/2026-04-16-meta-post-quantum-cryptography-migration-at-meta-framework-lesson)

A "relevant quantum event" is explicitly broad:

  • Advances in quantum computing development — a CRQC breakthrough, better error correction, a new algorithm.
  • Standards publications — a new NIST / IETF / ISO PQC standard that should be adopted.
  • Establishment of new industry practices — a shift in what "state of the art" means.

Why this metric

Quantum events are fundamentally hard to forecast. The CRQC arrival date is a probability distribution, not a fixed calendar entry. New cryptanalytic attacks can invalidate primitives (cf. SIKE in 2022). New industry practices can shift what counts as acceptable. An organisation's quantum-readiness posture shouldn't optimise for a specific forecasted event — it should minimise the cost of responding to any surprise.

Time-to-react is the single-scalar proxy for that property:

  • Low time-to-react → organisation is resilient to surprise.
  • High time-to-react → organisation's posture depends on the timeline going as currently expected.

How the ladder reduces time-to-react

Level Time-to-react Why
PQ-Unaware Indefinite. Discovery is the bottleneck before any response can begin.
PQ-Aware Bounded by scoping work. Organisation knows where to start but hasn't started engineering.
PQ-Ready Short — flip a switch. Solution exists in-place; only enablement left.
PQ-Hardened Minimised given state of the art. Everything that can be deployed is deployed.
PQ-Enabled Zero — event handled. Protection is active.

Each rung on the ladder permanently reduces the time-to-react by an amount proportional to the engineering work committed. That's the case for moving up even one rung: it's a bank of pre-done work that pays off the next time a quantum event occurs.

Why PQ-Ready is valuable even without enablement

"This is not a desirable end goal given the fact it is not yet protecting the use case against quantum attacks, but it does reduce the time to react when compared to lower levels." (Source: this post)

An organisation at PQ-Ready has:

  • Identified the use case (PQ-Aware completed).
  • Designed a PQ solution.
  • Implemented the PQ solution in code.
  • Tested the PQ solution.
  • Left enablement off (behind feature flag, config, etc.).

When a relevant quantum event occurs — say a new CRQC-capability disclosure — the organisation at PQ-Ready flips the enablement switch. Minutes to hours of response time instead of months of engineering.

This justifies the PQ-Ready budget category: "companies that may not have budgeted for near-term enablement can feel motivated (and rewarded) for building the necessary building blocks to complete risk mitigation in the future."

  • concepts/harvest-now-decrypt-later — the confidentiality urgency driver. Time-to-react here matters because every day spent at a low level is a day of unencrypted-under-future-CRQC ciphertext being recorded.
  • concepts/q-day — the event-date framing. Time-to-react is the organisation-side response, Q-Day is the threat-side event-date.
  • concepts/post-quantum-authentication — the live-attack urgency driver. Time-to-react here matters because the moment the CRQC turns on, the classical signatures are forgeable.

Practical instrumentation

Organisations can operationalise time-to-react by:

  • Per-use-case level assessment — each critical use case has a known PQC Migration Level.
  • Crypto inventory completeness — no use case is PQ-Unaware.
  • Dependency tracking — external blockers are known and have estimated unblock dates.
  • Runbook existence — each "relevant quantum event" has a pre-planned response (enable the feature flag on X use cases, start migration on Y use cases, deprecate algorithm Z).

Seen in

Last updated · 319 distilled / 1,201 read