Device certificates, provisioned automatically
X.509 per device, rotated on a schedule, revoked when you say so. Zero certificate code on the device.
First boot, automatically authenticated
Every connected product needs device identity. The right answer is X.509 client certificates issued per device. The wrong answer is shared API keys flashed at the factory. Most teams pick the wrong answer because the right one is too much work.
SCADABLE issues a unique certificate to each device on first boot, signed against your organization root, stored in secure element or NVS depending on your hardware. Your device code does not touch certificate logic.
How rotation works
Certificates rotate on a schedule you set. 90 days by default. SCADABLE issues a new cert before the old one expires, the device picks it up over the next clean session, and the old cert is retired without dropping connections.
When a device is decommissioned or compromised, revoke from the console. The CRL propagates to the broker within seconds and that device is locked out.
The foundation everything else sits on
- OTA firmware updates are signed with the device certificate chain
- MQTT TLS uses the same cert for mutual authentication
- File uploads sign their requests with the device identity
- Audit logs in the console attribute every action to a specific device
Without losing your mind
If you've tried to do TLS on ESP32 by hand, you know the failure modes. Clock skew breaking validation, root certificates not flashing, mbedTLS allocator quirks. libscadable handles all of it. Clock sync, cert pinning, allocator hints. So you can ship secure devices without becoming a PKI expert.
Bring your fleet onto SCADABLE.
Connect a repo, leave with a fleet you can manage from your codebase.