The strategic question is not “When will Q-Day happen?” It is “Will our most valuable data and critical services be protected before it does?”
Executive takeaway: Begin with clear governance and cryptographic discovery. Prioritize systems based on business criticality and data lifespan, validate NIST-standardized algorithms through controlled pilots and embed migration into routine technology refresh cycles
Q-Day: The definition every leadership team needs
Q-Day is the point at which a cryptographically relevant quantum computer can break widely used public-key cryptography at operationally meaningful scale. The systems most often discussed are RSA, Diffie-Hellman and elliptic-curve cryptography, which underpin digital certificates, TLS, code signing, identity, software updates, secure communications and many trust services.
Q-Day is not a confirmed calendar date. It is a risk threshold. No organization should build its plan around a single prediction because the migration of large estates can take years, while sensitive information collected today may still be valuable when quantum decryption becomes practical. This creates the “harvest now, decrypt later” exposure: an attacker can capture encrypted traffic or data now and retain it for future decryption.
Why waiting for certainty is the wrong strategy
- Standards are available now. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024.
- Migration is an estate-management problem, not only an algorithm swap. It touches applications, protocols, certificates, HSM/KMS platforms, software libraries, hardware, vendors and third parties.
- Long-lived sensitive data may already be exposed to future decryption risk.
- Legacy and operational technology may have replacement cycles that extend beyond external transition targets.
What the NIST timeline means for customers
NIST states that organizations should begin applying the finalized PQC standards now. NIST IR 8547, currently an initial public draft, describes an expected transition approach and is intended to inform federal agencies, industry and standards organizations. NIST’s PQC project states that quantum-vulnerable algorithms are expected to be deprecated and ultimately removed from NIST standards by 2035, with high-risk systems moving earlier.
| Milestone | Customer interpretation | Recommended response |
| Now | Final standards are available for implementation | Create governance, inventory cryptography, start pilots and update procurement requirements. |
| Before 2030 | High-risk and new-system decisions need earlier action | Avoid introducing fresh dependencies on quantum-vulnerable public-key cryptography where supported alternatives exist. Prioritize long-lived data and critical services. |
| By 2035 | NIST indicates removal of quantum-vulnerable algorithms from its standards | Plan for enterprise-scale completion, subject to sector rules, product support and approved exceptions. |
Important: NIST IR 8547 is a draft transition document. Customers should track the final publication and any algorithm-, protocol- or sector-specific guidance rather than treating a draft milestone as a universal legal deadline.
A customer strategy built around seven decisions:
Establish accountable governance
Name an executive sponsor and a PQC program lead. Define decision rights across security, enterprise architecture, application teams, infrastructure, procurement, privacy, legal, risk and business owners.
Define the risk appetite and scope
Agree which data, services and trust functions cannot tolerate quantum exposure. Include confidentiality lifetime, integrity lifetime, system criticality, external exposure, safety impact and replacement lead time.
Build a governed cryptographic inventory
Discover algorithms, keys, certificates, libraries, protocols, crypto APIs, HSM/KMS dependencies, identities, code-signing paths and third-party services. Normalize this evidence into an application-level Cryptographic Bill of Materials (CBOM).
Prioritize, do not migrate everything at once
Rank systems using business criticality, data lifetime, HNDL exposure, internet reachability, regulatory relevance, vendor readiness and migration complexity.
Design for crypto-agility
Separate cryptographic policy from application logic, eliminate hard-coded algorithms and keys, standardize interfaces, automate certificate/key lifecycles and make algorithm changes testable and reversible.
Use controlled pilots and hybrid transition patterns
Validate interoperability, performance, certificate sizes, handshake behavior, HSM/KMS readiness, logging, rollback and operational support. Use hybrid approaches only where standards, products and risk decisions support them.
Govern the supply chain
Require vendors to disclose cryptographic dependencies, PQC roadmaps, standards support, validation status, upgrade paths and end-of-life constraints. Make PQC readiness part of architecture review and procurement gates.
Where to start: a practical 90-day mobilization plan
| Window | Priority activities | Outputs |
| Days 0-30 | Appoint sponsor and program lead; define scope; identify applicable regulators; classify long-lived sensitive data; select representative pilot applications. | Program charter, governance/RACI, regulatory register, initial risk hypothesis, pilot shortlist. |
| Days 31-60 | Run targeted cryptographic discovery across certificates, code, binaries, network services, cloud, PKI and HSM/KMS; engage critical vendors. | Initial CBOM, dependency map, data-lifetime view, vendor-readiness register, discovery gaps. |
| Days 61-90 | Score quantum risk; test selected NIST algorithms in a lab; define transition patterns and exception process; build a multi-year roadmap and funding case. | Prioritized backlog, pilot report, target-state principles, roadmap, investment estimate, executive dashboard. |
Regulatory and government guidance: what to map
The correct obligation depends on jurisdiction, sector, data type, government-contract status and the systems in scope. The following sources should be mapped into the customer’s regulatory register and validated by legal and compliance teams.
| Authority / guidance | What it says | Implication for enterprise planning |
| NIST FIPS 203, 204, 205 | Standardizes ML-KEM, ML-DSA and SLH-DSA; NIST says organizations should begin migration now. | Use standardized algorithms as the technical baseline and track validated implementations and protocol support. |
| NIST IR 8547 (initial public draft) | Describes NIST’s expected transition approach and identifies quantum-vulnerable and quantum-resistant standards. | Use for planning, while tracking changes before treating draft dates as final requirements. |
| UK NCSC migration timelines | By 2028: goals, discovery and initial plan. By 2031: high-priority migration and a thorough roadmap. By 2035: complete migration of systems, services and products. | A useful enterprise program structure even outside the UK, subject to local regulation. |
| US federal direction | OMB M-23-02 directs federal agencies to inventory cryptographic systems. 2026 US direction calls for prioritized migration and governance, with federal-specific milestones. | Federal agencies and suppliers should map contract and agency-specific requirements and maintain evidence of inventory and prioritization. |
| European Commission Recommendation (EU) 2024/1101 | Calls for a coordinated implementation roadmap and encourages migration of public administration and critical infrastructure as soon as possible. | EU organizations should align PQC with NIS2, resilience, critical-infrastructure and national implementation guidance. |
| Sector regulators and contracts | Requirements may arise through resilience, data protection, records retention, operational risk, outsourcing or procurement rules even where “PQC” is not explicit. | Create a traceability matrix connecting obligations to data, systems, controls, evidence and target dates. |
HCLTech recommended transformation model
Discover: Establish enterprise visibility across applications, infrastructure, cloud, network, PKI, HSM/KMS, code, binaries and third parties.
Assess: Enrich the CBOM with business service, data classification, retention, ownership, algorithm strength, trust dependency and regulatory context.
Prioritize: Create a defensible quantum-risk score and sequence remediation waves based on exposure, urgency, feasibility and business impact.
Transform: Execute pilots, platform upgrades, protocol changes, PKI and code-signing modernization, vendor remediation and application refactoring.
Operationalize: Embed crypto-agility into architecture governance, DevSecOps, procurement, vulnerability management, audit evidence and lifecycle operations.
HCLTech point of view: The most valuable first deliverable is not a list of algorithms. It is a governed, application-aware cryptographic system of record that connects technical evidence to business risk, regulation, ownership and a funded migration roadmap.
Board-level questions customers should be able to answer
- Which data must remain confidential or trustworthy beyond the plausible arrival of a cryptographically relevant quantum computer?
- Where do RSA, ECC, Diffie-Hellman and dependent protocols exist across our most critical services?
- Which applications and suppliers have viable, tested upgrade paths and which require redesign or replacement?
- What are our 2028, 2031 and 2035 planning assumptions and which stricter sector or contractual dates override them?
- How will we measure progress: discovery coverage, CBOM completeness, vendor readiness, pilot success, remediation burn-down and residual risk?
- Who can approve temporary exceptions and how will compensating controls and expiry dates be governed?
Conclusion: Start before the deadline becomes an emergency
Q-Day may be uncertain, but the direction of travel is not. The standards are available, government roadmaps are converging on discovery, prioritization and staged migration and the operational effort is substantial. Customers should begin now by establishing ownership, discovering cryptographic dependencies, identifying long-lived and high-impact exposure, validating vendor readiness and piloting NIST-standardized PQC. The goal is broader than replacing RSA or ECC: it is to build crypto-agility so that the organization can adapt safely as algorithms, standards, products and regulatory expectations evolve.
References
- NIST Post-Quantum Cryptography
- NIST CSRC Post-Quantum Cryptography Project
- NIST IR 8547, Initial Public Draft
- NIST NCCoE Migration to Post-Quantum Cryptography
- UK NCSC: Timelines for migration to PQC
- OMB Memorandum M-23-02
- European Commission Recommendation (EU) 2024/1101
HCLTech helps enterprises assess cryptographic exposure, build CBOM-led visibility, define quantum-risk priorities, design crypto-agile target states and execute phased post-quantum transformation across applications, infrastructure, cloud, PKI, HSM/KMS and third-party ecosystems.
