Sectigo
Sectigo · Become Quantum Ready

Your quantum risk starts before Q-Day arrives.

Attackers can capture encrypted information today and decrypt it later. See where vulnerable cryptography hides, prioritize what matters most, and become Quantum Ready before Q-Day — not after.

Live traffic

Enterprise sessions · TLS 1.3 · X25519 · ECDSA

Adversary archive

Encrypted — safe today

A silent copy of handshakes and ciphertext is written to storage. Nothing looks wrong. Nothing alerts.

Quantum in 60 seconds

What quantum computing actually threatens — and what it does not.

No cryptographically relevant quantum computer exists today, and nobody can name an exact Q-Day. What can be described precisely is which mathematical assumptions change.

1 · Classical security

RSA and ECC rest on mathematical problems that are extremely expensive for classical computers to solve.

2 · Quantum capability

A sufficiently capable fault-tolerant quantum computer running Shor's algorithm changes the economics of exactly those problems.

3 · Result

The security assumption underneath RSA and ECC no longer provides the protection it was chosen for.

TechnologyQuantum impact
RSAVulnerable to Shor's algorithm
Diffie-HellmanVulnerable to Shor's algorithm
ECC / ECDH / ECDSAVulnerable to Shor's algorithm
AESAffected differently; larger keys retain strong protection
Modern hashesAffected differently; not subject to the same structural break

Guided assessment

Scope your environment, score your Q-Day risk, brief your leadership

Four short steps map where quantum-vulnerable cryptography lives in your estate and how exposed it is before Q-Day. Add your own logo and colors, then export a board-ready PDF.

Organization profile

Sets the regulatory backdrop and the size of the certificate estate we plan around.

Primary industry

Certificate estate size

Public plus private TLS, code signing, device and user certificates.

Step 1 of 5

Your exposure

The real deadline is organizational, not astronomical.

The question is not when a quantum computer arrives. It is whether your data shelf life plus your migration time overlaps a plausible threat window.

How long must your most sensitive data remain confidential?

5–10 years
<1 year20+ years

How long would a cryptographic migration take across your organization?

2–3 years
<1 yearUnknown

How difficult is your environment to change?

Your planning horizon

Protected until ~2036

Sensitive data selected today may need protection until roughly 2036. With your migration profile, cryptographic decisions made now would still be in force around 2030 — inside the window where cryptographic assumptions may have to change.

Qualitative urgency

Elevated

Qualitative by design. No mathematical certainty is implied, and no exact Q-Day is predicted.

Harvest now, decrypt later

The attacker does not need a quantum computer today.

They may only need your encrypted traffic today. Record the handshake, keep the ciphertext, and wait for the mathematics to change.

Client

Browser · service · device

X25519 (ECDHE)

Server

TLS 1.3 termination

Adversary archive

Captured: public handshake + encrypted traffic · stored indefinitely

9f2a c41d 77be 0a53 e9d2 … 4b17 ff90 2c6e 8811 a0d4 …

Unreadable today. Valuable later.

Someone copies your encrypted traffic now and stores it. Later, when the mathematics gets cheaper, they open it. Anything that must stay secret for a long time is already exposed.

The attacker does not need a quantum computer today. They may only need your encrypted traffic today.

Quantum Ready

You cannot migrate cryptography you cannot see.

Cryptography is not a product you own. It is infrastructure spread across certificates, protocols, code, cloud services, key stores, pipelines and devices.

Enterprise environment

Cryptography is invisible until something asks for it.

Cryptography is infrastructure.

Most organizations do not maintain a complete, continuously updated inventory of where cryptography exists or what it protects.

Run the scan to reveal cryptographic dependencies across your estate.

Certificate discovery

Answers: which certificates exist, who issued them, when do they expire. Necessary, and the foundation of certificate lifecycle management — but bounded to certificates.

Cryptographic discovery

Answers: which algorithms are actually negotiated, which libraries and key stores are involved, which business data depends on them, and what it would take to change them.

How cryptographic discovery works

Six observation planes converge into one cryptographic inventory.

Business context — CMDB, ownership, data classification — is layered on afterwards, so findings arrive with consequences attached rather than as raw key material.

1. Passive network observation

What cryptography is actually negotiated in production traffic.

2. Active network discovery

Probing endpoints for supported suites, versions and parameters.

3. Certificate / PKI inventory

Issued, deployed and orphaned certificates across CAs.

4. Endpoint & filesystem signals

Keystores, private keys, trust stores, embedded material.

5. Cloud / KMS / HSM APIs

Managed keys, wrapping keys, supported algorithm sets.

6. Application & dependency analysis

Crypto calls in code, libraries, pipelines, containers.

Example finding

payments-api-prod

Asset
payments-api-prod
Application
Payments platform
Owner
Payments Platform team
Environment
Production
Protocol
TLS 1.3
Key establishment
X25519
Authentication
ECDSA P-256
Network exposure
Internet exposed
Data classification
Payment data
Required secrecy period
7 years retention
PQ hybrid negotiation
Not observed
HSM ML-DSA support
Unavailable
Confidence
High (passive + active corroboration)

Discovery is not a list of keys. It is a map of cryptographic dependencies and business consequences.

Prioritization

Not every RSA or ECC object is equally urgent.

Prioritization is what turns an inventory into a migration program. Drag the dimensions to see how exposure changes.

Algorithm exposure · 30%90
Data longevity · 20%80
External exposure · 15%85
Business criticality · 15%75
Migration friction · 10%60
Governance gap · 10%70

Illustrative Quantum Exposure Score

80

Illustrative and transparent — this is an educational model for this experience, not a production scoring model.

ACT NOW

Data shelf life plus estimated migration lead time overlaps the plausible threat window. This asset is urgent regardless of where the composite score lands.

Adversary mode

Quantum readiness is an adversarial contest, not a compliance project.

The attacker's capability changes over time — and so does the attack. Step through the phases.

Attacker capability

Classical

  • Capture encrypted traffic
  • Store indefinitely
  • Target long-lived confidentiality

Defender response

  • Prioritize long-lived confidentiality
  • Deploy hybrid key establishment first
The goal is not to choose the last cryptographic algorithm your organization will ever need. The goal is to become capable of changing cryptography continuously.

PQC algorithm explorer

PQC is a portfolio, not an algorithm.

Start from the function you need to protect. Key establishment and authentication are different jobs, solved by different primitives.

What are you trying to protect?

ML-KEM

Standardized
Role
Key establishment (KEM)
Standard
NIST FIPS 203
Origin
CRYSTALS-Kyber
Mathematics
Module lattice / Module-LWE
ML-KEM-512ML-KEM-768ML-KEM-1024

ML-KEM-768 is a strong general-purpose starting point. ML-KEM establishes shared secrets — it is not a certificate signature algorithm.

HQC

Standardization in progress
Role
Key establishment (KEM)
Standard
Selected as a backup KEM; final standard expected later than ML-KEM
Mathematics
Code based

HQC exists partly because crypto agility requires mathematical diversity if a structural problem is ever found in lattice-based KEMs.

How a KEM actually works

  1. 1. Bob publishes an encapsulation key.
  2. 2. Alice encapsulates against it.
  3. 3. Alice gets ciphertext + shared secret.
  4. 4. Bob decapsulates the ciphertext.
  5. 5. Both now share a symmetric secret.

True-scale comparison

Deployment impact is measured in bytes, not opinions.

Sizes below are in bytes at real relative scale. A KEM ciphertext and a signature are different artifacts and are never compared against each other here.

ML-KEM-512

Constrained hybrid TLS

Public key
800 B
Ciphertext
768 B
Private key
1632 B

CPU: Very fast

Maturity: FIPS 203

Implementation: Moderate

ML-KEM-768

General-purpose hybrid TLS

Public key
1184 B
Ciphertext
1088 B
Private key
2400 B

CPU: Very fast

Maturity: FIPS 203

Implementation: Moderate

ML-KEM-1024

High-assurance key establishment

Public key
1568 B
Ciphertext
1568 B
Private key
3168 B

CPU: Fast

Maturity: FIPS 203

Implementation: Moderate

HQC-128 (backup KEM)

Mathematical diversity

Public key
2249 B
Ciphertext
4433 B
Private key
2305 B

CPU: Slower

Maturity: Standard in progress

Implementation: Higher

Hybrid TLS simulator

Transition without a flag day.

A correctly constructed hybrid exchange is designed so that the resulting session remains protected if at least one component remains secure.

X25519

Classical elliptic-curve key agreement

+

ML-KEM-768

Post-quantum key encapsulation (FIPS 203)

Secure combiner

Derives the session secret

TLS shared secret

Protects the session

Client key share size

Classical
32 B
Hybrid
1216 B

The handshake grows by roughly an order of magnitude. That is where migration programs actually break.

Operational consequences to test

FragmentationMiddleboxesProxiesConstrained devicesHandshake latencyMemoryTLS inspection
PQC migration is an interoperability program, not merely an algorithm-selection exercise.

Certificate evolution

What actually changes inside the certificate.

X.509 anatomy — hover a field

Field descriptions appear here.

Deployed everywhere

Today's default. Both authentication and the CA's own signature rely on quantum-vulnerable mathematics.

A PQC certificate does not automatically mean the TLS key exchange is quantum resistant.

Authentication and key establishment are separate. ML-DSA in the certificate proves who you are talking to. ML-KEM in the handshake protects what you say. Harvest-now, decrypt-later is defeated by the second one, not the first.

Sectigo PQC operations

PQC becomes real when it becomes part of normal certificate operations.

A pilot proves an algorithm works. Operations prove your organization can keep changing it.

01

Test

Sectigo PQC Labs — try ML-DSA and hybrid chains before committing.

02

Issue

Private PQC in Sectigo Certificate Manager, including ML-DSA workflows.

03

Approve

Policy, roles and approval workflow around who can request what.

04

Deploy

Automated installation to endpoints, load balancers and workloads.

05

Discover

Certificate inventory across CAs, networks and cloud.

06

Monitor

Visibility into what is deployed, expiring and non-compliant.

07

Renew

Automation sized for shorter lifecycles, not calendar reminders.

08

Revoke

Fast response when a key or algorithm becomes untrustworthy.

09

Replace

CA-agnostic lifecycle management as algorithms and policies change.

Capability descriptions are illustrative of the Sectigo platform direction and subject to product confirmation.

Sectigo

Discover. Prioritize. Migrate. Automate. Repeat.

Discovery and posture intelligence, joined to certificate lifecycle management and PQC operations.

Cryptographic discovery

Provides the visibility and posture intelligence required to understand cryptographic exposure: where cryptography lives, what it protects, and what should be addressed first.

Sectigo

Provides the PKI, certificate experimentation, lifecycle automation and operational controls required to migrate certificate-based trust — and to keep changing it.

  1. 01

    Discover cryptography

  2. 02

    Inventory dependencies

  3. 03

    Assess exposure

  4. 04

    Add business context

  5. 05

    Prioritize migration

  6. 06

    Test PQC

  7. 07

    Issue new certificates

  8. 08

    Deploy and automate lifecycle

  9. 09

    Observe production cryptography

  10. 10

    Rediscover continuously

Then it repeats. The loop is the product — complementary discovery and lifecycle capabilities, not a claim of native remediation orchestration.

The crypto-agility arms race

No algorithm ends the contest.

Defender

RSA
Stronger classical crypto
PQC
Hybrid PQC
Pure PQC
Next algorithm transition
→ continues

Adversary

Classical cryptanalysis
Harvesting
Quantum resource improvements
Downgrade attacks
Side channels
Implementation attacks
New cryptanalysis
Key theft
Supply-chain attacks
→ continues

Crypto agility is the security capability that survives algorithm change.

Readiness assessment

How close are you to Quantum Ready?

Eight questions. The result is a maturity stage and a recommended next step toward Q-Day readiness — never a claim that anyone is permanently quantum safe.

1. Do you have a continuously maintained inventory of cryptography?

2. Can you identify RSA/ECC/DH use across certificates, applications, protocols and infrastructure?

3. Do you know which encrypted data must remain confidential for more than five years?

4. Do you know which systems support standardized PQC today?

5. Have you tested ML-KEM or ML-DSA in your environment?

6. Can your HSM/KMS infrastructure support your target PQC algorithms?

7. Can you automatically replace certificates or algorithms at scale?

8. Can you verify which cryptographic algorithms are actually negotiated in production?

Answer all eight questions.

Your snapshot appears here: current stage, highest priority, visibility gap, migration blocker, and a recommended 90-day action list you can take into a planning session.

Next step

Get visibility now. Become Quantum Ready before Q-Day.

Pick the level of engagement that matches where you are on the path to Q-Day readiness.

Contact me about my readiness snapshot

Quantum readiness is the permanent ability to discover cryptographic risk, prioritize it, migrate it, and keep changing cryptography faster than adversaries can exploit it.