How ready is your infrastructure for the post-quantum transition? Identify every vulnerable algorithm, classify every cryptographic asset by risk, and build a migration plan that converts through API instead of replacing hardware.
Cryptographically relevant quantum computers (CRQCs) — machines capable of running Shor's algorithm at scale — are expected within a 5-15 year window. Current estimates from government agencies, academic researchers, and industry leaders converge on the late 2030s as the likely inflection point, though shorter timelines cannot be ruled out. In 2023, IBM demonstrated a 1,121-qubit processor. Google, Microsoft, and multiple well-funded startups are pursuing fault-tolerant architectures that could reach the threshold needed to break RSA-2048 and ECDSA P-256.
But the threat is not in the future. It is active today. Harvest-now, decrypt-later (HNDL) attacks are the present-tense quantum threat. Intelligence agencies and sophisticated adversaries are intercepting and storing encrypted communications with the explicit plan to decrypt them when CRQCs become available. This means any data encrypted today with RSA, ECDSA, or ECDH that needs to remain confidential for more than 10-15 years is already at risk.
The math is straightforward. If your data needs to stay secret for X years, and it will take Y years to complete your migration, and quantum computers arrive in Z years, then you need to start migrating when X + Y is greater than Z. For most enterprises, that means the migration window opened years ago. For organizations holding data with 20+ year confidentiality requirements (healthcare, government, legal, financial services), the window is closing.
A structured approach to discovering, classifying, prioritizing, and migrating your cryptographic assets. Each phase produces actionable output that feeds the next.
Discover every cryptographic algorithm, key, certificate, and protocol in your infrastructure. This includes TLS configurations, HSM key inventories, code-level algorithm usage, certificate chains, API authentication mechanisms, database encryption keys, and third-party integration cryptographic dependencies. Automated scanning covers API endpoints, certificate stores, configuration files, and code repositories. The output is a complete cryptographic bill of materials (CBOM).
Categorize every cryptographic asset along four dimensions: algorithm vulnerability (quantum-vulnerable vs. quantum-safe), data sensitivity (public, internal, confidential, restricted), retention period (how long the data must remain confidential), and regulatory exposure (which compliance frameworks apply). Each asset receives a composite risk score. The output is a classified cryptographic risk register.
Rank migration targets by composite risk score, adjusted for business impact and integration complexity. Systems protecting long-lived secrets with high regulatory exposure migrate first. Internal tools with short-lived data migrate last. The priority matrix maps each system to a specific migration wave, timeline, and H33 API integration point. The output is a phased migration roadmap.
Execute migration through H33's API-first approach. Each system wraps existing cryptographic operations with post-quantum algorithms through API calls. Hybrid mode ensures backward compatibility during transition. Continuous monitoring via crypto-agile telemetry confirms that every system is operating with post-quantum protection. The output is verified post-quantum coverage.
H33's readiness scoring evaluates four dimensions for every cryptographic asset in your infrastructure. Each dimension is scored independently, and the composite score determines migration priority.
| Dimension | What It Measures | Score Range | Critical Threshold |
|---|---|---|---|
| Algorithm Vulnerability | Is the algorithm quantum-vulnerable? RSA, ECDSA, ECDH = high. AES, SHA = low. | 0-100 | > 70: immediate migration |
| Data Sensitivity | Classification of data protected by this cryptographic asset. | 0-100 | > 80: restricted/classified data |
| Retention Period | How long does the data need to remain confidential? | 0-100 | > 60: exceeds 10-year HNDL window |
| Regulatory Exposure | Which compliance frameworks apply and what are their PQ deadlines? | 0-100 | > 70: CNSA 2.0 or sector-specific mandate |
The composite score maps to five priority levels, each with a recommended migration timeline.
| Priority | Composite Score | Migration Timeline | Typical Systems |
|---|---|---|---|
| P0 — Critical | 350-400 | Immediate (within 30 days) | Long-term key agreement, classified data encryption, financial transaction signing |
| P1 — High | 280-349 | Near-term (within 90 days) | Customer authentication, medical record signing, inter-bank messaging |
| P2 — Medium | 200-279 | Planned (within 6 months) | Internal API authentication, employee SSO, database connection encryption |
| P3 — Low | 120-199 | Scheduled (within 12 months) | Development environment TLS, internal tooling, CI/CD signatures |
| P4 — Deferred | 0-119 | Opportunistic | Short-lived tokens, ephemeral keys, public-facing data |
The difference between organizations that assess before they migrate and those that react to regulatory pressure.
| Dimension | Ad-Hoc Migration | Structured Readiness (H33) |
|---|---|---|
| Inventory | Manual, incomplete, outdated within weeks | Automated CBOM with continuous monitoring |
| Priority | Squeakiest wheel first; critical systems missed | Risk-scored matrix covering every asset |
| Timeline | Reactive; starts when regulator demands it | Proactive; migration starts before deadlines |
| Coverage Gaps | Discovered during audits or incidents | Identified during assessment; closed before production |
| Compliance Evidence | Assembled retroactively for auditors | Generated automatically from migration telemetry |
| Ongoing Monitoring | None; point-in-time only | Continuous algorithm health dashboards |
| Cost | Higher (emergency migrations, compliance penalties) | Lower (planned rollout, API-based conversion) |
| Algorithm Agility | None; each change is another project | Crypto-agile; rotate algorithms via API |
A quantum readiness assessment is a structured evaluation of your organization's cryptographic infrastructure to identify which systems, algorithms, keys, and data are vulnerable to quantum computing attacks. It produces a prioritized migration plan based on data sensitivity, algorithm vulnerability, regulatory deadlines, and business impact.
All public-key algorithms based on integer factorization (RSA), discrete logarithms (DH, DSA), and elliptic curve discrete logarithms (ECDSA, ECDH, Ed25519, X25519) are vulnerable. Shor's algorithm running on a sufficiently large quantum computer can break these in polynomial time. Symmetric algorithms like AES-256 and hash functions like SHA-256 are not significantly threatened by known quantum algorithms.
An initial assessment of cryptographic touchpoints typically takes 1-2 weeks, depending on the size and complexity of your infrastructure. This includes discovery of algorithms in use, classification of data sensitivity, and prioritization of migration targets. The subsequent API-based migration can begin immediately after assessment.
Start with systems that handle long-lived secrets, high-value transactions, or data with long confidentiality requirements. These are the most vulnerable to harvest-now, decrypt-later attacks. Authentication systems, key exchange mechanisms, document signing, and data-at-rest encryption keys should be assessed first. Internal tooling with short-lived data can be assessed in later waves.
The assessment produces a cryptographic inventory (every algorithm, key, and certificate in use), a vulnerability classification (which are quantum-vulnerable), a priority matrix (which systems to migrate first), and a migration plan with specific H33 API integration points for each system. This becomes your quantum migration roadmap.
Start with an API key. Discover what is vulnerable. Build a migration plan that converts without replacing.