Is a code scanner mandatory under NIS2?
The short answer is no: the word scanner does not appear in NIS2 or in the German BSI Act. What the law asks is that weaknesses in your own systems are known, dealt with and written up. Five brief answers for anyone running their own software who wants to know what actually binds them.

The short answer
No. There is no provision in the NIS2 directive or in the German BSI Act that requires a code scanner, a scanner product or any particular test method. Anyone who hears otherwise should ask for the citation. There is none.
What is required instead
The directive's list of minimum measures has one letter, Article 21(2)(e), for the whole life of a system: buying it, building it, keeping it running, and dealing openly with the vulnerabilities found along the way. The German act carries that over as number 5 of Section 30(2) BSIG with hardly a word changed, then adds two things of its own: subsection 1 says the whole thing has to be written down, and number 6 says you have to check, with a procedure, whether your measures actually work.
That is the whole duty: know vulnerabilities, handle them, disclose them, document, assess. How an entity gets there, the law leaves to the entity. For your own code the vulnerabilities are essentially hardcoded credentials, vulnerable dependencies and unsafe patterns; how a continuous scan evidences them is in our article on proving NIS2 compliance in daily operations and on our code security and compliance page.
Why we recommend the scan anyway
Because the documentation duty in subsection 1 is the bottleneck in practice. Vulnerabilities can also be managed with an annual manual review. What that lacks is a record for the time in between. A scan on every commit leaves an assessment, an action and a date behind every finding, and that file builds up while the work is done rather than before the audit. That is the reason for the recommendation, not a duty that does not exist.
What the scan cannot do, and what that means for the duty
A scanner finds what has a pattern. Business logic errors, such as authorisation logic that is wrong in business terms, it does not find, and design decisions it does not judge. But the duty under number 5 does not stop at the limit of the tool. Anyone who wants to meet it fully needs, alongside the scan, a periodic check of what has no pattern, usually a penetration test. That is not prescribed either. It is another route to the required outcome.
Who the question applies to at all
Section 30 BSIG addresses essential and important entities. Whether a company is one depends on sector and size; our NIS2 quick check settles that in a few minutes. And regardless of NIS2: anyone who writes no software and runs no bought software themselves has nothing to scan. Anyone who has either has vulnerabilities to manage, whether the directive covers them or not. Whether it is worth it, the free code analysis shows, with no obligation.
Frequently Asked Questions
Does the word scanner appear anywhere in the law?
No. Neither in Article 21 of the directive nor in Section 30 BSIG. What is required is vulnerability management in development and maintenance and its documentation, not a product.
Is an annual penetration test enough to meet the duty, then?
It evidences the day of the test. The duty targets the ongoing handling of vulnerabilities and its documentation. The time between two tests needs a record too, and a continuous scan is the simplest way to produce one.
We are not covered by NIS2. Is the question settled for us?
The duty, yes; the risk, no. A hardcoded key in a repository is an open password regardless of the law. Whether it is worth looking, the findings of the free analysis will tell you.
Sources
- Directive (EU) 2022/2555 (NIS2), Art. 21 (EUR-Lex)
- Section 30 BSIG, German Federal Office for Information Security Act (gesetze-im-internet.de)
- CAVRIX: Secure development under NIS2, ISO 27001 and the CRA
- CAVRIX: Code security for mid-sized businesses
- CAVRIX: Penetration testing for mid-sized businesses