Industries · Telecom & networks

Every hop sealed. Every change signed.

Networks carry other people's secrets for decades and change their own configuration every day. R-Series brings hybrid post-quantum key exchange to the network edge and gives every configuration change in the core a signed receipt: who changed what, on which device, under which approval.

Follow one config change Hybrid at the edge

Key exchangeX25519MLKEM768

Staging edgeIn development

Receipt signatureEd25519 + ML-DSA-65

StatusIn development

00 Why networks are different

The longest-lived traffic, on the most-changed systems.

A network operator is exposed twice: through what it carries, and through what it changes.

Backbone and access networks carry traffic whose value outlives the cryptography protecting it. Anyone who records encrypted traffic today can store it and wait. That is the harvest-now, decrypt-later risk, and it applies to the key exchange that opens every session, not to the bulk cipher.

At the same time, the network itself is in constant motion. Routers, firewalls, VPN concentrators and TLS terminators are reconfigured by engineers, scripts and, increasingly, by AI agents. When an outage or a security incident happens, the first question is the same every time: who changed what, and who approved it? Today the answer is assembled from change tickets and device logs that the investigated party controls.

R-Series addresses both halves. At the edge, sessions move to hybrid key exchange (X25519 combined with ML-KEM-768, the X25519MLKEM768 group) through standard TLS stacks. In the core, each configuration change becomes a receipt: signed with Ed25519 and ML-DSA-65, chained to the change before it, and checkable offline by an auditor or regulator without access to the operator's systems.

Underneath sit the layers that make a migration provable: a cryptographic bill of materials (CBOM) of the estate, migration evidence for every step (R+13), and a key registry that says which key was valid when (R+14).

Traffic captured today can be read tomorrow. A change made today must still be provable.

01 Harvest now, decrypt later

The risk is already in the recordings.

A quantum computer that can break today's key exchange does not need to exist yet for today's traffic to be at risk. It only needs to exist before the data stops mattering.

01 · CAPTURE

Recorded at a tap, stored cheaply

Encrypted sessions crossing a backbone, an interconnect or a submarine landing can be copied in bulk. Nothing breaks and nothing alerts; the ciphertext simply waits.

02 · THE WEAK POINT

The handshake, not the cipher

Session keys agreed with classical elliptic-curve or RSA key exchange can be recovered by a large enough quantum computer. Recover the key and the recorded session opens.

03 · THE FIX

Hybrid key exchange now

Combining X25519 with ML-KEM-768 means a recorded session stays closed unless both are broken. It is a transport change, done through standard stacks, with no home-made combiner.

Traffic class	Why its lifetime matters	Where hybrid key exchange goes first
Interconnect and backbone sessions	Aggregated traffic from many customers; one recording holds a great deal	TLS and VPN at the edges that terminate them
Management plane	Credentials and configuration in transit expose the network itself	SSH and API access to network devices
Enterprise and government customers	Their data may need to stay confidential for a decade or more	Customer-facing TLS edges and managed VPN
Signalling and subscriber data	Identity and location data with long sensitivity	Assessed per interface through the CBOM; no claim made here

What hybrid key exchange does not do. It protects confidentiality of new sessions. It does not make an old recording safe, and on our own edge the authentication stays classical (ECDSA P-256) for now. We describe this as hybrid key exchange, never as a post-quantum-secure network.

02 One configuration change, end to end

Propose, approve, apply, sign.

Scroll through the four moments that turn a router change in the network core into evidence that someone outside the operator can check.

Network operations core01 / 04

01 · PROPOSE

A change is declared before it is made.

An engineer, a script or an agent proposes a change to a core router: here, adding the X25519MLKEM768 group to a TLS policy. The proposal names the device, the intent and the change ticket, and fingerprints the configuration as it stands.

Who proposed it: a person, a tool or an agent, each with its own key
Target device recorded as a commitment, not a raw hostname

02 · APPROVE

Held until two people sign.

Above the policy threshold the change waits. Two named approvers sign, and the approval is itself a receipt recording the policy version in force. Approvals are time-limited: they lapse rather than linger.

Approval kind with scope and expiry, as in R+13
A missing or expired approval is visible, not silent

03 · APPLY + DUAL-RUN

Old and new run side by side.

The configuration is pushed. For a defined window both paths serve or shadow traffic, divergence is counted, and a downgrade check confirms peers are not falling back to the classical path. If it fails, the rollback is signed too.

Configuration hash before and after the change
Degraded handshakes receipted, not dropped

04 · SIGN + CHAIN

The receipt joins the chain.

The change closes with a receipt signed by Ed25519 and ML-DSA-65, linked to the change before it. An auditor holding the public key and the chain can replay the sequence offline and see any insertion, removal or edit.

Both signatures must verify; there is no "mostly valid"
Bundles stay labelled unanchored until the anchor proof lands

03 Inside a configuration-change receipt

Who, what, where, under which approval.

A receipt is small, structured and signed. These are the parts that matter to a network operator, built from fields that already exist in the receipt core and in R+13.

Part	What it holds	What it lets you prove	State
Actor	The engineer, tool or agent that made the change, by key	Attribution that does not depend on a shared admin account	In development
Intent + ticket	The declared purpose and the change ticket it belongs to	The change was the one that was asked for	In development
Target	A commitment to the device, not its raw hostname	Which device changed, without exposing topology in the receipt	In development
Config before / after	Hashes of the configuration on each side of the change	Exactly what changed, and that nothing else changed with it	Planned
Approval	Approver commitments, policy hash, scope and expiry	Four-eyes happened before the push, under that version of the rule	In development
Dual-run + downgrade	Window, divergence count, downgrade check, rollback	The new path behaved, and nothing slipped back to classical	In development
Chain parent	The previous receipt for the same device or workflow	The change history can be rebuilt in order, with gaps visible	In development
Hybrid signature	Ed25519 + ML-DSA-65 over one canonical (dCBOR) pre-image	Integrity and origin today, and after classical signatures weaken	In development
Anchor	Merkle inclusion and an external anchor	The record existed then and was not inserted later	Planned

Honest gap. There is no network-specific receipt profile yet. Profile schemas exist under the unchanged core verifier; a configuration-change profile would be added the same way. The control actions on the critical infrastructure page, including configuration pushes, use the same pattern.

04 Hybrid at the network edge

X25519MLKEM768 through standard stacks.

The edge is where post-quantum migration starts for a network: the TLS terminators, VPN concentrators and management interfaces that open sessions. R-Series does not ship a home-made handshake or combiner. Key exchange runs through standard TLS stacks, with known-answer tests on both OpenSSL and Go.

On our own edge, a watcher receipts every handshake, including degraded ones where a peer fell back to classical. Authentication remains classical. This work is in development.

Client hello→X25519 + ML-KEM-768 shares→Hybrid session key→Watcher receipts handshake→Peer not ready → degraded, receipted

Network surface	Adapter	Real state
TLS edge	Edge policy + key-exchange telemetry	In development Key exchange hybrid, authentication classical
SSH (device management)	Probe	Planned The cheapest second in-path slice
VPN	Feasibility note	Planned WireGuard with a post-quantum pre-shared key, proposed
API authentication	None yet	Planned Second transport pilot on an API surface
Service mTLS	None yet	Planned After TLS and API
PKI	None yet	Planned Following Merkle Tree Certificates
Code and firmware signing	None yet	Planned ML-DSA under KMS custody; LMS needs an HSM that holds signer state

05 CBOM for a network estate

An inventory is not a migration.

But a migration claim means nothing without one.

In development

Cryptography in a network estate hides in places nobody wrote down: TLS terminators, VPN concentrators, management interfaces, HSM partitions, firmware, and libraries several dependencies deep. Many tools now find it. R-Series does not add another scanner.

Instead, one CycloneDX 1.6 ingest takes scanner output, runtime inventory and probes, from our tools or the tools an operator already runs, and labels each record with the tool, its version and the scope it covered. What was not scanned is declared in a signed scope statement, so absence of evidence is never reported as evidence of absence.

The CBOM hash is signed into the migration plan before anything changes, after every step and at the end. The diff is occurrence-aware: the same algorithm on two devices counts twice, so fixing one does not hide the other.

Honest status: our own engine CBOM is good (schema-validated, drift-checked in CI), but it is not yet a product-scope CBOM with occurrence evidence of which service uses which algorithm. An earlier recorded fixture diff measures a change of scope, not a migration, and we do not present it as one.

06 SIM, eSIM and network PKI

Which key was valid, on which device, then.

Networks run on keys: device certificates, subscriber credentials, signing keys for configuration and firmware. R+14 keeps a signed, append-only registry of key events, so a record signed years ago can still be judged against the registry as it stood that day.

GENERATE · ACTIVATE

Born under a custody class

Each key event records its custody class (HSM, KMS, software or research), a commitment to the ceremony and the witnesses. Activation opens the signing window.

ROTATE

Fleet-wide rotations on the record

A new key supersedes an old one, and a key can never supersede itself. Records signed under the old epoch stay valid under that epoch.

REVOKE · RECOVER

Revocation names what it affects

A revoke carries a reason class and the affected sequence range, so a compromised credential sweeps up only what it touched. Recovery closes the gap on the record.

Network key population	Where R+14 would apply	State
Receipt signing keys (operator-held)	Registry root and key epoch inside every receipt; historical verification	In development
Device and edge certificates	Lifecycle events for certificates used by TLS edges and management interfaces	Planned
SIM / eSIM provisioning keys	Provenance of key generation, rotation and revocation events as signed records	Planned
Configuration and firmware signing	Which signer key was valid when a configuration or image was signed	Planned

Read this table carefully. R-Series is not a SIM, eSIM or certificate-authority platform and does not provision credentials. The rows marked "design fit" describe where the R+14 record model applies; no integration with an operator's subscriber or certificate systems exists. On staging, receipt keys sit in a cloud KMS behind a key handle for both the Ed25519 and ML-DSA-65 legs. Production keys are created only after certification.

07 Honest claims

What we can say today, and what we cannot.

Networks are sold on reliability numbers. Evidence should be held to the same standard, so this is the exact line we draw.

HONEST TODAY

We can say

Hybrid key exchange with classical authentication on a DCS staging edge.
Every handshake on that edge, including degraded ones, is receipted.
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.
A migration control plane on staging, in development.

NOT YET

We do not say

"Post-quantum network" or "post-quantum secure everywhere".
"Hybrid TLS in production".
"Customer migrations completed". None have been recorded.
Any certification, or any named operator as a customer.
"Production post-quantum key management".

08 How an operator starts

Inventory first. Touch the edge last.

The path is built so that no live traffic changes until people at the operator say so.

STAGE 1

Briefing + inventory

A closed session, then your existing scanner exports enter through the CycloneDX 1.6 ingest, labelled by tool, version and scope.

STAGE 2

Shadow receipts

Configuration-change receipts minted alongside your existing change process, observe-only, for one device class.

Operator-held keys
No effect on live config

STAGE 3

Verify it yourselves

Your audit or security team replays the chain offline with the licensed verifier, on your own machines, with DCS switched off.

STAGE 4

One edge, receipted

A single TLS edge moved to X25519MLKEM768 through plan, approval, transition and close, with dual-run and downgrade checks on the record.

Planned

09 Questions

From network, security and audit teams.

Does hybrid key exchange make our network post-quantum secure?

No, and we do not say so. It protects the confidentiality of new sessions on the links that adopt it. Authentication on our own edge is still classical, recordings made before the change are not protected, and every other surface needs its own migration step.

Do you replace our TLS stack or VPN?

No. Key exchange runs through standard stacks, with known-answer tests passing on OpenSSL and Go. There is no home-made handshake or combiner. R-Series records the change and its evidence.

Does network traffic pass through DCS?

No. Receipts carry hashes and commitments, not traffic or full configurations. Control and user traffic never routes through DCS, and receipts verify offline.

Will a receipt expose our topology?

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

Can agents make configuration changes under this?

Yes, as actors with their own keys. The receipt records which agent proposed the change, under which policy, and who approved it, so an agent's change is held to the same evidence standard as an engineer's.

Do you support SIM, eSIM or certificate authorities?

Not as a product. The R+14 key registry is a record model for key events; it fits device and subscriber credential lifecycles, but no integration with subscriber or certificate systems exists today.

Has an operator migration been recorded?

No. The live evidence so far comes from our own staging edge. The first product migration waits on certification, and no customer migration has been recorded.

10 The network, on the record

Seal the hop. Sign the change.

Hybrid key exchange at the edge, a signed receipt for every change in the core, and an inventory that shows what actually moved. Built in stages, labelled honestly, checkable without us.

Book a briefing The migration programme

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.