Skip to content

PATTERN Cited by 1 source

PQC migration ladder

Shape

Structure a multi-year PQC migration programme as a laddered set of reachable milestones rather than a single "migrated yes / no" binary. Each rung is a committable engineering scope with a clear deliverable, and each rung permanently reduces the organisation's time to react to a relevant quantum event.

Meta's five-rung ladder (PQC Migration Levels):

PQ-Unaware  →  PQ-Aware  →  PQ-Ready  →  PQ-Hardened  →  PQ-Enabled
no awareness   assessed    implemented  all available    fully
                          not enabled   protections      protected
                                        deployed

(Source: sources/2026-04-16-meta-post-quantum-cryptography-migration-at-meta-framework-lesson)

The pattern's core commitment

Organisations planning a PQC migration encounter the same project-management problem: the full end state is multi-year, depends on external actors, and requires cross-org engineering. Committing to "fully PQ-Enabled by date X" is often unrealistic; committing to "no change until we can do it all" leaves the organisation at PQ-Unaware indefinitely. The ladder pattern resolves this:

  • Each rung has a scoped engineering commitment that can be budgeted independently.
  • Each rung reduces reaction time by a known amount, providing a concrete security benefit at that commitment level.
  • The ladder has no intrinsic end-state coupling — different use cases can be at different rungs simultaneously.

Why laddered structure wins

1. Budget alignment

"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." (Source: this post)

The ladder lets budget conversations happen at each rung:

  • "We can commit $X to reach PQ-Ready this budget cycle" delivers tangible risk reduction even without full enablement.
  • "PQ-Enabled requires Y more spend over Z years" is the follow-on conversation, not a one-shot yes-or-no.

2. Reachable intermediate milestones

PQ-Aware (initial assessment) is a scoped research project, not an engineering project. Moving from PQ-Unaware to PQ-Aware is typically weeks of work for a small security/cryptography team.

PQ-Ready (implemented but not enabled) is a coding project with testing — but no service-disrupting deployment. Suitable for teams who can't commit to the user-facing-risk of enablement.

PQ-Hardened (all available protections enabled) is a deployment project — requires coordination with SRE, user-facing rollout, monitoring.

PQ-Enabled (full protection) requires the external dependencies to land.

3. External-dependency handling

Some use cases cannot reach PQ-Enabled until external actors deliver (NIST standards, HSM support, library implementations — see patterns/third-party-dependency-quantum-assessment). The ladder handles this gracefully: such use cases can reach PQ-Hardened or PQ-Ready and sit there until the dependency lands. No "stuck" state; the migration programme still makes progress.

4. Portfolio view

Large organisations have thousands of use cases at different risk tiers. The ladder allows a portfolio roadmap:

Priority × Level matrix PQ-Unaware PQ-Aware PQ-Ready PQ-Hardened PQ-Enabled
High (HNDL-vulnerable) STOP Drive up Drive up Drive up ✓
Medium (online signatures) Drive up Drive up Drive up Drive up ✓
Low (Grover-only) Acceptable near-term Track Track Track ✓

Combined with PQC prioritisation framework, this is the full programme roadmap artefact.

Implementation playbook

  1. Establish crypto inventory — needed to identify use cases and their primitive usage. PQ-Aware is defined as "completed an initial assessment" which is structurally an inventory operation.
  2. Classify use cases by the prioritisation framework (High / Medium / Low + dependency / patching status).
  3. Assign each use case a target rung for the current budget cycle.
  4. Commit engineering resources to rung-crossing work.
  5. Track external dependencies for use cases blocked below the full PQ-Enabled target.
  6. Re-assess regularly — standards publications, cryptanalytic advances, and CRQC-capability news all shift the landscape. Each "relevant quantum event" triggers a re-plan.
  7. Maintain dashboards of use-case rung distribution. A programme that has zero use cases at PQ-Unaware and most at PQ-Hardened is meaningfully defensible even before full PQ-Enabled rollout.

What it's not

  • Not a substitute for PQ-Enabled. The ladder is a path, not an end state. PQ-Hardened and below are acknowledgements that organisations can't enable everywhere simultaneously, not statements that they shouldn't try.
  • Not an excuse to stop at PQ-Ready. "This is not a desirable end goal given the fact it is not yet protecting the use case against quantum attacks." (Source: this post)
  • Not purely defensive. Moving up rungs has a positive operational effect (reaction time, attacker cost) beyond the compliance framing.

Seen in

Last updated · 319 distilled / 1,201 read