When to begin PQC migration and when to defer deployment
Discovery and planning can begin now; they do not depend on a quantum arrival date. Replacing production cryptography is a separate decision, made per system from evidence: how long data must stay confidential or verifiable, current capture exposure, lead time, supplier and dependency readiness, and applicable obligations. Deferring deployment is acceptable under QCI-QS1 only as a recorded decision with an owner, interim treatment and review triggers.
New to this? Read What is Harvest Now, Decrypt Later? first. After this, continue with What determines PQC migration duration and effort.
In one sentence: Start discovery now; decide production replacement system by system, and treat any wait as a governed decision.
Why it matters
Uncertainty about when a cryptographically relevant quantum computer will exist does not justify waiting on everything. Long-lived data can be captured today, and trust anchors and hardware can take years to replace.
It also does not justify replacing everything at once. Deploying a profile before it is approved, interoperable or supported can create its own risk.
Illustrative example: an insurer decides to begin discovery across all domains this quarter, to start procurement for its signing hardware because of a long supplier lead time, and to defer a partner file-exchange change for two quarters because the partner has not confirmed support. The deferral has an owner, an interim control and a review trigger tied to the partner's response.
Starting discovery versus replacing production cryptography
| Decision | Depends on | Typical evidence |
|---|---|---|
| Start discovery and planning | Scope and ownership only | Approved assessment boundary, appointed owners, first inventory records |
| Replace production cryptography | Approved profile, supplier support, test plan, capacity, obligations | Roadmap entry, adequate supplier response, Clause 4.7 acceptance |
Factors that bring a production change forward
- Confidentiality horizons that extend beyond the expected life of current protection, with present capture exposure (QCI-4.2-02).
- Long verification horizons for signatures, certificates or records (QCI-4.2-02).
- Long lead times for hardware, trust anchors or supplier upgrades, which must start when the risk and dependency analysis requires (QCI-4.2-02).
- End-of-support dates and applicable deadlines in the obligations register (QCI-2.2-01).
Governing a decision to defer
QCI-M1 states that a decision to wait is a decision: it is governed when it has an owner, a rationale, an interim treatment, a review date and review triggers, within the obligations register and risk appetite. Otherwise it is drift.
Where a deferral is accepted as risk, QCI-QS1 requires the affected assets, rationale, residual risk, compensating controls, approving authority, expiry and review triggers to be recorded, with review at least quarterly (QCI-4.3-02). A general migration target does not override an earlier applicable deadline (QCI-2.2-01).
Review triggers
- A supplier confirms or withdraws support.
- A relevant standard, errata or advisory is published (QCI-2.2-02).
- An obligation or exception deadline approaches (QCI-4.3-01).
- A material change to the system, data or trust dependency.
What organizations should do
- Approve the assessment boundary and begin discovery without waiting for a deployment decision.
- Record horizons and exposure for each critical record before deciding production timing.
- Start long-lead hardware and trust-anchor work when the dependency analysis requires it.
- Write a decision record for every deferral, with interim treatment and triggers.
- Check each decision against the applicability register for earlier deadlines.
Evidence an auditor should expect
Rows marked "QCI requirement" come from the standard. Rows marked "Editorial suggestion" are QCI's practical advice and are not requirements.
| Artifact | Scope | Owner | Currency | Verification | Basis |
|---|---|---|---|---|---|
| Roadmap decision record | Each production change or deferral | Quantum Risk Owner | At decision and on trigger | Check the QCI-4.2-02 factors are addressed | QCI requirement (QCI-4.2-02) |
| Accepted risk or exception record | Each deferral accepted as risk | Competent approving authority | Reviewed at least quarterly | Check expiry, triggers and residual risk | QCI requirement (QCI-4.3-02) |
| Applicability register | External obligations and adopted profiles | Quantum Risk Owner with legal and engineering | Reviewed at least quarterly | Compare decision dates with recorded deadlines | QCI requirement (QCI-2.2-01) |
How NIST or other primary authorities address it
NIST's post-quantum algorithm standards, including FIPS 203, are final. NIST IR 8547, which proposes a transition trajectory, remains an initial public draft dated November 12, 2024. Neither sets a start date for a particular organization; that comes from the obligations that apply to it.
Deadlines from regulators, contracts and national guidance are listed on the PQC migration timeline page with their scope. Check each against the original source before relying on it.
How QCI-QS1 addresses it
QCI-QS1 does not set a universal start date. It requires each roadmap decision to weigh horizons, exposure, dependencies, lead time, end-of-support and applicable deadlines, and governs deferrals through Clause 4.3.
| Requirement | Clause | Relationship | Pillar | Gate |
|---|---|---|---|---|
| QCI-4.2-02 | 4.2 | explicit requirement | P4 | — |
| QCI-4.3-02 | 4.3 | explicit requirement | P1 | — |
| QCI-4.3-01 | 4.3 | supporting evidence | P1 | — |
| QCI-2.2-01 | 2.2 | explicit requirement | P1 | — |
| QCI-2.2-02 | 2.2 | supporting evidence | P1 | — |
Common mistakes
- Treating uncertainty about quantum timing as a reason to postpone discovery.
- Deferring without an owner, interim treatment or review trigger.
- Using a general migration target in place of an earlier contractual or regulatory date (QCI-2.2-01).
- Deploying a draft or unapproved mechanism to show early progress (QCI-4.5-02).
Questions for the board
- Which deferrals are current, who owns them, and what would trigger a review?
Questions
Should we wait until a quantum computer can break current encryption?
No. Data captured now can be read later, and some replacements take years. QCI-QS1 bases timing on horizons, exposure, lead time and obligations rather than an arrival date (QCI-4.2-02).
Is deferring deployment ever acceptable?
Yes, when it is a recorded decision with an owner, rationale, interim treatment, review date and triggers, and any accepted risk meets Clause 4.3 (QCI-4.3-02).
Is NIST IR 8547 a binding deadline?
No. It is an initial public draft. QCI-QS1 treats its trajectory as informative; binding dates come from the obligations that apply to you.
Sources
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 4.2. Supports: Decision factors and long-lead work.
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 4.3. Supports: Escalation and accepted risk.
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 2.2. Supports: Applicability register.
- QCI-M1 Migration Governance Method, Quantum Core Institute, V2.0, September 23, 2026 (methodology; not required for conformance), Section 2. Supports: A decision to wait is a decision.
- FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, NIST, Final, August 13, 2024. Supports: ML-KEM specification and final status.
- IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards, NIST, Initial public draft, November 12, 2024. Supports: Draft transition guidance; not final.
Related learning
Before this
Back to Migration and crypto agility · All Knowledge Center topics
Page history
- Published
- Not yet recorded
- Standard edition
- QCI-QS1 v2.3 (September 23, 2026)
Cite this page
Quantum Core Institute. (n.d.). When to begin PQC migration and when to defer deployment. https://quantumcoreinstitute.com/learn/migration/when-to-start-pqc-migration
Link: https://quantumcoreinstitute.com/learn/migration/when-to-start-pqc-migration