No. Waiting for external pressure usually means the programme starts too late and with too little flexibility. The article shows that many organisations are already underprepared, so deferring funding only increases the chance of rushed migrations, weak ownership, and missed dependencies when timelines tighten.
Why funding PQC early is really a migration planning problem
Post-quantum cryptography is not a switch you flip at the point of regulation. Funding early matters because PQC work usually begins with inventory, dependency mapping, algorithm selection, test environments, and change windows, long before any production cutover. That makes the issue one of planning depth and cryptographic agility, not just compliance timing.
Organisations that wait for external pressure often discover that the hard parts are already in motion elsewhere, especially where certificates, signing, APIs, embedded components, or third-party services depend on long-lived cryptographic assumptions. A delayed start compresses all of that into a shorter decision window and increases the chance of brittle replacements or one-off exceptions.
For teams already looking at certificate and key lifecycle, Machine Identity, PKI and Certificate Lifecycle Guide is the right mental model because pqc migration is not only about algorithms, it is also about how identity-bearing material is issued, renewed, rotated, and eventually retired.
What delayed PQC funding breaks in practice
The first failure mode is inventory blindness. If you do not know where cryptography is used, you cannot tell which systems need dual-stack support, replacement certificates, updated libraries, or vendor coordination. That is why post-quantum programmes should start with a cryptographic inventory and a view of where trust decisions are made across the estate.
The second failure mode is dependency lock-in. Many organisations will find that applications, appliances, and suppliers cannot all move at the same pace. If funding starts late, the programme ends up driven by the slowest dependency, which forces rushed remediation and can leave gaps in testing, rollback planning, and interoperability. Post-Quantum Readiness for Identity and PKI is useful here because it frames migration as an inventory and crypto-agility effort, not a single procurement decision.
The third failure mode is governance delay. Late funding usually means ownership is unclear until the pressure is immediate, and that is when organisations discover they have no agreed path for prioritising certificates, signatures, authentication flows, and third-party dependencies. Once that happens, technical teams may be asked to solve a portfolio problem with only local fixes available.
Current guidance from the broader cryptographic community points in the same direction: the organisations that fare best are the ones that treat PQC as a staged programme with discovery, prioritisation, and transition planning rather than a deadline-driven emergency.
What good PQC readiness looks like before the deadline arrives
Good readiness does not mean migrating everything immediately. It means having enough visibility and budget to choose where to start, what to defer, and which dependencies need compensating controls while standards and product support continue to mature.
A practical programme usually has three traits. First, it identifies which systems have long confidentiality horizons, because those are the most exposed to harvest-now, decrypt-later concerns. Second, it distinguishes between environments that can absorb change quickly and those that need longer vendor or hardware lead times. Third, it creates a decision path for certificate, signing, and key-management updates so that the work can be sequenced rather than improvised.
That is also why the most mature teams do not wait for one regulator, one customer, or one audit to justify action. They fund enough early work to answer the questions that would otherwise become bottlenecks later: what must be replaced, what can be dual-run, what needs testing first, and where the business can tolerate transitional complexity.
NIST SP 800-57 Key Management is a useful reference point when the question becomes how to handle lifecycle and cryptoperiod decisions, while NIST SP 800-53 Rev 5 Security and Privacy Controls supports the broader control view around access, configuration, and system integrity during migration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | NIST-800-57 — Key Management Recommendations | PQC migration depends on key lifecycle, cryptoperiods and algorithm transition planning. |
| Recommendation — Use key-lifecycle planning to phase quantum-safe transitions before deadlines force rushed changes. | ||
| NIST SP 800-53 Rev 5 | SC — System and Communications Protection | PQC work affects protected communications, crypto agility and secure transition of systems. |
| Recommendation — Update system protection controls to support crypto-agile migration and dual-run operations. | ||
| NIST CSF 2.0 | GV.SC — Cyber Supply Chain Risk Management | PQC readiness depends on vendor, product and dependency coordination across the supply chain. |
| Recommendation — Build supplier dependency tracking into PQC plans so external blockers are identified early. | ||
| CIS Controls v8 | CIS-3 — Data Protection | PQC protects long-lived sensitive data against future decryption risk. |
| Recommendation — Inventory data with long confidentiality life and prioritise its quantum-safe protection first. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | PQC is a cryptography governance and transition issue within Annex A technological controls. |
| Recommendation — Plan cryptographic transitions under a formal use-of-cryptography control and review them regularly. | ||
Practitioner Guidance
What to prioritise: Fund discovery and dependency mapping before you fund wholesale replacement. If you cannot name the systems, vendors, and certificate or signing paths in scope, you are not ready to estimate the real migration effort.
Decision rule: If a system protects data with a long confidentiality lifespan or depends on externally supplied cryptography, treat it as a near-term planning item even if the formal deadline is distant. Waiting for regulatory pressure in that case is usually a signal that the cost will be higher, not lower.
What to verify: Confirm that the programme has explicit ownership across security, infrastructure, application, and procurement teams, because PQC failures are often coordination failures first and cryptography failures second.
Practitioner takeaway: Early PQC funding buys optionality, and optionality is what prevents a hard deadline from turning into a rushed and fragile migration.