// iiot trust platform · sovereign · air-gap

The trust platform for sovereign IIoT.

Hardware identity, local decision, autonomous action, air-gap. Four open and auditable layers — take one building block, several, or the complete stack.

See the demo console → What the platform can do Technical documentation

// platform telemetry

devices.enrolled412 policy.evals.local12 847 attestations.signed1 976 audit.entries8 402 satellites.online99.4 % stackEU / open

// demo data — demonstration bench

// snapshot · Île-de-France bench

▸Ops-Devices is the sovereign trust platform for the IIoT.

Trust-Buster is the first system built on it: ABAC access control with power cut-off satellites, deployed and operated on site. trust-buster.com ↗

// what the platform can do

Capabilities

Capabilities demonstrated on the bench.

Perceive: Passive RF detection (BLE / WiFi), presence correlation, mapping, electrical consumption signatures (NILM — corroboration only, never proof of identity).
Identify: Anchored hardware identity (enclave, IoT SAFE), mTLS attestation signed by the enclave, enrolment of legacy equipment without modifying it.
Decide: Policies evaluated locally, offline, against a signed manifest; anti-rollback through monotonic counters; no server call on the critical path.
Act: Power cut-off, flow filtering, trust proxy per interface (BLE, USB, Ethernet, serial, RS-485 / Modbus).
Prove: Signed audit log, append-only, non-repudiation, SIEM export (syslog / CEF).
Interoperate: Standard MQTT 5.0, REST / OpenAPI, webhooks, boundary adapters (CoT for defence).
Deploy: On-premise, full air-gap, or sovereign hosted; 3 form factors.

// 4 independent layers

Technical building blocks

Each layer is documented, versioned, and usable independently. You buy what is missing from your current stack — not a monolithic solution.

L1

Hardware

3 form factors (Cube, DIN rail, hardened IP68) · ESP32-S3 + secure component

Ready-to-use default firmware, public datasheets, electronic schematics on NDA request. The chain of trust is anchored in a secure component certified Common Criteria EAL5+ (enclave inherited from Tiempo Secure, via Sequans Monarch 2): the private key is generated there and never leaves it. The certification covers the component, not Ops-Devices.

MCU: ESP32-S3 / ESP32-C6
Cellular: Walter (Sequans Monarch 2, FR/BE)
Radio: BLE 5.0 + WiFi 6
Charging: Qi 5V + USB-C
Enclosure: 12 cm cube, IP not specified v1
Secure component: CC EAL5+ certified (Tiempo Secure)
Protocol: IoT SAFE (GSMA RP.25)
Private key: Generated in the enclave, never in RAM
Attestation: mTLS X.509 signed by the enclave, not firmware

L2

Firmware

Open-source ESP32 firmware, SDK, signed OTA via hawkBit

Apache 2.0, developed in Europe, auditable, reproducible build. Configurable profiles (alert, gateway, control). Adapt the MQTT payloads to your constraints, add your own detection heuristics.

Licence: Apache 2.0
Framework: ESP-IDF v5.1+
MQTT: 5.0 + mTLS X.509 (TLS 1.3)
OTA: Ed25519-signed, hawkBit
Security: AES-256-GCM, ECDH/HKDF
Anti-rollback: Monotonic counters in the enclave

L3

Backend & API

MQTT ingestion, policies, signed log, REST + webhooks

Python asyncio + PostgreSQL/TimescaleDB. REST API documented with OpenAPI, MQTT webhooks, ProtoBuf ingestion. Self-hostable on-premise (air-gap possible) or sovereign hosted. The platform distributes the policies; it never takes part in the decision.

Stack: Python 3.12 + asyncio
DB: PostgreSQL + TimescaleDB
Broker: EMQX 5 (MQTT 5.0) — demo
Sovereign broker: HiveMQ / VerneMQ / Mosquitto
API: REST OpenAPI + webhooks
Export: SIEM syslog / CEF
Deployment: Podman / Docker / on-prem / air-gap

L4

Supervision console

SvelteKit frontend + Three.js 3D cube — real-time supervision

Open-source, customisable (logo, colours, faces, labels). Admin dashboards, message inbox, multi-cube, RF mapping. Deployable under your own brand (OEM / white-label option).

Stack: SvelteKit 2 + Tailwind 3
3D: Three.js
Auth: OIDC (LemonLDAP, Keycloak…)
i18n: FR / DE / IT included
Licence: Apache 2.0 + OEM agreement

// architecture

One anchor, many satellites.

The anchor sits away from the equipment it protects, and it protects several of them: it is never wired directly to any one of them. The Cube is the trust anchor and the decision point of a zone. The satellites enforce, one per interface. The Cube never delegates authority: it issues signed ephemeral capabilities, with a limited lifetime and bound to the context. It never trusts a satellite — it verifies.

Controlled interface	Satellite	Role	Status
230 V power supply	Shelly (hardened stock firmware, detached input)	Cut-off / authorisation of a piece of equipment	● Demonstrator
BLE peripherals	BLE proxy	Keyboard, mouse, wireless peripheral	● Roadmap
USB bus	USB-HID filter — STM32H7 (two USB cores)	USB keyboard — reference case for the full flow	● Roadmap
Wired network	Ethernet gate	OT segment	● Roadmap
Serial interface	Serial gateway — STM32 + isolated ST3485E	Legacy Modbus RTU PLC (RS-485 / RS-232)	● Roadmap

The power satellite, in detail

This is the only satellite in operation. The Cube delegates no authority to it: it issues a signed ephemeral capability with a short TTL, and verifies its state.

Hardware: Shelly (Allterco, Bulgaria — ISO 27001)
Firmware: Stock firmware, hardened — no reflash
Input: Detached input — the button signals, the relay obeys only the Cube
Disabled: Cloud, BLE, schedules, webhooks
On boot: Power-on OFF state (fail-closed)
Link: MQTT over mTLS, authenticated web interface
Interlock: Upstream measurement (Pro 1PM, DIN rail) vs downstream (Plug S)
Bench: 2× Plug S Gen3, 1× Pro 1PM, 1× EM Gen3, 1× Plus i4 DC
Portability: Plug S Gen3 = ESP32-C3: the Cube's firmware cannot be ported to it

On the satellites, the sovereignty is real

The satellites need no radio: the Cube's ESP32 compromise disappears there. They are built on STMicroelectronics (French-Italian) — STM32 MCU and STSAFE-A120 secure element, certified Common Criteria EAL5+. The enforcement points, in contact with the critical equipment, therefore have a European hardware root of trust — which the Cube v1 does not have, its enclave having passed under Qualcomm control. The STSAFE-A120 validated on the satellites is the candidate for the Cube v2.

Tamper / self-healing loop

Detection of a satellite reset (reappearance of the default AP, MQTT LWT) → fail-closed lockdown of the zone → authenticated re-enrolment with evil-twin protection. A differential current interlock (upstream vs downstream measurement) flags a physical bypass.

The first system built on this pattern

We started with ABAC access control with a power cut-off satellite — that is the Trust-Buster system, deployed and operated on site. The same pattern extends to BLE, USB, Ethernet and serial.

→ trust-buster.com ↗

// authorisation

The ABAC model — three questions never merged

Contextual authorisation: subject × resource × place × time slot, against a signed manifest.

Factor	Question	Mechanism	Security status
Presence	Where — who is probably there?	RSSI co-presence of enrolled devices	Gate — necessary, never sufficient
Identity	Who — is it really them?	Cryptographic challenge-response (smartphone secure element ↔ Cube enclave)	Proof
Entitlement	What — are they allowed, here, now?	Manifest signed by the authority: scheduled activity (day, place, resource), TTL	Right

Golden rule

The RSSI says “they are there”; the crypto says “it really is them”. A physical actuation is never conditioned on the passive factor alone. The NFC badge is a proximity pointer — it designates who to challenge — not proof of identity.

Authorisation machine

1 · REQUEST Detached satellite input (button press) → request to the Cube. The button never actuates the relay directly.
2 · GATE Co-located RSSI presence of at least one candidate enrolled user → otherwise rejection: nobody plausible in the zone.
3 · PROOF Challenge from the Cube → response signed by the smartphone's secure element (nonce bound to the context: resource, zone, window).
4 · RIGHT Signed manifest verified: scheduled activity, this day, this place, this resource; TTL not expired; monotonic counter (anti-rollback).
5 · CAPABILITY Issuance of a signed ephemeral capability to the satellite concerned.
6 · EXECUTION The satellite executes; the Cube logs (signed log, append-only). Any failed step → rejection logged with its reason.

Air-gap: compensating for the absence of real-time revocation

Short TTLs on the manifests (expiry replaces revocation), monotonic counters in the enclave (policy anti-rollback), context-bound nonces in the challenge-response.

// our approach to sovereignty

Why an ESP32 in a stack that calls itself sovereign?

[01] The ESP32 (Espressif) is not a European MCU — why choose it? ▶

Because it is today the only mature open-source ecosystem with BLE 5 + WiFi 6 + radio coexistence at this price. Forcing an EU MCU into v1 would double the hardware cost and delay the product by 18 months. We own it and we document it: the supply chain risk sits on the silicon layer only, not on the firmware (open-source, EU) nor the platform (self-hostable on-prem).

[02] Which European alternative are you working on? ▶

An STM32WB variant (STMicroelectronics, FR/IT) + a European RF module, planned for v2.0 (Q4 2027). For customers requiring a 100 % EU supply chain with no concessions, this variant will be available with an acceptable degradation of radio coexistence (BLE 5 without simultaneous WiFi).

[03] And the Walter module (LTE-M)? ▶

Walter is designed and manufactured in Belgium by DPTechnics, based on a Sequans Monarch 2 modem (FR). EU supply chain on the cellular layer — useful to demonstrate sovereignty on the critical uplink.

[04] And the cloud platform / the data? ▶

OVHcloud France (Roubaix datacenter). PostgreSQL + TimescaleDB, Mosquitto, LemonLDAP::NG (FR), Garage S3 (Deuxfleurs FR). No US hyperscaler dependency. All data stays in the EU, and the KMS is under your control on-prem if you wish. In air-gap, no data leaves the site.

[05] Can the firmware be audited before deployment? ▶

Yes. The firmware is open-source (Apache 2.0), reproducible build, signed releases. You can audit every line, or have it audited by a third party. That is a decisive argument against the proprietary firmware of the major manufacturers.

[06] Your EAL5+ secure component — what does it actually change? ▶

The device's private key is generated directly inside the enclave (Tiempo Secure IP, via Sequans Monarch 2). It never reaches RAM or ESP32 flash. An attacker who compromises the firmware cannot extract it. Every mTLS handshake is signed by the enclave — not by the host SoC. This is what the GSMA IoT SAFE standard formalises. Two honest clarifications: the Common Criteria EAL5+ certification covers the component, not Ops-Devices; and EAL5+ is NOT the highest level on the scale (it goes up to EAL7). To our knowledge, no European player offers this combination on this segment.

[07] Why EMQX, given that the vendor is Chinese? ▶

EMQX is used on the demonstration bench for its maturity and its clustering performance. For defence contexts or those requiring maximum sovereignty (ANSSI compliance, classified perimeters), we deploy HiveMQ (DE), VerneMQ or Mosquitto (Eclipse Foundation, open source). We only use standard MQTT 5.0, with no proprietary extension, precisely in order to remain portable. The choice of broker is documented in the HBOM of each deployment and does not touch the cryptographic chain of trust.

[08] Do you provide an SBOM and an HBOM? ▶

Yes. Our SBOM (Software Bill of Materials) is generated in CycloneDX 1.6 format and covers every firmware dependency (ESP-IDF, mbedTLS, esp-mqtt) and backend dependency (Python, PostgreSQL, broker). Our HBOM (Hardware Bill of Materials) documents each physical component with its manufacturer, country of design, country of foundry and sovereignty level, per IPC-1752A and NIST SP 800-161. These documents are available on NDA request, and included in the CRA compliance file delivered with every deployment.

[09] Tiempo Secure was acquired by Qualcomm — what happens to your sovereignty? ▶

Qualcomm acquired Tiempo Secure and Sequans' 4G IoT assets: the enclave IP is now under US control. Our sovereignty is therefore operational and by design: no foreign cloud, no remote kill-switch, full air-gap, European design and integration. We do not claim a 100 % European IP. The Cube v2 roadmap targets a discrete secure element with European certification (ST, Infineon, NXP). This is not merely an intention: our satellites — the enforcement points in contact with the equipment — are specified around the STSAFE-A120 (STMicroelectronics, CC EAL5+), a genuinely European hardware root of trust. We validate it there first, then we port it to the Cube.

[10] What can't you do? ▶

We do not measure physical distance: no distance bounding, and BLE 6.0 Channel Sounding is not available on our current hardware. A relay (wormhole) attack therefore remains possible. We detect and trace it — signed log, correlations, differential current interlock — but we do NOT claim to block it. The only hard preventive lever remains the power cut-off. This is documented in our threat model, along with the other residual risks.

// compliance

Compliance, backed by evidence

Designed according to IEC 62443-4-2, with an architecture aligned on foundational requirements FR1 to FR7. Design target: SL-C 2 (industrial).

⚠ Third-party evaluation not yet performed. We display no SL level as achieved: an SL-C requires a third-party evaluation that we do not have.

IEC 62443 mapping — foundational requirements

Requirement	How the architecture answers it
FR1 Identification & authentication	Hardware identity in the enclave, challenge-response smartphone secure element ↔ Cube, mTLS X.509 attestation signed by the enclave.
FR2 Use control	ABAC authorisation against a signed manifest (subject × resource × place × time slot), short TTLs, ephemeral capabilities per satellite.
FR3 System integrity	Ed25519-signed OTA, anti-rollback through monotonic counters in the enclave, open-source firmware with reproducible build.
FR4 Data confidentiality	mTLS (TLS 1.3), AES-256-GCM, ECDH/HKDF. Private key generated and kept in the enclave, never exposed in RAM.
FR5 Restricted data flow	Local decision, no server call on the critical path, full air-gap possible. The satellites hold no permanent authority.
FR6 Timely response to events	Signed append-only audit log, satellite tamper/reset detection, fail-closed zone lockdown, SIEM export (syslog / CEF).
FR7 Resource availability	Offline operation by design, power-on state OFF, authenticated re-enrolment after an incident.

Residual risk register — published

Risk	Posture we own
Relay / wormhole (BLE)	Unsolvable on the current hardware (it would require BLE 6.0 Channel Sounding). Detective posture: detection + attribution, no prevention claimed. Only hard preventive lever: the power cut-off.
Physical access / teardown	Prolonged physical access makes it possible to destroy the hardware. The teardown is detectable — it destroys the tamper-evidence proof — but it cannot be prevented.
Denial of service through fail-closed	The fail-closed posture can be exploited to force a shutdown. A choice we own: in case of doubt, the equipment stops.
Silicon supply chain	ESP32 (Espressif) and the enclave IP now under Qualcomm control. Publicly documented (SBOM / HBOM), never concealed.

CRA positioning

SBOM CycloneDX 1.6, HBOM IPC-1752A / NIST SP 800-161, documented threat model (STRIDE), published residual risk register. Compliance file delivered with every deployment.

// r&d log

The alternatives we rejected

Every structuring decision is recorded with the rejected alternative and the reason for it.

Rejected	Chosen	Reason
Sonoff	Shelly (Allterco, BG, ISO 27001)	Natively local-first, detached input, DIN rail variants, EU origin, MQTT over TLS.
Reflashing the satellites	Hardened stock firmware + lockdown profile	Shelly's OTA is ECDSA-signed; a UART teardown would be destructive and would destroy the tamper-evidence proof.
Mongoose OS	Hardened Shelly stock firmware	Obsolete, predates ESP32-C3 support.
RSSI alone as authorisation	Triptych presence + identity + entitlement	Spoofable by relay, ineffective under MAC randomisation. The RSSI remains a gate, never a proof.
The NFC badge as proof of identity	Badge = proximity pointer	Clonable, no challengeable secret.
NILM as proof of equipment identity	NILM = corroboration only	Load signatures are not conclusive.
Permanent authority delegated to the satellites	Signed ephemeral capabilities issued by the Cube	Internal zero-trust: verify, never believe.
Claiming anti-relay prevention	Detective posture + attribution	The wormhole is unsolvable without BLE 6.0 Channel Sounding. To be reassessed on the move to BLE 6.0.
Presenting EAL5+ as an Ops-Devices certification	Always “inherited from the component”	Technical honesty: over-claiming is paid for in due diligence.
The RF scan as a barrier to entry	The IoT SAFE integration layer	Passive scanning is reproducible in a few weeks. The real lead is in the integration of the chain of trust.
ESP32 for the satellites	STM32 (ST, FR/IT)	A satellite needs no radio: the compromise that forces the ESP32 onto the Cube no longer applies. A 100 % European chain becomes possible.
A non-European secure element (Microchip ATECC)	STSAFE-A120 (ST, CC EAL5+)	A genuinely European hardware root of trust on the enforcement points — and the Cube v2 candidate.
A single USB controller (OTG) for the HID proxy	STM32H7 — two independent USB cores	OTG switches roles: it cannot be host and device simultaneously. A keyboard proxy requires both.
A non-isolated serial satellite	Galvanic isolation of the data and of the power supply	An OT bus is noisy (common-mode of several hundred volts): without isolation, intermittent failures and hardware risk.

Product catalogue

We are at demonstrator stage.

Level 1 — Form Factors (hardware)

Ref.	Designation	Status
OPS-FF-CUBE	Interactive light cube — 12 cm, NFC, RGB LEDs, Qi+USB-C	● Demonstrator
OPS-FF-DIN	35 mm DIN rail enclosure — 24V DC, RS-485, IP20, industrial	● Roadmap
OPS-FF-HARD	Hardened waterproof enclosure — IP68, field / outdoor	● Roadmap

Level 2 — Software profiles (per Cube)

Ref.	Designation	Status
PROFILE-ALERT	Alert-only mode — non-intrusive, zero infrastructure change	● Demonstrator
PROFILE-GW	Network gateway mode — active cut-off of unauthorised flows	● Roadmap
PROFILE-CTRL	Direct control mode — ABAC + actuation satellite	● Demonstrator

Level 3 — Platform (subscription)

Ref.	Designation	Status
OPS-PLATFORM-EDGE	On-prem / air-gap licence — no cloud connection required	● Roadmap
OPS-PLATFORM-SAAS	Sovereign hosted — OVH France, multi-site, REST API	● Demonstrator
OPS-PLATFORM-OEM	White-label — rebrandable console, royalty, dedicated support	● Roadmap

Level 4 — Satellites (enforcement points)

Ref.	Designation	Status
OPS-SAT-PWR	230 V cut-off — hardened stock Shelly, detached input	● Demonstrator
OPS-SAT-485	Serial gateway RS-485 / RS-232 — STM32 + isolated ST3485E + STSAFE-A120	● Roadmap
OPS-SAT-HID	USB-HID filter — STM32H7 (two USB cores) + STSAFE-A120	● Roadmap

Legacy references (OPS-CUBE-S3, OPS-WLT-*, OPS-RF-CORE, OPS-MAP-SAAS…): reclassified into this architecture. Mapping table in the technical documentation, on NDA request.

Engineering principles

Open-source: Open stack (Apache 2.0), auditable, reproducible build. No black box.
Sovereignty: EU hosting, European design and integration. Documented supply chain (SBOM / HBOM) — limits included.
Local decision: The policy is evaluated on the Cube, offline. No server call on the critical path, full air-gap possible.

// segment rule

Which channel for which need?

Critical situations — dangerous equipment, sensitive perimeter, binding compliance, legally admissible traceability — are handled as an operated service by Trust-Buster: hardware deployed and operated on site. → trust-buster.com ↗

Automation needs and standard deployments go through the platform and its network of integrators and resellers.

// distribution & oem

Distribution, resellers, OEM

You build your stack on our building blocks, you deploy at your customers' sites, or you offer the platform under your own brand.

Discovery

Free

Evaluate the stack before committing

▸ Access to the complete technical documentation
▸ 1 demo probe loaned for 30 days
▸ Demo console with a test account
▸ Email support (reply within 5 working days)

Authorised reseller

Framework agreement

Deploy our building blocks at your customers' sites

▸ Tiered hardware volume pricing
▸ 2-day technical training (Paris or remote)
▸ Product roadmap shared quarterly
▸ Priority support (SLA 1 working day)
▸ "Authorised reseller" logo on your website

OEM / White-label

Tailored

Offer our building blocks under your brand

▸ Platform under your brand (front + console)
▸ Hardware co-branding (sticker, packaging)
▸ Quarterly technical committee
▸ Contractual SLA commitment
▸ Fixed royalty or percentage depending on volume

Discuss your case See the technical documentation

// technical contact

Evaluate the platform, or become a partner.

Describe your technical need: which building blocks, which integration, what target volume. Technical documentation, datasheets, SBOM / HBOM and threat model available under NDA. We get back to you within 5 working days.

Email contact@ops-devices.eu

Platform ops-devices.eu

Operated system trust-buster.com ↗

Hosting OVH France