PQC migration · Cryptographic Transition Assurance

Rack by rack, key by key.

Finding classical cryptography is the crowded half of the market. Proving that it was actually replaced, step by step, in a form an assessor can check offline, is the empty half. R-Series builds that half: a migration control plane whose every step leaves a signed receipt through R+13.

Ask about a design partnershipThe ten stages
What it recordsEvery migration step, signed
CheckedOffline, without DCS
StateIn development
OfferCBOM + before/after diff — design partnership, limited slots
01 The problem

An inventory is not a migration.

Cryptography hides in places nobody wrote down: TLS terminators, VPN concentrators, code-signing pipelines, HSM partitions, database encryption, firmware and libraries three dependencies deep. Many tools now find it. Discovering, assessing and planning are well served.

What is missing is evidence that the change happened: 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. Evidence is only strong when it is minted at the point of action; an inventory receipt is not a migration receipt.

R-Series records every migration step as a signed receipt on the same engine as every other receipt, with the cryptographic bill of materials before and after. When a regulator, auditor or board asks how far along you are, the answer is a bundle they can verify without trusting DCS.

02 Watch a data centre move

Discover, flag, migrate, prove.

Data centre01 / 04
01 · DISCOVER

Every rack is a question mark.

Probes, runtime inventory and scanner output, from our own tools or from the tools you already run, enter through one CycloneDX 1.6 ingest. Each record is labelled with the tool, its version and the scope it covered.

02 · ASSESS + PLAN

Classical-only cryptography lights up.

Findings are scored for exposure and data lifetime, and a signed plan fixes the scope, the target, the policy and the planned steps before anything changes.

03 · MIGRATE + DUAL-RUN

Hybrid suites roll across the floor.

After a signed approval, each step is a signed change record: from-state, to-state, side-by-side result, downgrade check and rollback. Peers that are not ready keep working, and every fallback is recorded.

04 · VERIFY + RECEIPT

The count is on the record.

A close receipt states completeness, open items and the inventory after. The bundle checks offline in two languages. Absence of evidence is never reported as evidence of absence.

03 The control plane

Seven steps, each one receipted.

The control plane is a state machine that executes through adapters and never carries cryptography of its own: every signature comes from the R-Series engine.

1

Discover

Probes and CBOM ingest, labelled as inventory.

2

Assess

Exposure scoring and a signed risk verdict.

3

Plan

A signed plan: scope, target, steps.

4

Migrate

A signed approval, then the change.

5

Dual-run

Both stacks side by side; downgrades caught.

6

Verify

Offline bundle check in JS and Python.

7

Receipt

A close receipt with the CBOM after.

How R+13 records a migration →

04 The programme

Ten stages, each with an exit it must prove.

The programme runs in ten stages, from one consolidated ledger to discovery adapters for customer estates. Each stage closes only on written evidence, not on a date. The first migrations run on our own systems before any customer estate.

StageWhat it delivers
LedgerOne integration line, one hash ledger, the before/after inventory pair.
EngineThe post-quantum engine behind one interface, with a second implementation in Python.
Key exchangeHybrid key exchange from standard TLS stacks only. No home-made combiner.
Key authorityA signed key registry with custody classes, rotation and revocation drills.
Transition evidenceSigned change records, a signed inventory diff and a signed risk verdict.
First product migrationOne of our own products moved to hybrid signatures, end to end, checked offline by someone who did not build it.
EdgeA DCS-controlled edge to prove things on.
Transport migrationHybrid key exchange at an edge, with degraded handshakes and downgrades on the record.
Adapters + profilesOne core verifier, many migration surfaces.
Discovery + riskProbes, inventory and plans built from the scanner exports customers already have.

In development

05 CBOM verdict

A good engine CBOM. Not yet a product CBOM.

The engine's cryptographic bill of materials is CycloneDX 1.6, validated against the official schema, deterministic, and guarded by a drift check. Weak and broken algorithms are marked blocked.

A product-scope CBOM goes further: which service uses which algorithm, and the components outside libraries, such as TLS termination and token algorithms. Our scanners, open-source tools and incumbent vendors' exports all enter through one ingest, labelled as inventory. Scanner signatures are never treated as evidence; only the engine signs.

In development

06 Migration surfaces

Each surface needs an adapter and a receipted pilot.

SurfaceAdapterState
TLSEdge policy + key-exchange telemetryIn development
Receipts and documentsR-Series engineIn development
SSHProbePlanned
VPNFeasibility notePlanned
API authenticationTo be builtPlanned
Code and firmware signingTo be builtPlanned
PKITo be builtPlanned
Data at restSovereign-memory envelopeIn development
Service mTLSTo be builtPlanned
OT / IoTOT gateway profile. See OT / IoT.In development
07 Design partnership

What a design partner receives.

One offer is open today: cryptographic inventory and change evidence (CBOM + before/after diff) — design partnership, limited slots. The other offers are planned.

CBOM

Cryptographic inventory and change evidence

Bring the CycloneDX exports from the scanners you already run; receive a signed inventory and a before/after diff when the estate changes. Design partnership, limited slots.

In development

ASSURANCE

Cryptographic Transition Assurance

Evidence for your assessor that one migration slice on your estate happened as recorded, checkable offline.

Planned

TRANSPORT

Transport migration

Hybrid key exchange at an edge you control, with degraded handshakes and downgrades on the record.

Planned

SIGNING

Signing-path migration

A code or firmware signing slice moved to post-quantum signatures, recorded in the signing path itself.

Planned

08 Questions

Before you start.

Is this a migration service I can buy today?

No. Today we offer one thing: cryptographic inventory and change evidence (CBOM + before/after diff) — design partnership, limited slots. Everything else is in development. Customer migrations have not been completed, and we do not claim they have.

Do we have to replace our discovery tools?

No. Discovery is well served. Your scanners' CycloneDX exports enter through the same ingest as ours, labelled as inventory. Our part is the evidence that the change happened.

What makes this evidence stronger than a report?

Each step is a signed receipt from the same engine, minted at the point of action, chained, and checkable offline in two languages without trusting DCS. A non-author re-runs the bundle before it counts.

Will hybrid break clients that are not ready?

Hybrid key exchange negotiates down for peers that do not support it, and every fallback is recorded as a degraded handshake. Nothing is forced until both ends are ready.

What about devices that cannot be upgraded?

They are fenced and migrated at a gateway that calls the R-Series engine, never with cryptography of its own. See the OT / IoT programme.

Start with one slice of your estate.

Start with your cryptographic inventory and a signed before/after diff, as a design partner.

Ask about a design partnershipThe fifteen layers

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