Firmware Security & OTA for Manufacturing & Automation
On an automation line the real attack surface is not the firmware logic, it is the unsigned image a contractor flashes over USB and the unauthenticated Modbus write that nobody logged. We secure the device itself: a hardware root of trust burned into eFuses, an OTA path that only accepts countersigned encrypted images, and a command layer that proves who issued each setpoint. The line keeps running, but it stops trusting anything it cannot cryptographically verify.
Challenges specific to Manufacturing & Automation
Unsigned firmware flashed by anyone with a cable
Without a hardware root of trust the bootloader runs whatever sits in flash, so a contractor's laptop or a swapped module can inject rogue firmware that looks identical to production on the HMI.
OTA images travel and rest in cleartext
When the update channel lacks signature verification and at-rest encryption, an attacker on the plant LAN can capture, clone, or substitute the image and push malicious logic to every identical controller on the line.
Downgrade re-opens patched vulnerabilities
A device that accepts any validly signed image can be rolled back to a known-vulnerable build, undoing a security patch while still passing every signature and version check the operator sees.
Setpoint writes have no authenticated origin
Flat OT protocols let any host on the segment write a speed, recipe, or actuator command, so a compromised engineering workstation can drive the process with no proof of who issued the change.
No tamper-evident record of who changed what
When firmware updates, config edits, and privileged commands are not logged with identity and integrity protection, a forensic team after an incident cannot reconstruct the sequence or trust the records that survive.
Controllers sit on one flat, untrusted network
With no zone and conduit boundaries an infected office PC reaches PLCs and edge nodes directly, so a single phished credential exposes the entire cell instead of one segmented assembly station.
How GizanTech solves them
- eFuse hardware root of trust (Secure Boot v2). Burn the RSA-3072 public-key digest into ESP32 eFuses and enable Secure Boot v2 so the ROM bootloader cryptographically verifies every stage; a tampered or unsigned image halts at boot instead of running, satisfying IEC 62443-4-2 CR 3.4 firmware integrity.
- Signed and AES-XTS-encrypted OTA pipeline. Sign each release with an offline key in an HSM/Yubico token, encrypt flash with AES-256-XTS, and ship updates over mutually-authenticated TLS so the device only accepts a countersigned image and the binary is useless if intercepted or dumped.
- Monotonic anti-rollback enforcement. Gate every OTA on a secure-version eFuse counter that only increments, so the bootloader refuses any image with a security version below the device's current floor, blocking downgrade-to-vulnerable attacks per IEC 62443-4-2 CR 3.10.
- Authenticated command channel with RBAC. Wrap setpoint and actuator writes in per-message authentication (signed/HMAC payloads or mTLS client certs) with role-based authorization, so the controller rejects any command lacking a valid operator or engineer identity, satisfying CR 1.1/1.2 and CR 2.1.
- Tamper-evident audit logging to SIEM. Emit hash-chained, timestamped records for every firmware update, config change, and privileged command over syslog/TLS to the plant SIEM, so each entry is integrity-protected and a deleted or altered line breaks the chain and raises an alert.
- Zone and conduit network segmentation. Design the device to live behind a defined conduit with a deny-by-default firewall, dedicated OT VLAN, and brokered northbound MQTT/TLS rather than direct exposure, applying IEC 62443-3-3 zoning so a compromised IT host cannot reach the controller.
| Security control | Mechanism | IEC 62443 reference | Attack / risk prevented |
|---|---|---|---|
| Secure Boot | RSA-3072 signature verified by ROM against an eFuse-burned key digest | 62443-4-2 CR 3.4 (firmware integrity) | Rogue or unsigned firmware flashed via USB or a swapped module |
| Signed + encrypted OTA | Offline-key release signing plus AES-256-XTS flash encryption over mutual TLS | 62443-4-2 CR 3.4 / CR 4.1 (confidentiality) | Image interception, cloning, or substitution on the plant LAN |
| Network segmentation | OT VLAN behind a deny-by-default conduit with brokered northbound traffic | 62443-3-3 SR 5.1 / SR 5.2 (zones & conduits) | Lateral movement from a compromised IT or office host |
| Command authorization | Per-message HMAC / mTLS client certs with role-based access control | 62443-4-2 CR 1.1, CR 1.2, CR 2.1 | Unauthenticated setpoint, recipe, or actuator writes |
| Audit logging | Hash-chained, timestamped syslog/TLS records streamed to the plant SIEM | 62443-4-2 CR 2.8 / CR 2.9 (auditable events) | Silent tampering and an unreconstructable post-incident timeline |
| Anti-rollback | Monotonic secure-version eFuse counter checked by the bootloader before swap | 62443-4-2 CR 3.10 (least-functionality / downgrade) | Downgrade to a known-vulnerable firmware build |
Go deeper
Firmware Security & OTA for other industries
Frequently asked questions
Does Secure Boot v2 slow down our production line or boot time?
No meaningfully. Signature verification adds tens of milliseconds at power-up only, not during operation, so cycle time is untouched. The trade-off is operational: once eFuses are burned the device is permanently locked to your key, so we fixture key provisioning into your end-of-line flashing step rather than the field.
Can we still push OTA updates to controllers that cannot be stopped mid-shift?
Yes. We use A/B partitions so the new signed, encrypted image is written and verified in the background, then the swap is gated to apply only when the controller reports an idle or safe state, with automatic rollback to the previous slot if the post-boot self-check fails.
How does this map to IEC 62443 for an audit or a customer security questionnaire?
Each control maps to specific component requirements: Secure Boot and signed OTA to CR 3.4, anti-rollback to CR 3.10, command authentication to CR 1.1 and 1.2, and audit logging to CR 2.8 and 2.9. We deliver the control-to-requirement matrix and test evidence so your team can answer the questionnaire instead of reverse-engineering the firmware.
What happens to a device if an attacker swaps the flash chip or dumps it?
AES-256-XTS flash encryption ties the contents to a key held in eFuses that never leaves the chip, so a dumped or transplanted flash image is ciphertext and will not boot. Combined with Secure Boot, neither reading the firmware nor injecting a modified one is viable without the on-die key.
Can you retrofit this onto an existing deployed fleet, or only new designs?
Both, with constraints. New designs get eFuses burned and encryption enabled at manufacturing for full protection. For a deployed fleet we can enable Secure Boot and signed OTA on units that still have unburned eFuses via a one-time secured update; units already in an insecure state usually need a controlled physical touch to provision the root of trust safely.
Will authenticated commands break our existing Modbus or MQTT integration?
We layer authentication and authorization without discarding your protocols: northbound traffic moves to mutually-authenticated TLS with signed payloads, while legacy Modbus stays behind the conduit boundary and is brokered through the secured node, so the PLC and SCADA integration keeps working while the trust boundary moves to the device.