NIS2 & the Dutch Cybersecurity Act: what it means for legacy systems, shadow IT, and AI-assisted development

Before recording we read both underlying texts in full, Directive (EU) 2022/2555 and the Cybersecurity Act as published in Staatsblad 2026, 187, and searched them for what they say about systems that are past the end of their supported life. The search returned almost nothing, and that is what we spent most of the conversation on.

Source: Law & More, Tom Meevis

Abstract

The article sets out the scope, the duty of care, the notification duty, board responsibility and enforcement under NIS2 and the Dutch implementation. NIS2 covers eighteen designated sectors, split into sectors of high criticality and other critical sectors. Within those, the main rule catches organizations with at least fifty employees or more than ten million euro in turnover or balance sheet total, with several categories caught regardless of size, among them domain name registration service providers and trust service providers. The duty of care names ten mandatory subjects, from risk analysis through supply chain security to multi-factor authentication. Incidents follow a fixed ladder: an early warning within 24 hours, a formal notification within 72 hours, a final report within one month. Responsibility sits expressly with the management board, including personal liability. Fines reach ten million euro or two percent of worldwide turnover for essential entities. We reviewed the piece with Kishan Chamman, our CTO.

Review and insights

The law never uses the word legacy. We searched both the directive and the Act for legacy, end of life, decommissioning, phase out, obsolete and replacement, and the result was close to empty. What does exist is indirect. Article 21(2)(e) of NIS2 requires security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure. Recital 89 folds software updates, network segmentation and zero-trust principles into basic cyber hygiene. Recital 90 names technological lock-in and provider dependency as risk factors and attaches no action to either. The lifecycle is acknowledged and the end of it is left open. Kishan's reading is that this is deliberate. The regulator specifies the outcome an organization has to reach and leaves the route entirely to the organization. Refactor an application to satisfy the multi-factor authentication requirement, replace it, or find another way to get there, and the supervisor is indifferent as long as the requirement is met. The Dutch Act carries one provision that comes close to ordering replacement, allowing a minister to require an entity to stop using a specified party's products in designated components and to set a deadline for replacing what is already installed. That one triggers on state-actor threat, and not on age.

That makes compensating measures the cheapest legal route. Nothing in either text forces replacement, so network segmentation, monitoring and a web application firewall in front of an ageing system can satisfy the standard while the system underneath stays exactly as it is. Article 21(1) says so almost in as many words, requiring measures appropriate to the risk while "taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation". Recital 81 explains that the proportionality exists to avoid imposing a disproportionate financial and administrative burden. Asked what the strategic options are once a security team has flagged a vulnerable system near end of support, Kishan counted at least six, which is the 6R framework we published last year. The three he sees most often are refactoring to a supported long-term version, rebuilding from scratch while honouring every contract the old system holds, and replacing it with a commercial or SaaS product. Each one fails on a different constraint: refactoring and rebuilding both need planning and engineering capacity, rebuilding adds the complexity of reproducing undocumented behaviour, and replacing needs budget.

A legacy system does not automatically need improving. The fourth route is the one nobody sells, and Kishan raised it before any of the others. Sometimes the correct answer is to cut a system off from everything around it and let it run. Systems built in the seventies and eighties are still in production on contained machines with no contact with the outside world, and the risk they carry does not justify touching them. What changes the calculation is exposure. A public-facing system is visible to everyone, the attack surface is real, and that is where the duty of care starts to bite. The honest version of this advice is uncomfortable to give, because isolation looks like inaction on a roadmap while being exactly the proportionate measure the law is asking for.

The duty of care starts with an inventory almost nobody has. Article 21(2)(i) requires asset management alongside human resources security and access control policies, and the supervisor's stated approach is to test the duty of care by asking whether an organization has mapped its risks and taken matching measures. That makes the inventory the entry point to the entire assessment. Kishan's view is that a complete overview has always been out of reach for any organization with a varied application landscape, and that the name shadow IT has existed for years precisely because people build outside managed IT to get their work done. What changed is the consequence. Someone running something on the side is now a compliance failure the organization does not know it has, and the repercussions land at management level. One provision sharpens this further. Article 11 allows the CSIRTs to carry out proactive non-intrusive scanning of publicly accessible systems belonging to essential and important entities, to detect vulnerable or insecurely configured ones. The supervisor may map an organization's landscape from the outside before the organization has mapped it from the inside.

Anyone with a work laptop can create an asset before lunch. Asked directly whether NIS2 is a quiet killer for vibe coding inside organizations, Kishan's answer was that it depends on who provides the tooling. Right now anyone can open a Claude or ChatGPT session and build whatever they want, with nobody knowing what data passes through the result. He gave his own example. He could clone the company project management tool onto a free Vercel plan, no credit card required, and load in the legacy ticket archive, which holds screenshots and production data. That puts the organization in violation straight away. His working definition of an asset is broader than most people expect. Anything created in a company environment is an asset of that company, whether or not it holds relevant data, because an asset is something the company controls. That includes a trial account spun up on a work laptop. The duty of care requires asset management and never defines an asset, so the gap gets filled by whoever is doing the filling. The constructive answer is for the IT organization to provide a company platform where people can build these things and where the people managing IT keep oversight and governance of what gets built.

If an agent wrote the code, the responsibility does not move. The obligation sits with the entity itself, wherever the code came from, which means an organization develops a network and information system the moment anyone puts generated code into production. Kishan is direct about where that lands. A company is ultimately run by people, so humans stay responsible for whatever the agents produce, and an organization detached from the process does not even know which problems exist. Setting one agent to check another inherits the same limitation, because the checking agent only looks for what it was told to look for, and without the right guardrails it will not find security issues on its own unless it was built for that. Eli5 ships with AI daily, and the way we keep it defensible is to keep the work scoped and stay in control of it. Other teams queue tickets, let the loop run and never read the output, which leaves the organization unable to describe its own exposure. Industry research on AI-generated code consistently finds a meaningful share of it carrying vulnerabilities from the OWASP Top 10. The counterweight belongs here too, and Kishan raised it himself. Humans write bugs, plenty of incidents trace back to code a person wrote and reviewed, and a reviewer can miss what an agent would have caught. This is not a clean line.

Supply chain security is the subject no organization can fully discharge. Article 21(2)(d) makes supply chain security one of the ten mandatory subjects, and Article 21(3) requires entities to take into account the vulnerabilities specific to each direct supplier and the overall quality of their products and cybersecurity practices, including their secure development procedures. Recital 85 names software editors explicitly. The mechanism Kishan described is the one the industry has watched repeatedly. A dependency maintainer or their publishing token gets compromised, an infected version ships, and everything downstream that pulled the update inherits the compromise. An organization can write secure code and still be exposed through software it did not write, and in modern web development nobody depends on nobody.

The link to software modernization

The Act does not require modernization, and reading it as a modernization mandate leads to the wrong first move. What it requires is that an organization knows what it runs, has judged the risk each system carries, and can substantiate why the measures it chose are appropriate. The reasoning is supervised alongside the outcome. That puts the inventory and the risk assessment ahead of any migration plan, and it explains why organizations that start by scoping a replacement often cannot answer the supervisor's first question.

It also changes what a modernization business case has to look like. Article 20 requires management bodies to approve the cybersecurity risk-management measures, to oversee their implementation, and it makes them liable for the entity's infringements. It also requires board members to follow training so they can identify risks and assess the measures and their impact on the services the entity provides. The Dutch implementation goes further, adding a deadline for board members to reach that level of knowledge along with a certificate evidencing the training. Enforcement reaches individuals: for essential entities the supervisor can request that a court temporarily prohibit a person at chief executive or legal representative level from exercising managerial functions. Technical debt that used to live in an engineering backlog now has to be written in a form a director can sign, with the risk stated as an effect on service continuity that a board can actually weigh.

The pattern underneath is one we keep arriving at. In our review of Meta's AI second brain the transferable lesson was that the agent layer is the simple part, and the years of work making systems reachable is where the time and money go. In our review of forward deployed engineers the test that mattered was whether an organization can still operate the thing once the specialists leave. The Cybersecurity Act asks a version of the same question. An organization that cannot say what it runs, who maintains it and what happens when the supplier disappears has an operational problem and a compliance problem at once, and only one of them comes with a date.

Concluding remarks

The Law & More piece is well written and legally sound, and for a board trying to work out its position it does the job. Reading it against the statute surfaces one thing worth flagging. Its list of the mandatory duty-of-care subjects reduces the acquisition, development and maintenance subject to vulnerability policy alone, dropping the front half of it, and leaves out human resources security, access control policies and asset management altogether. Those are the two subjects that speak to the state of an organization's software landscape. What remains is a list that reads as policy, procedures and multi-factor authentication, all of which can be arranged without ever looking at the systems underneath.

This is worth stating carefully, because the point is structural and has nothing to do with one firm. The compliance summary is the version the board reads, and the summaries in circulation consistently drop the inventory duty. An organization working from one of them can meet the deadline with a defensible policy binder and no idea what it runs.

Two moves are worth avoiding. Waiting for the detailed technical requirements is the first, because they are left to a further order that does not exist on the day the Act enters into force, while the risk inventory is the entry point to the assessment with or without them. Buying a compliance document instead of an inventory is the second, and it will be widely on offer.

Where to start

Knowing what runs, who maintains it and what happens when a supplier disappears is the first deliverable, and it is the one most organizations cannot produce on short notice. Our modernization assessment maps the application landscape, scores each system on exposure and maintainability, and produces the substantiation the duty of care asks for, in language a board can approve. It also answers the question the law leaves open, which is whether a given system should be refactored, rebuilt, replaced or deliberately left alone.

Questions we kept coming back to

Does my organization fall under the Cybersecurity Act?

It depends on sector, size and group structure, and the answer has to be reached without waiting for notification. The sector test runs against the eighteen designated sectors in the two annexes to NIS2. The size test starts at fifty employees or ten million euro in turnover or balance sheet total. The exception that gets missed most often is group counting: the SME definition in Recommendation 2003/361/EC includes partner and linked enterprises, so a thirty-person subsidiary inside a larger group is not an SME for this purpose. Several categories are caught regardless of size, and a designation can also pull in an organization whose services are critical at national or regional level. The RDI publishes a self-test for sectors under supervision.

The technical rules are not published yet. Invest now or wait?

The work can start now, because the missing piece does not gate it. The detailed requirements are left to a further order that does not exist as the Act enters into force. What already applies in full is the duty to identify risks, take proportionate measures and substantiate the reasoning, and the supervisor's stated entry point is whether an organization has mapped its risks. An inventory and a risk assessment keep their value whatever the eventual technical norm says, and neither can be produced quickly under pressure.

What does the board actually have to do?

The board must approve the measures, understand them, and be able to prove both. Under Article 20 of NIS2 the management body approves the cybersecurity risk-management measures, oversees their implementation, and can be held liable for the entity's infringements. Board members are required to follow training so they can identify risks and assess the measures and their impact on the services provided. The Dutch implementation adds a deadline for reaching that level of knowledge and a certificate evidencing the training. For essential entities the supervisor can go further and ask a court to temporarily bar a chief executive or legal representative from exercising managerial functions.

We build software for an organization in scope and we are too small to be caught. Does this reach us?

Yes, it reaches suppliers through the customer's contract rather than through the Act. Article 21(3) requires entities to take into account the vulnerabilities specific to each direct supplier and the overall quality of their products and cybersecurity practices, including their secure development procedures, and recital 85 names software editors specifically. Because outsourcing does not move the customer's liability, customers will start asking for evidence they can audit: audit rights in the contract, a documented vulnerability policy with response times, and notification commitments fast enough to support their own 24-hour clock, which in practice means eight to twelve hours for the supplier. Public procurement applies no size threshold at all.

What do we write down as root cause when the honest answer is that the system is fifteen years old?

Write that sentence, if it is true. The final report under Article 23 has to describe the type of threat or root cause likely to have triggered the incident, along with the mitigating measures applied and under way. An organization that documented the risk, weighed the options and recorded why it chose compensating measures has a defensible file. An organization that never made the assessment files an incident report that doubles as evidence of a duty-of-care failure, which is a materially worse position than the technical debt itself.

Full video episode

The first step to start your modernization journey

Software modernization and architectural rebuilds lie at the heart of Eli5. We solve complexity to deliver direct business value by focusing on pragmatic, cloud-native transitions.

Before you decide whether to wrap your legacy system, buy a new SaaS product, or use AI to build custom tools, you need total visibility into your current tech landscape.

Would you like to book a free brainstorm to discuss your legacy stack? It is the essential first step to turning your technical debt into a scalable, modular future.

‍

‍

‍

‍