NIS2 and the Cyber Resilience Act: What IoT Operators Must Do Before the Deadlines

Two pieces of EU law now govern how connected devices are built and operated. NIS2 (Directive EU 2022/2555) requires organizations in sectors the EU treats as important to society to put specific security measures in place and to report significant incidents on a 24-hour, 72-hour, and one-month timeline.

The Cyber Resilience Act (Regulation EU 2024/2847) requires manufacturers of connected products to make them secure by design and keep them secure across their supported life. NIS2 is in force. 

The CRA's first hard deadline, vulnerability and incident reporting, lands on 11 September 2026, and it reaches products already in the field. Full CRA requirements follow on 11 December 2027. No single product makes you compliant with either. The work is yours, and the time to start is now.

The Attached Obligations

If your organization runs connected devices, you have a compliance footprint whether you have mapped it or not. Your fleet routes data across cellular networks. It connects field equipment to back-end systems. It gives third-party service technicians remote access to machines in places your security team never visits. Each of those activities now sits inside the scope of EU law, and the accountability runs to the top of the organization.

For decision-makers, this is no longer a question for the security team alone. NIS2 makes management bodies personally responsible for approving and overseeing security measures. The fines reach 10 million euros or 2 percent of global turnover. The reporting clocks are short. And the second of the two laws, the Cyber Resilience Act, carries a deadline most teams have not planned for.

"Security is not a feature. It is a foundation."

Henning Solberg, CTO and co-founder, IXT

What NIS2 Asks of You

NIS2 applies to essential entities across 18 sectors, from energy and water to manufacturing and digital infrastructure. It sets out ten minimum security measures under Article 21. The measures are outcomes, not products. The law tells you what to achieve, not which technology to buy. They cover risk analysis, incident handling, business continuity, supply chain security, access control, encryption, and multi-factor or continuous authentication, among others.

Article 23 sets the reporting timeline. When a significant incident occurs, you send an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. Meeting those windows depends on one thing above all: knowing an incident has happened in the first place.

Two points raise the stakes for leadership. Article 20 holds management bodies accountable for cybersecurity risk management, which moves the obligation onto the board. And transposition runs through national law, so the exact scope, fines, and reporting routes vary by member state. If you operate across borders, you answer to more than one regime.

What the Cyber Resilience Act Adds

Where NIS2 governs how you operate, the Cyber Resilience Act governs what you put on the market. It applies to manufacturers of products with digital elements, meaning hardware and software designed to connect to other devices or networks. Gateways, sensors, controllers, routers, and the equipment behind them all fall inside its scope.

The CRA places three duties on manufacturers. Products have to be secure by design and free of known exploitable weaknesses, with a path for security updates across the supported life. Manufacturers need a documented process for receiving and fixing reported vulnerabilities. And from 11 September 2026, they have to report actively exploited vulnerabilities and severe incidents to ENISA and their national authority within 24 hours, with a fuller report to follow.

Most teams have pinned their planning to 11 December 2027, the date full requirements and CE marking apply. The earlier date is the one to watch. The September 2026 reporting obligation reaches products already placed on the market, not only new ones. Penalties run to 15 million euros or 2.5 percent of global turnover.

Connectivity Gap

Most IoT deployments still rely on a private APN or a VPN to keep traffic off the public internet. It helps. It is not enough for what these laws ask. A private APN does not segment devices from one another. It does not show you what a device communicates with. It does not limit what a contractor reaches once connected. And it does not produce the audit trail a regulator will ask to see.

The result is a familiar gap. You have connectivity, and you do not have visibility, control, or evidence. NIS2 asks for all three. The CRA asks you to prove them across a product's life.

Zero Trust

The security model these regulations point toward, often called Zero Trust, rests on a few principles, and none of them depend on a particular vendor.

• Replace network access with identity-based access. A device or a contractor reaches the specific application it is approved for, nothing wider. There is no standing access to the network behind it.
• Segment the fleet. If one device is compromised, segmentation holds the problem inside a small boundary instead of letting it spread across everything connected.
• See traffic in real time. A live view of what each device communicates with turns incident detection from guesswork into observation, and it is what makes the 24-hour reporting clock realistic.
• Control third-party access. Vendor remote access is one of the highest-risk activities in IoT. Brokered, time-limited, recorded sessions replace open VPN tunnels, so you know who did what and when.
• Keep an audit trail. Every session and every connection logged gives you the evidence both laws expect you to hold.

Read against Article 21, these principles line up with access control, segmentation, incident detection, supply chain access, and continuous authentication. They do not replace the parts of compliance only you own.

Before the Deadlines

• Start with an inventory. List the connected products you make and the devices you operate, and mark which fall under NIS2, the CRA, or both. You answer to different parts of each law depending on whether you operate the system or sell the product.
• Run a gap analysis against the ten Article 21 measures. Find where you have controls, where you have policy without controls, and where you have neither.
• Fix detection first. The 24-hour clock fails if you find out about incidents days later. Real-time visibility into device behavior is the foundation the reporting timeline rests on.
• Treat September 2026 as the near deadline, not December 2027. If you build or ship connected products, the reporting obligation arrives first and covers what is already in the field.
• Brief the board. Under Article 20, this is their responsibility, not the security team's alone. The people held accountable need to understand the exposure before an incident forces the conversation.

One caution. The mapping above is a working guide, not legal advice. Verify the specifics against your compliance team's reading of the national law in each country where you operate.

FAQ

What does NIS2 Article 21 require?

Article 21 requires essential entities to put appropriate security measures in place to manage risk to their network and information systems. It lists ten minimum measures and describes the outcome each has to achieve, rather than the technology to use.

When do Cyber Resilience Act obligations start?

The CRA entered into force on 10 December 2024. Vulnerability and incident reporting obligations apply from 11 September 2026 and reach products already on the market. Full requirements, including conformity assessment and CE marking, apply from 11 December 2027.

Does any single product make my organization compliant?

No. Both laws combine technical measures with documentation, governance, and processes you own. A security architecture helps you meet specific technical measures and produce evidence. It does not cover risk documentation, incident response planning, staff training, or supplier governance.

How is this different from a VPN or a private APN?

A private APN or VPN keeps traffic off the public internet. It does not segment devices, show what a device communicates with, restrict what a contractor reaches once connected, or produce an audit trail. The model these regulations point toward adds identity-based access, segmentation, real-time visibility, and recorded third-party sessions on top of the connection.