nis2 security compliance

NIS2 for IoT, without the panic

NIS2 turns a lot of public-sector IoT estates from optional to in-scope overnight. A practical read on what the directive actually asks of a sensor platform.

Poya Shad 2 min read

NIS2 widened the net. A lot of organisations that were comfortably out of scope under the original directive now find their water metering, building management, and traffic sensors counted as essential or important services. The reaction is usually panic, then a procurement for a compliance product. Both are avoidable.

The directive is not a checklist you buy. It is a set of obligations about how you run a system. Most of them are things a well-built IoT platform should already do. Here is the honest version of what it asks.

Know what you have

You cannot secure an estate you have not inventoried. The first NIS2 conversation is rarely about firewalls. It is about the fact that nobody has a complete list of which sensors are deployed, what firmware they run, and which network they sit on. An asset register that updates itself from the platform is worth more than any single control.

Assume the device is hostile

Field sensors are physically accessible, cheaply made, and rarely patched. Treat every device as potentially compromised. That means per-device identity, scoped credentials, and an ingestion layer that validates rather than trusts. A sensor should be able to report a reading and do nothing else. If a compromised meter can reach your database, the architecture, not the meter, is the vulnerability.

Be able to tell the story

NIS2 has reporting obligations with real clocks attached. An early warning within 24 hours, a fuller notification within 72. You cannot meet those if you cannot see what happened. Logging, retention in a readable format, and the ability to reconstruct a timeline are not nice-to-haves. They are the difference between a contained incident and a regulatory problem.

The controls that actually matter

  • Identity per device, rotated. No shared secrets across a fleet.
  • Encrypted in transit and at rest, with keys you control.
  • Network segmentation so a breach in the field stays in the field.
  • Tested backups and a recovery you have rehearsed, not one you assume works.
  • Supplier accountability written into the contract, so the chain is auditable.

Why ownership helps here

Compliance is a continuous obligation, not a certificate. If meeting it depends on a vendor whose roadmap you do not control, every directive update becomes a negotiation. When you own the code and the data, you can answer an auditor directly, patch on your own schedule, and prove the chain of custody without asking permission. Sovereignty and security turn out to be the same conversation.

NIS2 is demanding, but it is not mysterious. Build the platform properly and most of the directive is already satisfied. The panic comes from systems that were never built to be inspected.

Poya Shad
written by
Poya Shad

Founder of Zero46. Building IoT and sensor-data platforms for companies and public sector.

// talk to us

Building something that has to survive production?

Book a 30-minute call and tell us what you're working on. If it fits, we follow with a two-hour working session: architecture sketch, honest scope, no invoice.

Book 30 min