OT / IoT · PQC migration line

Plants that outlive their cryptography.

Refineries, dams, grids and desalination plants run PLCs, RTUs and telemetry on classical cryptography that will be in service for decades. This line is designed to migrate those estates to post-quantum protection through a DCS OT Gateway, and leaves a receipt for every step a regulator can check.

See the gateway
Line stateIn development
Public claimNone yet
01 What this line is

The third programme on the R-Series engine.

Post-quantum migration and verifiable trust for operational technology: industrial control, utilities, telecom edges and fleets of constrained devices.

In OT, cryptography is built into hardware that stays in service for ten to twenty years. It cannot be re-flashed on a browser's update cycle. Many controllers cannot be patched at all. The migration order names OT/IoT as the second phase of the PQC programme. It now has its own roadmap because it needs a hardware track, a gateway profile and a field pilot that neither the PQC Migration lane nor R+13–R+15 contain.

The line uses what R-Series already provides: the S1 engine, the S2 universal receipt, R+13 migration evidence, R+14 key lifecycle and R+15 long-horizon evidence. It builds the gateway, device onboarding, the firmware-signing workflow, discovery for OT estates and the reference hardware.

It never builds cryptography. The gateway calls the engine, and firmware signing runs through the engine's custody path. DCS migrates existing estates. It does not fabricate devices or boards. The gateway runs on the customer's industrial PC or on an off-the-shelf industrial SBC.

02 Why now

Regulators now name OT explicitly.

OT estates migrate more slowly than anything else, so they are the first that need evidence the migration has started.

UNITED STATES · NSA

CNSA 2.0

A transition schedule for national-security systems that names stateful hash-based signatures (LMS, XMSS) for software and firmware signing, and ML-KEM-1024 and ML-DSA-87 for the rest.

FRANCE · ANSSI

Hybrid, not a swap

ANSSI strongly recommends hybrid constructions during the transition (a post-quantum algorithm combined with a well-studied classical one) and requires them for products seeking its security visa; hash-based signatures such as LMS, XMSS and SLH-DSA are exempt.

EUROPEAN UNION

Coordinated roadmap

Member states have a coordinated implementation roadmap that puts critical infrastructure and high-risk use cases first.

INDIA · DST TASK FORCE

CBOM for critical sectors

The national task force report (archived copy) names strategic agencies as urgent adopters and recommends a cryptographic bill of materials (CBOM) for critical sectors (a recommendation, not a mandate).

INDIA · CERT-IN

BOM guidelines v2.0

CERT-In's bill-of-materials guidelines include a cryptographic BOM: an inventory of the algorithms, keys, protocols and certificates a product uses. Following them means being able to say which algorithms each device and firmware image uses.

GULF + INDIA ESTATES

Decade-long cycles

Refineries, desalination plants, dams and pipelines run PLCs, RTUs, gateways and remote telemetry on classical cryptography, and their replacement cycles run to decades.

THE REAL EXPOSURE · 1

Harvest now, decrypt later, on telemetry

The risk does not start the day a quantum computer exists. Telemetry, VPN sessions and credentials crossing a WAN today can be recorded now and decrypted later. Anything in them that stays sensitive is already exposed.

THE REAL EXPOSURE · 2

Firmware keys that outlive the algorithm

A firmware-signing key issued today is trusted by devices that will still run in twenty years. If that signature can be forged later, an attacker can push firmware those devices will accept. This is why firmware signing needs hash-based signatures.

Vendors sell a box or a scanner. Nobody sells migrate, verify, receipt and preserve across a device's twenty-year life.

03 Architecture

Estate → gateway → control plane → backbone.

OT architecture01 / 04
01 · OT ESTATE

PLCs, RTUs, sensors, HMIs, historians, remote sites.

Devices keep the protocols they already speak. Where a device cannot change, it is not changed: a legacy controller that cannot migrate is fenced, not replaced.

02 · DCS OT GATEWAY

Software on reference hardware, with no cryptography inside.

The gateway taps the cell network, carries device identity, relays signed firmware, bridges classical transport to a PQ-hybrid uplink and produces CBOM fragments. Every cryptographic operation is a call to the R-Series engine (S1).

  • Device identity only through the engine's custody path
  • Hybrid uplink: X25519MLKEM768 on the WAN side
03 · R-SERIES CONTROL PLANE

Discover → assess → plan → migrate → dual-run → verify → receipt.

The same R+13 state machine used for IT estates runs here. Old and new transports run side by side on the gateway until the new one is proven, and each step closes with a receipt.

04 · R-SERIES BACKBONE

Receipts, keys and epochs, archive, anchoring.

Receipts land in the transparency log. R+14 records which key was valid and when. R+15 keeps the evidence verifiable after the algorithms that signed it are retired.

04 Trust boundary

The gateway is a consumer, not a cryptographer.

No DCS component contains cryptography. The engine is the only trust boundary.

The gateway holds a device identity only through the engine's custody path, never as raw key material in gateway code. The TPM authenticates the gateway, and S1 signs the receipts. Secure-element provisioning is a ceremony, and it produces its own receipts.

Each OT receipt binds the device identity (committed, not revealed), the firmware image the device runs, the gateway policy in force and the key exchange the uplink negotiated.

In development

05 Workstreams

Eight workstreams, one line.

Discovery for OT estates, the gateway profile and onboarding, the transport bridge, the firmware-signing workflow, migration evidence per device class, reference hardware and a bench, a field pilot, and a certification path.

In development

06 Pilots

Four pilots, each proving one thing.

BENCH

Onboarding → receipt → migration

On the bench and the reference gateway: onboarding, a receipt, migration of the gateway WAN transport, and a transition receipt. All of it verifiable offline.

Planned

FIELD, READ-ONLY

A real estate, observed

One site, telemetry only, run in shadow mode. It produces a discovery CBOM of a real estate and receipts for the observed state, with no change to the site.

Planned

FIELD MIGRATION

A real migration step

On the same site, the gateway transport and one credential class are migrated, with dual-run and a rollback drill. The result is evidence a regulator can verify.

Planned

LONG-LIFE

Evidence that survives

The pilot evidence is archived under the R+15 profile and put through a renewal rehearsal, to show it survives an algorithm change.

Planned

07 Order of work

Bench first, then a named pilot, then a field site.

Every step is proved on a physical bench before any site sees it. A field pilot follows only with a named partner: one site, one device class, one protocol, read-only first. Any step stops if it would need cryptography outside the engine, a write to the PLC, or a fence around a safety function.

08 Honest claims

What we will say, and when.

The line is sold as "OT migration with evidence": discovery and CBOM first, gateway and credentials second, device replacement planning third. It is sold through the migration programme, not as a box.

TODAY Nothing beyond the engine's own claims
AFTER THE BENCH PILOT

"A DCS gateway on a bench migrated its WAN transport to a PQ-hybrid suite and produced a third-party-verifiable transition receipt (staging, not yet through certification, unanchored)."

AFTER THE FIELD MIGRATION PILOT

"A real site's gateway transport and one credential class were migrated with receipted dual-run and rollback."

NEVER until the specific evidence exists

Any claim that the OT estate is quantum-proof, that devices are post-quantum, or that anything carries a certification.

09 Questions

From plant and security engineers.

Do we have to replace PLCs or RTUs?

No. The line migrates around existing devices. The gateway carries the post-quantum transport and the evidence, and a device that cannot migrate is fenced behind the gateway. Device replacement planning comes third, after discovery and the gateway layer.

Will the gateway ever write to our controllers?

No. The bench requires zero PLC writes by the gateway, and any step that would need a write to the PLC stops. Field work starts in read-only shadow mode.

Do you scan our control network?

Not actively. Discovery is passive on control networks. Whether active TLS/SSH probes may run on a customer's non-control segments is still open.

Is anything post-quantum protected today?

No OT claim is made today. The engine's hybrid Ed25519 + ML-DSA-65 issuance is release candidate 4, running on staging. Full post-quantum protection along the whole path is not claimed, and the OT line is in development.

Does DCS build its own devices?

No. DCS does not fabricate devices or boards. The DCS OT Gateway is migration software on reference hardware: an off-the-shelf industrial SBC with a TPM or secure element, or the customer's own industrial PC.

Does this carry an IEC 62443 certification?

No. The certification path maps evidence to IEC 62443, NIST SP 800-82 and CERT-In BOM as a reference only. No certification is claimed until an external assessor issues one.

One site. One device class. One protocol.

The first field pilot is deliberately small: read-only first, then the gateway's transport, with every step receipted.

Inside the gateway Firmware signing

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.