NIS2 gets treated as a security topic, and for most companies it is not one. It is a legacy topic arriving in the shape of a security topic.
The reason is in the law. In the German implementation, in force since December 2025, the BSIG requires risk management measures in ten areas. Several of them are not a matter of intent but of construction: a system that cannot be updated without somebody accompanying it by hand does not satisfy them, however much care the team brings.
This article translates the requirements into technical findings and an order of work. It is not legal advice, and it does not answer whether you are in scope: that depends on sector, headcount and turnover, and the regulator publishes assessment aids for it.
Why this is a legacy topic
Of the ten areas, four are structurally difficult for a grown system, and they decide the matter.
Security in development and maintenance, including vulnerability handling. That assumes a reported vulnerability in a dependency can actually be closed. In a system on an unmaintained language version exactly that is impossible: the package exists, the fix exists, and both require a version the system does not have.
Supply chain security. It means service providers and suppliers, and for an application it also means the packages it brings along. Anyone who cannot say what is installed cannot say anything about their supply chain.
Business continuity, including backup management and recovery. Not the existence of backups but the recovery. Most organizations have rehearsed the first and not the second.
Access control and multi-factor authentication. In a system built before these requirements, sign-in often lives inside the application itself, with no place a second factor could attach to.
None of those four can be settled with a product. All four are questions about construction, and that is the difference between a security measure and a modernization.
Which findings regularly turn up in an old PHP system is covered in Ten holes that sit in every old PHP system.
The findings that turn up every time
Translate the areas into an inventory and grown systems produce the same list with great reliability.
A language or framework version without security fixes. Dependencies with no traceable origin, because the lock file is missing or the package was abandoned. Credentials in the repository or in a configuration file on the server. A shared administrator account several people know. Backups that were never restored. And logs that either do not exist or disappear after seven days.
None of that is a surprise or an accusation. It is the ordinary result of ten years of operation under different requirements. What is new is only that it now has an addressee.
The supply chain nobody reads as one
Of the ten areas, supply chain is the one where technical teams think of contracts first and of their own packages last. Yet the second part is the one they control themselves.
An application brings third-party code with it, and the same question applies to it as to a service provider: where does it come from, who maintains it, and what happens when they stop. The answer can be generated and does not have to be remembered:
# An inventory that falls out of the build rather than out of
# memory. Daily, not once a year.
composer audit --format=json > vulnerabilities.json
composer licenses --format=json > origin.json
# And the uncomfortable line: packages with no release in two
# years. An abandoned package is a supplier who no longer
# answers the phone.
composer outdated --direct --format=json | jq -r '.installed[] | "\(.name) \(.version) \(.latest)"'Two things regularly surface here, and both are supply chain findings in the sense of the law. One is packages without maintenance and without a successor. The other is packages that were modified by hand and therefore cannot take a fix any more without losing the modification. Neither appears in any contract, and both are exactly what the requirement means.
Doing it is not enough, showing it is part of the job
The point that surprises technical teams most: the law also requires procedures for assessing the effectiveness of the measures. So it is not enough that something gets done. It has to be demonstrable that it works.
In practice three things have to come together, and none of them is expensive when it runs along from the start.
A list of what is there, generated rather than maintained. An inventory of dependencies with version and origin comes out of the build and is therefore always current; a spreadsheet on a share is not, after one quarter.
A log that outlives what it is supposed to evidence. Anyone who has to report an incident within the statutory deadlines needs the data from before the incident, not from after it.
A rehearsal with a date. The restored backup, the test run of the recovery, the revoked permission that demonstrably took effect. An appointment with a result is the evidence a concept does not provide.
Building that anyway has a side effect: those same three things are what a customer wants to see in a supplier assessment. The requirement arrives through NIS2 today; it arrived through tender documents before that.
How the dates behind this turn into a list with lead times is covered in An end-of-life calendar for the whole stack.
The order that is worth the money
The common reaction to a list like this is a project that tackles everything at once, and it stalls in the second month. The order that holds sorts by two criteria: what an attacker can use today, and what makes the other measures possible in the first place.
Access first. Break up shared accounts, get credentials out of the repository, multi-factor everywhere a sign-in leads inside. That is days, not weeks, and it closes the route most incidents actually take.
Then visibility. Logs with a retention that matches the reporting deadline, and a generated inventory of dependencies. Without those two, every further measure is unevidenced.
Then recovery, rehearsed once, with a date and a measured duration.
And only then the versions. The jump to a maintained language and framework version is the largest item and the only one that takes months. It goes last, because the three steps before it protect in the meantime.
What this changes about the conversation
The real difference from the years before is not in the technology but in who is listening.
An upgrade used to be a proposal from engineering and competed with features. A statutory obligation with a penalty range and personal responsibility at management level does not compete, it gets planned in. For everybody who has been pointing at the same list for years, this is the first opportunity to get it worked through.
That is no reason to make the list longer than it is. Using the obligation to push through a project that has nothing to do with it burns exactly the trust the obligation just created. What belongs on the list is in the law, and the rest belongs in ordinary planning.
How such an inventory runs technically and what happens first afterwards is described on the modernization page. The findings themselves are manual work, and they start with access, not with versions.
This article continues a series about systems that already exist. The retrospective on the first three months orders its articles by situation.
