EU regulation · DORA and NIS2
DORA, NIS2 and end-of-life open source
DORA (Regulation (EU) 2022/2554) defines a legacy ICT system as one past end-of-life and requires a specific risk assessment of those systems at least yearly (Article 8(7)). NIS2 (Directive (EU) 2022/2555, Article 21) requires vulnerability handling and supplier security. Neither bans end-of-life software; both require you to manage it and to hold vendors to written terms.
Published . Clause text checked 26 October 2026against the sources listed at the foot of the page. OSSeva's evidence supports your own assessment; it does not make you compliant.
DORA
- Instrument
- Regulation (EU) 2022/2554, directly applicable
- Applies from
- 17 January 2025 (Article 64)
- Who
- Financial entities listed in Article 2
- End-of-life hook
- Article 3(3) and Article 8(7)
NIS2
- Instrument
- Directive (EU) 2022/2555, applied through national law
- Applies from
- 18 October 2024 (Article 41(1))
- Who
- Essential and important entities in the covered sectors
- End-of-life hook
- Article 21(2)(d) and (e)
Scope
Which regime applies to you
DORA and NIS2 overlap, and the first question is which one carries the duty. Your legal team decides that. The table shows how the texts divide it.
| You are | Rule that carries the duty | Basis |
|---|---|---|
| A financial entity: bank, payment or e-money institution, investment firm, insurer, trading venue, crypto-asset service provider and the other types listed | DORA, applying since 17 January 2025 | Articles 2(1)(a) to (t) and 64 |
| A financial entity that NIS2 would also cover | DORA, which NIS2 treats as the sector-specific act for these entities | DORA Article 1(2) |
| An essential or important entity in another sector (energy, health, digital infrastructure and the rest of Annexes I and II), medium-sized or larger | NIS2, as your Member State transposed it. Member States had to apply their measures from 18 October 2024 | NIS2 Articles 2(1) and 41(1) |
| An ICT provider to a financial entity, such as an extended-support supplier | Your customer's DORA duties reach you through the contract. Direct oversight applies only to providers the European Supervisory Authorities designate as critical | DORA Articles 2(1)(u), 30 and 31 |
DORA
DORA: the articles that reach end-of-life open source
DORA uses the term in one place. Article 3(3) defines a "legacy ICT system" as one that has reached the end of its lifecycle (end-of-life), is not suitable for upgrades or fixes, or is no longer supported by its supplier or by an ICT third-party service provider, and is still in use. The three limbs are joined by "or", so an open source line past its end date fits the first limb. Extended support does not change that date. Ask your supervisor or counsel how they read the definition for a line a third party patches.
| Article | What it requires | What it means for an ended open source line |
|---|---|---|
| Art. 3(3) | Defines a legacy ICT system by end of lifecycle or loss of supplier support. | Your end-of-life components are legacy ICT systems for the rest of the rules below. |
| Art. 8(1), 8(4), 8(6) | Identify, classify and document ICT assets, map their configuration and interdependencies, and keep the inventories current. | The asset map has to name the component and its version. An SBOM per build is a direct input. |
| Art. 8(7) | At least yearly, a specific ICT risk assessment on all legacy ICT systems. Microenterprises are excluded. | A dated assessment for each ended line. It is yours; a vendor's CVE record is evidence inside it. |
| Art. 9(4)(f) | Appropriate, comprehensive, documented policies for patches and updates. | The policy states a patch window. A supplier's patch window and CVE record per release show it operating. |
| Art. 28(2), 28(3) | A strategy on ICT third-party risk, and a register of information on every contractual arrangement, separating those that support critical or important functions. | An extended-support contract gets a register entry, with a flag for any critical or important function it supports. |
| Art. 28(4), 28(5) | Before contracting: assess criticality, identify risks, do due diligence, and contract only with providers that meet appropriate information security standards. | The pre-contract file for the vendor. A SOC 2 Type II report under NDA can be one input to due diligence. |
| Art. 28(7), 28(8) | Termination rights in listed circumstances, and tested exit strategies for services supporting critical or important functions, with transition plans to another provider or in-house. | Patches apply to upstream source with no fork, so an exit is to a supported upstream release or another provider. The exit plan still has to name the target version. |
| Art. 29 | Assess whether a contract would leave you with a provider that is not easily substitutable, or with concentrated dependency. | Check that no single supplier's proprietary build is the only way to run the line. |
| Art. 30(2), 30(3) | Contract terms: service descriptions, locations, service levels, incident assistance, cooperation with authorities, termination, and for critical or important functions audit rights and a transition period. | The checklist further down maps these terms to what OSSeva states publicly. |
NIS2
NIS2: Article 21 and what it asks about vulnerabilities and suppliers
The NIS2 Directive does not use the words end-of-life. It reaches ended software through Article 21, the core of NIS2 compliance, which requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures for cybersecurity risk management of their network and information systems.
| Article | What it requires | What it means for an ended open source line |
|---|---|---|
| Art. 3(1), 3(2) | Annex I entities above the medium-sized ceilings are essential entities. Other entities of an Annex I or II type are important entities. | Your classification decides the supervision and fines below. Each Member State keeps a list of essential and important entities (Art. 3(3)). |
| Art. 20(1) | Management bodies approve the cybersecurity risk-management measures, oversee them and can be held liable for infringements. | A decision to run an ended line is a management decision, recorded as such. |
| Art. 21(2)(c) | Business continuity, such as backup management and disaster recovery, and crisis management. | The fallback if a patched build fails or a vendor is unavailable: a tested rollback and a second route to a fix. |
| Art. 21(2)(d) | Supply chain security, including security-related aspects of the relationships with direct suppliers or service providers. | An extended-support vendor is a direct service provider, so it falls under your supplier assessment. |
| Art. 21(2)(e) | Security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. | The vulnerability-handling record: which CVEs affect the line, which are fixed, in which build. |
| Art. 21(3) | When choosing supplier measures, take into account each direct supplier's vulnerabilities and the overall quality of its products and cybersecurity practices. | Ask for evidence of how the vendor builds and signs what it ships. |
| Art. 21(4) | An entity that finds it does not comply takes the necessary corrective measures without undue delay. | A finding on an ended line starts a clock for a documented fix or plan. |
| Art. 23(4) | Significant incidents: early warning within 24 hours, notification within 72 hours, final report within one month of the notification. | If an unpatched component is exploited, these clocks start when you become aware of the incident. A vendor's response time affects how quickly you get the facts. |
| Art. 32(2)(e), 32(2)(g) | Supervisors of essential entities can request information on the cybersecurity risk-management measures, including documented policies, and evidence of their implementation, such as audit results and the underlying evidence. | CVE records, VEX statements and signed-build verification are the underlying evidence for an ended line, ready before the request arrives. |
| Art. 34(4), 34(5) | Maximum fines of at least EUR 10 million or 2 % of worldwide turnover for essential entities, and EUR 7 million or 1.4 % for important entities, whichever is higher. | The Directive sets the floor for the maximum fine. Your Member State sets the national figure. |
NIS2 does not apply the same way in every EU country. Member States had to adopt and publish their measures by 17 October 2024 and apply them from 18 October 2024 (Article 41(1)), and the national text, the list of covered sectors and the supervisor are what bind you. Check the law of each Member State where you operate.
Vendor terms
What to demand from an end-of-life support vendor
DORA Article 30 lists the terms a contract with an ICT provider must carry. NIS2 does not list contract terms but requires you to assess suppliers. The table turns both into questions for any extended-support vendor, and shows what OSSeva states publicly today. Where the site says nothing, the table says so: ask for the term in the draft contract before you rely on it.
One point on service levels. Article 30(3)(a) asks for precise quantitative and qualitative targets for services supporting critical or important functions. Separate response from fix. A 15-minute P1 is a response time. A Critical CVE patched within 48 hours is a delivery window for a fixed build. Neither is a time to resolve your incident, and a contract should say which it is.
| Term to ask for | Source | What OSSeva states publicly today |
|---|---|---|
| A complete description of services and whether subcontracting is allowed | DORA Art. 30(2)(a) | The Patch, Assure and Operate pages describe scope. Subcontracting terms are not stated on this site. |
| Locations where services are provided and data is processed | DORA Art. 30(2)(b) | Not stated on this site. Ask for it in the draft contract. |
| Service levels with precise targets | DORA Art. 30(2)(e), 30(3)(a) | Critical CVEs patched within 48 hours and High within 7 days, for every technology. Operate: 24/7, P1 15 minutes, P2 1 hour, P3 4 hours. Assure includes 24/7 reactive support. |
| Assistance with ICT incidents at no extra cost or a cost set in advance | DORA Art. 30(2)(f) | Operate covers P1 response around the clock. The cost terms are not stated on this site. |
| Full cooperation with competent and resolution authorities | DORA Art. 30(2)(g) | Not stated on this site. Ask for it in the draft contract. |
| Termination rights and minimum notice periods | DORA Art. 30(2)(h) | Not stated on this site. Ask for it in the draft contract. |
| Security measures, tools and policies appropriate to your regulatory framework | DORA Art. 30(3)(c) | A SOC 2 Type II report under NDA. Builds signed with GPG (packages and Maven artifacts) and cosign (container images) with SHA-256 checksums; steps are on the security page. |
| Notice and reporting duties for developments that could affect service | DORA Art. 30(3)(b) | Not stated on this site. Ask for it in the draft contract. |
| Access, inspection and audit rights | DORA Art. 30(3)(e) | The SOC 2 Type II report is available under NDA as independent assurance. Audit and inspection rights are not stated on this site. |
| An exit strategy with a transition period | DORA Art. 28(8), 30(3)(f) | Patches apply to upstream source with no fork, so the exit is to a supported upstream release or another provider. The transition period is not stated on this site. |
Evidence
The evidence OSSeva supplies, mapped to each regime
The same evidence serves both regimes. It matches the DORA and NIS2 rows on the compliance matrix. It supports your own assessment. Whether the Directive or the Regulation applies to you, and what it requires of you, comes from your Member State's law and your supervisor.
| Regime | OSSeva evidence | What stays with you |
|---|---|---|
| DORA Articles 8, 9(4)(f), 28(3), 28(8) | An SBOM per build for the asset map; a documented patch window with a CVE record per release; signed builds that apply to upstream source with no fork, so an exit is to a supported release or another provider. | The register of information, the legacy-system risk assessment, the exit plan and its testing. |
| NIS2 Article 21(2)(d) and (e) | CVE records and a VEX statement per CVE as the vulnerability-handling record; signed builds for supply-chain integrity. | Your measures and policies, the management approval, and the national law that applies. |
For how assessors and supervisors read patched-build evidence, see what auditors accept for end-of-life software. For the longer treatment of the Regulation, see DORA compliance for financial firms using open source infrastructure. For payment card rules, see PCI DSS and end-of-life software, and for US federal rules, see FedRAMP and CMMC with end-of-life software.
Not a fit for
- You need a provider that calls itself DORA-compliant. OSSeva makes no such claim. DORA puts its duties on financial entities and puts direct oversight on providers the supervisors designate as critical, and OSSeva makes no claim of that designation.
- You need an assessor or a supervisor's view. OSSeva does not certify that you comply with DORA or NIS2, and it does not file reports for you.
- You are looking for Cyber Resilience Act conformity. This page does not cover the Cyber Resilience Act, and OSSeva makes no conformity claim. See the Cyber Resilience Act and end-of-life open source.
- Your component is closed source. OSSeva patches open source lines; check yours on the supported versions page.
Does DORA apply to open-source support vendors?
DORA lists ICT third-party service providers in its scope (Article 2(1)(u)), but the duties in Articles 5 to 30 fall on the financial entity. They reach a support vendor through the contract, because Article 30 lists the terms the contract must carry. Direct oversight applies only to providers the European Supervisory Authorities designate as critical under Article 31. OSSeva makes no claim to be a DORA-compliant provider.
Is end-of-life software a NIS2 issue?
NIS2 does not use the words end-of-life. Article 21(2)(e) requires security in the maintenance of network and information systems, including vulnerability handling, and Article 21(2)(d) requires supply chain security. An ended component with unpatched vulnerabilities is a vulnerability-handling and supplier question under those points, and the Article 21(4) duty to take corrective measures without undue delay applies once you find a gap.
Is an end-of-life open source line a legacy ICT system under DORA?
Article 3(3) defines a legacy ICT system as one that has reached the end of its lifecycle (end-of-life), is not suitable for upgrades or fixes, or is no longer supported by its supplier or an ICT third-party service provider, and is still in use. A line past its end date fits the first limb. Article 8(7) then requires a specific ICT risk assessment on all legacy ICT systems at least yearly, apart from microenterprises. Ask your supervisor how they treat a line a third party patches.
When did DORA and NIS2 start to apply?
DORA has applied since 17 January 2025 (Article 64). NIS2 Member States had to adopt their national measures by 17 October 2024 and apply them from 18 October 2024 (Article 41(1)), so the date and detail that bind you are in your Member State's law.
Sources
Checked 26 October 2026. Clause numbers and wording are from the official texts below. OSSeva does not certify that you comply with any of these rules, does not act as an assessor and does not file reports for you.
Get a quote
Need evidence for an end-of-life component in an EU regulated firm?
Ask for a sample evidence pack. It shows what one patched build ships with: the SBOM, VEX statements, signed build and CVE record. Your supervisor or assessor decides what it proves.