Quantum Readiness:
You Can’t Migrate What
You Cannot See
Quantum readiness runs straight through your certificates, your PKI and your HSM— and it starts with knowing what cryptography you actually have. Accutive Security helps you build the inventory, sequence the work, and implement it on the platforms you already own.
9+
Certified on 9+ cryptography platforms
2009
Securing machine identities since 2009
The deadline moved. It is now 2030, or even 2029 according to Google.
For three years, post-quantum planning was scoped against a 2035 horizon. In June 2026 the United States moved the operative deadlines forward by five years and attached them to federal procurement.
Dec 31, 2030
Federal high-value assets must use post-quantum key establishment
Dec 31, 2031
The same systems must use post-
quantum digital signatures
109:1
Ratio of machine to human identities… and growing
10+ years
How long the SHA-1 to SHA-2 migration took. PQC touches considerably more.
If you sell to the federal government, or to anyone who does, this stops being a research topic and becomes a contract requirement.
The quantum readiness problems nobody put on the migration roadmap
Every organization we assess arrives with the same six problems. None of them are about algorithms.
It is not in one place. It is in TLS terminations, service meshes, embedded firmware, code-signing pipelines, database encryption, VPN concentrators, and a decade of certificates issued by certificate authorities nobody remembers standing up. There is no single console that shows you all of it. In almost every assessment we run, the unmanaged certificate population turns out to be larger than the managed one.
Post-quantum migration falls between infrastructure, application security, the PKI team and GRC. Each of them owns a piece. None of them owns the programme, and none of them has a budget line for it. Without a named owner it stays a slide in a strategy deck for another year and the deadline does not move to accommodate that.
The board asks when quantum computers will break RSA, and the honest answer is that nobody knows exactly, but the best estimate is 2029-2031. That is the wrong question, and it is why the funding conversation stalls. The right question is whether your data’s confidentiality lifetime plus your migration time already exceeds the threat horizon. For most enterprises it does, which reframes this from a forecast into a measurement.
The phrase is doing an enormous amount of work in vendor marketing. It can mean production ML-DSA issuance, or a roadmap slide, or an experimental flag in a lab build. Some post-quantum capabilities are shipping today against non-FIPS-validated hardware while validation is still pending. As a vendor-agnostic center of excellence, we cut through the marketing spin to provide actionable, data-driven guidance.
Machine identities now outnumber human ones by roughly 109:1, and post-quantum migration means re-issuing across that entire estate. If certificate issuance currently runs through a ticket queue, the arithmetic simply does not work — not by 2030, and not by 2035. The automation problem has to be solved before the algorithm problem can be.
Post-quantum algorithms change handshake and signature sizes materially. Middleboxes drop oversized ClientHellos, IKE packets fragment, embedded clients reject longer certificate chains. Moving without measuring breaks things in production. Not moving accrues harvest-now-decrypt-later exposure every day. This is exactly why hybrid deployment and lab benchmarking exist.
X is how long your data must stay confidential. Y is how long your organization needs to migrate. Z is the time until a cryptographically relevant quantum computer exists. If X plus Y exceeds Z, you are exposed now — and for most enterprises, it already does. Data encrypted today under classical key exchange should be treated as compromised in transit.
Where to start?
Start with a Cryptographic Bill of Materials (CBOM)
Every one of those six problems has the same first move. Before you can prioritize anything, choose an algorithm, or answer a customer questionnaire honestly, you need an inventory of the cryptography you already run. That inventory is a Cryptographic Bill of Materials.
A credible CBOM reaches five places:
-
Network and protocol
TLS scanning across internal and external endpoints, capturing cipher suites, protocol versions and key exchange in actual use rather than in policy. -
Certificates
CA-integrated, network and agent-based discovery across managed and unmanaged estates, including the certificate authorities nobody documented. -
Code and dependencies
Static analysis for cryptographic API calls, hard-coded algorithms and embedded keys, with output in CycloneDX format. -
Keys and hardware
HSM partitions, key ceremonies, root and issuing hierarchies, and every location private key material lives. -
Prioritisation metadata
Data shelf life, key lifetime, system owner and vendor dependency. Without this the inventory is a list; with it, it is a plan.
Why this is becoming a requirement, not a best practice
Executive Order 14412 directs CISA, in coordination with NIST, to publish minimum-element guidance for cryptographic bills of materials. Once that guidance lands, CBOM moves into federal procurement the way SBOM did — and from there into supplier questionnaires across the wider market. Organisations that already hold a current inventory will answer those questions in an afternoon. Organisations that do not will spend a quarter on it.
What the migration actually looks like
A multi-year programme, not a project. Phases overlap in practice — most organisations we work with are somewhere between one and three.
Discover and
inventory
Build the CBOM.
Assess & prioritize
Rank findings by exposure rather
than convenience.
Make the next algorithm change a configuration change.
Deploy hybrid
Classical and post-quantum together, so security never regresses.
Transition and decommission
Pure PQC, then retire classical on a published schedule.
Where the work actually lands
Post-quantum migration is not one project with one owner. It surfaces as concrete work in three systems you already operate — and the state of those three determines how long your migration takes.
Certificate Lifecycle
Management
what changes
Post-quantum certificates are substantially larger — an ML-DSA-65 chain adds roughly 14–15 KB to a TLS handshake compared with ECDSA, with knock-on effects for CRLs, OCSP responses and constrained clients. More importantly, migration means re-issuing across an estate where machine identities outnumber human ones by 109:1.
What we do
Certificate discovery across managed and unmanaged estates, CLM platform selection and implementation, and lifecycle automation through ACME, EST, SCEP and API integration.
Public Key
Infrastructure
what changes
Roots and issuing hierarchies take the longest to move and are hardest to reverse. Trust anchors signed with classical algorithms will outlive the deadline unless replacement is planned now, and hierarchy decisions made today determine whether a post-quantum root rollout is feasible at all.
What we do
PKI assessment and hierarchy design, PQC- ready CA architecture, migration from legacy and unmanaged CAs including ADCS, and pilot hierarchies issuing ML-DSA certificates so you can test relying-party compatibility before committing production trust.
Hardware Security
Modules
what changes
Post-quantum algorithms carry higher computational and memory overhead, and PQC signing depends on firmware that supports the new algorithms. Stateful hash-based signatures used for firmware signing add a further constraint: signing state must be enforced inside the HSM, because a restored backup that rewinds that state breaks the scheme outright.
What we do
HSM selection, deployment and integration across Thales, Entrust and Utimaco estates, firmware assessment against PQC requirements, key ceremony design, and migration planning for key material currently protected by classical algorithms.
And the systems that depend on them
Key Management
Symmetric cryptography survives the transition, but only at sufficient strength. CNSA 2.0 specifies AES-256 and SHA-384 or SHA-512, and key management platforms need to enforce that baseline.
Secrets Management
Long-lived credentials in code, pipelines and configuration are harvest-now-decrypt-later exposure in their own right, and they rarely appear in a certificate inventory. A credible CBOM has to reach them.
How we help you get there
We are a Center of Excellence, not a traditional VAR. Our engineers hold certifications across the leading cryptography platforms, which means the recommendation you get is shaped by what fits your environment rather than by what we are incentivized to sell.
Assess
A Quantum Readiness Assessment establishes what cryptography you run, where it is exposed and what moves first. You receive a CBOM, a prioritized exposure register and a phased roadmap.
Plan
Platform selection where there is a gap, architecture for PQC-ready PKI and HSM estates, and post quantum requirements written into your vendor scorecards and contract renewals.
Implement
Vendor-certified engineers deliver the build, with knowledge transfer to your team throughout rather than at the end.
Operate
Managed services and staff augmentation keep the estate current as standards evolve, because crypto governance does not end when the migration does.
Assess
A Quantum Readiness Assessment establishes what cryptography you run, where it is exposed and what moves first. You receive a CBOM, a prioritized exposure register and a phased roadmap.
Plan
Platform selection where there is a gap, architecture for PQC-ready PKI and HSM estates, and post quantum requirements written into your vendor scorecards and contract renewals.
Implement
Vendor-certified engineers deliver the build, with knowledge transfer to your team throughout rather than at the end.
Operate
Managed services and staff augmentation keep the estate current as standards evolve, because crypto governance does not end when the migration does.
Certified across the platforms you are already evaluating
Post-quantum capability is arriving at different speeds across the vendor landscape, and roadmaps matter as much as shipping features. We hold implementation certifications across nine platforms, so we can tell you what a vendor supports in production today versus what is on a slide.
We work alongside your existing reseller relationships rather than replacing them.
Test it before you commit to it
PQC changes handshake sizes, signing throughput and chain behaviour in ways that only appear under real workloads. We benchmark against your traffic profile, not vendor datasheets.
Assessment
Request a Quantum Readiness Assessment
Tell us about your environment and one of our cryptography engineers will schedule a 30-minute scoping call. No obligation, and no sales engineer reading from a deck.
Resources
Article
Understanding Palo Alto Networks Next Generation Trust Security (NGTS): What Does It Mean for PKI, CLM, and Beyond?
Case Study
Accelerating a Mature PKI Practice: From On-Premises PKI to Automated Containerized PKI
Video
47-day-readiness-cyberark-webinar
Whitepapers
Encryption or Data Masking: Evaluating Strategies for GPDR Compliance