Skip to content
DCSAITechnologies
In developmentTrust Systems

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
01 · Why now

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.
02 · The process

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.

  1. 01Discover

    Find what is running

    Your scanners’ CycloneDX 1.6 exports and ours enter one ingest. What was not scanned is said out loud.

  2. 02Assess

    Rank by risk

    Data lifetime, exposure and algorithm strength, with a signed risk verdict.

  3. 03Plan

    Write it down first

    Scope, target, policy and steps fixed and signed before anything changes.

  4. 04Migrate

    Change one target

    After a signed approval, through adapters: API connectors, a host agent, or a gateway for OT.

  5. 05Dual-run

    Old and new side by side

    Both paths serve the same traffic; divergence is counted and signed.

  6. 06Verify

    Nothing slipped back

    A downgrade check on every transition; a failure is rolled back and signed.

  7. 07Receipt

    Close the plan

    Planned, executed, failed and deferred, with the inventory after.

03 · Migration evidence

Every migration is four signed records.

Each record has a fixed shape. A record with anything unknown or missing is refused.

Signed migration records Hybrid-signed
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
04 · Migration surfaces

Each surface needs an adapter and a receipted pilot.

  • TLS

    Edge policy and key-exchange telemetry

    In development
  • Receipts & documents

    R-Series engine

    In development
  • Data at rest

    Sovereign-memory envelope

    In development
  • OT / IoT

    OT gateway profile

    In development
  • SSH

    Probe

    Planned
  • VPN

    Feasibility note

    Planned
  • API authentication

    To be built

    Planned
  • Code & firmware signing

    To be built

    Planned
  • PKI

    To be built

    Planned
  • Service mTLS

    To be built

    Planned
05 · Post-quantum safety

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.

06 · Why evidence

A change log asks to be trusted. A receipt can be checked.

Operator’s change logPQC Migration evidence
Written by the party under reviewSigned at the moment of the change
The auditor has to believe itChecked offline, without access to the operator’s systems
“Migrated” with no before or afterThe inventory hash at the start, after every step and at the end
Failures quietly left outEvery rollback signed with its reason; a plan cannot close while steps are missing
Hostnames and names exposedTargets and approvers appear as hashes; you choose who sees the inventory
07 · Services

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
08 · Where it applies

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.

09 · Honest status

Where PQC Migration stands today.

From dcslabs.ai/r-series/migration , checked 27 Oct 2026.

  1. Built

    The engine’s cryptographic bill of materials: CycloneDX 1.6, validated against the official schema, deterministic, with a drift check.

  2. Open now

    Cryptographic inventory and change evidence (CBOM + before/after diff), as a design partnership with limited slots.

  3. In development

    The migration control plane, signed migration records, the hybrid issuer, and the TLS and data-at-rest adapters.

  4. 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.

Every feature, on screen

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.

pqc migrationIllustration · demo data
PlansIn development

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.

Once you connect

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.

Start with PQC Migration.

Request early access, or talk to us about enterprise and sovereign deployment.