Securing the OT/IT Boundary: A Practical Guide to IoT Cybersecurity

Industrial IoT security has a structural problem that enterprise IT does not: the devices outlive the assumptions. A sensor commissioned this year will still be running in 2041, on firmware someone must still be able to sign, with certificates someone must still be able to rotate, against threats nobody has described yet. Every design decision must be made with that horizon in mind.

Identity has to be rooted in hardware, or it is not identity

A device that authenticates with a credential in flash authenticates anything that has read that flash. Once a shared key or a copyable certificate is extracted from one unit — and physical access to a field device should be assumed, not debated — the attacker is indistinguishable from every device in the fleet.

Real device identity means a private key generated inside a secure element, never exported, with signing performed on-chip. The device proves possession without the key existing anywhere it can be read.

• Secure element or TPM: key generated on-die, marked non-extractable, with tamper response. The floor for anything deployed to an uncontrolled location.
• Certificate provisioned at manufacture and bound to that key, so identity is established before the device ever reaches a network.
• DICE for constrained parts that cannot carry a discrete secure element — layered key derivation rooted in an immutable device secret and measurements of each boot stage.
• Physically unclonable functions where even a stored device secret is unacceptable, deriving the key from silicon manufacturing variation rather than storing it.

With per-device asymmetric identity, compromise of one unit compromises one unit. With a shared symmetric key it compromises the fleet, and the remediation is a truck roll to every site. That difference is worth a great deal more than the per-unit cost of the secure element.

Secure boot: an unbroken chain, and the anti-rollback counter

Secure boot is a chain of measured, verified stages from an immutable root — mask ROM or OTP fuses — through bootloader, kernel and application. Each stage verifies the next before transferring control, and a break anywhere invalidates everything above it.

The control most often omitted is rollback protection. Verifying a signature proves an image is authentic; it does not prove it is current. Without a monotonic anti-rollback counter in fuses or secure-element storage, an attacker can install a genuinely signed but known-vulnerable earlier version and re-open a patched hole using nothing but a legitimate artefact.

bool accept_update(const image_t *img) {
    if (!verify_signature(img, ROOT_PUBKEY))      return false;  /* authentic  */
    if (img->version <= otp_read(ANTIROLLBACK))   return false;  /* not stale  */
    if (!verify_hash(img, img->declared_hash))    return false;  /* intact     */
    if (img->hw_rev != device_hw_rev())           return false;  /* right part */
    return true;
}

/* Advance the counter only after the new image boots and marks itself healthy.
   Advancing at install time bricks the device if the update fails to start. */

That final comment is a real failure mode with an expensive remedy. Burn the counter at install and a failed boot leaves a device that can neither run the new image nor legally accept the old one. The counter advances after the new firmware has confirmed itself operational, which means the A/B rollback path and the anti-rollback policy have to be designed together rather than separately.

Certificate lifecycle is the operational problem, not the cryptographic one

Mutual TLS with per-device certificates is well understood. Operating it across 200,000 devices for fifteen years is where programmes come apart, because it becomes a throughput problem.

Provisioning batches create synchronised expiry. Ten thousand devices manufactured in the same week will attempt renewal in the same week two years later, and if that burst exceeds the CA's capacity, devices that fail to renew drop off the network permanently. Randomise validity periods at issuance so expiry is spread, start renewal attempts at half of remaining lifetime, and retry with backoff and jitter across a long window.

Segmentation, and the protocols that have no security to configure

A large share of installed industrial protocols were designed for physically isolated networks and have no authentication whatsoever. Modbus/TCP will execute a write from anyone who can reach the port. This is not a misconfiguration to be corrected; it is the specification, and it will not be fixed on equipment already in the field.

The compensating control is architectural. The Purdue model's layered zones with enforced conduits between them remain the practical framework, and IEC 62443 formalises it: zones grouped by security requirement, conduits as the only paths between them, each with a defined security level derived from a risk assessment.

Zero-trust principles apply, with an honest caveat. You cannot authenticate a protocol that has no authentication. What you can do is authenticate and authorise at the conduit — an enforcement point that terminates the session, verifies the caller, applies policy, and re-originates the request onto the untrusted protocol — and monitor the zone for behaviour the process should never exhibit. A write to a safety setpoint from an engineering workstation at 3 a.m. is anomalous regardless of whether the protocol permitted it.

The regulatory position has changed, and the dates are close

Security in connected products has moved from good practice to statutory obligation. The EU Cyber Resilience Act imposes essential cybersecurity requirements on products with digital elements placed on the EU market, with vulnerability handling obligations, a coordinated disclosure process, and a duty to provide security updates for a defined support period. Reporting obligations for actively exploited vulnerabilities commence ahead of the main requirements, and the main obligations follow.

Alongside it, ETSI EN 303 645 provides the consumer baseline, IEC 62443 remains the governing framework for industrial automation, and NIST's IoT guidance covers the US federal procurement path. The common thread across all of them is documentation: a software bill of materials, a declared support lifetime, and a demonstrable vulnerability-handling process. These are not things that can be retrofitted to a product already in the field, which is why the design decisions described above have to be made at the start of a programme rather than in response to an assessment.

The short version

Hardware-rooted per-device identity. An unbroken verified boot chain with rollback protection whose counter advances only after a healthy boot. Certificate automation designed for burst expiry. Conduit-level enforcement in front of protocols that cannot defend themselves. And an SBOM and support commitment that exist because the regulation now requires them. None of this is novel. All of it is far cheaper before the first unit ships than after the hundred-thousandth.