Does NIS2 require an SBOM? Not by name.
Neither the NIS2 directive nor Implementing Regulation 2024/2690 mentions a software bill of materials. They ask for information about the components of what you acquire, a complete asset inventory with traceable changes, and patches that are tested and come from trusted sources. Below: what each text says, who it binds, and which of it Attestree can evidence for Windows software.
Engineering mapping, not legal advice — confirm scope and obligations with counsel
Asset management, supply chain, vulnerability handling.
The directive
Article 21(2) lists the risk-management measures every essential and important entity takes, through its member state’s law. The software-relevant ones:
“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”
“security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”
“human resources security, access control policies and asset management”
Entities take into account “the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures”.
Implementing Regulation (EU) 2024/2690
The regulation spells those measures out in its Annex. It binds DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers (Art. 1). Every other entity meets Art. 21(2) through national law, but the Annex still shows what the measures look like in practice.
Acquisition processes include “information describing the hardware and software components used in the ICT services or ICT products”.
The closest either text comes to an SBOM: component information about what you acquire.
Security patches “are tested before being applied in production systems” and “come from trusted sources and are checked for integrity”.
“monitor information about vulnerabilities through appropriate channels” and, “where appropriate”, perform vulnerability scans and “record evidence of the results of the scans”.
“a complete, accurate, up-to-date and consistent inventory of their assets”, recording “changes to the entries in the inventory in a traceable manner”.
ENISA’s implementation guidance
ENISA’s Technical Implementation Guidance (June 2025) expands on the regulation. It says it is not legally binding, and it does not mention SBOMs either. For patch management it lists evidence such as testing patches before deployment in a controlled environment, detailed audit trails from identification to deployment, and checking vendor certificates and patch signatures, and it describes rolling, gradual deployment. For the asset inventory it suggests fields including the software’s version and the date of the asset’s last update or patch.
The CRA requires an SBOM. It asks the maker, not the user.
Where an SBOM still helps under NIS2: it answers “which of our machines contain component X?” the day a vulnerability is disclosed (6.10), and asking suppliers for one is a way to obtain the component information in 6.1.2(c). Our EU CRA mapping covers the manufacturer side.
Evidence for the Windows software slice, point by point.
What is actually installed
The agent reports what is on each Windows machine (winget, Chocolatey, Scoop and Add/Remove Programs), including per-user installs in each user’s profile and software nobody deployed through Attestree. Every install, upgrade and removal Attestree performs is a signed, timestamped event per endpoint.
LIMIT Changes made outside Attestree show up as current state only: no history of when they happened, and no install dates.
A sandbox first, then rings
With a Hyper-V or Proxmox host attached, each winget installer is installed in an isolated VM before it is served as verified, and what it wrote and left running is recorded. Versions then move through rings (canary, pilot, broad, all) with a minimum soak in each. Hosted instances serve sandbox-verified installers only.
LIMIT Winget only. Community Edition can serve an untested installer under an operator’s recorded, expiring acceptance, labelled dev-grade. A rollback runs after an operator confirms it; it is not automatic.
Your feed, pinned bytes
On a fenced endpoint, winget installs only from your own feed and only the installer whose SHA-256 the feed pins. The installer’s signer and the installed program’s signer are recorded per version, and the opt-in update pipeline stops a version whose signer changed before it reaches canary.
LIMIT The fence covers winget. It does not stop someone running an installer by hand.
An SBOM you produce yourself
A signed in-toto statement per verified version, carrying the installer’s SHA-256 and the digest of a CycloneDX SBOM that Syft builds from what the install put on disk: component information you hold without waiting for the vendor.
LIMIT A third-party SBOM of what the installer wrote. It is not your supplier’s SBOM, and a run can end without one.
Which machines are affected
CVE records from the CVE Program and CISA’s Known Exploited Vulnerabilities catalog, matched against the live inventory, KEV first, so a named vulnerability is answered with which machines run an affected version. Confident and hedged matches are kept apart.
LIMIT It matches against the current inventory, not a past one.
Signed decisions, exportable
Promotions and other operator decisions are signed audit events, kept indefinitely by default. An export for a window you choose re-verifies every signature and seals a signed SHA-256 manifest. Community Edition included.
LIMIT Each event is provably unedited; the export does not prove that no event was deleted from the database.
Two ways NIS2 reaches a Swiss company.
Directly, for some providers. Cloud computing, data centre, content delivery network, managed service and managed security service providers, DNS providers, TLD registries, online marketplaces, search engines and social networks that are not established in the EU but offer services there, and fall within the directive’s scope, must designate a representative in a member state where they offer them (Art. 26(3)). Regulation 2024/2690 then applies to them as written.
Otherwise, as a supplier. Entities in scope must manage security in their direct supplier relationships and weigh their suppliers’ products and development practices (Art. 21(2)(d) and 21(3)). A Swiss supplier meets that as a questionnaire, a contract clause and a request for evidence. Switzerland’s own reporting duty for critical infrastructure under the Information Security Act is a separate regime, not covered here.
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:
- Application control: software nobody approved is detected in the inventory, not blocked from running
- A history of inventory changes made outside Attestree, and install dates
- Your supplier’s SBOM, and the top-level SBOM the CRA asks a manufacturer for: ours is a third-party SBOM of what an installer put on disk
- Anything outside Windows software: hardware, OT, network, cloud and SaaS assets
- 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
Straight answers.
Does NIS2 require an SBOM?
Not by name. Neither Directive 2022/2555 nor Implementing Regulation 2024/2690 mentions a software bill of materials, and neither does ENISA’s June 2025 implementation guidance. The regulation asks the entities it covers to obtain “information describing the hardware and software components” of the ICT products and services they acquire (Annex 6.1.2(c)); an SBOM is one way to get it. The law that does require an SBOM is the Cyber Resilience Act, and it puts that duty on manufacturers.
Does Implementing Regulation 2024/2690 apply to us?
Directly, only if you are one of the provider types in its Article 1: DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers. Every other essential or important entity meets the Art. 21(2) measures through its member state’s transposing law. The regulation still shows in detail what those measures look like in practice.
What must a NIS2 asset inventory contain?
For the entities it covers, the regulation asks for “a complete, accurate, up-to-date and consistent inventory” with changes recorded “in a traceable manner”, at a granularity that fits the entity (Annex 12.4.1–12.4.2). ENISA’s guidance, which says it is not legally binding, suggests fields such as the software’s version and the date of the asset’s last update or patch. Inventories tend to fail on software nobody deployed on purpose and on per-user installs that a machine-scope collector never sees.
Should we ask our suppliers for SBOMs?
You can: it is one way to obtain the component information in 6.1.2(c). Expect mixed answers. Manufacturers must draw up an SBOM under the CRA from December 2027, but the CRA does not oblige them to publish it, and nothing in NIS2 obliges a supplier to hand you one.
Is a CRA SBOM NIS2 evidence?
Usually not the same document. A CRA SBOM describes a product you make and sell; NIS2’s component information and asset inventory describe the software you run. An organisation that both makes products and runs in-scope services holds both kinds.
Does NIS2 apply to a Swiss company?
It can, directly. A provider of one of the Art. 26(1)(b) types (cloud, data centre, CDN, managed or managed security services, DNS, TLD registry, online marketplace, search engine, social network) that is not established in the EU but offers services there, and falls within the directive’s scope, must designate a representative in a member state where it offers them (Art. 26(3)). Otherwise NIS2 reaches a Swiss company as a supplier, through its EU customers’ obligations under Art. 21(2)(d) and 21(3). Switzerland’s own reporting duty for critical infrastructure under the Information Security Act is a separate regime, not covered here.
Can I show an auditor proof of which installs were approved?
That is the shape of the evidence. Promotion to a ring is a signed audit event, and the endpoint agent acts only on HMAC-checked desired state and, on a fenced endpoint, installs only the pinned SHA-256. The export bundles those events for a window you choose, re-verifies every signature, and seals a signed SHA-256 manifest. What it is not is a claim about your whole NIS2 programme: it is the software-installation slice of it.
Sources: Directive (EU) 2022/2555, Implementing Regulation (EU) 2024/2690, Regulation (EU) 2024/2847 (CRA), ENISA Technical Implementation Guidance v1.0.
What was tested, approved and installed.
Signed records of each decision and an inventory of what is actually there: the evidence an auditor asks for about patching, and a customer asks for in a supplier questionnaire.