Device protection by sector: why identity and secrets must be baked in

At a glance

What this is: This is a sector-by-sector analysis of device protection that finds digital secrets, certificate lifecycle management, and supply chain integrity must be built into IoT and OT security from the start.

Why it matters: It matters because the same governance gaps that weaken NHI programmes, weak lifecycle control, poor rotation, and incomplete visibility, also undermine device identity and trust at scale.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read DigiCert's sector analysis of device protection strategies

Context

Device protection in IoT and operational technology is really an identity and trust problem: systems need to know which device, key, certificate, or operator is allowed to act, and for how long. DigiCert’s sector analysis argues that older assumptions about perimeter defence, static hardening, and retrofitted controls no longer fit interconnected, high-availability environments.

That matters for IAM and NHI programmes because device identities behave like non-human identities with lifecycle, rotation, revocation, and audit requirements. The stronger message is not that more security tools are needed, but that trust must be designed into onboarding, maintenance, recovery, and supply chain delivery from the beginning.

Key questions

Q: How should security teams protect device identities in connected environments?

A: They should treat each device credential as a governed identity with an owner, a purpose, and a lifecycle. That means controlling issuance, rotation, renewal, and revocation, and pairing those controls with signed updates and traceable maintenance actions. In live OT and IoT environments, the goal is not isolation at any cost, but verifiable trust with minimal operational disruption.

Q: Why do digital secrets create such large risk in IoT and OT?

A: Digital secrets create large risk because they are the proof mechanism for device trust. If passwords, keys, or certificates are exposed or stale, attackers can impersonate devices, alter configurations, or misuse remote maintenance channels. In connected fleets, one compromised secret can propagate across many endpoints, so lifecycle control matters as much as cryptographic strength.

Q: What breaks when device security is added after deployment?

A: Retrofit security usually breaks alignment between identity, maintenance, and operational reality. Controls may depend on perimeter segmentation, manual updates, or inspection of traffic that is already encrypted or safety-critical. The result is fragile protection that either fails to detect compromise or forces outages when containment is attempted.

Q: Which frameworks should guide device identity and trust governance?

A: NIST Cybersecurity Framework 2.0 and Zero Trust Architecture are useful starting points because they emphasise continuous protection, identity-aware control, and resilience. For device-heavy programmes, NHI lifecycle thinking also helps teams manage secrets, certificates, and revocation as governed assets rather than one-off technical tasks.

Technical breakdown

Why bolted-on controls fail in connected device environments

Connected device environments break traditional hardening models because the devices are live, distributed, and often safety-critical. A VLAN-style containment approach that works for user endpoints can cause outages in OT, while firewalls and intrusion detection systems are frequently retrofitted onto protocols that were never designed for hostile networks. As encryption becomes more common, deep-packet inspection also loses visibility unless the application layer is re-engineered. The practical result is that security has to move closer to identity, integrity, and lifecycle control rather than relying on network inspection alone.

Practical implication: treat device identity, message integrity, and recovery design as first-class controls instead of relying on perimeter detection.

Digital secrets, certificates, and remote maintenance

The article places passwords, keys, and X.509 certificates at the centre of device protection because they are the mechanisms that prove authenticity and enable trusted delivery. In these sectors, secrets are not just login artifacts. They are the basis for secure messaging, trusted updates, device recovery, and lifecycle management across remote fleets. If rotation is delayed or renewal is manual, compromise becomes persistent rather than contained. Certificate-backed trust only works when issuance, renewal, revocation, and audit trails are handled as an operational lifecycle, not a one-time setup step.

Practical implication: map every device credential to an owner, a rotation trigger, and a revocation path before deployment.

Supply chain trust and auditability for device fleets

The sector examples repeatedly show that trust extends beyond the device itself into the manufacturing, delivery, and maintenance chain. Tamper-resistant content delivery, trusted configuration updates, and auditability are needed because a compromised update path can undermine thousands of devices at once. This is the same structural problem seen in machine identity governance: if the trust anchor is not protected from birth, the entire lifecycle inherits that weakness. Auditability is therefore not just compliance reporting. It is the evidence that identity, delivery, and change control remained intact across the device estate.

Practical implication: require end-to-end traceability for device software, certificates, and maintenance actions across the supply chain.

Threat narrative

Attacker objective: The attacker aims to subvert trusted device operations by gaining durable control over identity, updates, or messaging paths.

1. Entry occurs when insecure industrial protocols, exposed device channels, or untrusted supply chain delivery introduce access to connected device systems.
2. Credential access or abuse follows when passwords, keys, or certificates are weakly protected, poorly rotated, or reused across device fleets.
3. Escalation happens when compromised trust mechanisms allow malicious software, configuration changes, or remote maintenance actions to spread across live systems.
4. Impact is operational disruption, unsafe behaviour, data exposure, or large-scale compromise of device fleets and the services they support.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Security for connected devices fails when organisations treat trust as a perimeter property. DigiCert’s sector framing reinforces a core identity lesson: the device, the key, the certificate, and the maintenance channel are one governance chain. If any one link is bolted on after deployment, the whole chain inherits uncertainty. Practitioners should read this as a lifecycle problem, not a network problem.

Digital secrets are device identities, not just technical artefacts. Passwords, keys, and X.509 certificates define what the device can prove, what it can receive, and what it can update. That makes rotation, renewal, and revocation governance functions, not maintenance chores. The practical conclusion is that device identity controls need the same lifecycle discipline now applied to service accounts and other NHIs.

Built-in protection is the only durable model for safety-critical environments. The article is right that reactive monitoring cannot compensate for insecure foundations in OT, healthcare, transportation, or defense. Where live systems cannot be safely quarantined, prevention must be embedded into identity, update pathways, and integrity verification. Practitioners should reframe “hardening” as controlled trust establishment across the full device lifecycle.

Supply chain trust is an identity problem disguised as a logistics problem. Tamper-resistant delivery, trusted configuration, and historic audit trails are all about proving that the right identity touched the right artifact at the right time. That connects device security directly to governance, accountability, and change control. The implication is clear: if the chain of custody is weak, the chain of trust is already broken.

Identity blast radius is the right concept for sector-based device protection. When thousands of endpoints, sensors, or controllers share the same trust pattern, a single weakness can propagate widely. Sector variation matters because the consequences of that blast radius differ across healthcare, energy, aviation, and defense. Practitioners should design for containment by identity scope, not by device count alone.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a deeper lifecycle lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, which helps translate visibility gaps into ownership, rotation, and offboarding controls.

What this signals

Identity blast radius: sector-based device protection will increasingly be judged by how tightly organisations can constrain the spread of a single credential or certificate failure. When fleets share the same trust pattern, the operational risk is not just compromise, but propagation across maintenance channels, update paths, and downstream services.

Teams should expect device identity governance to converge with NHI governance, especially where certificates and keys function as long-lived trust primitives. The practical shift is toward lifecycle management, evidence of revocation, and auditability that can withstand regulated environments and safety-critical operations.

With only 5.7% of organisations reporting full visibility into their service accounts, per our Ultimate Guide to NHIs, visibility is already a weak point for machine identity programmes. The same blind spot will surface in IoT estates unless device trust anchors are inventoried and owned from the start.

For practitioners

• Inventory device trust anchors by sector Catalogue which devices rely on passwords, keys, certificates, or hardware roots of trust, then assign an owner and lifecycle policy to each trust anchor. Link this inventory to onboarding, renewal, and revocation workflows so the organisation can see where trust is created and where it is lost.
• Make certificate rotation operational, not occasional Set renewal triggers for X.509 certificates and other device secrets based on risk, maintenance windows, and device criticality. Use automated renewal where possible and ensure emergency revocation can be executed without waiting for manual maintenance cycles.
• Require tamper-resistant update delivery Validate that firmware, configuration, and software updates are signed, traceable, and verifiable before they reach field devices. Extend this requirement to distributors, integrators, and service providers so the update chain remains trustworthy end to end.
• Test recovery without network quarantine assumptions Run incident simulations that assume devices cannot be isolated without operational disruption. Build recovery paths for trusted software replacement, configuration rollback, and key renewal that preserve availability while restoring integrity.

Key takeaways

• Device protection in IoT and OT fails when trust is bolted on after deployment instead of built into identity, update, and recovery workflows.
• Digital secrets and certificates are lifecycle assets, so rotation, renewal, revocation, and auditability matter as much as cryptographic strength.
• The practical response is to govern device trust anchors like non-human identities, with ownership, visibility, and supply chain traceability from birth to offboarding.

Key terms

• Device Trust Anchor: A device trust anchor is the root credential or hardware-backed identity that lets a device prove it is genuine and authorised. In practice, it underpins secure messaging, update validation, and lifecycle actions such as renewal or revocation across connected fleets.
• Certificate Lifecycle Management: Certificate lifecycle management is the controlled process of issuing, renewing, rotating, and revoking digital certificates. For device environments, it is a governance function that keeps trust current, limits stale access, and supports safe maintenance across large, distributed estates.
• Tamper-Resistant Delivery: Tamper-resistant delivery is the practice of ensuring software, configuration, and content reach devices without unauthorised alteration. It relies on signing, traceability, and verification so the receiving system can confirm both integrity and provenance before applying change.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: The Elixir of Things: Strategies for Device Protection by Sector. Read the original.