Industries · Enterprise & digital infrastructure

Migrate the estate. Prove every step.

Your board will ask how far the post-quantum migration has got, and your regulator will ask you to show it. R-Series turns each step, from inventory to cut-over, into a signed receipt with the cryptographic inventory before and after, bundled so anyone can check it offline without trusting you or us.

Migration evidenceIn development
Receipt signatureEd25519 + ML-DSA-65
OfferDesign partnership
00 For CIO and CISO teams

An estate you do not fully see, and a question you will have to answer.

A modern estate runs its cryptography in three places at once: on-premises data halls and campus networks, cloud regions with their own key services and load balancers, and a long tail of SaaS applications reached through OAuth grants and API tokens. RSA and elliptic-curve keys sit in TLS terminators, VPN concentrators, HSM partitions, database encryption, code-signing pipelines and libraries three dependencies deep.

Finding that cryptography is well served by the market. What is missing is evidence that it was replaced: which system moved from which algorithm to which, who approved it, whether old and new ran side by side, whether a downgrade was caught, and what the inventory looked like before and after.

R-Series records each migration step as a signed receipt on the same engine as every other receipt it issues, with the cryptographic bill of materials (CBOM) hashed in before and after. Keys carry their own signed history (R+14), and records that must last decades get an archive profile and renewal (R+15).

The only offer today: Cryptographic inventory and change evidence (CBOM + before/after diff) — design partnership, limited slots. The control plane is in development. No customer migration has been recorded, and this page does not suggest otherwise.

An inventory is not a migration.

01 What you will be asked for

Six things a board, an auditor or a regulator will want to see.

Each maps to a part of R-Series, with its real state today.

01 · INVENTORY

Where the cryptography is

One CycloneDX 1.6 ingest for probes, runtime inventory and the scanner exports you already own. Each record is labelled with the tool, its version and the scope it covered.

In development

02 · RANK

What to move first

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

In development

03 · MIGRATE

Proof the change happened

Plan, approval, transition and close: four signed receipt kinds, with dual-run, downgrade check and rollback recorded on every step (R+13).

In development

04 · KEYS

Which key was valid, then

A signed, append-only key registry with custody classes and epochs. An old receipt is checked against the registry as it stood when it was signed (R+14).

In development

05 · EVIDENCE

A pack anyone can verify

Receipts chain into a bundle that verifies offline in JavaScript and Python.

In development

06 · DECADES

Records that outlive the algorithm

Archive manifests sealed with hash-based signatures, witnessed checkpoints and renewal receipts that carry old evidence forward without re-signing it (R+15).

In development

02 The migration machine

Inventory, rank, migrate, prove.

Migration01 / 04
01 · INVENTORY

Every target becomes a line in the CBOM.

Probes, runtime inventory and scanner output, from our tools or the ones you already run, enter through one CycloneDX 1.6 ingest. The inventory's hash is signed into the plan, and a signed scope statement declares coverage and every scan that failed.

  • What was not scanned is said out loud
  • Scanner signatures are never treated as evidence; only the engine signs
02 · RANK

Order the work by how long it must last.

The scheduler weighs data lifetime, exposure and algorithm strength, and signs its verdict. The plan references that verdict, so anyone can later check why one system went before another.

  • Longest-lived secrets and longest-trusted signatures first
03 · MIGRATE

One target, one change, everything on the record.

A signed plan fixes scope, target and steps; a signed approval records who allowed it and when the approval lapses. Each change is a transition receipt: what it moved from and to, how long old and new ran side by side, whether a downgrade was caught, and any rollback with its reason.

  • Peers that are not ready keep working; every fallback is recorded
  • A trail with no rollbacks should raise questions, not settle them
04 · PROVE

Close the plan, honestly, and hand over the bundle.

The close receipt states what was planned, executed, failed and deferred, with the CBOM after. The bundle verifies offline, and a non-author re-runs it before it counts. Absence of evidence is never reported as evidence of absence.

  • Bundle rules exist in JavaScript; the Python bundle verifier is open work
  • Bundles are not yet anchored
03 Cryptographic inventory across the estate

On-prem, cloud and SaaS, through one ingest.

You do not have to replace your discovery tools. Their exports enter the same way as ours, labelled as inventory. Our part is the evidence that the change happened.

ON-PREMISES

Data halls and campus

TLS terminators, VPN concentrators, SSH, HSM partitions, database encryption and code-signing pipelines.

  • A host agent acts on premises
  • Devices that cannot be upgraded are fenced at a gateway (see OT / IoT)
CLOUD

Regions and key services

Load balancers, API gateways and cloud key management. Our own staging signs Ed25519 and ML-DSA-65 inside a cloud KMS, behind a key handle.

  • Hybrid key exchange from standard stacks only
  • No home-made combiner, no home-made handshake
SAAS

Applications behind OAuth

The cryptography you do not run yourself still has keys, grants and tokens. Connector OS reaches SaaS targets through their APIs, and every credential event becomes a receipt.

  • Connector OS is the adapter for API targets
  • Target state; see Connector OS
Your scanners+Our probes→CycloneDX 1.6 ingest→Labelled inventory→Classical findings→Signed CBOM diff
SurfaceWhere it livesAdapterReal state
TLSEdge, load balancersEdge policy + key-exchange telemetry.In development
Receipts and documentsEvery productS1 engine. Built; the Website Maker migration not yet run.In development
SSHOn-prem, cloud hostsProbe. The cheapest second in-path slice.Planned
VPNCampus, remote accessFeasibility note: WireGuard with a post-quantum pre-shared key, proposed.Planned
API authenticationCloud, SaaSSecond transport pilot on an API surface.Planned
Code and firmware signingBuild pipelinesML-DSA can use existing KMS custody; LMS needs an HSM that holds signer state.Planned
PKIEverywhereWatching Merkle Tree Certificates.Planned
Data at restDatabases, object storesR+7 hybrid envelope.In development
Service mTLSCloud, data hallAfter TLS and API.Planned
The CBOM verdict, honestly. Our engine's CBOM is CycloneDX 1.6, schema-validated, deterministic and drift-checked in CI, with SHA-1, MD5, RSA PKCS#1 v1.5 and "none" marked blocked. It is not yet a product-scope CBOM: it has no dependency graph or occurrence evidence. An earlier recorded before/after pair measures a change of scope, not a migration, and is not presented as one.
04 Key lifecycle · R+14

A key revoked tomorrow does not erase what it honestly signed today.

Every key event (generate, activate, rotate, revoke, recover) is a signed record in an append-only registry. The records roll up into a Merkle root, and every new receipt carries the registry root and key epoch it was signed under.

When an old receipt is checked, the verifier resolves the registry snapshot named in the receipt, not one handed to it by the caller. The answer comes in two parts: integrity, and what has happened to the key since. They are never merged into one pass or fail.

Where the key lives is part of the evidence. A revoke names the affected range of sequence numbers, so receipts outside it are not swept up with it.

Custody classWhat it meansState
HSMThe strongest class. Defined in the registry; a hardware provider behind it is still to be connected.Class defined
KMSKeys stay inside a cloud KMS behind a key handle. Staging signs both legs this way, with a separate key for the witness.In development
SoftwareAllowed where policy permits, and always declared, so a verifier can see it.Defined
ResearchFor experiments and test vectors. A receipt claiming production status under a research key does not verify.Refused in production
Production keys. Production keys are created only after certification and a key ceremony.
05 Connector OS across SaaS estates

The connectors are the reach. R-Series is the trust.

Much of an enterprise's cryptography sits in other people's systems. Connector OS lets agents act in those systems; R-Series turns every action and every credential event into a receipt. This section describes the target state and marks what is built.

CREDENTIALS

Credential lifecycle as evidence

OAuth grants, token refresh, scope changes and revocation are receipted under R+14, with per-tenant signing keys and epochs: a verifiable history of who could access what, and when it stopped.

Planned

CHANGE

No silent connector change

Any change to a connector, including provider API version, auth method, scopes or cryptography, produces transition receipts with the before and after state, under R+13.

Planned

PASSPORT

Which code touched your systems

Each connector version carries a signed passport: manifest, permissions, dependencies, CBOM and build provenance (R+12). The library is built; there is no HTTP route yet.

In development

PRECONDITION

No receipt, no write

If evidence cannot be produced, write actions do not run. If the provider executed but issuing was interrupted, a durable pending obligation is completed later.

Planned

One rule across every product. Connector OS never hashes, signs or verifies on its own. Every cryptographic step goes through the R-Series engine, so a connector bug cannot weaken a signature. Hybrid transport today runs on the R-Series staging edge, not on Connector OS.
06 Evidence packs for boards and regulators

Not a status report. A bundle they can check themselves.

Most regimes still run on attestation: an organisation says what it has done. A migration evidence pack is designed to be checked by a third party who was not in the room, offline, without access to your systems.

WHAT IS IN IT

The signed trail

  • The plan, approval, every transition and the close
  • A signed before/after CBOM diff, occurrence-aware
  • The signed risk verdict that set the order
  • Log inclusion (witness cosignature planned)
  • An open offline verifier
WHO READS IT

Three audiences, one bundle

  • Board: how far along, with what failed and what was deferred
  • Auditor: signed evidence in place of screenshots and exports
  • Regulator: who allowed each change, and whether anything was left out
WHAT IT HIDES

Commitments, not hostnames

  • Targets and approvers appear as commitments (hashes)
  • The CBOM appears as a hash; you choose who sees the inventory
  • Approvals lapse; they are not permanent
The questionWhere the answer livesState
What did the estate look like before?The signed plan and its scope statementIn development
Why this order?A signed scheduler verdictIn development
Who allowed it?The signed approval: approver commitment, human or automated, scope, expiryIn development
Did old and new behave the same?The dual-run record with its divergence countIn development
Did anything slip back to classical?A downgrade check on every transition; degraded handshakes receiptedIn development
Is it finished?The close receipt: planned, executed, failed, deferred, open itemsIn development
Can a stranger re-run it?A non-author re-runs the bundle and gets the same answerPlanned
07 Long-horizon records · R+15

Never re-sign history. Seal it, and seal the seal later.

Contracts, audit trails and signed evidence can be relied on for decades, longer than the algorithms that signed them. R+15 keeps them verifiable across algorithm generations without touching the originals.

ARCHIVE

Hash-based seal on manifests

A hash-based signature on archive manifests, log checkpoints and registry roots, never per receipt. Manifests carry two hashes from different design families.

In development

RENEWAL

Evidence renewal

A newer suite seals over a range of older receipts. The originals still verify under their own rules, and the renewal chain is checked from there to the present.

In development

WITNESS

Outside cosignatures

Checkpoints in the C2SP tlog-checkpoint format, cosigned by a witness that refuses forks and replays. Built and tested, not yet running.

In development

Not for sale yet. A renewal service and any multi-year retention commitment wait until the engine archive suite is wired and through certification.
08 Honest claims

What you can repeat to your board, and what you cannot.

Honest today
  • Per-action receipts signed at origin, hash-chained and verifiable offline (Website Maker receipts: in production).
  • A hybrid Ed25519 + ML-DSA-65 issuer, both legs required: in development.
  • A CycloneDX 1.6 CBOM of the engine stack, with a drift gate.
  • Hybrid key exchange with classical authentication on a DCS staging edge.
  • A migration control plane on staging, in development.
Not yet
  • "Post-quantum secure everywhere."
  • "Production post-quantum key management."
  • "PQC migration service" as a live offering.
  • "Hybrid TLS in production."
  • Certification, or anchored migration evidence.
09 Working with an enterprise

Start with one slice of your estate.

STAGE 1

Briefing

A closed session on the control plane, the pilot records and the honest state of every layer.

STAGE 2

Verify it yourselves

Your team checks sample receipts and a bundle offline with the public verifier, on your own machines.

STAGE 3

CBOM ingest and signed diff

Bring CycloneDX exports from the scanners you already run; receive a signed, digest-bound inventory and a diff when the estate changes.

  • Design partnership, limited slots
STAGE 4

One migration slice

A transport or signing-path slice on your estate, with a before/after CBOM diff, log inclusion, a witness and an offline verifier for your assessor.

  • Planned
10 Questions

From CIO and CISO teams.

Is this a migration service we can buy today?

No. The only offer today: Cryptographic inventory and change evidence (CBOM + before/after diff) — design partnership, limited slots. No customer migration has been recorded, and we do not claim one has.

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, with the tool, version and scope.

Does it cover cloud and SaaS, not just our own data halls?

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. The Connector OS path is target state today.

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.

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.

If a key is revoked, are its old receipts invalid?

Not automatically. The historical verifier reports integrity and key status separately. A receipt signed before the revocation, outside the affected range, verifies with the note "revoked after signing".

Does this make us compliant?

No. A receipt is evidence of what happened. It supports your controls and your answers to an assessor; it does not declare compliance, and no certification is claimed.

Migrate once. Prove it forever.

Every cryptographic change on your estate, from inventory to close, as signed evidence you can hand to a board, an auditor or a regulator, and let them check for themselves.

In development — talk to us about a design partnership.

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