The EU NIS2 directive 2022/2555 sets cybersecurity risk-management and incident-reporting rules for medium and large organizations across 18 critical sectors, including manufacturing, energy, and digital infrastructure. Member states were required to apply their national transposition measures from October 18, 2024.
For industrial companies running MQTT and IIoT infrastructure, NIS2 can make broker security, access control, and monitoring part of the measures needed to meet legal obligations rather than purely internal best practices.
NIS2: key takeaways
- The NIS2 directive covers entities across 18 EU sectors; national laws must provide maximum fines of at least €10 million for essential entities and €7 million for important entities.
- NIS2 requires organizations to report significant incidents within 24 hours for an early warning, 72 hours for an incident notification with an initial assessment, and one month after that notification for a final report.
- NIS2 Article 21 defines ten categories of technical and organizational security measures, covering encryption, access control, supply chain security, and business continuity.
- Cedalo’s Enterprise MQTT Platform helps industrial companies meet NIS2 Article 21 requirements through encrypted broker connections, role-based access control, audit logging, and clustered high availability.
What is the NIS2 directive?
NIS2 replaced the original NIS Directive from 2016 and expanded its scope from 7 to 18 sectors. It requires organizations to manage cybersecurity risk systematically and to notify authorities when incidents disrupt their services. Company management bodies must approve and oversee these measures directly, and they can be held liable if they don’t.
NIS2 vs. NIS1: what changed
NIS1 left most classification decisions to individual member states, which produced uneven coverage across the EU. NIS2 replaces much of that discretion with a largely size-based rule: medium and large entities operating in the listed sectors generally fall within scope, subject to specific exceptions.
Which sectors and company sizes are in scope
NIS2 splits regulated organizations into essential and important entities. The distinction affects how closely authorities supervise a company, not which security measures apply.
| Category | Example sectors | Supervision |
|---|---|---|
| Essential entities | Energy, transport, health, digital infrastructure | Proactive audits and inspections |
| Important entities | Selected manufacturing sectors, chemicals, food, postal services, digital providers | Reviewed mainly after an incident or complaint |
Is your company affected by NIS2?
A company generally falls under NIS2 if it operates in a listed sector and qualifies as at least a medium-sized enterprise under the EU SME definition. Smaller entities can still fall into scope under specific NIS2 exceptions, including certain critical and digital infrastructure entities regardless of size.
Why industrial and manufacturing companies are now in scope
The original NIS Directive barely touched manufacturing. NIS2 adds manufacturing of critical products, along with several other industrial categories, which pulls a large number of OT-heavy organizations into scope for the first time. Many of these companies now need to secure machine-to-machine communication and cloud connectivity that previously sat outside any formal compliance requirement.
What does NIS2 require from industrial OT/IT environments?
Article 21 requires an all-hazards approach: organizations must protect network and information systems against a broad range of risks, not just cyberattacks. For a company running MQTT as its data backbone between machines, sensors, and cloud systems, several of these requirements point directly at broker configuration.
From legal requirement to MQTT security measure
The table below translates the Article 21 categories most relevant to industrial data infrastructure into concrete technical steps and the documentation an auditor would expect to see.
| NIS2 requirement (Article 21) | OT/IIoT risk | MQTT security measure | Documentation |
|---|---|---|---|
| Cryptography and encryption | Plaintext MQTT traffic between machines and cloud | TLS/mTLS encryption on broker connections where appropriate | TLS configuration records, certificate inventory |
| Access control and asset management | Shared or generic broker credentials | Role-based access control per client and topic | User and role assignment logs |
| Incident handling | Broker failures or intrusions go unnoticed | Centralized logging and real-time monitoring | Log retention policy, monitoring dashboards |
| Business continuity | Single broker instance as a point of failure | Clustering and automatic failover | Failover test reports, uptime records |
| Supply chain security | Broker software or container images of unverified origin or integrity entering your stack | Source the broker from a maintained vendor and verify the provenance and integrity of its binaries and container images (signed images, checksums, and a published SBOM) | SBOM, image signatures and checksums, vendor security and support agreements |
| Vulnerability handling | Outdated broker software with known vulnerabilities | Risk-based vulnerability and patch management | Patch logs, support agreement |
Business continuity and high availability
A single MQTT broker instance without redundancy can halt production data flow when it goes offline. Clustering distributes broker load across multiple nodes and can keep data moving during maintenance or hardware failure, which supports the continuity requirement in Article 21(2)(c).
How do you secure MQTT and IIoT communication under NIS2?
Meeting Article 21 at the communication layer comes down to four technical areas: encryption, access control, monitoring, and availability. Each maps to a specific configuration change on the broker side.
TLS/mTLS encryption for MQTT traffic
Unencrypted MQTT traffic exposes machine data, credentials, and commands to anyone with network access. A MQTT TLS configuration guide walks through setting up TLS and mutual TLS so that both broker and client verify each other’s identity before exchanging data.
Access control and authentication
Generic or shared broker logins make reliable attribution of who published or subscribed to a given topic difficult, which can weaken the access-control measures required under Article 21(2)(i). Setting up MQTT authentication and authorization on Mosquitto ties every client to a unique client identity and restricts topic access by role.
Logging and monitoring for audit readiness
Auditors expect evidence, not assurances. Mosquitto broker logging captures connection events and broker activity, while a connected Grafana dashboard for MQTT monitoring turns broker metrics collected through Prometheus into a real-time view of broker health across sites.
High availability and clustering
Configuring MQTT high availability removes the single point of failure from the broker layer and distributes traffic across multiple nodes, which keeps production data flowing even when individual hardware fails.
Keep your MQTT broker running through any failure
Clustering distributes broker load across multiple nodes, so a single node failure does not have to take production data offline when appropriate redundancy is in place.
What are the deadlines and penalties for NIS2 non-compliance?
NIS2 regulations set reporting timelines and minimum requirements for national maximum fines. Breaches can lead to financial and legal consequences for the entity and, in specific cases, its management.
| Reporting stage | Deadline | Content |
|---|---|---|
| Early warning | Within 24 hours | Initial notice, possible cross-border impact |
| Incident notification | Within 72 hours | Severity, impact, indicators of compromise |
| Final report | Within 1 month | Full description, root cause, mitigation steps |
Member states must provide maximum fines of at least €10 million or 2% of global annual turnover for essential entities and at least €7 million or 1.4% for important entities, whichever is higher. Management bodies can be held liable for infringements of Article 21 under applicable law.
How do you build a NIS2 compliance roadmap for your MQTT infrastructure?
A roadmap turns Article 21 into a project plan rather than a legal abstraction.
- Confirm your scope: Check company size, sector, and turnover against the essential/important entity thresholds.
- Map your current MQTT setup against Article 21: Document encryption status, access control, logging, and failover for every broker in production.
- Prioritize the gaps with the highest exposure: Assess unencrypted connections, shared credentials, and documentation gaps according to your organization’s specific risk assessment.
- Implement the technical measures: Prioritize TLS, access control, monitoring, and clustering according to the risks identified.
- Document everything as you go: Auditors may ask for evidence, so relevant certificates, logs, and test reports should be available where applicable before an incident happens.
Turn NIS2 requirements into a working compliance plan
NIS2 requires industrial companies to protect their network and information systems with appropriate measures and report significant cybersecurity incidents, not just describe good intentions in a policy document. Encryption, role-based access, centralized logging, and clustered high availability cover several of the Article 21 categories directly at the broker layer, and each one produces the kind of evidence an auditor expects to see.
Your advantages with Cedalo:
- You run TLS/mTLS encryption and role-based access control on a broker built from Eclipse Mosquitto, the world’s most deployed MQTT broker.
- You get audit-ready logs and a monitoring dashboard instead of piecing together evidence after an incident.
- You keep production data flowing through clustering and automatic failover instead of relying on a single broker instance.
- You connect Kafka and databases through Pro Mosquitto’s native bridges, so SCADA, ERP, and analytics systems consume the same broker data.
Start learning how enterprise MQTT supports compliance
The MQTT Academy covers broker security, clustering, and monitoring in practical lessons, helping your team map NIS2 requirements to your infrastructure before purchasing decisions.
NIS2 – frequently asked questions
Does NIS2 apply to companies outside the EU?
Yes, certain non-EU providers fall under NIS2 if they offer covered digital services, such as cloud computing or online marketplaces, within the EU and meet the Directive’s scope criteria. These providers must designate a representative in an EU member state where they offer services.
What is the difference between NIS2 and the Cyber Resilience Act?
NIS2 governs how organizations manage cybersecurity risk and report incidents. The Cyber Resilience Act sets security requirements for products with digital elements, including vulnerability handling throughout their support period.
Can an MQTT broker alone make a company NIS2 compliant?
No single component covers every Article 21 requirement. An MQTT broker with encryption, access control, and logging built in addresses several technical measures directly, while organizational steps like risk assessments and staff training happen separately.
How does Cedalo’s MQTT platform support NIS2 documentation?
Audit trails, connection logs, and access records are produced by the broker itself and across the Cedalo MQTT Platform; the Management Center centralizes and surfaces them in one place. These logs give compliance teams evidence for Article 21 measures without manual tracking across multiple systems.
What counts as a significant incident under NIS2?
A significant incident has caused or can cause severe operational disruption or financial loss, or considerable material or non-material damage to others. The applicable thresholds follow NIS2, relevant implementing rules, and national law or guidance.
What does a NIS2 directive summary need to cover for OT teams?
A useful NIS2 directive summary for OT teams covers three points: which sectors and company sizes fall in scope, which Article 21 measures apply to industrial systems, and the reporting deadlines and fines that follow a missed requirement. Teams researching NIS2 for the first time typically check these three points before mapping requirements to their own MQTT or IIoT infrastructure.
How long does a NIS2 rollout typically take for an OT environment?
Timelines vary by company size and how mature the existing security setup is. Companies that already run encrypted connections and centralized logging tend to close remaining gaps faster than those starting from unmanaged broker access.
