.png){kind=logo}
Manufacturing and Device Identity Provisioning
In the Internet of Things (IoT) and embedded systems industry, ensuring a secure and scalable method for injecting trusted device identities at the point of manufacture is critical. OEMs may run their own factories or contract with third-party contract manufacturers (CMs), potentially located in untrusted or offshore environments. Sometimes, the factory environment does not even provide a stable real-time Internet connection. Without a robust device identity provisioning framework, devices are vulnerable to counterfeiting, key leakage, and non-compliance with industry standards such as Cyber Resilience Act (CRA), Matter, and IEEE 802.1AR.
In this solution area, the following topics are covered:
An overview of common challenges in secure manufacturing
The architecture of the solution, including key components and data flows
Explanations of how Public Key Infrastructure (PKI), cryptographic key injection, and provisioning are securely and automatically managed to enable trusted identities for products on the factory floor.
Physical and logical architecture diagrams illustrating EJBCA deployment in a manufacturing environment
Challenges and Considerations for Secure Device Manufacturing
Securing the manufacturing phase is fraught with challenges, especially when production is outsourced to third-party partners. Ensuring that these partners adhere to the same stringent security standards is paramount.
Some of the critical challenges include:
Complying with standards: Organizations must often support multiple use cases and manage certificate issuance across diverse environments. Without a flexible PKI, this leads to fragmented systems, manual workarounds, and inconsistent security, making it hard to comply with security standards.
Ensuring Secure Programming Operations: Manufacturers must ensure that programming operations are secure, even when conducted at third-party production sites. This involves implementing robust security protocols to prevent unauthorized access, tampering, overproduction, counterfeiting, cloning, and leakage of secrets, including sensitive keys.
Injecting Unique Digital Identities: A strong and unique digital identity, often referred to as a "Initial Device Certificate," must be injected into each device during manufacturing. This identity is crucial for proving genuineness, tracking, and verifying the device throughout its lifecycle. It will also be useful in the case of a factory reset of a device
The importance of random numbers: Ensuring that all devices have access to adequate entropy sources to generate unique private or symmetric keys, regardless of the capabilities of their MCU random number generator
When the factory doesn’t have a stable internet connection: Establishing secure and reliable communication between factories and OEM PKIs, even in environments with limited or intermittent internet connectivity.
Complying with export controls and regional PKI restrictions: Factories are often located overseas in countries like China, where usage of cryptographic material is highly regulated, and some restrictions may apply to deploying a PKI across borders.
Documenting Secure Manufacturing Processes: CRA mandates the documentation of secure manufacturing processes with the objective of transparency towards the customer. This requires meticulous record-keeping and compliance with regulatory standards, and implementing the capability to audit the system at any moment
Initial Device Certificates and PKI in Industry Standards
PKI enables OEMs to bind a unique, cryptographic identity to each device at the time of manufacturing. This identity can later be used for:
Mutual authentication between devices and services.
Secure onboarding and updates.
Trust-based ecosystem participation (e.g., Matter Smart Home, Wi-SUN, V2G).
PKI and X.509 certificates are foundational security components in standards such as IEEE 802.1AR, Wi-SUN, DLMS, ISO 15118-2/20, IEC 62443, and Matter. These standards mandate the issuance of initial device certificates (IDCs) and other PKI-based provisioning credentials during the manufacturing process to ensure strong, verifiable device identities and secure lifecycle operations.
Keyfactor Solutions
EJBCA PKI provides a secure and automated platform for Initial Device Certificate provisioning on the factory floor. EJBCA and its various deployment options address common challenges in device identity and provisioning. The following sections describe how the solution solves these challenges:
Challenge: Organizations must support multiple security standards and manage certificate issuance across diverse environments, from cloud to on-prem factories. Without flexible PKI, this leads to fragmented systems, manual workarounds, and inconsistent security.
Solution: EJBCA provides a unified platform to standardize and manage your entire PKI.
Use case support:
EJBCA supports issuing X.509 certificates and can be configured to comply with a broad range of industry standards and protocols commonly used in connected devices and infrastructure, including:
Matter – for device attestation credentials (DACs) in smart home ecosystems
Wi-SUN – for field area network security in smart utility networks
DLMS - for smart-meter security in smart utility networks
IEEE 802.1AR – for secure device identity (DevID) and provisioning
3GPP – for cellular network infrastructure and SIM-related security
ISO 15118-2/20 - for Vehicle to Grid (V2G) and EV charging support
IEC 62443 - for Initial Device Certificate injection into factory components at manufacturing
In addition, EJBCA supports:
Card Verifiable Certificates (CVC) – used in secure identification systems (e.g., ePassports, national ID cards)
SSH Certificates – for secure access control and key management in infrastructure environments
Deployment option support:
EJBCA can be deployed in several environments depending on infrastructure and operational requirements:
Cloud-based (SaaS) deployments for managed PKI
On-premises Hardware Appliances, PKI and Hardware Security Module (HSM) in a box
EJBCA Software Appliances, which can be installed on VMs or containers
This flexibility allows teams to align PKI deployment models with both system architecture and compliance needs, while a single installation can efficiently support multiple PKIs for diverse use cases.
EJBCA is a multi-tenant system and can, for example, support both the Initial device certificate PKI and the Firmware signing PKI in one installation:
Typical OEM PKI for Initial Device and FW Signing Certificates
Challenge: Ensuring Secure Programming Operations: Manufacturers must ensure that programming operations are secure, even when conducted at third-party production sites. This involves implementing robust security protocols to prevent unauthorized access, tampering, overproduction, counterfeiting, cloning, and leakage of secrets, including sensitive keys.
Solution: An EJBCA HW appliance can be configured as a local Registration Authority (RA) within the factory environment. It connects locally to the production computer and establishes a secure, authenticated (mTLS) REST-based connection to the OEM’s centralized EJBCA PKI and CAs.
Deploying an EJBCA RA Hardware Appliance to secure the connection to the SaaS CA from an untrusted factory
EJBCA’s fine-grained certificate profiles and access control ensure that CAs and RAs at the Contract Manufacturer are strictly scoped and monitored, reducing risk and satisfying corporate governance requirements.
Challenge: Injecting Unique Digital Identities: A strong and unique digital identity, often referred to as an "Initial Device Certificate," must be injected into each device during manufacturing. This identity is crucial for proving genuineness, tracking, and verifying the device throughout its lifecycle. It will also be useful in the case of a factory reset of a device.
Solution:
EJBCA logs every certificate issuance, enabling traceability and lifecycle management.
Long-term key and certificate management is supported by EJBCA’s scalable CA hierarchy, enabling later renewal or re-enrollment workflows as devices are updated or re-issued.
Challenge: Ensuring that all devices have access to adequate entropy sources to generate unique private or symmetric keys, regardless of the capabilities of their MCU random number generator.
Solution:
EJBCA is designed to issue certificates complying with any MCU, MPU, secure element or TPM so that OEMs can bring their own Root-of-Trust (BYORoT). The BYORoT program at Keyfactor is making sure that the EJBCA PKI software can issue x.509 certificates complying with every major silicon vendor MCU, MPU and secure element and interface with third-party certificate injection services: Bring Your Own Root Of Trust (BYORoT) by Keyfactor.
EJBCA can also generate private keys on behalf of resource-constrained devices, ensuring that secure identities can still be issued even if the devices can’t generate keys themselves.
When devices are capable of local key generation, they should submit their own signed CSRs to EJBCA, maintaining strong device-level security.
Challenge: Establishing secure and reliable communication between factories and OEM PKIs, even in environments with limited or intermittent internet connectivity.
Solution:
EJBCA addresses this by enabling a local CA instance in the factory to run on a hardware appliance, in a controlled security perimeter, when a remote CA connection is not possible.
This CA is signed by the same root as the other CAs and can generate certificates off-line at scale.
PKI integration for Factory environments with limited or intermittent internet connectivity
If initial device certificate revocation is needed and the factory environment cannot be trusted to manage certificate revocation, a mirror hardware appliance CA can be deployed in the centralized IT environment to handle revocation, CRL (Certificate Revocation List) generation, and OCSP (Online Certificate Status Protocol) interfacing to a VA (Validation Authority).
EJBCA allows for the configuration of a manual or an automated synchronization between both mirror CAs' databases.
Challenge: Complying with export controls and regional PKI restrictions.
Solution:
In more sensitive or restricted network environments (e.g., CMs in China), the architecture supports offline or semi-connected operations and controlled, temporary exposure of CA endpoints via gateways or DMZs.
An EJBCA HW Appliance runs locally and acts as an all-in-one RA + CA in the factory when the factory doesn’t offer the possibility to connect to a remote CA.
Challenge: Documenting Secure Manufacturing Processes: CRA mandates the documentation of secure manufacturing processes with an objective of transparency towards the customer. This requires meticulous record-keeping and compliance with regulatory standards and implementing the capability to audit the system at any moment.
Solution:
EJBCA PKI provides centralized policy control over certificate issuance, expiration, and revocation, allowing OEMs to enforce compliance with standards such as IEEE 802.1AR, Wi-SUN, DLMS, ISO 15118-2/20, IEC 62443, Matter, etc., and maintain audit trails.
Example Use Case: Secure Initial Device Identity Personalization in Contract Manufacturing
Challenges
An OEM needs to personalize the appliances it manufactures to ensure traceability and enable secure commissioning in the field. This personalization requires injecting a unique, trusted cryptographic identity, typically an X.509 certificate, into each device during contract manufacturing.
However, the OEM outsources production to a Contract Manufacturer who doesn’t provide real-time internet connectivity on the production line, making it impossible to connect securely to the OEM corporate PKI and issuing CA to retrieve Initial Device Certificates.
Furthermore, the OEM needs to manage the revocation of these certificates, and this is another challenge because only the CA having issued a certificate can revoke it and assemble a CSR or interact with a Validation Authority running an OCSP responder.
Solution
In this scenario, the OEM will deploy an EJBCA Hardware Appliance locally in a controlled security perimeter in the factory and configure it as the issuing CA for initial device certificates. This CA is signed by the OEM product root CA running in the OEM corporate IT environment.
The production computer attached to the programming machine acts as a Registration Authority (RA), aggregating device data and securely requesting certificates from the EJBCA CA instance on the local factory network. This approach ensures that device identities can be issued reliably and securely at scale, independent of internet availability.
Nevertheless, the factory Hardware Appliance CA cannot be used to revoke certificates because it is deployed inside the Contract Manufacturer factory infrastructure, and the CM doesn’t allow OEM remote access to the Hardware Appliance on its factory LAN.
The OEM therefore mirrors the factory CA into another EJBCA Hardware Appliance hosted in his corporate IT environment. Both HW Appliances are configured to synchronize their databases overnight with a dedicated TLS connection and port without human intervention and in accordance with the CM cybersecurity policy. This allows the mirror CA to keep a copy of the list of all certificates issued by its factory counterpart and to manage their revocation, CRLs or interfacing with the OEM Validation Authority OCSP responder.
The OEM then deploys a Validation Authority in the cloud so that OEM customers can validate OEM Initial Device Certificates in real-time. The VA uses the mirror CA as a source for certificate validity.
Logical and Physical PKI Architecture
The diagram below illustrates a typical PKI setup for issuing initial device certificates to a production computer on the factory floor, designed for environments where the factory does not have a stable internet connection.
EJBCA PKI setup for a factory environment with limited or intermittent internet connectivity
The Certificate Signing Request (CSR) signing and certificate provisioning flow:
The production computer securely connects to the Factory CA using mTLS.
The production computer retrieves a CSR from the device, vets it, and forwards it to the Factory CA.
The production computer retrieves the signed certificates and aggregates all data to be programmed (firmware, input files, etc.) and programs it into the device.
The production computer manages batches and controls the production run while the Factory CA logs every certificate issued.
The Factory CA synchronizes asynchronously with its mirror CA inside the OEM IT.
A VA is configured within the OEM IT-hosted PKI and exposes CRLs or OSCP to external requests.
Conclusion
Establishing secure, standards-compliant manufacturing at scale, especially across third-party or untrusted environments, requires a purpose-built solution for provisioning device identities, protecting critical assets, and maintaining control over certificate issuance. The EJBCA PKI solution provides a modular, automated, and auditable method for initial device certificate provisioning.
This solution area has outlined:
The challenges faced in secure device manufacturing and provisioning
How EJBCA solves these challenges
Deployment models and architectures tailored to contract manufacturing environments
How to inject and manage Initial Device Certificates (IDCs) securely and at scale
Related Content
Hands-On Guide
Complementary Solution Areas:
Further Reading:
Contact us
Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.