Know what is installed. Prove it was allowed.
NIS2 asks in-scope entities for asset management, supply-chain risk management and vulnerability handling. For Windows software that resolves to three practical questions: what is actually on the estate, where did it come from, and can you show the decision that let it in.
Engineering mapping, not legal advice — confirm scope and obligations with counsel
Four measures we produce evidence for.
Asset management
An accurate, current inventory of the software actually present on your estate — collected from the endpoints themselves rather than inferred from what you believe you deployed, and including the software nobody deployed on purpose.
Supply chain security
Evidence about what you admitted from your suppliers and why. Each artifact carries a CycloneDX SBOM and a signed record of the check it passed before any endpoint was allowed to install it.
Vulnerability handling
A self-hosted CVE index matched against observed inventory, KEV-first, so a named vulnerability can be answered with which machines are affected and at what confidence — rather than a scan you commission after the question is asked.
Cryptography
Every state transition is signed, and the resulting evidence bundle re-verifies each signature before it is sealed — so the record you hand a supervisory authority is one they can check rather than take on trust.
Not bound by it. Still asked about it.
Switzerland is not an EU member state, so NIS2 does not apply to a Swiss company directly. It arrives anyway, through Article 21(2)(d): entities that are in scope must manage security risk across their direct supplier relationships. In practice that obligation is discharged by asking suppliers — so a Swiss firm selling into an EU essential or important entity meets NIS2 as a questionnaire, a contractual clause, and a request for evidence, rather than as a regulator.
That is a better position to be in than it sounds, because the answer is the same artifact either way. An inventory you can stand behind and a signed record of what you admitted answers the supplier questionnaire, the CRA component-inventory obligation, and your own vulnerability handling — one body of evidence, generated as a side effect of how software gets installed rather than assembled before an assessment.
NIS2 is an organisational programme. We are one slice of it.
Any vendor claiming to make you NIS2-compliant is selling you something that does not exist. Here is what stays with you:
- Incident reporting under Art. 23 — the 24-hour early warning, 72-hour notification and one-month final report are yours to file
- Governance and management-body accountability under Art. 20, including the training obligation
- Business continuity, backup and crisis management under Art. 21(2)(c)
- Human-resources security, access-control policy and MFA across your wider estate — we cover our own surface, not your identity programme
- Determining whether you are an essential or important entity at all, and in which member states
- Anything outside Windows software installation — network security, physical security, and the rest of the Art. 21 programme
Straight answers.
Does NIS2 apply to a Swiss company?
Not directly. NIS2 is an EU directive, transposed into the national law of member states, and Switzerland is not a member state. The route it reaches Swiss businesses is commercial rather than jurisdictional: Article 21(2)(d) obliges in-scope EU entities to manage security risk in their direct supplier relationships. If you supply an essential or important entity in the EU, their obligation becomes your questionnaire — and increasingly your contract. Separately, Switzerland has its own reporting duty for critical-infrastructure operators under the revised Information Security Act, which is a distinct regime and not covered here.
What counts as a software asset inventory under NIS2?
The directive sets the objective — asset management as part of the Art. 21(2) risk-management measures — rather than prescribing a format, so the practical test is whether the inventory is accurate, current, and covers what is genuinely present. The two places homegrown inventories fail that test are software nobody deployed deliberately, and per-user installs that a machine-scope collector never sees. Both are counted here as first-class rather than as gaps you discover during an assessment.
Is an SBOM required by NIS2?
NIS2 does not name SBOMs the way the Cyber Resilience Act does. What it requires is supply-chain risk management and vulnerability handling, and an SBOM is the practical instrument for both — it is what lets you answer which of your systems contain a newly-disclosed component. Teams subject to both regimes generally generate the SBOM once, for CRA purposes, and reuse it as NIS2 evidence.
Can I show an auditor proof of which installs were approved?
That is the shape of the evidence. Admission to the catalog is a signed decision, promotion to a ring is a signed decision, and the install on the endpoint re-verifies signature and hash before it proceeds. The export bundles those spans for a window you choose, re-verifies every signature, and seals a SHA-256 manifest. What it is not is a claim about your whole NIS2 programme — it is the software-installation slice of it.
One inventory, several regimes.
The same signed evidence answers NIS2 supplier questions, the CRA component inventory, and your own vulnerability handling.