Why now · the clock

The clock started before the machine.

Nobody can say when a quantum computer will break today's public-key cryptography. Two things are certain already. Data captured now can be opened later. Signatures made now must still hold when the algorithms behind them no longer do. Regulators have started to act on both.

What to do firstThe regulatory landscape
Confidentiality clockHarvest now, decrypt later
Integrity clockSignatures that outlive algorithms
RegulatorsNaming inventories and transitions
R-Series postureHybrid by design · in development
01 Two clocks

The deadline is set by your data, not by the machine.

A cryptographically relevant quantum computer (CRQC) would recover the private keys behind RSA and elliptic-curve cryptography. That is the cryptography under almost every VPN, certificate, firmware image and signed record in use today. The year it arrives is unknown. This page does not guess it.

The first clock is about confidentiality. Anything encrypted with classical key exchange and recorded today can be stored and opened once such a machine exists. The exposure began the day the traffic was captured.

The second clock is about integrity. A signature is a promise that has to hold for as long as anyone relies on it. A firmware-signing key in a substation, a contract, an audit trail or an AI agent's receipt can all be relied on for decades. If the algorithm falls first, the promise falls with it, and everything it proved becomes deniable.

Neither clock waits for the machine. Both depend on how long your data and your evidence must last, and on how long migration takes.

02 The clock, step by step

From captured traffic to a first move.

The clock01 / 05
01 · HARVEST

Captured today, kept for later.

An adversary does not need to read traffic yet. Storage is cheap. OT telemetry, credentials crossing a remote link, VPN sessions and encrypted archives are all worth keeping. The store only grows.

02 · LIFETIME

Shelf-life plus migration time.

Add how long the data must stay secret to how long it takes to migrate the systems that protect it. If that sum reaches past the day a CRQC exists, the data is already exposed. The threshold is uncertain, so the shaded zone has no date on it.

03 · SIGNATURES

Evidence has to outlive its algorithm.

A classical-only signature can be forged after the threshold, so everything it proved can be denied. A hybrid signature, with a hash-based archive profile and scheduled renewal, keeps the evidence verifiable across an algorithm change.

04 · REGULATORS

The markers are already on the ring.

NIST has standardised the algorithms. National programmes now name transition schedules, hybrid guidance, critical sectors and cryptographic bills of materials. AI regulation, such as Article 12 of the EU AI Act, adds a duty to keep traceable records of what automated systems did.

05 · FIRST MOVES

Inventory, CBOM, prioritise, hybrid, evidence.

The first steps are not exotic. Find the cryptography, write it down in a form others can check, and rank it by how long it must last. Move transport and signatures to hybrid, and keep evidence of every step.

03 A rule of thumb

If the sum crosses the line, the work is late.

shelf-life of the data + time to migrate > time until a CRQCWhen the left side is larger, data protected today with classical cryptography alone is already at risk. Nobody knows the right side. You do know the left side, and you can shorten the second term.

For signatures, read "shelf-life" as how long the signature must be trusted. Firmware keys in OT estates, land and court records, financial audit trails and machine-evidence receipts sit at the long end.

OT estates migrate most slowly. PLCs, RTUs, gateways and remote telemetry run on classical cryptography with replacement cycles measured in decades. The exposure there is not "quantum tomorrow". It is harvest-now-decrypt-later on telemetry and credentials, and firmware-signing keys that will outlive the algorithm.

04 What organisations say

The threat is accepted. Preparation is not.

In the Entrust / Ponemon PKI & Post-Quantum Trends survey of more than four thousand respondents in six regions, three in four expect a cryptographically relevant quantum computer within ten years, while fewer than two in five are actively preparing. Fewer than half claim full visibility of their cryptography, and inventory and visibility is the top concern, ahead of budget. India was not surveyed.

05 The regulatory landscape

Who is naming what.

This table says only what our roadmap sources record, along with how firmly each item has been checked. Where an instrument is voluntary or a recommendation, the table says so.

InstrumentWhat it namesHow firm
NIST FIPS 203 · 204 · 205The finalised post-quantum standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). R-Series is built to use ML-DSA-65 for receipts and ML-KEM-768 for key encapsulation, and keeps SLH-DSA for its archive profile.Published standards
CNSA 2.0 (US NSA)A transition schedule for national-security systems, with the algorithm set ML-KEM-1024, ML-DSA-87 and, for firmware and software signing, ML-DSA-87 or single-tree LMS/XMSS (HSS and XMSS^MT are not allowed for NSS).Algorithms re-checked
ANSSI (France)Strongly recommends hybrid constructions (a post-quantum algorithm combined with a well-studied classical one) during the transition, and requires them for products seeking its security visa; hash-based signatures such as LMS, XMSS and SLH-DSA are exempt. A joint statement by 18 European cybersecurity agencies recommends hybrid deployment for most uses.Recommendation
EU coordinated roadmapA coordinated post-quantum transition across member states, with high-risk use cases first.Recommended, not binding
India · National Quantum Mission and DST task forceThe DST quantum task force report (archived copy of the official file) names critical sectors and urgent adopters, including space and defence research, and recommends a cryptographic bill of materials (CBOM) for critical sectors.Recommended, not binding
CERT-In BOM guidelines v2.0Bill-of-materials guidelines from India's national CERT, including a cryptographic BOM; named by our OT/IoT roadmap as a driver for critical-sector operators.Voluntary
US Executive Order 14412Signed 22 June 2026. It directs the FAR Council to propose a rule requiring covered contractors to use NIST's post-quantum FIPS by 31 December 2030 (no rule has been proposed yet), and CISA, with NIST, to publish CBOM minimum elements. Its CBOM text frames inventory for automated assessment and names no signing or registration.Re-checked
EU AI ActTraceability: high-risk AI systems must allow automatic logging of events over their lifetime, so their functioning can be traced (Article 12). Under the 2026 amendment these duties apply from 2 Dec 2027 (Annex III systems) and 2 Aug 2028 (Annex I systems). That is a record-keeping duty, and the receipt is a stronger form of record.Public text · mapping not yet reviewed
Sector controlsRBI and SEBI IT controls, the DPDP Act, the GDPR, ISO/IEC 27001, ISO/IEC 42001 and SOC 2 ask for evidence of control. PCI DSS v4 (requirement 12.3.3) and DORA (with its ICT risk standards) add inventory duties.Mapping in progress
External regulatory dates

Reference clocks from the primary sources

Dates set by others, checked against the documents linked here on 20 October 2026. They are reference points, not DCS commitments.

CNSA 2.0 · new national-security acquisitions1 Jan 2027
US contractor compliance date in the FAR rule EO 14412 directs (rule not yet proposed)31 Dec 2030 re-checked
CISA / NIST CBOM minimum elements (EO 14412)within 270 days of the order re-checked
EU Cyber Resilience Act · full application11 Dec 2027
EU high-risk use cases migrated (roadmap)end 2030 · recommended
India task force · critical-sector foundations, vendor CBOM (report, archived copy)2027 / FY2027-28 · recommended
06 Attestation versus proof

Today every regime runs on attestation and liability, not proof.

Most instruments ask an organisation to say what it has done: an inventory, a plan, a signed representation. Examiners accept documents. That makes sense while the work is only starting. It stops making sense when a migration has to be shown to a third party who was not in the room.

Our own study is frank about the open question. If the instruments name signing, registration or provenance, independent receipts become a category. If they list fields only, receipts are a feature. The CBOM text in the US order names no signing today. That is why we build migration evidence an assessor can check, not just accept.

07 What to do first

Seven steps, in an order that does not break anything.

Find the cryptography

Automated cryptographic discovery and inventory across code, certificates, TLS and SSH endpoints, keys and devices. On live control networks, use passive discovery only, with no active scans. Where scanning is impossible, ingest vendor attestations.

Write it down as a CBOM others can check

A cryptographic bill of materials with occurrences and dependencies, not a spreadsheet. Ingest the CBOM exports from tools you already own rather than replacing them.

Rank by lifetime, not by count

Put the longest-lived secrets and the longest-trusted signatures first: archives, firmware keys, identity roots and evidence trails.

Move transport to hybrid where the stack supports it

Use standard hybrid key exchange such as X25519MLKEM768 from standard stacks, never a home-made combiner. Receipt any downgrade, and keep the legacy side unchanged where devices cannot move.

Sign new evidence hybrid from day one

Ed25519 plus ML-DSA-65, both required. Anything signed classically from here on adds to the backlog you will have to renew.

Make each migration step provable

Record plan, approval, transition and close, with a before/after CBOM diff. Run in shadow mode and dual-run first, and rehearse a rollback. Evidence a regulator can verify replaces screenshots.

Plan for evidence that must outlive this decade

Use a hash-based archive profile and scheduled renewal for records that must stay verifiable after an algorithm change. Old receipts are carried forward, never rewritten.

08 How R-Series answers the clock

Each clock and where our answer stands.

ClockR-Series answerState
Harvest now, decrypt later (transport)Standard hybrid key exchange, with any downgrade receiptedIn development
Harvest now, decrypt later (stored memory)Sovereign agent memory with hybrid key encapsulationIn development
Signatures that must outlive algorithmsEvery universal receipt signed Ed25519 + ML-DSA-65; both signatures requiredIn development
Evidence across an algorithm changeA hash-based archive profile, independent witnessing and scheduled renewalIn development
Key and algorithm historyWhich key was valid when, recorded in every receiptIn development
Provable migrationMigration evidence: plan, approval, transition, close, and a before/after CBOM diffIn development
Cryptographic inventoryCryptographic inventory and change evidence (CBOM + before/after diff) — design partnership, limited slots.In development
OT / IoT estatesA gateway profile, a physical bench and reference hardware, then a field pilotIn development
AI traceability dutiesOne receipt per agent action, through Connector OS and every product profilePlanned

Nothing here is presented as independently assured or post-quantum end to end. In development — talk to us about a design partnership.

09 Questions

What people ask us.

When will a quantum computer break RSA?

Nobody knows, and we do not guess. Three quarters of surveyed organisations expect one within ten years. What matters for planning is your own shelf-life and migration time, which you can measure.

Is it too early to act?

For anything that must stay secret, or stay trusted, for longer than your migration will take, it is already late. Inventory and a CBOM are useful whatever the year turns out to be.

Why hybrid rather than post-quantum only?

Post-quantum implementations are young. Hybrid keeps the well-understood classical guarantee and adds the post-quantum one. It fails closed if either is missing, and it matches the hybrid guidance that European cybersecurity agencies now publish.

Do the regulations require receipts?

Not today. They require inventories, plans and records. Receipts are a stronger form of that evidence: something a third party can verify instead of a document they must accept. Whether instruments start naming signing or registration is an open question that we track.

What about OT equipment that cannot be upgraded?

Leave the device side unchanged where it cannot move. Migrate the gateway's wide-area transport and one credential class at a time. Receipt every step, run dual-run and a rollback drill, and archive the evidence so it outlives the device's cryptography.

Is R-Series itself post-quantum today?

The hybrid issuer is release candidate 4, running on staging. Production keys and an external review are still ahead. We do not claim post-quantum end to end.

Start with what you can measure.

How long your data must last, how long migration takes, and what you can prove you have done.

See the migration pathPost-quantum trust

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.