PQC MigrationCryptographic transition assurance
Rack by rack, key by key. Every step of a post-quantum migration, signed.
Design partnership · limited slots
- Security & PKI teams
- Regulated enterprises
- Assessors & auditors
- Migration steps, each one a signed receipt
- 7
- Signed records per migration: plan, approval, change, close
- 4
- Ed25519 + ML-DSA: both signatures must hold
- Hybrid
- Open today: CBOM + before/after diff, limited slots
- 1 offer
Signed today. Still trusted in 2040?
A quantum computer large enough to break RSA and elliptic curves does not need to exist yet to cause harm. Traffic and records copied today can be opened later, and signatures made only with classical cryptography can be forged after the fact. If a record must stay valid for fifteen years and a migration takes five, the work has to start before the machine exists.
Finding classical cryptography is well served; many tools do it. What is missing is evidence that it was actually replaced: which system moved from which algorithm to which, who approved it, whether both stacks ran side by side, whether a downgrade was caught, and what the inventory looked like before and after. PQC Migration records every step as signed evidence an assessor can check offline.
An inventory is not a migration. Migrate once, prove it forever.
Seven steps, each one receipted.
A control plane that executes through adapters and never carries cryptography of its own. Every signature comes from the R-Series engine.
- 01Discover
Find what is running
Your scanners’ CycloneDX 1.6 exports and ours enter one ingest. What was not scanned is said out loud.
- 02Assess
Rank by risk
Data lifetime, exposure and algorithm strength, with a signed risk verdict.
- 03Plan
Write it down first
Scope, target, policy and steps fixed and signed before anything changes.
- 04Migrate
Change one target
After a signed approval, through adapters: API connectors, a host agent, or a gateway for OT.
- 05Dual-run
Old and new side by side
Both paths serve the same traffic; divergence is counted and signed.
- 06Verify
Nothing slipped back
A downgrade check on every transition; a failure is rolled back and signed.
- 07Receipt
Close the plan
Planned, executed, failed and deferred, with the inventory after.
Every migration is four signed records.
Each record has a fixed shape. A record with anything unknown or missing is refused.
- Plan
What will changeIntent, starting inventory and rules, fixed before anything moves- Approval
Who allowed itHuman or automated policy, what it covers and when it lapses- Change
One target, one changeBefore and after, dual-run, downgrade check, any rollback- Close
The honest endPlanned, executed, failed and deferred, and the inventory at the end
Each surface needs an adapter and a receipted pilot.
TLS
Edge policy and key-exchange telemetry
In developmentReceipts & documents
R-Series engine
In developmentData at rest
Sovereign-memory envelope
In developmentOT / IoT
OT gateway profile
In developmentSSH
Probe
PlannedVPN
Feasibility note
PlannedAPI authentication
To be built
PlannedCode & firmware signing
To be built
PlannedPKI
To be built
PlannedService mTLS
To be built
Planned
Two locks, not a swap.
Post-quantum algorithms are young; classical ones are well understood but mortal. A hybrid signature stays safe as long as either one holds.
Ed25519 + ML-DSA-65
The balance of size and strength for most records: enterprise, finance, government.
Ed25519 + ML-DSA-87
The highest ML-DSA level, the one CNSA 2.0 names for national-security systems.
No silent fallback
A missing, stripped, swapped or reordered signature fails verification.
Downgrades on the record
Peers that are not ready negotiate down, and every degraded handshake is receipted.
Rollbacks are evidence
A failed step returns to a known state; the rollback and its reason are signed.
History is never re-signed
Receipts are checked under the suite they were issued with.
A change log asks to be trusted. A receipt can be checked.
Four offers, one evidence layer.
One offer is open today as a design partnership. The others are planned.
- Offer 01
Cryptographic inventory and change evidence
- Bring the CycloneDX exports you already have
- Receive a signed inventory and a before/after diff
- Open now · limited slots
- Offer 02
Cryptographic Transition Assurance
- Evidence that one migration slice on your estate happened as recorded
- Checkable offline
- Planned
- Offer 03
Transport migration
- Hybrid key exchange at an edge you control
- Degraded handshakes and downgrades on the record
- Planned
- Offer 04
Signing-path migration
- A code or firmware signing slice moved to post-quantum signatures
- Recorded in the signing path itself
- Planned
One evidence layer, many migrations.
Enterprise estates
Every step of an estate’s move to post-quantum cryptography, written as signed change records.
Plants and fleets
Gateway-driven migrations of equipment that cannot be patched in place, with dual-run and rollback on the record.
Space and autonomous systems
Key changes on platforms that are hard to reach, recorded the same way as every other migration.
Assessors and regulators
A bundle they can verify themselves, instead of a report they have to take on trust.
Where PQC Migration stands today.
From dcslabs.ai/r-series/migration , checked 27 Oct 2026.
- Built
The engine’s cryptographic bill of materials: CycloneDX 1.6, validated against the official schema, deterministic, with a drift check.
- Open now
Cryptographic inventory and change evidence (CBOM + before/after diff), as a design partnership with limited slots.
- In development
The migration control plane, signed migration records, the hybrid issuer, and the TLS and data-at-rest adapters.
- Not claimed
No customer migration has been completed. The first migrations run on our own systems, and independent certification comes before production use.
PQC Migration is a DCS Labs programme built on R-Series, which is release candidate 4 on staging and under audit.
Inside PQC Migration
Pick a feature to see its screen, what it does, and how it works once you connect your own accounts and data. All values are demo data.
Migration plan · demo-estate
Statusin development
Discover → Assess → Planreceipted
Migrate → Dual-run → Verifyreceipted
Closeplanned, executed, failed and deferred listed
Every step receipted
Discover, assess, plan, migrate, dual-run, verify and close, each a signed record.
Planned: each of the seven migration steps on your estate is written as a signed record by the R-Series engine; no customer migration has been completed yet.
Part of one ecosystem
Start with PQC Migration.
Request early access, or talk to us about enterprise and sovereign deployment.