How should organisations govern device identity across manufacturing and deployment?

They should treat manufacturing identity and operational identity as separate governance stages. The factory-issued certificate proves origin, while the deployment certificate proves continuing trust inside the environment. That split requires different owners for issuance, renewal, revocation, and audit, especially when operators and OEMs both participate in the trust model.

Why This Matters for Security Teams

device identity in manufacturing is not the same problem as device identity in production. A factory certificate can prove origin, but it does not automatically prove the device still belongs inside a specific operational environment, under a specific policy, or within a specific support boundary. That distinction matters because device fleets often cross organisational lines between OEMs, contract manufacturers, integrators, and operators, which creates competing authority over issuance and revocation.

Security teams often underestimate how quickly a “born trusted” device becomes a governance gap after shipment. The practical failure is not usually the certificate itself, but the absence of clear ownership for renewal, replacement, audit, and emergency revocation once the device is deployed. NIST Cybersecurity Framework 2.0 frames this as an asset governance problem as much as an identity problem, and the same logic appears in NHIMG guidance on lifecycle control in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. Current guidance suggests treating device identity as a staged trust model rather than a single credential event.

That framing is not academic. NHIMG notes in the Ultimate Guide to NHIs that 71% of NHIs are not rotated within recommended time frames, which is a warning sign for any device estate that relies on long-lived credentials. In practice, many security teams encounter device trust failures only after a shipment, a maintenance cycle, or a compromise has already broken the original factory assumptions.

How It Works in Practice

Organisations usually need two identity layers. The first is manufacturing identity, which establishes provenance: who built the device, which component set it came from, and whether it left the factory in a known-good state. The second is operational identity, which binds the device to a deployed context: where it is allowed to connect, what services it may call, and which controls govern its continued access.

That separation works best when issuance and lifecycle ownership are split deliberately. OEMs or manufacturers may control factory attestation and initial certificate generation, while operators own onboarding, renewal policy, revocation triggers, and exception handling. The operational certificate or credential should be short-lived where possible, or at least renewable under active policy, because a device that stays valid indefinitely is hard to recover when hardware is replaced, resold, repaired, or stolen.

A workable model usually includes:

• Factory attestation tied to hardware provenance or signed build records.
• Deployment onboarding that exchanges origin proof for environment-specific trust.
• Separate revocation paths for manufacturing compromise and runtime compromise.
• Inventory and audit logs that show both identity stages, not just the current certificate.
• Policy checks at renewal time, not only at provisioning time.

Where possible, align this with zero trust principles and runtime policy evaluation rather than static trust lists. The NIST Cybersecurity Framework 2.0 and the NIST Cybersecurity Framework 2.0 both support this style of continuous verification, and NHIMG’s research on the Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforces that auditability depends on knowing who controls each stage of the identity lifecycle.

These controls tend to break down when the same certificate authority, asset owner, and operational approver are all different parties and there is no shared revocation process.

Common Variations and Edge Cases

Tighter identity separation often increases operational overhead, requiring organisations to balance stronger provenance assurance against faster deployment and simpler field support.

There is no universal standard for this yet, so the right model depends on whether devices are consumer-facing, safety-critical, or embedded in regulated industrial systems. For example, a device that is frequently reflashed may need a more flexible renewal model than a sealed appliance that rarely changes state. In highly distributed fleets, the biggest risk is not weak origin proof but drift between what the factory asserted and what the environment still permits.

Edge cases also appear when OEMs need remote support access after deployment. That access should not be folded into the same credential as the device itself. Best practice is evolving toward separate support identities, separate approval workflows, and explicit time bounds for vendor access. NHIMG’s 52 NHI Breaches Analysis shows how quickly identity sprawl becomes a breach path when ownership is unclear. For identity-heavy environments, the Top 10 NHI Issues is a useful reminder that visibility and rotation failures usually emerge together, not in isolation.

In practice, the hardest cases are mixed-trust fleets where factories, distributors, and operators all touch the same device before and after deployment.

Related resources from NHI Mgmt Group

• How should security teams govern AI transformation across identity and access programmes?
• How should NHS trusts govern shared IAM across multiple organisations?
• How should organisations govern access when identity controls are spread across IGA, AM, and PAM?
• How should organisations govern identity across hybrid cloud environments?