PQC migration · Cryptographic Transition Assurance

Rack by rack, key by key.

R-Series is developing cryptographic transition evidence: records of scope, approval, change and verification that an assessor can check independently.

What it recordsApproved migration steps, signed
CheckedOffline, without DCS
StateIn development
OfferScoped assessment and separate change pilot · in development
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.

A migration also needs 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 is designed to record each approved 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 designed to be 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, are designed to 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 offers

What each offer covers.

Choose how far you want to go

Start with an assessment and report. You can stop after receiving the agreed deliverables, act on them with your own team, or discuss a separate DCS change pilot. The assessment does not change your systems.

Assessment and change-pilot delivery depend on their respective readiness checks and approvals. We welcome enquiries now and confirm scope, availability and fees before accepting an engagement.

We welcome conversations about a scoped PQC assessment and a separately approved change pilot. Both offers are in development. Customer delivery begins only after the relevant readiness checks and approvals are complete.

ASSESSMENT

PQC Assessment and Report Only

Understand the cryptography observed across an agreed set of TLS and SSH endpoints. Discuss a reviewed inventory, coverage gaps, prioritised findings and a verifiable evidence package. You can use the assessment to plan your next steps without buying remediation from DCS.

Delivery is subject to scope, service readiness and engagement approval.

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

04 Migration surfaces

Observation and change execution, surface by surface.

SurfaceObservation or assessment scopeChange execution availability
TLS and SSH endpointsScoped handshake observations; IPv4 only at presentSeparate approved pilot; only accepted adapters and environments
Certificate chainsChains visible through the scoped TLS observationsPKI changes are separately qualified
Imported inventoryOnly explicitly supported and validated import formats, with provenance and coverage In developmentAn import is not evidence that a change occurred
Source, storage and key managementOutside the initial assessment unless separately acceptedNo availability inferred from roadmap or primitive support
OT and IoTNamed device classes and approved assessment scope only. See OT / IoT.Reference work in development; bench and environment qualification required
05 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 by an independent verifier.

7

Receipt

A close receipt with the CBOM after.

How R+13 records a migration →

The assessment and change engagement: Crypto-Agility.

06 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. Migration evidence components are being integrated with approved execution, failure handling and recovery. A customer change pilot has its own acceptance requirements.

StageWhat it delivers
LedgerOne integration line, one hash ledger, the before/after inventory pair.
EngineThe post-quantum engine behind one interface.
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

07 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 are designed to enter through one ingest, labelled as inventory; import support is in development. Scanner signatures are never treated as evidence; only the engine signs.

In development

08 Questions

Before you start.

Can we buy only the assessment?

Yes. We can scope an assessment-only engagement. Remediation and any change pilot are separate purchases and approvals. Delivery depends on service readiness and agreed terms.

Can another provider use the results?

The proposed engagement should permit your internal team or an authorised provider to use your deliverables for remediation, subject to confidentiality and third-party licensing terms. Confirm these rights in the signed statement of work.

Will you scan all our cryptography?

We assess the systems and observation types accepted in writing. The first offering focuses on TLS and SSH endpoint observations over IPv4 and the certificate material visible through those observations. Other channels need separate scope acceptance. The report states what was and was not observed.

What can two scanners tell us?

Cross-checking can expose disagreements within overlapping supported coverage. It does not guarantee that every system was observed. The report identifies untested areas and unresolved differences. Two-scanner checking is an expression of interest until the tools, coverage and delivery workflow have passed their checks.

Does a signed receipt establish that our systems have been migrated?

No. A receipt binds the recorded evidence to its issuer under the applicable verification rules. It does not prove that every asset was discovered or that your systems have been migrated.

Will you change our systems during assessment?

No configuration change is included. Any later change requires its own approved plan and engagement.

What will it cost?

Fees depend on agreed scope, observation windows, analysis and deliverables. We confirm a quote before accepting work. No public price is promised here.

Is ongoing monitoring included?

No. A point-in-time assessment or separately arranged re-scan does not include a recurring monitoring service. A re-assessment requires a separately agreed scope and written observation authority; comparisons depend on compatible evidence.

Can we start today?

You can discuss your scope with us today. Assessment delivery and the separate change pilot each depend on their own readiness and approval checks. An enquiry does not authorise scanning or a change to your systems. Customer migrations have not been completed, and we do not claim they have.

Do we have to replace our discovery tools?

No. Your scanners' CycloneDX exports are designed to enter through the same ingest as ours, labelled as inventory. Import support is in development, and an import is not evidence that a change occurred. Our part is the evidence that the change happened.

What makes this evidence stronger than a report?

Each step is designed to be 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?

A gateway can protect supported communication paths and record evidence for legacy devices. It does not upgrade the cryptography inside every device. Assessment determines whether a device can be adapted, isolated, replaced or decommissioned. See the OT / IoT programme.

Start with one slice of your estate.

We welcome conversations about a scoped PQC assessment and a separately approved change pilot. Both offers are in development. Customer delivery begins only after the relevant readiness checks and approvals are complete.

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