Manufacturers should establish PKI-backed identity issuance early in the device lifecycle, ideally at the production line or factory edge. That means assigning each device a unique certificate-based identity, validating it against the target ecosystem standard, and tying issuance to controlled manufacturing and registration workflows. This reduces ambiguity later and gives the device a verifiable identity before it ever reaches customers.
How manufacturers issue trusted device identities at scale
trusted device identity is not something to bolt on after shipment. Manufacturers need to treat identity as a production capability, with each device receiving a unique cryptographic identity during manufacturing, registration, or first secure bootstrap. The practical goal is simple: the device should leave the factory with a verifiable identity, controlled issuance path, and a clear trust anchor that the downstream ecosystem can validate.
What makes device identity trustworthy in production
Trust comes from uniqueness, cryptographic binding, and controlled issuance. A scalable approach uses a manufacturing-rooted PKI, device-specific key material, and certificates or equivalent attestations that can be validated by the target platform. This is why device identity differs from a simple serial number or shared secret: the identity must prove possession of private key material and be traceable back to an issuer the ecosystem already trusts.
At production scale, the manufacturer must also decide where the identity is created and when it becomes active. Many programmes generate and inject keys at the factory edge, then register the device against an inventory, certificate authority, or onboarding service before it is released. If the ecosystem uses a standard such as IEEE 802.1AR or another device identity profile, the issuance process should conform to that standard rather than inventing a one-off scheme that will be hard to operate across models and regions.
A good implementation separates identity creation from customer enrollment. The factory establishes the device’s core identity, while the customer environment accepts or activates it after verifying the manufacturer’s trust chain. That separation reduces ambiguity when devices are resold, replaced, repaired, or moved between tenants.
How to keep issuance manageable across high-volume lines
Scale depends on automation and strict lifecycle control. The manufacturing workflow should be able to generate, inject, track, and revoke identities without manual exception handling for every unit. In practice, that means integrating certificate issuance with MES or provisioning systems, binding each identity to a hardware root of trust where possible, and preserving immutable evidence of what was issued, to which unit, and under which batch or line process.
Manufacturers should also plan for failure cases: missed issuance, duplicated credentials, line rework, and returns. If a device fails provisioning, the process must quarantine it rather than allow a partially provisioned identity to leak into shipping. Where devices are refurbished or reassigned, the old identity should be retired and a fresh issuance path used, not reusing the same credential material across lifecycles. Device and IoT Identity Guide covers the device-certificate and onboarding patterns that make that lifecycle discipline practical.
The operational checkpoint is traceability. A manufacturer should be able to answer, for any shipped device, which identity was issued, when it was activated, what issuer signed it, and whether it is still in good standing. Without that record, large-scale issuance becomes an inventory problem rather than a trust system.
What buyers and platform operators should verify before trusting the device
Downstream trust should be based on verification, not marketing claims. Buyers and platform operators should confirm that the device identity is unique, that issuance is tied to a controlled process, that certificates or attestations chain to an approved root, and that replacement or revocation is supported when a device is compromised or decommissioned. They should also verify whether the manufacturer supports secure onboarding, device attestation, and revocation at scale, because identity that cannot be retired is only partially trustworthy.
The trust model should also match the deployment environment. Consumer IoT, industrial IoT, and regulated device ecosystems often have different expectations for attestation, key protection, and lifecycle governance. A certificate may be valid yet still unsuitable if the platform cannot enforce the intended trust boundary or if the device can be cloned during provisioning. CA/Browser Forum is useful as a reference point for trusted certificate issuance discipline, even though device identity often needs its own ecosystem-specific profile.
Risk and Threat Considerations
Weak issuance creates a large blast radius because every cloned, reused, or poorly protected device identity can become a standing access path into the fleet. The biggest risk is not just credential theft, but trust failure at scale: one bad manufacturing workflow can create thousands of devices that look legitimate to downstream systems.
Failure mechanism: Shared keys, predictable provisioning, weak factory controls, or reused certificates let an attacker impersonate devices, intercept onboarding, or pivot through trusted device channels. If revocation and reissue are slow or inconsistent, compromised identities can remain valid long after detection.
Impact: The result can be fleet-wide spoofing, unauthorized access, false telemetry, blocked updates, and expensive recall or re-provisioning campaigns. In regulated or safety-sensitive environments, identity failures can also become product-security and compliance failures, not just operational defects.
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 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Device identity issuance often depends on cloud onboarding and provisioning controls. |
| Recommendation — Harden provisioning endpoints and cloud defaults that can expose device identity material. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Per-device credentials and certificates need controlled issuance, rotation, and revocation. |
| IA-9 — Service Identification and Authentication | IoT devices authenticate as non-human endpoints using machine credentials. | |
| CM-8 — System Component Inventory | Fleet-wide issuance needs authoritative inventory and traceability for each device identity. | |
| Recommendation — Manage device authenticators with lifecycle controls for issuance, rotation, and revocation. Require strong machine authentication for device-to-platform trust paths. Maintain an accurate device inventory that ties each identity to a specific asset. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Manufacturing issuance must assign and govern each device identity across its lifecycle. |
| A.8.24 — Use of cryptography | Trusted device identity is rooted in certificates and cryptographic keys. | |
| Recommendation — Assign, track, and retire device identities under a formal identity management process. Protect device keys and certificates with approved cryptographic controls. | ||
| EU Cyber Resilience Act | Cyber Resilience Act | Product security obligations shape secure-by-design device identity issuance and lifecycle handling. |
| Recommendation — Build device identity issuance into secure-by-design product processes and lifecycle controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Asset Management and Access Control | Trusted device identities support controlled access and verified device registration. |
| Recommendation — Register devices before access and tie each identity to an approved trust boundary. | ||
Practitioner Guidance
What to prioritise: Build issuance around a single, auditable trust chain and make factory-line identity generation a first-class production control, not a post-production service.
What to verify: Confirm that every device can be individually traced, that private key material is protected during creation and transport, and that revocation works before mass deployment begins.
Common mistake: Treating serial numbers, shared bootstrap secrets, or ad hoc onboarding tokens as if they were durable device identity. Those mechanisms may help bootstrap, but they do not provide the same trust properties as per-device cryptographic identity.
Practitioner takeaway: At scale, trusted device identity is won or lost in the factory workflow, so the best programmes optimise for uniqueness, traceability, and revocation before they optimise for convenience.
Related resources from NHI Mgmt Group
- How should IoT teams secure mobile device identities when deploying NB-IoT and eSIM-based connectivity at scale?
- Why do IoT device identities create more security risk when certificates and keys must be issued at manufacturing scale?
- How should security teams govern IoT device certificates at scale?
- How should teams govern IoT device identities with PKI?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
