NIS2 compliance for IoT platforms: the complete guide.

NIS2 is Directive (EU) 2022/2555. It applies to essential and important entities across eighteen sectors. Essential covers energy including district heating, drinking water, wastewater, health, transport, digital infrastructure, and public administration. Important covers waste management, postal services, chemicals, food, manufacturing, and research.

The general size threshold is 50 employees or 10 million euro in annual turnover, with exceptions: sole providers and entities critical to public safety can be designated regardless of size. Public administration is in scope at central and regional level, and each member state decides about municipalities. Several, Sweden among them, include municipalities and regions.

The practical reading: if you operate water, energy, health, or municipal digital infrastructure, plan on being covered and let a lawyer confirm the edge cases.

The directive regulates the network and information systems an entity uses to provide its service. For a utility or a city, that includes the meter fleet, the radio network, the gateways, the ingestion platform, the time-series database, the dashboards, and every integration between them.

The common failure is a scope statement that covers office IT and stops at the field network. The definition in the directive is broad on purpose, and an estate of ten thousand cheap, physically accessible, rarely patched devices is exactly the attack surface it was written for.

Article 21(2) lists ten minimum measures. Every entity in scope implements all ten, sized to its risk. Here is what each one means for an IoT platform.

• Risk analysis and security policies. A written threat model of the estate: devices, radio links, backhaul, platform, integrations. Kept current as the estate changes, not filed after go-live.
• Incident handling. Detection, an on-call path, and a runbook that says who isolates a misbehaving gateway and how.
• Continuity, backups, and disaster recovery. Restores you have rehearsed, and a plan for running the service while the platform is degraded.
• Supply chain security. You know what is inside your devices and your vendors’ stacks, and the contracts carry security obligations.
• Secure acquisition, development, and maintenance. A patching path for firmware, secure development practice on the platform, and a route for reporting vulnerabilities to you.
• Effectiveness assessment. Evidence that the controls work: audits, tests, metrics. A policy that exists only on paper fails this one.
• Cyber hygiene and training. Including the operations staff who handle field devices, not only the IT department.
• Cryptography. Encrypted in transit and at rest, with a documented policy and keys you control.
• Access control and asset management. Per-device identity, scoped credentials, an asset register that updates itself from the platform, and offboarding that actually revokes access.
• Multi-factor authentication and secured communications. MFA for every human, mutual authentication for every machine.

Article 23 attaches deadlines to significant incidents: an early warning within 24 hours, an incident notification within 72 hours, and a final report within a month. The clocks start when you become aware of the incident.

Meeting them requires a platform that can reconstruct a timeline: logs retained in a readable format, timestamped alerts, and someone able to say what happened, on which devices, since when. If your current tooling cannot answer that in an afternoon, this is one of the first gaps to close.

Most public-sector IoT estates are run by a supplier: the platform is hosted, the devices are managed, the dashboards are rented. None of that moves the obligation. NIS2 places the duty on the entity that provides the service, and Article 20 makes management responsible for approving and overseeing the measures, with personal liability attached.

What you can do is pass requirements down the chain. A platform contract compatible with NIS2 gives you incident notification measured in hours, audit rights, a firmware patching commitment, data ownership, and exit terms that let you leave with your history intact. If a supplier declines to sign those, that fact belongs in your risk analysis.

The list above is long. This is the order we work it in, because each step makes the next one cheaper.

1. 01 Inventory. A complete register of devices, firmware versions, SIMs, and networks. You cannot secure, patch, or report on an estate you have not counted.
2. 02 Identity and access. Per-device credentials with no shared secrets across the fleet, MFA for humans, scoped API keys for integrations.
3. 03 Segmentation. A breach in the field stays in the field. A compromised meter that can reach your database is an architecture problem, not a device problem.
4. 04 Logging and reporting readiness. Retention, timestamps, and a rehearsal: try producing a 72-hour incident notification from your current tooling.
5. 05 Backups and recovery. Tested restores, and a documented degraded mode for the service itself.
6. 06 Supplier contracts. Renegotiate the ones that fail the previous five steps, at renewal or sooner.

Policies, training, and effectiveness reviews run alongside all six. They are continuous obligations rather than steps you finish.