Continuous verification of every device, user and connection inside the OT network, rather than trusting anything already inside the traditional Purdue-model perimeter.
Embedded device-level cybersecurity (secure identity & boot)
Cryptographic device identity, secure boot and signed firmware built into field controllers and smart final-control elements themselves, not bolted on at the network layer.
Short entry. This page summarises our current placement. Full, sourced analyses are published first for the technologies closest to practical use; see the list of full analyses.
How it works
Device-level security starts with a hardware root of trust, a protected chip or processor region that holds cryptographic keys which cannot be read out. At power-up, each stage of software verifies the digital signature of the next before running it. If the firmware has been altered, the chain breaks and the device refuses to start it.
The same protected keys give the device an identity. A manufacturer-installed certificate proves what the device is; the owner can add a site-specific certificate when it is commissioned. With identities in place, devices and controllers can authenticate each other and encrypt or sign their communications, and firmware updates are accepted only if they are signed by the vendor.
Why it matters
Extends zero-trust principles down to the device that actually moves the valve, closing the gap left by network-only OT security architectures.
Where it fits
This matters most for devices that sit outside the control room and are physically reachable: remote I/O, field controllers, drives, smart final elements and gateways. It is increasingly a procurement requirement under component security standards and under product cybersecurity regulation. For the installed base, the practical route is compensating controls around the device, since the hardware cannot be added later.
Why we place it at the Emerging Idea stage
Emerging first in newer remote I/O and safety controller product lines; retrofit to the installed base of legacy field devices is not realistically possible. Estimated time to the Proven in Use stage: 5–10 yrs. What the stages mean.
Key risk
Certificate lifecycle management (issuance, rotation, revocation) at field-device scale is an operational capability few OT teams have built yet.
Questions to ask before committing
- Which specific capabilities does the product have: secure boot, signed updates, unique device identity, authenticated communication?
- Who will run the certificate infrastructure, and what happens operationally when a certificate expires?
- Can a failed device be replaced and enrolled by a technician on shift, or does it need a security specialist?
Standards and terms to know
- Root of trust
- The hardware-protected foundation on which a device's security checks rest.
- IEEE 802.1AR
- The standard for secure device identity, including manufacturer and locally issued certificates.
- IEC 62443-4-2
- The part of the industrial security standard that sets technical requirements for components.
Related technologies
See this entry on the full maturity map · All Control Devices entries · How placements are made. Stage and time-horizon placements are editorial judgements based on public information as of October 2026, not engineering, safety or investment advice; see the Terms of Use.