The problem we solve
Most industrial IoT platforms call themselves secure. But their gateways decrypt everything.
The status quo is broken
In a typical industrial IoT deployment, sensors send data over a local network to a gateway. The gateway terminates the connection, decrypts the payload, and forwards it to the cloud. This means every gateway in your network has access to plaintext sensor data — temperatures, pressures, vibrations, production metrics, everything.
That single design choice creates a cascade of problems:
Every gateway is an attack surface
A compromised gateway exposes all sensor data flowing through it. Physical access to an edge device in a factory, warehouse, or remote site is often trivial.
Compliance scope explodes
If a gateway can read customer data, it enters scope for GDPR, industry audits, and breach notification — even if it adds no analytical value. More decryption points mean more compliance work.
Device identity is an afterthought
Most platforms generate keys in software, share them across devices, or verify identity only at the network layer. If a key can be extracted from firmware or cloned via JTAG, the entire identity model collapses.
Firmware updates are manual and risky
When OTA isn't built into the platform, updates become SSH scripts and hope. No rollback, no canary strategy, no verification that the new image actually boots.
How TrustKern fixes this
TrustKern takes a fundamentally different approach: the gateway never sees plaintext. Data is signed and encrypted on the sensor itself — in dedicated security hardware — and only decrypted inside a controlled cloud boundary.
Before: Gateway decrypts
Sensor → TLS → Gateway (plaintext!) → TLS → Cloud
TrustKern: Gateway is blind
Sensor (sign + encrypt) → Gateway (verify, forward ciphertext) → Cloud (decrypt)
Hardware-rooted identity
Every sensor has an ATECC608A secure element. The signing key is generated on-chip and never leaves the hardware — not visible to firmware, not extractable via JTAG, not shared across devices.
Gateway-blind forwarding
The gateway verifies signatures and enforces anti-replay, but it has no decryption keys. Even a fully compromised gateway cannot read sensor data. This removes it from your compliance boundary.
Controlled decryption boundary
Plaintext only appears inside infrastructure you control — EU-hosted, customer-managed, or fully self-hosted. You choose where decryption happens, not the platform vendor.
Safe OTA with rollback
Signed firmware images delivered via MCUboot. Test boot, health check, confirm or automatic rollback. Canary rollouts (10%) or full fleet. No manual SSH, no guesswork.
See it in action
Walk through the architecture, deployment models, and a live sensor-to-cloud demo.
Book a walkthrough