Device certificates for manufacturing and IoT

Device certificates for manufacturing and IoT: why the plant floor changes the PKI design

If your plant runs machines, PLCs, gateways and sensors that cannot be identified reliably, you need a device certificate program before you need more network segmentation. Each device should carry a unique, verifiable identity issued at provisioning, and you should be able to renew and revoke that identity without touching the production line. Device identity differs from employee or server PKI in three ways that drive the design: device certificates often outlive the software and staff who installed them, many devices have intermittent or no connectivity to a CA, and a certificate failure on a controller can stop production or create a safety hazard. Regulators add pressure. NIS2 lists manufacturing as a critical sector, the Cyber Resilience Act applies to products with digital elements from 11 December 2027, and the Machinery Regulation adds an essential requirement that connecting another or remote device must not lead to a hazardous situation from 14 January 2027.

On platforms, the short answer is a split by where the device sits. step-ca is the strongest fit for automated device issuance on IT-side services and gateways, because it supports ACME, OIDC, cloud instance identity and JWK provisioners and can protect CA keys in HSMs or cloud KMS. OpenBao PKI fits where secrets and certificates are already centralized under OpenBao and your team wants one control plane for issuance and key handling. FreeIPA fits where the estate is Linux-heavy and you want directory, DNS and certificate authority management in one system. None of these platforms should be assumed to speak the protocols or enroll the firmware of your OT devices natively. Confirm, device by device, which enrollment method each controller, sensor and gateway supports, whether the firmware can store a private key securely, and whether it can trust a private root and fetch revocation information.

Start with a device inventory that records model, firmware version, protocol stack and connectivity pattern for every identity-bearing device, then ask your vendors in writing which certificate formats, enrollment paths and renewal behavior their firmware supports. Plan for offline or intermittent devices with longer local validity and a documented manual or gateway-assisted renewal path, and test what happens when the CA is unreachable during a maintenance window. Keep OT and IT trust chains separate, with distinct roots and issuing CAs, so that a compromise on the office side cannot issue identities the plant trusts. Your implementation partner should be able to show how that separation, the renewal runbook and the revocation procedure will be tested before any device goes live.

Which requirements shape device certificate design in manufacturing

This table maps the regulations and standards that touch manufacturing and connected equipment to the certificate design choices they force, including lifetime, revocation speed, key storage and logging. Read each row as a question to answer during design: what the requirement asks, and what it changes in your device identity build. Most rows point to the same takeaway: OT and IT trust chains need to be separated and revocation must work even when devices are offline.

Requirement	Source	What it means for the build
Zones, conduits and the four-group structure of IACS security	ISA/IEC 62443 series (four groups: general, policies and procedures, system, component)	Define zones by function and place separate trust chains for OT and IT. Conduits between zones decide which certificates may cross, so document which issuing CA serves each zone.
System security requirements and security levels	ISA-62443-3-3-2013	Target a security level per zone and derive certificate requirements from it, such as authentication strength for each device class. Ask suppliers which level their components were built to.
Asset owner security program	ANSI/ISA-62443-2-1-2024	The asset owner must run a program covering identity, change and incident handling. Keep a device certificate inventory tied to asset records and assign owners for issuance and revocation decisions.
OT performance, reliability and safety constraints	NIST SP 800-82 Rev. 3 (September 2023)	Renewal traffic and CA calls must not disrupt control loops. Favor certificates renewed locally or in batches during maintenance windows, and test what a device does when the CA is unreachable.
Manufacturing scope and incident reporting deadlines	NIS2 Annex II (NACE Rev. 2 divisions 26 to 30) and Article 23(4)	Early warning within 24 hours, notification within 72 hours and a final report within one month. Revocation and certificate logs must be fast to query so the team can establish which devices were affected within these windows.
Reporting of actively exploited vulnerabilities and severe incidents	CRA Article 14 (applies from 11 September 2026); product obligations from 11 December 2027	Manufacturers must report under Article 14 now. Build a record of which firmware and device identities shipped, so you can revoke or reissue credentials for affected product batches.
Connected devices must not cause hazards	Machinery Regulation (EU) 2023/1230, Annex III 1.1.9, applies from 14 January 2027	A compromised or misbehaving connected device must not lead to a hazardous state. Revocation should be able to isolate a device at the network and application layer, and key storage should resist extraction from the device.

Separating OT and IT trust chains without breaking production

A dedicated OT issuing CA gives the production zone its own intermediate authority, chained to a root that the OT team controls or shares under written rules. Devices in the zone trust only that chain, so a compromise or misconfiguration in the IT estate does not reach the line. The trade-off is operational load: someone must run a second CA, keep its keys protected and keep the device profiles current.

Trust anchor: the OT root or intermediate is installed in controllers, gateways and engineering workstations as the only anchor for device identity.
Who operates it: typically the OT engineering or plant automation team, with security as the approver for key ceremonies and profile changes.
Failure impact: if the OT issuing CA is unavailable, only new enrollments and renewals stop; devices already holding valid certificates keep running until expiry.
Revocation: publish a short-interval CRL or OCSP responder reachable from the plant network, and confirm that each device firmware can fetch or cache it.
Confirm: whether your controllers and gateways can validate a chain without online checks, and how long a cached status remains acceptable.

Which open-source platforms fit device identity and why

Device identity splits into three jobs: issuing a certificate at provisioning, renewing it on hardware that may be offline for long periods, and watching the fleet for misuse. No single open-source platform covers all three well, so the choice depends on where the device trust chain sits and which team runs it. The cards below cover the CA options, the directory option for Linux-heavy estates, monitoring, and the identity provider only where device users sign in.

step-ca for device certificates

step-ca is Smallstep's open-source online CA, licensed under Apache-2.0. It issues X.509 certificates for TLS and mutual TLS, so a gateway or sensor can prove its identity to a broker or service. Provisioners decide who may request a certificate: ACME for automated renewal, JWK for factory-loaded keys, OIDC for operator-approved enrollment, and cloud instance identity where devices run in a cloud account. The CA key can sit in an HSM, cloud KMS or YubiKey. Check how your devices reach the CA during provisioning and renewal, since a CA reachable only from the corporate network does not serve a plant floor.

OpenBao PKI for secrets-linked devices

OpenBao is an MPL-2.0 fork of Vault, hosted under the OpenSSF, with v2.7.1 published on October 1, 2026. Its PKI secrets engine and TLS certificate auth method suit fleets that already use OpenBao for credentials, because device certificates, keys and secrets share one audit and access model. Storage backends are integrated Raft or PostgreSQL, and the HA docs name both as the officially supported HA options. Confirm the PKI engine's fit for your provisioning flow with the vendor and with your own tests, since a device that needs an offline root may still need a separate CA.

FreeIPA for Linux-heavy estates

FreeIPA bundles a directory, Kerberos and a certificate authority built on Dogtag, which many Linux shops already run for host enrollment. It fits plants where Linux gateways and edge hosts join one domain and need host certificates tied to that identity. The limit is scope: it is a directory-centric system, and mixed fleets of microcontrollers with no Linux stack will not enroll natively. Confirm Dogtag's certificate profile options, renewal behavior and HSM support with the FreeIPA project and your own test lab before you commit to it.

Wazuh for device telemetry

Wazuh is a GPL-2.0 security platform with XDR and SIEM capabilities. It does not issue or renew certificates, but it can collect logs and events from gateways and servers that touch the PKI, including enrollment requests, renewal failures and unexpected certificate use. Release v4.14.9 was published on October 15, 2026. Confirm which certificate and CA events your gateways emit and whether an agent can run on each device class, because constrained sensors often cannot host an agent and need telemetry sent from the gateway in front of them.

Keycloak or ZITADEL for operator login

Devices rarely log in, so an identity provider belongs in the design only where people use it. Keycloak (Apache-2.0) and ZITADEL (AGPL-3.0) both support OpenID Connect and MFA, and they can gate the enrollment portal or the OIDC provisioner that issues certificates to technicians. Keep this layer separate from device identity: a human approving enrollment should not be the device's credential. Check the license obligations of ZITADEL's AGPL-3.0 before embedding it in a product you distribute, and confirm that the chosen provider integrates with your existing directory.

HashiCorp Vault licensing caveat

HashiCorp Vault from version 1.15.0 onward is licensed under the Business Source License 1.1, with IBM named as licensor, and that license is not an OSI-approved open source license. Teams that want Vault's PKI engine on an open-source basis should review that license before standardizing on it, and should not assume the open-source label carries over from older Vault releases. Ask your counsel to review the Business Source License terms against your intended use, and compare the OpenBao option on the same criteria.

How a device PKI rollout runs in phases

The sequence moves from understanding which machines sit in which trust zones, to a signed trust hierarchy, a proven pilot on one line, and a handover that your own team can run after DeployOpen leaves. Each phase closes with a written artifact you can review before the next one starts.

Map devices and zones under ISA-62443 concepts
DeployOpen works with your OT engineers, IT security team and line integrators to inventory machines, PLCs, gateways, sensors and vendor-managed equipment, then group them into security zones and conduits using the zone-and-conduit model from the ISA/IEC 62443 series. For each zone, the team records which devices need identity, which can use a shared gateway identity, and which cannot accept certificate-based authentication at all. The output is a zone map with device classes, owners, connectivity patterns and the systems each zone talks to. The phase is complete when the OT and IT owners have each signed off on the map.
Design the trust hierarchy and key ceremony
Using the zone map, DeployOpen drafts a certificate hierarchy that separates an offline root, intermediate CAs per trust domain (for example, OT plant, IT and vendor access) and the issuing identities for each device class. The design covers certificate profiles, key algorithms, lifetimes, revocation method, and where keys live, whether in an HSM, a cloud KMS or hardware tokens supported by the CA platform you select. Your team and DeployOpen then run a documented key ceremony with witnesses and recorded steps. The output is a signed hierarchy design, a ceremony script and a key custody record that assessors can read later.
Pilot enrollment on one line with a gateway
The pilot picks one production line and one gateway, then issues device certificates through the chosen issuing CA, using the enrollment method that fits the device firmware (for example, ACME where the gateway runs a client, or an API-driven enrollment where the controller can call a service). DeployOpen instruments the gateway to log issuance, renewal and failures, and confirms the device can authenticate to the systems it needs without opening new paths into the OT network. The output is a pilot report listing devices enrolled, failures, firmware constraints and the changes made to the design. The pilot ends only when the line has run in normal production conditions with the owners' approval.
Integrate provisioning with the manufacturer or integrator
Device identity is usually created on the factory floor or during commissioning, so this phase connects the CA to the process that installs the first credential. DeployOpen works with the device manufacturer or line integrator to define how a device receives its key pair, how the certificate signing request is generated, who approves issuance, and how the device identifier is bound to the certificate. Each provisioning step is written as an acceptance test. The output is a provisioning interface specification, a list of test cases with pass results, and a named owner for the provisioning credentials.
Run renewal, revocation and CA outage drills
Before cutover, DeployOpen runs renewal on devices with limited connectivity, including devices that are offline for part of their renewal window, and checks what happens when the issuing CA is unreachable. The drills also include revoking a test device, confirming that the revocation reaches systems that check it, and confirming that the device is refused access afterward. The team records how long a device can operate on its current certificate and which functions degrade when it cannot renew. The output is a tested renewal and revocation log, a list of failure modes with agreed responses, and a decision on which devices need manual recovery procedures.
Separate OT and IT trust chains at cutover
Cutover moves the lines in the pilot and the next agreed zones onto the new hierarchy, with OT and IT trust chains kept separate so that a compromise in one does not automatically grant trust in the other. DeployOpen confirms that cross-zone access goes only through defined conduits, that the trust stores on each device contain only the roots and intermediates for that zone, and that monitoring alerts on unexpected issuance or failed renewals. Changes are staged zone by zone with a rollback plan. The output is a cutover record showing each zone, its trust store contents and the monitoring rules in force.
Hand over the runbook and operating evidence
The final phase transfers operation to your team. DeployOpen delivers a runbook covering issuance and renewal procedures, revocation steps, CA backup and restore, key ceremony repeats, incident response for a compromised device, and escalation contacts for OT and IT. Your staff run one supervised renewal and one supervised revocation to prove they can follow the document. The output is the signed runbook, a training record, a certificate inventory export and the evidence set that supports your internal audit or regulator questions. Ongoing support and upgrades can then be scoped separately as a retainer.

What a plant team must provide before a device CA project starts

The first thing a plant team must provide is an inventory of the devices that will hold certificates: the models, the firmware versions each model runs, and whether the device can store a private key, present a certificate in a TLS or mutual TLS handshake, and run an enrollment or renewal client. Many programmable logic controllers, drives, sensors and gateways cannot do this at all, or can only do it after a firmware upgrade that the vendor must approve. Ask each equipment supplier to confirm, in writing, which certificate formats, key lengths, enrollment protocols and trust store sizes each model supports, and which models need a gateway to act on their behalf. Without that list, no one can estimate how many device types the project covers.

The second input is a current OT network diagram with zones and conduits marked, plus the paths that carry enrollment and renewal traffic from the CA to each cell, line or gateway. The diagram shows where an issuing CA can be reached, where a certificate revocation list or OCSP responder can be placed, and which segments must never talk to the internet. The plant team should also name a single OT engineering owner who can approve changes to controllers and historians, and a safety contact who signs off any change that could affect machine behavior. Change windows must be agreed in advance, because a device that loses its certificate during production can stop a line. Supplier access terms also need to be settled early: who from the vendor may log in to a controller, under what conditions, and who records that access.

Evidence assessors and regulators ask for from a device CA

This table maps each evidence set an assessor or regulator is likely to request from a device certificate authority to the component that produces it and the requirement it supports. Read it as a checklist for designing logging and records before the first device is provisioned, since evidence that is not captured at issuance is hard to reconstruct later. Confirm the exact evidence format with your assessor and your sector regulator, because the requirements listed here set the purpose of each record rather than a fixed template.

Evidence	Producing component	Related requirement
Certificate inventory per device and zone	step-ca or OpenBao issuance logs, joined with Wazuh asset data	ISA/IEC 62443 asset inventory expectations for OT zones and conduits; NIS2 risk management measures
Issuance and revocation logs for each device identity	step-ca or OpenBao PKI audit logs, forwarded to a central log store	Traceability of device enrollment and compromise response; NIS2 incident reporting timelines
CA policy and certificate profile documents	Written CA policy, certificate profiles and provisioner configuration exported from the CA	Documented security requirements for IACS components under ISA/IEC 62443-3-3 and 4-2 (confirm mapping with your assessor)
Key ceremony records for the issuing and root CA	Signed ceremony scripts, witness sign-off and HSM or cloud KMS configuration records	Protection of CA private keys; confirm required ceremony depth with your auditor
Renewal test results on representative devices	Test reports from devices with limited connectivity, including offline and reconnect scenarios	Availability and maintenance expectations for OT systems in NIST SP 800-82 Rev. 3
Access and audit records for CA administrators	Administrator authentication logs and CA change records, reviewed in Wazuh or the SIEM	Audit controls and unique user identification under 45 CFR 164.312 apply only if health devices are in scope; otherwise confirm which logging rules apply

Questions manufacturers ask before hiring help on device certificates

What drives the cost of a device certificate project?

The cost depends mostly on how many device types you have, how each one gets its identity today, and how much of the work your own team can absorb. Each device family needs its own enrollment path, certificate profile and renewal method, so a plant with a few controller models costs far less to bring under one CA than one with dozens of firmware generations. One-time costs include the CA design, key storage decisions (HSM, cloud KMS or hardware tokens), the provisioning integration on the production line, and documentation for auditors. Recurring costs include operating the CA, monitoring expiry, handling revocations and patching the CA itself. Ask any partner for a quote that separates these items, lists the device families in scope and states which integration work sits with your engineers. Fixed-scope agreements are written before work starts, so the scope document is where cost is actually decided.

How long does a device certificate pilot take?

A pilot runs as long as it takes to prove issuance, renewal and revocation on a representative set of devices, and the length is set by four drivers: how many device types are in the pilot, whether firmware on those devices can be changed to request certificates, how often production windows allow maintenance, and how quickly your OT and IT teams approve the trust design. A pilot on one line with a device that already supports ACME-style enrollment is much shorter than one that needs a firmware update from a vendor who controls release timing. Ask the partner to name the drivers in writing and to tie each milestone to a device or site, rather than to a calendar estimate. Any duration you are given should be tested against your change approval calendar.

What must our plant team do itself?

Your team keeps authority over the decisions that only the plant can make, and an implementation partner can carry the build work around them. Plant and OT staff should own the device inventory, the production windows, the list of safety-relevant machines that cannot be rebooted, and the approval of any change to controller firmware or network paths. Your IT or security team should own the CA hierarchy decisions, key custody policy, the identity provider or directory that authorizes enrollment, and the retention rules for audit logs. Vendors of PLCs and gateways must be engaged early when firmware changes are needed. A partner can document the procedures, build the automation and test it, but it cannot approve changes on equipment your organization operates.

Can device certificates be done without OT engineers?

A project can start without OT engineers only for the IT-side parts, and it cannot finish safely without them. Certificate issuance, the CA, inventory tooling and monitoring are IT work. Deciding which devices can be touched, which zones may carry traffic to the CA, how a failed renewal affects a running process, and what a safe fallback looks like all depend on people who understand the process being controlled. The ISA/IEC 62443 series, which sets requirements and processes for securing industrial automation and control systems, assumes that asset owners and system engineers work together on zones, conduits and security levels. Plan OT engineers into the design review and the pilot from the start, and treat their sign-off on each device family as a gate.

How does revocation work when a device is offline?

Revocation cannot reach a device that is disconnected, so the design relies on short certificate lifetimes, a published revocation list or status check that the device or its gateway can read once it reconnects, and cutoffs on the systems that accept the device. Short-lived certificates reduce how long a stolen identity stays useful, but they do not remove the need to block a device at the server, gateway or network layer. Ask the partner how the CA publishes revocation information, how far a device's peers rely on cached status, what happens when a device has been offline longer than its certificate lifetime, and who decides to reprovision a device after a suspected compromise. The answers should be tested in the pilot with a device that is deliberately disconnected.

Does step-ca support OT protocols directly?

step-ca is an X.509 and SSH certificate authority that issues and renews certificates. It does not speak OT protocols such as Modbus, PROFINET, EtherNet/IP or OPC UA, and it does not configure industrial equipment. Its role is to issue the certificates those devices and gateways present for TLS or mutual TLS, typically through ACME, OIDC, cloud instance identity or JWK provisioners. Whether a given PLC, gateway or historian can request and install a certificate depends on the device firmware and the vendor's support for certificate enrollment, so confirm that with each vendor before design. Where a device cannot renew itself, the usual pattern is a gateway or agent that holds the device credential and handles renewal on its behalf. Test that pattern on the actual hardware.

How do the CRA and NIS2 reporting timelines affect the design?

Reporting clocks change what your logs, inventory and vulnerability records must support, so they belong in the design from the beginning. NIS2 requires in-scope entities to send an early warning within 24 hours of a significant incident, an incident notification within 72 hours and a final report within one month. Manufacturing is a critical sector under NIS2 Annex II. The Cyber Resilience Act's Article 14 obligations to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026, and its product requirements apply from 11 December 2027. In practice, you need a current inventory of which device certificates exist, which firmware runs them, and how a compromised certificate is traced to affected lines within those windows. Ask the partner how the CA records issuance and revocation, how fast those records can be exported, and who is named as the reporting contact.

Is a SaaS PKI an alternative to a self-hosted CA?

A SaaS PKI can be an alternative, and the choice depends on where you need control. A managed service removes some CA operation work, but you still own the device enrollment design, the production integration, the inventory, and the evidence that auditors will ask for. Self-hosting keeps the CA and its keys inside your own cloud accounts, data centers or air-gapped networks, which matters when you need offline or enclave operation, or when a provider's trust hierarchy does not fit your OT zones. Compare the options on who holds the CA keys, where issuance logs are stored, how revocation reaches isolated segments, what happens if the provider is unreachable during a production window, and what each option costs to change later. Ask for written answers to those points from each option before you decide.

Questions to ask a partner before committing to device PKI work

Start with ISA-62443 experience, because it shapes every later answer. Ask the partner which parts of the ANSI/ISA-62443 series they have applied on live industrial sites, and whether they have worked on the asset owner side (ANSI/ISA-62443-2-1-2024, ANSI/ISA-62443-3-2-2020, ISA-62443-3-3-2013) or only on component certificate requirements (ANSI/ISA-62443-4-2-2018). Ask how they map each device certificate to a target security level and who signs off that mapping. Ask for a written example of a zone and conduit diagram from a past engagement with customer details removed, and request references only if they exist. Confirm every capability in writing before you rely on it.

Next, ask how they separate OT and IT trust chains. The answer should name separate intermediate CAs for plant and enterprise use, separate issuing policies and certificate profiles, and rules that stop an IT-issued certificate from being accepted as a device identity on a control network. Ask how the root and intermediates are stored, which roles can request device certificates, and how the partner tests that a compromised IT certificate cannot authenticate a PLC or gateway. Also ask how they handle firmware that cannot update its trust anchors. Require a written plan for pinning, a trust-store update path, or a replacement schedule for those devices, and a list of the devices affected. Ask how revocation works for disconnected devices, including whether they use CRLs with a defined refresh window, short-lived certificates that expire without contact, or a combination, and what happens when a device is offline past its renewal date.

Finally, ask about key storage, evidence and continuity. Ask which hardware options they support for CA and device keys (HSM, cloud KMS or YubiKeys, as supported by step-ca) and whether they can run key ceremonies on your premises. Ask what evidence pack they deliver: the certificate inventory, issuance and revocation logs, policy documents and test results. For reporting under the Cyber Resilience Act, ask how they would support patching and the Article 14 obligations, which have applied since 11 September 2026, and who inside their team would be available inside that window. Ask for a handover plan, and for the retainer terms that cover upgrades to the CA and to firmware-side tooling.

How DeployOpen scopes and supports device certificate work

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including device certificate work for manufacturing and IoT. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Map every device class, gateway and sensor family that needs a certificate, with its connectivity pattern and renewal window
Define which trust chains are in scope, separating OT enrollment from IT service identities and recording where each root lives
Agree in writing which revocation paths, provisioning points and audit logs the engagement will deliver before work begins

How we build

Configure the self-hosted CA, provisioners and certificate profiles, and deploy them inside your own cloud account, data center or air-gapped network
Build the provisioning step for factory enrollment and test renewal on devices with intermittent connectivity under realistic conditions
Run security testing against the enrollment, renewal and revocation paths, then remediate findings within the agreed scope

How we hand over

Document the hierarchy, key custody, profile catalog, device lifecycle runbooks and the steps for revoking a compromised device
Deliver an inventory format and evidence pack that your team and independent assessors can review against your own control set
Train operators on renewal monitoring, incident steps and CA backup and restore before handover is accepted

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build
Track CA software releases and plan upgrades on your change windows, with the scope of each upgrade agreed in writing
Ask us to repeat device enrollment and revocation tests whenever firmware, gateway or network architecture changes