Teams should first establish a secure identity and signing foundation before devices leave manufacturing. That means generating keys on device, defining a root of trust, and centralizing code signing so firmware can be authenticated before installation. Without that foundation, over the air updates become a major integrity risk and operators have little assurance that installed firmware is genuine.
What “first” means when firmware will be updated after shipping
The first job is to make the device capable of proving where firmware came from before it ever leaves manufacturing. For IoT devices that will accept over-the-air updates, update security starts in the factory, not in the field. If the device cannot verify integrity and origin with a trusted root, every later update mechanism is easy to subvert.
That means the manufacturing process should already be defining the device trust anchor, provisioning or generating the keys that support it, and wiring code-signing into the release path. In practice, this is the difference between a controlled update channel and a transport that merely moves bytes.
For device trust and firmware authenticity, the most useful reference point is the Device and IoT Identity Guide, which treats device identity, attestation and secure onboarding as part of the same trust foundation.
What has to exist before the first update is trusted
The minimum foundation is a root of trust, a signing process, and a verification step on the device that runs before installation. The device should not accept firmware simply because it arrived over a legitimate network path. It should accept firmware only if the signature, chain of trust, and version policy all validate against trusted device state.
That foundation also changes how manufacturing is done. Keys should be created and protected so they are bound to the device or to the approved signing service, not scattered across build systems or copied into images. If the signing key can be reused broadly, the update model becomes centralized in name only and weak in practice.
This is why the code-signing process needs to be treated as part of product security architecture, not as a post-release control. A practical external reference for understanding secure device architectures is NIST SP 800-82 Rev 3, OT Security Guide, which emphasizes trust boundaries and control integrity in connected systems.
For manufacturing teams, the operational question is whether the device can reject tampered firmware deterministically. If the answer is no, then the update path is still a distribution path, not a security control.
Why skipping the foundation turns updates into an integrity problem
Once devices are in the field, the update channel becomes part of the attack surface. Without authenticated firmware, an attacker who can alter traffic, compromise an update service, or influence the supply chain can introduce malicious code that still looks like a routine maintenance package. The problem is not only interception in transit, but also trust in the package itself.
That creates a direct integrity risk because the device has no reliable way to distinguish an authorized firmware image from a forged or modified one. It also creates an operational recovery problem: if many deployed devices are updated from the same broken trust model, a single weakness can scale into a fleet-wide compromise.
Manufacturing hardening for connected devices is easier to get right when teams start from a device-identity mindset. The HPE Aruba Hard-Coded Secrets case is a reminder that secrets embedded too early or too broadly can undermine device trust long after shipment.
For broader hardening discipline, external baselines such as CIS Benchmarks are useful as a model for consistent control expectations, even though firmware authenticity itself must still be solved at the device and signing layers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Field-updated devices need strong machine authentication and trusted firmware provenance. |
| IA-5 — Authenticator Management | Firmware signing depends on protected key and secret lifecycle control. | |
| SC-12 — Cryptographic Key Establishment and Management | A root of trust and signing foundation depends on sound key establishment and protection. | |
| Recommendation — Bind device update trust to authenticated non-organizational device identities. Protect signing keys and rotate them on a controlled lifecycle. Establish and protect the cryptographic root of trust for firmware signing. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Signed firmware and trust anchors are cryptographic controls for update integrity. |
| Recommendation — Require cryptographic signing and verification for every firmware release. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Manufacturing-time key exposure would undermine firmware trust and update integrity. |
| Recommendation — Keep device and signing secrets out of exposed build and deployment paths. | ||
Practitioner Guidance
What to verify: Before the first field update is allowed, verify that each device can validate a signed image against a trusted root and that unsigned or altered firmware is rejected automatically. Also verify that the signing authority is operationally separate from routine build output so a compromised build step cannot silently replace trust.
Decision rule: If the device cannot prove firmware origin on its own, prioritize secure boot and signing architecture before enabling OTA delivery. If you already have an update pipeline but no device-side trust anchor, treat the update mechanism as incomplete rather than merely immature.
What good looks like: A field device can boot only trusted code, update only from authenticated releases, and expose a clear failure state when validation does not pass. The best sign of maturity is not update convenience, but the ability to revoke or replace trust without redesigning the entire fleet.
Practitioner takeaway: The first control is not the transport, it is the trust model. If firmware authenticity is not anchored before shipment, every later update is an exposure management exercise instead of a security control.
