The Cybersecurity Act focuses on voluntary cybersecurity certification and harmonising standards across member states, while NIS2 expands mandatory security and incident reporting requirements for essential and important entities. For IoT teams, the distinction matters because one is mainly a certification framework and the other is a broader operational resilience obligation with stricter enforcement expectations.
Certification versus operational duty: how the two laws split for IoT teams
The cleanest way to separate the EU Cybersecurity Act from NIS2 is to ask whether you are buying trust signals or meeting legal resilience duties. For iot security teams, the Cybersecurity Act is mainly about certification schemes and harmonised assurance claims, while NIS2 is about operational security, governance, and reporting obligations for in-scope entities. The first can influence product positioning; the second changes how security is run day to day.
That distinction matters in IoT because product teams often confuse device assurance with organisational compliance. A certified device can still sit inside an organisation that fails incident reporting, risk management, or supplier oversight duties, and a non-certified device can still be subject to NIS2 if the deploying entity is in scope.
What the Cybersecurity Act means in practice
The Cybersecurity Act is best understood as a certification and market-harmonisation instrument. It supports EU-wide cybersecurity certification schemes so that products, services, and processes can be assessed against common criteria, which helps buyers compare assurance across borders. For IoT teams, that usually means aligning device design, evidence, and supply-chain claims to a certification target rather than treating the Act as a direct operating rulebook.
For teams building connected devices, the practical value is in assurance discipline: secure-by-design features, traceability of components, updateability, and evidence that security claims can be tested. The Cybersecurity Act does not by itself replace product-security engineering, but it can shape what evidence procurement, regulators, or enterprise buyers expect to see. If the device must be sold into regulated or assurance-sensitive environments, certification can become part of the go-to-market strategy.
Because the law is framework-oriented rather than incident-oriented, it is usually less about “what do we do when we are attacked?” and more about “what can we prove about the product’s security posture?” That makes it useful for procurement, conformance, and cross-border trust, but it is not the primary instrument for operational reporting or organisational resilience obligations.
What NIS2 changes for IoT security operations
NIS2 is broader and more forceful from an operational perspective. It imposes mandatory risk management measures and incident reporting duties on essential and important entities, which means IoT teams must think about governance, monitoring, supplier risk, and response as ongoing obligations, not optional controls. The compliance question becomes whether the organisation can demonstrate active management of security risk across its connected-device estate.
For IoT environments, that typically pulls in device inventories, patch and vulnerability handling, access control, supplier dependencies, logging, backup and recovery, and reporting thresholds. If IoT devices support critical business services, NIS2 drives accountability beyond the device itself and into the organisation that deploys, operates, or depends on those devices. This is where many teams underestimate scope: the compliance duty may attach to the operator even when the device was sourced from a third party.
NIS2 is therefore the stronger driver for incident response playbooks, board visibility, and evidence that security controls are actually running. Where the Cybersecurity Act asks for assurance, NIS2 asks for operational resilience and demonstrable management of risk.
How IoT teams should think about the overlap
The two instruments intersect, but they answer different questions. Certification can support procurement and reduce ambiguity about baseline product security, while NIS2 can force the deploying organisation to manage the lifecycle of that product in a live environment. A team that treats certification as a substitute for governance will miss the operational obligations that matter under NIS2.
For connected products, the most useful working model is: use Cybersecurity Act certification to strengthen product assurance and market confidence; use NIS2 to structure controls over deployment, monitoring, incident handling, and supplier accountability. In other words, one law helps prove a security claim, the other compels you to keep the service secure after deployment.
If you are supporting both product engineering and enterprise operations, this split should also shape ownership. Product security, compliance, and legal functions usually own certification readiness, while security operations, resilience, and governance teams own NIS2 execution. The handoff between them is where gaps commonly appear, especially when device telemetry, vulnerability notices, and incident escalation paths are not clearly assigned.
Risk and Threat Considerations
For IoT security teams, the main risk is mistaking assurance for resilience. A product can look compliant on paper while the live deployment still has weak patching, poor telemetry, or slow escalation paths, which is exactly where NIS2 becomes demanding.
Failure mechanism: Teams treat certification evidence as proof that operational controls are already mature, so they underinvest in monitoring, incident reporting, supplier oversight, and lifecycle response for deployed devices.
Impact: When a device fleet is compromised or a supplier issue emerges, the organisation may miss reporting timelines, fail to contain spread, or discover that the assurance story does not match operational reality.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 sets the technical controls, while NIS2 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | N/A — EU NIS2 Directive | Sets mandatory risk and incident-reporting duties for essential and important entities |
| Recommendation — Map IoT operations to NIS2 obligations for risk management, reporting, and governance. | ||
| ISO/IEC 27001:2022 | A.5.20 — Addressing information security within supplier agreements | IoT teams rely on third-party device and service suppliers under both regimes |
| A.8.8 — Management of technical vulnerabilities | IoT deployments need patch and vulnerability handling to meet operational duties | |
| Recommendation — Embed supplier security requirements and response obligations into IoT contracts. Operate vulnerability intake, prioritization, and remediation for connected devices. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | IoT fleets require ongoing discovery and remediation of device weaknesses |
| CIS-17 — Incident Response Management | NIS2 makes reporting and response readiness central for in-scope entities | |
| Recommendation — Maintain asset and vulnerability workflows for all connected devices. Define and test incident reporting and response procedures for IoT events. | ||
Practitioner Guidance
What to prioritise: Separate product assurance work from operational compliance work. Certification readiness should focus on evidence, design claims, and scheme-specific testing, while NIS2 readiness should focus on device inventory, logging, patch governance, incident routing, and supplier escalation.
What to verify: Confirm who owns each control after deployment. If the answer is unclear for patching, vulnerability intake, incident triage, or reporting decisions, the organisation does not yet have a defensible split between the two regimes.
Decision rule: If a control primarily helps demonstrate the product is trustworthy, treat it as Cybersecurity Act territory; if it determines how the organisation detects, contains, reports, or recovers from a security event, treat it as NIS2 territory.
Practitioner takeaway: The strongest IoT programmes use certification to raise the baseline, but they use NIS2 to prove they can operate securely under real conditions.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between the UK Cybersecurity and Resilience Bill and the EU Cyber Resilience Act?
- What is the difference between NIS1 and NIS2 for security governance teams?
- What is the difference between the UK Code of Practice for AI Cyber Security and the EU AI Act?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
