Cyber resilience for connected devices without breaking operations

At a glance

What this is: This is a Keyfactor analysis of how connected devices can meet CRA-driven resilience requirements through PKI, certificate automation, and orchestration without forcing disruptive reengineering.

Why it matters: It matters because device identity, lifecycle control, and cryptographic automation increasingly sit inside the same governance problem as NHI and workload identity management.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Keyfactor's analysis of cyber resilience for connected devices under the CRA

Context

Connected device resilience is really a lifecycle identity problem: if devices cannot be reliably identified, trusted, updated, and audited, security controls remain partial no matter how strong the crypto primitives are. The article argues that the Cyber Resilience Act raises the bar for device identity and updateability, especially where industrial and IoT environments already contain legacy systems, mixed transport protocols, and constrained hardware.

For IAM, NHI, and OT security teams, the important shift is that device security no longer stops at onboarding. Identity governance now has to cover certificate issuance, renewal, revocation, and post-deployment auditability across brownfield and greenfield environments, which is why the same governance lens used for machine identities increasingly applies here.

Key questions

Q: How should teams govern certificate lifecycle for connected devices at scale?

A: Treat certificates as governed identities with lifecycle ownership, not as static technical artefacts. Assign clear responsibility for issuance, renewal, revocation, and audit evidence across device classes, then automate those steps where possible. In mixed OT and IoT estates, the main failure point is usually not crypto strength but inconsistent operational control.

Q: Why do connected devices create more governance pressure than traditional endpoints?

A: Connected devices are harder to patch, harder to observe, and often distributed across factories, field locations, and third-party environments. That means identity, updateability, and trust must work through lifecycle automation rather than one-off administration. The governance burden grows when devices must remain operational while security controls change underneath them.

Q: What breaks when certificate management is handled manually in IoT and OT environments?

A: Manual handling breaks scale, consistency, and recovery. Teams miss expirations, revoke the wrong credentials, and create outages when trust decisions are applied unevenly across device families. It also makes audit evidence unreliable because the control process depends on people remembering steps that should be repeatable and machine-enforced.

Q: Who should own device trust governance across manufacturing and operations?

A: Ownership should sit across security, engineering, and operations, with one accountable model for device identity and certificate lifecycle decisions. If manufacturing, deployment, and field operations each run separate trust processes, governance fragments and auditability disappears. The right model is shared responsibility with one control framework and clear lifecycle handoffs.

Technical breakdown

How PKI establishes trusted device identity

Public key infrastructure gives connected devices a verifiable identity by binding cryptographic keys to certificates that can be checked during onboarding and communication. In IoT and OT environments, this matters because devices may be resource constrained, remotely deployed, or split across multiple trust domains. Birth, join, and platform certificates support different lifecycle stages, while code signing protects firmware and software provenance. The hard problem is not issuing certificates once, but maintaining trust when devices move between factory, shipment, deployment, and decommissioning.

Practical implication: map certificate issuance to device lifecycle stages and treat identity as a governed asset, not a one-time setup.

Certificate lifecycle management in mixed OT and IoT environments

Certificate lifecycle management is the operational layer that prevents trust from expiring silently. In connected device estates, certificates may fail for ordinary reasons such as short lifetimes, delayed renewal, revoked in-use credentials, or disconnected environments that cannot report status in real time. The article also points to late provisioning and zero-touch methods as ways to reduce shipping delays and human error, but those only work if renewal, revocation, and audit trails are automated across both public and private PKI. Without that, the cryptographic control plane becomes another outage source.

Practical implication: automate expiration, renewal, and revocation workflows before scaling device rollouts or enforcing tighter compliance.

Zero-touch orchestration for brownfield and greenfield devices

Device orchestration becomes necessary when the environment includes millions of devices, multiple vendors, and mixed transport protocols. The article describes zero-touch provisioning, low-code integration, and metadata-driven visibility as the practical way to manage trust without reengineering every endpoint. That approach is especially relevant where devices cannot support heavy agents or complex key management stacks. Orchestration only works, however, if the trust layer is interoperable across SCADA, SIEM, and asset systems, otherwise identity state and operational state drift apart.

Practical implication: design for orchestration across heterogeneous devices and integrate identity state with operational telemetry.

NHI Mgmt Group analysis

Connected device resilience is now an identity governance problem, not just a product security problem. The article shows that compliance, trust, and operational continuity depend on whether devices can be identified, updated, and audited across their full lifecycle. That is the same governance burden NHI teams already face with service accounts and certificates. Practitioners should stop treating device security as a bolt-on control set and manage it as governed identity infrastructure.

Certificate expiration and revocation are the hidden failure modes in resilient device programmes. The article repeatedly returns to renewal, revocation, and audit trails because those are the points where trust breaks in the field. This is a classic lifecycle control problem: the cryptography may be sound, but the governance around it is brittle. Identity lifecycle control: the real risk is not issuance, it is losing control after deployment when devices are offline, constrained, or operating across multiple domains. Practitioners should prioritise lifecycle visibility over one-time provisioning success.

Brownfield constraints expose the limits of manual trust administration. Legacy OT and IoT estates do not fail because teams lack policy intent. They fail because manual certificate handling, cross-domain PKI sprawl, and inconsistent transport support make trust decisions non-repeatable at scale. That is why zero-touch orchestration is a governance requirement, not a convenience. Teams should evaluate whether their current control model can still function when devices cannot be touched directly.

Device identity and workload identity are converging around the same governance questions. Both depend on immutable identity, lifecycle automation, and evidence that trust can be established without human intervention at each step. The article signals that device programmes are moving into the same operating model as machine identity programmes, where visibility and policy enforcement matter more than the underlying form factor. Practitioners should align IoT, OT, and NHI governance rather than run them as separate disciplines.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For lifecycle controls that extend beyond a single environment, see Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs.

What this signals

Identity governance for devices will increasingly be judged by lifecycle evidence, not policy intent. If a programme cannot prove when a device certificate was issued, renewed, revoked, or decommissioned, it will struggle to satisfy both resilience goals and audit scrutiny. For teams that already manage NHIs, the organisational pattern is familiar: visibility gaps create control gaps, and control gaps become operational risk.

Certificate automation should be treated as operational resilience infrastructure. The practical signal is whether trust can be maintained without manual intervention during outages, constrained connectivity, or hardware refresh cycles. That is where the next wave of device governance maturity will be measured, especially for organisations trying to bridge manufacturing, field operations, and security oversight.

Identity programmes that separate IoT, OT, and machine identity are creating avoidable drift. The more useful model is a shared governance layer for immutable identity, certificate handling, and offboarding evidence, with controls adapted to device class rather than programme silo. That alignment will matter more as regulators expect proof of lifecycle security after deployment.

For practitioners

• Map device identity to lifecycle stages Define how birth, join, active operation, renewal, revocation, and decommissioning will be handled for each device class, including constrained and offline systems.
• Automate certificate renewal and revocation Remove manual dependency from expiry handling, especially for short-lived certificates and environments where delayed action can interrupt field operations.
• Unify trust telemetry across OT and IT tools Correlate PKI state with SCADA, SIEM, and asset data so identity drift, expired credentials, and unmanaged devices are visible before they become outages.
• Test zero-touch onboarding in brownfield conditions Validate whether provisioning still works when bandwidth is limited, device memory is constrained, and endpoints cannot host heavy agents or custom workflows.

Key takeaways

• The article frames connected device security as a lifecycle governance problem, not a single control problem.
• The strongest operational risk is certificate drift, because trust can fail long after deployment if renewal and revocation are not automated.
• Teams should align PKI, orchestration, and audit evidence into one governed device identity model before scaling CRA compliance efforts.

Key terms

• Certificate Lifecycle Management: The operational discipline for issuing, renewing, revoking, and auditing certificates across their full life. In connected device environments, it is the control layer that keeps trust valid after deployment, especially when endpoints are offline, constrained, or spread across multiple domains.
• Device Orchestration: The coordinated automation of onboarding, updates, trust enforcement, and operational control across heterogeneous devices. It matters because IoT and OT estates often combine many vendors, protocols, and resource limits, making manual administration too slow and inconsistent for reliable governance.
• Trusted Device Identity: A verifiable cryptographic identity assigned to a device so its authenticity can be checked during onboarding and communication. In practice, it connects certificates, keys, and lifecycle controls to the device itself, rather than relying on network location or manual approval.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Keyfactor: How to Build Cyber Resilience for Connected Devices Without Breaking What’s Already Working. Read the original.