Defining post-quantum strategy, aligning with NIST timelines and enabling crypto-agility
October 19, 2026
Vinod Baburao Wagh
Deputy General Manager, Cybersecurity, HCLTech
October 19, 2026
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.
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 governanceName 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.
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 scopeAgree 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.
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 inventoryDiscover 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).
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 onceRank systems using business criticality, data lifetime, HNDL exposure, internet reachability, regulatory relevance, vendor readiness and migration complexity.
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-agilitySeparate cryptographic policy from application logic, eliminate hard-coded algorithms and keys, standardize interfaces, automate certificate/key lifecycles and make algorithm changes testable and reversible.
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 patternsValidate 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.
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 chainRequire 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.
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
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.
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 NCCoE Migration to Post-Quantum Cryptography
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.







