How should organisations secure connected devices during manufacturing before they are deployed in the field?

Organisations should treat manufacturing as a security control point, not just a production step. The strongest approach combines secure hardware, signed firmware, protected cryptographic keys, auditability, and traceability across the supply chain. That reduces the chance of duplicated firmware, tampered devices, counterfeit products, or stolen secrets later being exploited once the device is operational.

Securing Connected Devices at the Factory Stage

Manufacturing is where device trust is established, so security has to begin before the device ever reaches the customer or operator. That means provisioning a unique identity, loading only approved firmware, protecting keys during injection or onboarding, and keeping a record of what was built, when, and with which components. Factory compromise is often silent, but it can create a downstream security problem that field controls cannot fully undo.

For connected devices, the manufacturing phase is the point at which hardware roots of trust, attestation support, and initial trust anchors are set. If those are weak or shared across a fleet, later controls such as device authentication, secure update, and access policy become much less effective. A device that arrives in the field already cloned, preloaded with a weak key, or exposed through an insecure production process is harder to recover than one that was designed and provisioned securely from the start.

Manufacturing security also needs to account for the supply chain, not just the final assembly line. Organisations should verify that component provenance, firmware signing, and custody of credentials are controlled across contract manufacturers, test labs, and staging environments. The practical question is not whether a device can be built, but whether the build process can prove what was loaded, who handled it, and whether the resulting unit is distinguishable from every other unit in the fleet.

What Good Factory Controls Look Like

Strong factory controls start with unique device identity and per-device secrets, rather than shared default credentials or copied certificates. That supports secure onboarding later and reduces the value of one stolen device image or leaked production secret. It also requires a controlled path for firmware and configuration so that only signed, approved images can be injected or activated during production.

Traceability matters as much as cryptography. Organisations should be able to map each unit to a build record, a hardware lot, a firmware version, and a key injection event. That record is what makes later recalls, compromise investigations, and authenticity checks possible. Where production involves multiple sites or vendors, the same integrity requirements should follow the device across each handoff.

Physical and procedural controls still matter because many factory failures are not technical failures alone. Segregated production networks, restricted access to provisioning stations, tamper-evident handling, and controlled exception handling reduce the chance that a legitimate build path is abused to introduce counterfeit or modified devices. Device and IoT Identity Guide is a useful reference for the device identity and onboarding side of this problem.

Why Field Security Depends on Manufacturing Integrity

Once a device is deployed, the field environment can detect many problems but cannot easily reverse a broken trust foundation. If keys are duplicated in manufacturing, multiple devices may authenticate as the same asset. If firmware signing is weak, a tampered image may look legitimate. If the production process cannot prove provenance, operators may have no reliable way to separate authentic devices from imitations or altered stock.

That is why manufacturing security is closely tied to lifecycle assurance, not just initial configuration. The device should leave the factory in a state that supports later patching, revocation, attestation, and rotation without requiring special-case exceptions. A secure factory process is therefore a control over future operational risk, not only a safeguard for the assembly line.

For product classes covered by modern regulation, factory security is increasingly part of the compliance expectation as well as the technical one. The EU Cyber Resilience Act pushes secure-by-design and lifecycle security expectations into product development and manufacturing, while the same regulatory direction reinforces that insecure production is not a harmless upstream detail.

Risk and Threat Considerations

Factory weaknesses can create fleet-wide exposure because a single compromised provisioning step may be replicated across every unit built from that line. The main risks are cloned credentials, unauthorised firmware insertion, counterfeit substitution, and loss of provenance, each of which can survive into production and look like a normal device unless the organisation has strong validation and traceability.

Failure mechanism: An attacker or compromised insider abuses a trusted manufacturing step, such as key injection, flashing, labeling, or staging, to introduce shared secrets, altered code, or counterfeit units that later appear legitimate in the field.

Impact: The organisation may inherit devices that can be impersonated, remotely abused, or patched only with difficulty, and a single factory error can become a broad operational and security incident across the deployed base.

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 and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8, NIST SP 800-57 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-07 — Long-Lived Secrets	Factory provisioning often creates device secrets that must not persist insecurely across the fleet.
	NHI-02 — Secret Leakage	Manufacturing can expose keys, certificates, or bootstrap secrets before devices ship.
	NHI-06 — Insecure Cloud Deployment Configurations	Connected-device manufacturing often depends on cloud-backed provisioning and onboarding services.
Recommendation — Rotate or replace factory secrets before deployment and avoid reusable credentials across devices. Protect injection stations and secret handling to prevent production key leakage. Harden provisioning services and lock down build-time access paths used for device onboarding.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Device credentials and certificates need controlled issuance, storage, rotation, and revocation.
	CM-8 — System Component Inventory	Factory traceability depends on knowing exactly which device and component was built and shipped.
	SI-7 — Software, Firmware, and Information Integrity	Signed firmware and integrity checks are central to preventing tampered devices from leaving manufacturing.
Recommendation — Manage device authenticators with unique issuance, rotation, and revocation controls. Maintain a verifiable inventory linking each device to build, firmware, and component records. Enforce firmware integrity validation before activation or shipment.
CIS Controls v8	CIS-5 — Account Management	Manufacturing often relies on privileged provisioning accounts that must be tightly governed.
Recommendation — Restrict and review provisioning accounts used in device build environments.
NIST SP 800-57	Key Management	Device manufacturing depends on secure key generation, storage, and lifecycle handling.
Recommendation — Apply strong key lifecycle controls to protect device secrets from creation to retirement.
OWASP ASVS	V11 — Cryptography	Firmware signing and protected keys are core to manufacturing trust for connected devices.
Recommendation — Verify that signing keys and cryptographic protections are implemented correctly in the build process.

Practitioner Guidance

What to prioritise: Start with the trust anchor. If the device identity, firmware signing, and secret handling are not sound in manufacturing, downstream security work will be compensating for a broken foundation rather than strengthening the product.

What to verify: Require evidence that each device receives unique credentials, approved firmware only, and a build record that can be reconciled with inventory and shipment data. If those three elements cannot be proven, treat the production process as untrusted until corrected.

Practitioner takeaway: The most effective manufacturing security control is not a single test, it is a chain of provable identity, integrity, and traceability that makes cloned or tampered devices easier to detect before they ever reach the field.