Open-source software in NIS2 supply chains

Does NIS2 treat open-source software differently in the supply chain?

NIS2 encourages open-source security tools, and Recital 52 says they can diversify suppliers and support transparent, community-driven vulnerability discovery. It does not, however, create a separate regime for open-source components. The acquisition, update and vulnerability duties in Implementing Regulation (EU) 2024/2690 apply to open-source components in the same way they apply to any purchased product, and NIS2 creates no certificate of compliance for either. For an organization that adopts open-source software, the practical question is whether it can show, for each component, where the component came from, which security updates it receives and how vulnerabilities in it are tracked. Open-source status does not remove any of these duties.

Responsibility stays where NIS2 places it. The organization owns its controls and is accountable to its management body and its competent authority. An implementation partner can prepare systems, configure tooling and assemble evidence, but it does not decide whether the organization is compliant. Only an independent auditor or the competent authority assesses compliance, through inspections, security audits, scans or information requests under Articles 32 to 34. Confirm with your national competent authority how it expects evidence to be presented, because transposition laws and supervision practice differ between Member States.

What changes depends on three things. Sector and entity type determine whether you are essential or important and therefore how intensely you are supervised. Supplier model determines who holds the component information and update commitments: a community project, a commercial distributor offering support, or an internal fork you maintain yourself each requires different contract terms and different monitoring. If you maintain a fork, the update obligations fall on you. If you rely on a vendor's support contract, you must confirm in writing the support period and the security update commitments that cover it.

What the acquisition rules ask for when the component is open source

Point 6.1.2 of Implementing Regulation 2024/2690 names four elements that an acquisition process must cover. Each one applies differently to a community project, a commercially supported distribution and a fork your team maintains. Read the cards as a checklist for the acquisition file you keep for each component.

Security requirements set before selection

The acquisition process must cover security requirements for the product. For an open-source component, write them down as acceptance criteria: authentication options, encryption of data in transit and at rest, audit logging and hardened defaults. A community project meets these only through configuration you control, so record which requirements the default install satisfies and which you close yourself. A commercial distribution can be asked to state its position in writing. An internal fork inherits every requirement, so your team owns the baseline.

Updates for the product lifetime

The process must secure security updates for the product's lifetime or a replacement after end of support. Record the end-of-support date for each version in use and who issues fixes until then. A community project carries no contractual update commitment, so confirm an active maintainer and release cadence, or plan to backport patches yourself. A commercial distribution should state its update window in the contract. An internal fork makes your team the update source, so it needs a rebase routine and a replacement plan. Confirm the exact wording against the Implementing Regulation text.

Information on hardware and software components

The process must capture information on the hardware and software components of the delivered product. For open source, this means the full dependency tree, including transitive libraries, container base images and build tools, usually recorded as a software bill of materials. A community project seldom ships one, so generate it from the exact release you deploy. A commercial distribution should supply it with each release. An internal fork needs regeneration on every build, because your patches change the component list.

Validation of delivered products

The process must validate delivered products against the security requirements before they go live. For open source, validation means verifying the artifact itself: checksums and signatures against the project's published keys, reproducible builds where the project offers them, and a test run against your requirement list. A community project's binaries should be built or verified from source where practical. A commercial distribution's signed packages should be checked against the vendor's published keys. An internal fork relies on your own pipeline, so gate promotion on passing tests and clean scan results.

Where SBOM duties come from: the Cyber Resilience Act, not NIS2

The SBOM duties people associate with open source come from the Cyber Resilience Act, Regulation (EU) 2024/2847, not from NIS2. Annex I sets the essential requirements for products with digital elements, Annex VII point 2(b) puts the software bill of materials (SBOM) into the technical documentation, and Annex VII point 8 requires it to be given to a market surveillance authority on reasoned request. These duties fall on manufacturers placing products on the EU market. An organization that only buys and runs open-source components as a NIS2 entity does not inherit them by default.

The distinction matters for what you ask suppliers and internal teams to produce. Annex II point 9 requires a manufacturer to tell users where to access the SBOM only if the manufacturer decides to make it available to users. So a missing SBOM is not automatically a breach of the CRA by your supplier, and you cannot count on one arriving. Your NIS2 acquisition duties still apply: under Implementing Regulation (EU) 2024/2690, your acquisition process must cover information on hardware and software components, so ask suppliers in writing which components, versions and licenses the product contains, and record the answer. Confirm with each supplier whether it will publish an SBOM, and if not, what component information it will provide instead.

Start with the Commission's CRA implementation page to confirm which of your products and suppliers fall under the CRA and when its obligations apply to them. Then check the dates and the manufacturer role against your own counsel's reading of the regulation, because classification depends on the product and the supply chain rather than on whether the code is open source. Keep the two regimes separate in your register: CRA duties sit with manufacturers, and NIS2 duties sit with you as the entity that depends on the product.

How to monitor vulnerabilities in open-source components

This sequence turns vulnerability news about open-source components into a recorded, repeatable process: information is collected, components are checked against it, critical issues are handled first, and every decision leaves a record an assessor can read. It follows the monitoring and fix expectations in Implementing Regulation (EU) 2024/2690.

Maintain a component inventory
Before monitoring can work, the entity needs a current list of the open-source components in each in-scope system, including direct dependencies, the versions in use and the systems they run in. The platform team or the implementation partner builds this list from the SBOM supplied with the product or generated from the build, and the owner of each system confirms it. The output is a versioned component inventory that names each component, its version and its system owner. An assessor checks that the inventory matches what is running in production.
Collect vulnerability information from defined channels
The entity monitors vulnerability information from the channels the regulation names: CSIRTs, competent authorities and suppliers. Open-source projects, their security advisories and vulnerability databases are also useful inputs, but the entity should record which sources it watches and who reviews them. The security operations or platform owner is accountable for this feed. The output is a dated log of vulnerability notices received, with the source and the component each one affects, so an assessor can see that the monitoring channels were actually in use.
Match notices against the component inventory
Each vulnerability notice is compared with the inventory to find which systems run an affected component and version. Tooling such as OWASP Dependency-Track can consume CycloneDX SBOMs and VEX data and flag components with known vulnerabilities, which reduces manual matching, but the team still confirms the result. The output is a triage record for each notice listing the affected systems, or a documented reason why none are affected. Where a component is not exploitable in the entity's configuration, the reason should be written down as well.
Run vulnerability scans at planned intervals
Where appropriate, the entity runs vulnerability scans of its systems at planned intervals, independent of incoming notices. The scan schedule is set in the entity's policy and the platform owner runs or supervises the scans. Each scan produces a report with the findings, the scan date, the scanned scope and the tool version. Scan reports are retained as evidence that scanning happens on the planned cadence, and the results feed into the same triage record as notices. The assessor checks that the schedule was followed and that results were recorded.
Address critical vulnerabilities without undue delay
Critical vulnerabilities are handled first, without undue delay. The system owner, with the security lead, decides on the response: apply the vendor or project fix, apply a documented mitigation, isolate the component, or replace it. The regulation does not set a day count for this, so the entity should define in its own procedure how it prioritizes and escalates critical findings. The output is a change or remediation ticket linked to the triage record, with the date the fix or mitigation was applied and the person who approved it.
Apply other fixes within a reasonable time
Vulnerabilities that are not critical are fixed within a reasonable time. The regulation sets no patch deadline in days, so the entity should document how it judges reasonableness, for example by severity, exposure and the availability of a fix, and confirm that approach with its competent authority or auditor where the outcome is uncertain. Fixes are tracked through the normal change process. The output is a remediation record for each finding showing the decision, the date of the fix and any accepted risk with its approver.
Record the outcome and review the process
At planned intervals, the security lead reviews the monitoring records for gaps: notices that were not triaged, scans that were skipped, critical findings without a recorded decision and components no longer supported. Findings from the review update the inventory, the scan schedule or the procedure. The output is a periodic monitoring review record, signed by the accountable owner, which links to the inventory, notice log, scan reports and remediation records. This record shows the sequence was run and improved, not only designed.

Tooling options for evidence: self-hosted or purchased

Self-hosted tooling runs inside your own infrastructure, so the SBOM data, vulnerability findings and license records stay under your control. OWASP Dependency-Track, licensed under Apache-2.0, is the example most often considered. It consumes and produces CycloneDX SBOMs and VEX documents, identifies components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component with SPDX license IDs. The evidence it produces is a continuously updated component inventory, a findings history per project and a record of analysis decisions.

Component inventory: Imported SBOMs for each product or service, versioned so you can show what was deployed at a given date.
Vulnerability findings: Matches against known-vulnerable components, with the time each finding was opened and closed.
VEX analysis records: Documented decisions such as not affected or mitigated, with the justification attached.
License records: Component license use mapped to SPDX identifiers, with policy violations flagged.
Configuration and access records: Who can change policies, suppress findings or export data.

You still must define the vulnerability monitoring sources, set the scan schedule, decide who triages critical findings and document how fast they are addressed. Confirm with the project documentation which SBOM formats, ingestion methods and integrations the version you deploy supports.

Open-source suppliers and maintainers under Article 21 supplier duties

An open-source project has no contract counterparty by default, so the Article 21(3) supplier assessment cannot be run against the project itself. The practical question is who stands behind the component. That is usually one of three parties: a commercial support provider that sells a subscription, a foundation or community that coordinates releases, or your own team if you maintain a fork. Each party needs a documented answer on who triages vulnerabilities, who ships fixes and on what cadence. Record the chosen party, its support terms and the decision rationale in the supplier file, and confirm whether any commercial terms include security advisories, backport commitments or named escalation contacts, since community projects often provide none of these.

Document end-of-support dates for every component in the bill of materials, not only for the operating system and runtime. Acquisition rules under Implementing Regulation (EU) 2024/2690 expect security updates for the product's lifetime or a planned replacement after end of support, so for each component record the upstream support policy, the date the branch stops receiving fixes, and the replacement plan. Confirm these dates against the project's published policy rather than assuming them. A fork shifts the burden to your team: you must own the backport process, test it and apply it within a reasonable time, and your records should show that the work happened.

Article 12 concerns coordinated vulnerability disclosure, which sets the channel through which vulnerability reports travel between researchers, maintainers and authorities. It does not replace your own reporting duties under Article 23. Your intake should therefore accept advisories from the project, the support provider and the CSIRT or authority channels the regulation names, then decide whether the vulnerability affects an in-scope service. A vulnerability that is significant to your service may trigger the incident timelines, while a routine patch may not. Write that decision rule down, assign an owner, and test it with a tabletop exercise so the first real advisory does not become the first time the process runs.

What makes open-source evidence cost more or less

The cost of producing NIS2 evidence for open-source components depends less on the software than on how much of it you run, how well you know what it is, and when you collect proof. The cards below cover the five factors that move effort most, and what to check in each before asking for a quote.

Scope of components and systems

Every additional component, service and environment adds inventory entries, update records and vulnerability reviews. Start by listing the systems that support essential or important services, then the libraries, containers and images each one pulls in. Ask any implementation partner to price the work against a written list of systems rather than an estimate of total software. Narrowing scope to systems that actually support in-scope services is usually the most direct lever on effort.

Maturity of the existing inventory

A current software bill of materials (SBOM) for each system makes acquisition checks and vulnerability monitoring faster to evidence. If component data exists only in build logs or in people's heads, the first phase becomes discovery work. Check whether builds generate SBOMs automatically, whether the output is stored with version and date, and whether a named owner keeps it accurate after each release.

Forks and self-maintained components

A fork or patched copy of an upstream project means your team, not the upstream community, owns its security updates. Each fork needs its own tracking of upstream fixes, a documented patch history and a decision on how long it will be maintained. Count these components separately during scoping, because they generate recurring work that off-the-shelf dependencies do not. Where a fork is unavoidable, record why, and who is responsible for it.

Support contracts with suppliers

Commercial support for an open-source product often comes from a vendor, a foundation partner or a consultancy. Each contract may define security update timelines, notification duties and the end of support date, which the acquisition process must address. Confirm for each component whether a paid agreement guarantees fixes for the lifetime you need, or whether you depend on community releases. The number of separate suppliers multiplies the reviews and the contract evidence you must keep.

Continuous versus audit-time evidence

Evidence collected as work happens, through pipelines, ticket trails and scan logs with dates, is cheaper to assemble than evidence reconstructed before an inspection. Supervisors can request proof at any point, and reconstructed records are harder to defend. Decide which records are generated automatically, such as scan results and SBOM versions, and which need a named person to approve them. Ask any partner to specify which artifacts are produced continuously and which are created on request.

Vulnerability triage and response load

Monitoring many components produces alerts, and the effort lies in deciding which ones affect your deployment and recording that decision. Filtering by component version, exposure and whether a vulnerability is actually reachable reduces noise. Set an internal rule for how critical vulnerabilities are handled and how fast they are assessed, keeping in mind that the regulation requires application within a reasonable time rather than a fixed number of days. Confirm how alerts are routed and who signs off on each closure.

Who owns which open-source duties

The organization owns its NIS2 obligations, including the open-source components it selects, runs and depends on. Article 20 places approval and oversight of the Article 21 measures with the management body, and the management body remains accountable for them even when technical work is outsourced. The compliance team turns that oversight into decisions it can defend to a national competent authority.

Component decisions: Approving which open-source products enter production, the support model behind each one, and the conditions under which a component is retired.
Acquisition rules: Writing security requirements into procurement and internal change processes, including information on components and security updates for the product's lifetime or replacement after end of support.
Risk acceptance: Recording who accepts residual risk when a component has no active maintainer or a known vulnerability awaits a fix.
Evidence ownership: Keeping the policies, inventories, scan records and decisions that a supervisor may request.
Management training: Making sure board members understand the open-source risks they are approving.

Confirm with your counsel how your national transposition law assigns these duties and whether any sector rule adds to them.

Questions buyers ask about open-source components and NIS2

Does NIS2 ban the use of open-source software?

No. NIS2 does not prohibit open-source software, and Recital 52 says open-source cybersecurity tools and applications can diversify suppliers and support transparent, community-driven vulnerability discovery. The Directive also says Member States should be able to promote open-source software and open standards, particularly for SMEs facing implementation costs. What NIS2 requires is that you manage the risk of every component you run, whether it is proprietary or open source. Your Article 21 risk-management measures, acquisition processes and vulnerability handling apply to a community project exactly as they apply to a commercial product. Confirm with your national competent authority how your transposition law treats specific tools in your sector.

Do open-source components need a NIS2 certificate?

No. NIS2 creates no certificate of compliance, for open-source components or for anything else. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Your evidence is the set of records that shows your controls operate: component inventories, acquisition records, vulnerability scan results and patch decisions. A supplier or project badge does not prove that your organization complies. If a customer asks for a certificate covering an open-source tool, ask what the certificate covers and whether an independent body issued it. Keep the records that show your own decisions.

Must my organization publish an SBOM for the software it uses?

No. The software bill of materials duties in the sources come from the Cyber Resilience Act, not from NIS2, and they fall on manufacturers of products with digital elements. Under the Cyber Resilience Act, the SBOM belongs in the technical documentation and must be provided to a market surveillance authority on reasoned request. Sharing the SBOM with users is optional: a manufacturer only has to tell users where to access it if it decides to make it available. Under NIS2, your own duty is to know what components you run, so an internal inventory is usually the practical starting point. Confirm the exact obligations for your product role with the Cyber Resilience Act text.

How fast must security patches for open-source components be applied?

NIS2 does not set a patch deadline in days. The implementing regulation requires that security updates be applied within a reasonable time, and it separately requires you to address critical vulnerabilities without undue delay. In practice, your procedure should define how you receive vulnerability information from CSIRTs, competent authorities and suppliers, how you rate severity, and who approves emergency changes. Supervisors will test whether the process runs and whether the decisions are recorded. Set internal targets that match your risk assessment, document why they are reasonable for your environment, and record the exceptions. Ask your national authority whether it publishes further expectations.

Can my team manage open-source component risk in-house?

Often yes, if the team has the skills and time, but the management body keeps accountability either way. Work that can usually stay internal includes maintaining the component inventory, deciding which patches to apply, and recording the results of vulnerability scans. Work that teams often outsource includes setting up vulnerability monitoring, integrating scan tools into delivery pipelines, and preparing evidence packs for assessments. The cost depends on the number of components, the number of systems, how often they change, and whether you already run a vulnerability management process. Ask any provider for a written scope listing deliverables, responsibilities and the evidence each deliverable produces.

What work must my team supply when using open-source tools?

Your team supplies the decisions and the records, while tools and partners supply the mechanics. The core inputs are an inventory of components, including hardware and software details, acquisition requirements that cover security updates for the product's lifetime or replacement after end of support, and validation records for delivered products. Your team also owns the vulnerability monitoring procedure, the scan schedule and the record of what was fixed and when. For self-hosted tools, such as OWASP Dependency-Track, which consumes and produces CycloneDX SBOMs and VEX and tracks license use with SPDX license IDs, your team configures the instance, feeds it component data and reviews its findings. Confirm the tool's current capabilities in its documentation before relying on them.

Does DeployOpen handle open-source component management for NIS2?

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can prepare systems and evidence for compliance assessments. For component management, that can include setting up a self-hosted inventory and vulnerability tracking tool in your environment, connecting it to your build and deployment processes, and documenting the procedure your team runs. DeployOpen does not issue audit reports or certificates, and your organization keeps ownership of its controls and decisions. Engagements are fixed-scope, with deliverables agreed in writing before work starts, and a quote follows from that written scope.

What may change: the January 2026 NIS2 amendment proposal

The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13). The proposal includes a new small mid-cap category and aims to simplify some measures and align the Directive with the Cybersecurity Act. It is still a proposal. It needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 still describe it that way. Until the amended text is adopted and transposed, the obligations described on this page, including the Article 21 duties and the supplier expectations that come with them, remain the baseline you should plan against.

For open-source software, the practical risk is a change in who falls inside scope, which affects how much of your supplier and component evidence a supervisor will ask for. An entity that moves into or out of a category could see different supervision intensity or different reporting expectations. Ask your national competent authority whether the proposal affects your entity, and what it would change for your open-source inventory, vulnerability monitoring and acquisition records. Do not defer work on SBOM generation, component tracking or lifetime update planning on the assumption that the proposal will reduce your duties.

Check the status of COM(2026) 13 at the point you rely on it, not when you first read about it. The Commission's proposal page gives the reference and the status at the time of publication. Record the date you checked, the national transposition status in your Member State, and the decision you made as a result, so the file shows that your position followed the law in force at the time.

How DeployOpen prepares open-source evidence for NIS2

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For open-source components in a NIS2 supply chain, the work focuses on producing the acquisition records, vulnerability monitoring and SBOM evidence that the organization owns and can show to its supervisor. DeployOpen prepares that evidence but does not issue any compliance report or certificate.

How we scope

Engagements are fixed-scope, with the components, environments and evidence types agreed in writing before work starts.
The written scope names which open-source components are in the inventory and which acquisition records the client must hold for each.
Scope confirms which roles stay with the client, including management body approval and the supplier decisions it must make.

How we build

Component inventories and SBOM generation are set up in the client's own environment, with outputs stored in client-controlled systems.
Vulnerability monitoring is configured against the sources the client has chosen, with scan schedules and recorded results.
Dependency tracking, including license checks, is deployed using the client's chosen tooling and tested against sample components before go-live.

How we hand over

Handover includes runbooks for updating SBOMs, triaging new vulnerabilities and recording decisions on critical findings.
Documentation maps each evidence artifact to the acquisition, monitoring and SBOM duties so the client can show them to an auditor or authority.
The client receives the configurations, access records and evidence templates needed to keep the process running without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
Retainers can cover keeping SBOMs current after component upgrades and reviewing vulnerability records on a set cadence.
Confirm with DeployOpen which support and testing options apply to your environment before signing a scope of work.

Open-source software in the NIS2 supply chain