On 22 September 2026, ENISA published its annual Threat Landscape report. The 2026 edition covers 4,875 incidents analysed over the period July 2024 to June 2025 (source: ENISA Threat Landscape 2026, 22 September 2026). Its central conclusion is stated without ambiguity: digital dependencies widen the attack surface and require a new level of vigilance to prevent incidents and limit their impact. For teams steering a NIS2 or DORA programme, this report is not academic reading. It confirms or challenges your current priorities.
What ENISA measures: the intrusion vectors
The report documents three vectors that account for most of the malicious activity observed. Distributed denial of service represents 51.3% of the incidents recorded against entities in the European Union. Unauthorised access ranks second with 39.5%.
But the figure on vulnerability exploitation deserves the closest attention: 60.4% of successful intrusions use a vulnerability as the initial point of access, whether a zero-day flaw or a known, unpatched vulnerability (source: ENISA Threat Landscape 2026, 22 September 2026). This is not an emerging trend. It is confirmation, across four thousand eight hundred and seventy-five incidents, that the attacker takes the path of least resistance, and that this path almost always runs through an unpatched component, an exposed service or a forgotten interface.
On the financial side, 40% of financially motivated events involve the deployment of ransomware. The remainder splits between data exfiltration (31%) and identity-based fraud (19%). Public administration remains the most targeted sector, ahead of health, rail transport, maritime and ICT services.
What "digital dependencies" means in practice
ENISA uses the term "cyber dependencies" to refer to all the trust relationships and technical dependencies between your organisation and third parties: cloud service providers, software vendors, integration partners, maintenance providers. These dependencies are not new. What has changed is their density. The digitalisation of processes and the adoption of cloud have multiplied the points of contact between your information system and the outside world.
The report identifies a structural blind spot here. An organisation may have a rigorous vulnerability management policy for its known assets and yet remain exposed through assets it does not know exist, or through third parties whose attack surface it has never assessed. The attacker, for his part, maps systematically. He does not distinguish your "known" assets from your "unknown" ones. He looks for the available entry point.
What NIS2 and DORA already require on this point
For organisations subject to NIS2 or DORA, this picture is not theoretical. Both regulatory frameworks contain explicit obligations on asset visibility and dependency management.
The NIS2 Directive, Article 21, requires risk management measures that cover the supply chain and relationships with suppliers. This presupposes knowing which suppliers access your systems, under what conditions and with what residual level of risk. An organisation unable to answer these questions during an inspection by France's national cybersecurity agency (ANSSI) exposes a documentable gap.
DORA goes further. Financial entities must maintain a register of information on ICT third-party service providers, listing all of them with their level of criticality. This register must be kept up to date and provided to the competent authority on request. The French financial regulators AMF and ACPR have indicated that the review of this register is a supervisory priority for the second half of 2026. In other words, what ENISA describes as a systemic risk factor, NIS2 and DORA turn into a documentary obligation.
A representative scenario
Consider an intermediate-sized entity, subject to NIS2 as an important entity, that deploys a line-of-business application as SaaS. The SaaS provider itself integrates a third-party authentication component. This component, which the entity does not manage directly, has had a known vulnerability for three months: the CVE is public and a fix is available, but the SaaS provider has not yet applied it.
The entity does not know this component exists within its scope. Its security team monitors critical CVEs, but only on the assets it manages directly. The attacker exploits the flaw through the SaaS provider. The NIS2 entity must notify ANSSI within 24 hours, for an incident caused by a dependency it did not know existed.
This scenario is the concrete translation of ENISA's conclusion: unmapped dependencies are intrusion vectors that your detection and patch management processes cannot cover, precisely because they do not know those dependencies exist.
What your teams need to adjust
Three adjustments follow directly from the report.
Extend your asset mapping to cover second-tier dependencies. The task is not only to list your direct suppliers. It is to understand which third-party components they integrate into the services they deliver to you. The SBOM (Software Bill of Materials) standard is the structured tool for achieving this visibility. Requiring an SBOM from your critical suppliers is now a practice aligned with regulatory expectations. Implementation details are covered in the article on software inventory under NIS2 and DORA.
Integrate CVE alerts relating to your third-party components into your monitoring feed. A component you do not manage directly still falls within your risk perimeter. If your vulnerability monitoring tool covers only your internal assets, it does not cover your actual attack surface.
Test your notification process against a late-discovery scenario. The ENISA report confirms that incidents arising from vulnerability exploitation are rarely detected at source. They are often identified through an external alert or during a post-incident investigation. If your NIS2 notification plan does not provide for this case, it underestimates the operational reality that inspectors are familiar with.
What this report changes for your decisions
The Threat Landscape 2026 gives your teams an external benchmark to justify internal investment. When a digital dependency mapping programme is under budget discussion, the answer to the question "why now?" is now documented by the European cybersecurity agency, based on four thousand eight hundred and seventy-five real incidents.
When 60% of intrusions pass through a vulnerability, the question asked during a NIS2 inspection or a DORA review is not whether your organisation could be affected through this vector. It is whether it has enough visibility to detect, notify and contain an incident that used it. The inventory of your dependencies is the operational answer to that question.