R+13 · Migration evidence

Proof that the change happened.

A post-quantum migration is a long series of small, risky changes. R+13 turns each one into signed evidence: what the estate looked like before, which policy and approval allowed the change, how the old and new paths ran side by side, whether anything was downgraded or rolled back, and what the estate looks like after.

Where it standsThe migration programme
Receipt kinds4 signed kinds
Control plane7 states
StateIn development
01 What R+13 proves

A change log you do not have to take on trust.

Today, the evidence that a key or algorithm was migrated usually lives in the operator's own change ticket. An auditor has to believe it. R+13 proves that a cryptographic state change happened: from what, to what, under which policy, approved by whom, with the dual-run and any rollback recorded, and with the estate's inventory captured before and after.

All of that is verifiable without the operator's change log. The receipts are signed by the R-Series engine with both a classical and a post-quantum signature, chained to each other, and bundled so that anyone holding the bundle can check signature, hash and inclusion offline.

R+13 uses the same signing engine and the same receipt format as every other R-Series layer, so a migration record is checked the same way as any other receipt.

Every migration step leaves a receipt, including the ones that were rolled back.

02 The control plane

Seven states, one signed trail.

The migration control plane moves each target through the same seven states. Every state writes into a signed receipt, so the trail is complete by construction rather than by discipline.

Migration control plane01 / 07
01 · DISCOVER

Find what is actually running.

Scanners fingerprint hosts, endpoints, code and key stores. The result becomes the estate's cryptographic bill of materials (CBOM), and its hash is signed into the plan.

  • Scanner coverage and failed scans are declared in a signed scope statement
  • What was not scanned is said out loud
02 · ASSESS

Rank by risk, and sign the ranking.

The scheduler weighs data lifetime, exposure and algorithm strength. Its verdict is itself signed and referenced from the plan, so the order of work can be checked later. An unsigned verdict is rejected.

03 · PLAN

Write down every step before touching anything.

A plan receipt names the target, the policy and the list of planned steps. A separate approval receipt records who approved it, whether a human or an automated policy, the scope, and when the approval expires.

04 · MIGRATE

Change one target.

The target moves from its old state (algorithm, suite, key and certificate) to its new one. The control plane acts through adapters: Connector OS for API targets, a host agent on premises, and a gateway for OT equipment.

05 · DUAL-RUN

Run old and new side by side.

For a defined window, traffic is served or mirrored on both paths. The receipt records when the dual-run started and ended, how many responses diverged, and the result. Divergence is evidence, not noise.

06 · VERIFY

Check the new path, and check nothing slipped back.

Verification records its method and evidence. A downgrade check confirms peers are not falling back to the classical path. If it fails, the target is rolled back and the rollback, its reason class and the state it returned to are all signed.

07 · RECEIPT

Close the step, then close the plan.

Each step ends in a signed change receipt with the inventory hash after the change. When the plan is finished, a close receipt records what was planned, executed, failed and deferred, and the estate's inventory after.

03 Four signed records

Plan, approval, change, close.

Every migration is written down as four kinds of signed record. Each one has a fixed shape: a record with anything unknown or missing is refused.

PLAN

What will change

The intent of the whole migration, the starting inventory and the rules it runs under, fixed before anything changes.

APPROVAL

Who allowed it

Who approved the plan, human or automated policy, what the approval covers and when it lapses.

CHANGE

One target, one change

The before and after state, the side-by-side run, the downgrade check, any rollback, and the inventory after the step.

CLOSE

The honest end

Every step by reference, what was planned, executed, failed and deferred, and the inventory at the end.

04 Safety rails

Dual-run, downgrade check, rollback.

DUAL-RUN

Two paths, one window

The old and new configurations serve or shadow the same traffic for a defined period. The signed divergence count tells a reviewer whether the new path behaved the same. A zero has to be earned; it cannot be typed in later.

DOWNGRADE

No quiet fallback

Hybrid key exchange negotiates down for peers that are not ready. That is useful during a migration and dangerous if it persists. The downgrade check is recorded as pass or fail on every transition, and degraded handshakes are themselves receipted.

ROLLBACK

Failure is on the record

When verification or the downgrade check fails, the target goes back to a known state. The receipt records that a rollback occurred, a reason class and the state it was restored to. A trail with no rollbacks in it should raise questions, not settle them.

05 CBOM before and after

The inventory is the scoreboard.

A migration claim only means something against an inventory. R+13 signs the hash of the cryptographic bill of materials at the start, after every step and at the end. The CBOM diff between them shows exactly which findings changed.

The diff is occurrence-aware: the same algorithm in two places counts as two findings, so moving one does not hide the other. An inventory that does not match its record fails verification.

06 Where it stands

In development.

R+13 is in development and is not yet used in production. The first migrations it records are on our own systems, before any customer estate. In development — talk to us about a design partnership.

In development

07 Who uses it

One evidence layer, many migrations.

PQC MIGRATION

Enterprise estates

Every step of an estate's move to post-quantum cryptography, written as signed change records.

 OT / IOT

Plants and fleets

Gateway-driven migrations of equipment that cannot be patched in place, with dual-run and rollback on the record.

 SPACE AND AUTONOMY

Space and autonomous systems

Key changes on platforms that are hard to reach, recorded the same way as every other migration.
08 Questions

What reviewers ask.

Why not just keep a good change log?

A change log is written by the party under review. R+13 receipts are signed at the moment of the change, chained to each other and bundled for offline checking, so a reviewer does not need access to, or trust in, the operator's systems.

Do the receipts expose our infrastructure?

Targets and approvers appear as commitments (hashes), not raw hostnames or names. The CBOM appears as a hash; you choose who sees the inventory itself.

What happens when a step fails?

It is rolled back and the rollback is signed with a reason class and the state it returned to. The close receipt then counts it as failed or deferred. A plan cannot close as complete while steps are missing.

Has any of this passed certification?

Not yet. R+13 is in development. Independent certification comes before it is used in production.

Has a customer migration been recorded?

No. The first migrations are run on our own systems before any customer estate.

Can it migrate systems we cannot reach over an API?

The control plane acts through adapters: Connector OS for API targets, a host agent on premises, and a gateway for OT equipment. The receipt format is the same in every case.

Migrate once. Prove it forever.

R+13 makes every cryptographic change something you can hand to an auditor, a regulator or a board, and let them check for themselves.

Next: R+14 key lifecycleThe fifteen layers

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