ENISA Threat Landscape 2026: Counting Incidents Without a Cause

Start with the definitions

A taxonomy stands or falls with its definitions. ENISA’s threat reporting rests on three documents: the annual report, the methodology behind it, and the threat taxonomy the methodology names as its standard. I checked each of them for what it defines.

The report defines nothing it counts

ETL 2026 contains no definition of threat, incident, unauthorised access, data breach or ransomware, and I found none in its 101 pages. Its methodology section explains the sources, the reporting period and the caveats, and refers to ENISA’s Cybersecurity Threat Landscape (CTL) methodology for everything else (p. 9).

The methodology defines an attack by intent and effect

The CTL methodology was published in August 2025 and updated on 18 September 2026. It contains one definition that matters here, in a footnote. A cyberattack is:[2]

The definition names an intent (intentional effort) and three effects (disrupt, compromise, damage). It also names a means, which is either a state the attacker has reached (unauthorized access) or a repetition of the thing being defined (malicious actions). It never asks what made the asset vulnerable.

That choice carries through to the questions analysts must answer for each incident they collect. Paraphrased from the methodology, the questions are:[2]

• Does the incident target or impact an EU Member State, and is it cross-border?
• Which sectors, systems and assets are affected?
• What is the impact?
• How did the associated intrusion set carry out the attack (TTPs)?
• What is the intrusion set’s assessed motivation?
• Is there a specific context, and which mitigation measure can be applied?

Those questions cover geography, sector, asset, impact, the actor’s technique, the actor’s motive, context and mitigation. None asks which weakness the attack exploited. The closest is the TTP question, and even that is phrased around the intrusion set, the actor.

The taxonomy is the standard, and it is under revision

The methodology describes the ENISA Threat Taxonomy, “first established in 2016 and updated in 2022”, as “the guiding principle for CTLs and the standard for threats referenced within ENISA.” The next sentence reads: “The taxonomy is currently under revision for the purpose of developing a more mature, actionable framework.”[2] The footnote for the 2022 update links to the repository of the Reference Security Incident Taxonomy task force. That is a different classification, built for incident exchange between CSIRTs.

The 2016 taxonomy is still the spreadsheet ENISA serves on its threat-taxonomy page. It has eight high-level threats: Physical attack (deliberate/intentional); Unintentional damage / loss of information or IT assets; Disaster (natural, environmental); Failures/Malfunction; Outages; Eavesdropping/Interception/Hijacking; Nefarious Activity/Abuse; and Legal.[3] Most of them would survive a cause test. The difficulty is the cyber part. Almost everything an attacker does falls under one of the eight, Nefarious Activity/Abuse, and its subdivisions do not share a single axis:

• Spear phishing attacks appears twice, under Social Engineering and under Targeted attacks (APTs etc.). Mobile malware also appears twice, under Malicious code/software/activity and under Targeted attacks.
• Web application attacks / injection attacks (SQL, XSS) and Elevation of privileges are filed under Malicious code/software/activity, so server-side implementation flaws are classed as malware.
• Man in the middle / Session hijacking sits under Generation and use of rogue certificates, although Eavesdropping/Interception/Hijacking is a separate high-level threat.
• Compromising confidential information (data breaches) is listed as a threat, though it is an outcome.
• Targeted attacks (APTs etc.) is a kind of campaign, defined by who runs it and how patiently.

This is what “the standard for threats referenced within ENISA” looks like at the level where classification actually happens. An analyst with a spear-phishing incident has two valid places to put it. An analyst with an SQL injection has to call it malware.

What the report actually counts

Without a definition of threat, ETL 2026 measures its incidents on six different axes. Each is reasonable on its own. They become a problem when they are read as one list of threats.

Only the last axis asks the question a cause-oriented taxonomy is built on. It is also the axis with the least data.

What went wrong, and where

1. The cause is the attribute with the least data

Unauthorised access accounts for 39.5% of 8,257 incidents, about 3,260. ENISA was able to identify an intrusion vector for 5.2% of them (p. 11). If both percentages apply to the full dataset, as the text indicates, Figure 2 describes about 170 incidents, roughly 2% of the dataset. The headline that vulnerability exploitation enabled 60.4% of unauthorised access, repeated in the executive summary (p. 7), therefore rests on about 100 incidents.

The NIS2 figures quoted in the same report show the same pattern in a second data source. Member States reported 1,954 events under NIS2 for 2025. Of these, 941 were malicious actions, and for around half of those the root cause was reported as unknown (p. 19, note 79).

Part of this is the nature of open sources. A claim on a leak site names a victim and implies a motive. It rarely names an entry point, and ENISA says so plainly (pp. 9–10). But a report that can say why for more than nine incidents in ten and how for one in fifty will drift towards analysing why. The structure of ETL 2026 shows that drift.

2. One label, several axes

Social engineering appears in Figure 3 as an incident type, with 0.7% of incidents. The executive summary calls it “a common enabling tactic to abuse trust” (p. 7) and gives it its own technique breakdown (Figure 1). Both statements can only be true because they are on different axes. As an incident type, social engineering is whatever remained after DDoS, unauthorised access, fraud and information operations were counted. As a tactic, it sits inside most of them.

ENISA acknowledges the overlaps this creates: “data breaches, frauds, scams and ransomware are expected to present overlaps”, because data stolen in one is sold and used in the others (p. 9). When the categories are expected to overlap, one causal story is split across several labels. The shares cannot be read as a ranking of threats, compared year on year, or set against another report’s numbers.

3. Categories built on actors, and the actors converge

The four deep-dive chapters cover cybercrime, State-nexus activity, FIMI and hacktivism, which are actor types. The report then finds that this structure does not hold:

ENISA’s example is Moonstone Sleet, a State-nexus intrusion set, deploying Qilin ransomware (p. 14). The deployment is the same event whoever carries it out. Filed by actor, it moves between chapters as attribution changes, and attribution takes time. ENISA notes that cyberespionage campaigns are typically documented with a delay “often spanning from six months to more than four years” (pp. 9–10). A classification that depends on attribution stays provisional for that long.

TLCTC’s Axiom IV exists to prevent exactly this: “Actor identity (attribution, motivation, capability) is not a structuring element for threat categorization.”[4] Actor and motive remain valuable intelligence. They belong on their own axes, cross-tabulated against the cause, rather than used to define it.

A small slip in the report shows how loosely the motive labels are anchored. The text on p. 13 gives cyberespionage as 6.3%. In Figure 4, 6.3% is the “Unknown” bar, and cyberespionage is 5.9%, the figure the executive summary also uses (p. 7).

4. The vector list mixes attacks, failures and people

Figure 2 is the most cause-like chart in the report, and it shows why a cause axis needs rules and not just a list. Its nine vectors are not all of one kind:

• Insider threat (10.1%) names a person, not a vector. ENISA attributes its rise to Famous Chollima, DPRK operatives hired as IT workers (p. 11). TLCTC has no insider category. The R-SCOPE test asks whether an accountable grantor conferred an entitlement covering the action. An employee who stays within a genuinely held grant but misuses it for a corrupt purpose is Abuse of Rights: operational risk, with no cluster. Anyone acting outside a grant is in the Attack row, whether they sit inside the organisation or outside it.[4] The IT-worker scheme is in the Attack row, because the hiring itself was obtained by deception. The framework’s record of it reads #9 ||[human][@DPRK→@WesternOrg]|| →[Δt=~30d] #1 + [DRE: C].[6]
• Misconfiguration / exposure (20.7%) combines an attack with a non-attack. An attacker using what a misconfiguration exposes is abusing designed functionality and configuration, which is #1. A database that is left open and that nobody exploits is an Error in Use or a failure: operational risk, with no cluster.
• Vulnerabilities (60.4%) merges server-side and client-side implementation flaws. TLCTC separates them by the role of the flawed component (#2 and #3, R-ROLE) because they have different owners and different controls. Patching an internet-facing appliance is not the same job as hardening a browser fleet.
• Credential based (3.6%) is credential use, #4. The theft of the credential is recorded as a separate step in whichever cluster enabled it (R-CRED).
• Accidental appears among the assessed objectives in Figure 4 (0.1%). An accident has no objective. In TLCTC it falls outside the Attack row altogether.

This is the purpose of R-SCOPE’s three questions, asked in order: is there an actor, did they intend it, were they entitled?[4] Without them, attack statistics fill up with events that no security control could have prevented. The controls that could have prevented those events, such as segregation of duties, vetting and configuration management, are then never identified as such.

5. Outcomes counted as threats

The cybercrime chapter names three key threats: fraud and impersonation, data breaches and ransomware deployments. Two of them are outcomes, and for one of them ENISA says so itself: “Data breaches are often claimed as outcomes, providing limited visibility into the Tactics, Techniques and Procedures (TTPs) that led to the compromise” (p. 46). The data-breach count is built from claims advertised on criminal forums, whose “authenticity or currency” could not be verified (p. 42). Ransomware is measured the same way, through claims on data leak sites.

A leak-site claim records extortion. In TLCTC’s consequence chain, extortion is a business risk event, several links after the cause. The ransomware payload executing is #7 (R-EXEC). The encrypted files are [DRE: Ac], data present but unusable. The stolen data is [DRE: C]. The causes that came before, whether phishing, an exploited appliance or reused credentials, do not appear anywhere in a count of claims.

ENISA’s own chart of common ransomware TTPs (Figure 42, p. 53) makes the point. Its largest box is T1486, Data Encrypted for Impact, which is the impact. Read through the TLCTC ATT&CK mapping, the twelve techniques give this picture:[5]

Nine of the twelve techniques involve designed functions (#1), four end in code execution (#7), two use credentials (#4) and one exploits a server-side flaw (#2). That is a control agenda: restrict what administrative tools and interpreters can do, protect credentials, patch exposed servers and control execution. “Ransomware” as a threat category produces no such agenda.

6. Labels drift even where ATT&CK is used

ENISA documents ShinyHunters “across the full kill chain”, which makes it the best-described case in the report (p. 46). According to the report, the group “commonly gained access through vishing campaigns impersonating IT personnel to steal Single-Sign-On (SSO) credentials and MFA codes. Following compromise, operators accessed connected SaaS services (Exploitation of Remote Services (T1210) and Software Deployment Tools (T1072)), exfiltrated sensitive data and conducted extortion.”

ATT&CK defines T1210 as exploiting a software vulnerability in a remote service. In the TLCTC mapping it is #2, a server-side implementation flaw.[5] Nothing in ENISA’s description involves a code flaw. The operators logged in with stolen SSO credentials and then used what the connected services were built to do. Read by cause, the narrative is:

#9 ||[human][@External→@Org]|| + [DRE: C] → #4 → #1 + [DRE: C]

Vishing that captures credentials and MFA codes is #9, and the disclosure of those codes is a confidentiality event in its own right. Using the captured credentials is #4 (R-CRED). Using the connected SaaS services is #1, followed by the data loss. The extortion that ENISA counts comes afterwards, as a business risk event. If evidence showed code being pushed through a deployment tool, the T1072 label would add #1 → #7. ENISA’s text does not describe that, so it is not a step here.

The mislabel matters because a label assigns an owner. T1210 sends the problem to vulnerability management. The narrative points instead to a help-desk process, MFA codes that can be read out to a caller, and SaaS integrations with broad scope. ATT&CK is precise about techniques, but it has no test for which weakness was exploited. Without such a test, a technique label can point to the wrong owner. And the same path, carried out by a State-nexus group, would move to a different chapter of the report while its controls stayed exactly the same.

The ETL vocabulary, read by cause

Every label ENISA uses can be placed. Some are causes, some are consequences, and some are not attacks at all. The table below is my reading of ENISA’s categories against the TLCTC v2.7 rules. ENISA has not made this classification.

Reading the vocabulary this way has three effects. The causes form a closed set of ten, so every known vector has exactly one place and the shares add up. The consequences move to the right-hand side of the bow-tie, where ransomware, data breach and fraud no longer compete with their own causes. And the events that are not attacks leave the attack statistics. That is where ENISA’s “accidental” and part of its “misconfiguration / exposure” belong.

Why TLCTC belongs in the ETL

The methodology stresses “the immense importance of having consequent taxonomies and frameworks to produce reliable and consistent output” (CTL methodology, p. 10). It also wants the revised taxonomy to be “more mature” and “actionable”. A cause axis is the missing piece, and it does not need to replace anything ENISA already does well: the sector analysis, the actor reporting, the source grading on the Admiralty scale, and the estimative language. It adds one field, with rules for filling it.

1. One cause field per incident, from a closed list of ten. Record the cluster of every evidenced step, or ? where a step is known to have happened but its cause is not. “Unknown” then becomes a measured share rather than an empty field, and the shares can be compared from year to year and with other reports.
2. Actor and motive as separate axes. Keep ENISA’s objectives and actor types, and cross-tabulate them against the cluster. That turns the outlook’s claim that the same weaknesses are exploited “regardless of the groups’ motivation” into a number that can be checked.
3. Consequences recorded as consequences. Record data risk events (C, I, A) and business events such as extortion or fraud loss separately from causes. The overlap ENISA expects between ransomware, data breaches and fraud disappears, because they are no longer competing categories.
4. Attack statistics only for attacks. R-SCOPE’s three questions move accidents, failures and the misuse of a genuinely held entitlement out of the threat counts and into operational risk, where their controls are.
5. Bridges that already exist. ETL already maps TTPs to MITRE ATT&CK and ranks weaknesses by CWE. TLCTC publishes mappings for both: all 706 ATT&CK Enterprise v20 techniques, and an experimental mapping of 985 CWE weaknesses.[5] Applied to data ENISA already collects, they yield a first cluster distribution without any new collection. TLCTC is published under CC BY 4.0, the same licence ENISA uses for its methodology.[2]
6. A field NIS2 reporting can carry. Member States report the root cause as unknown for around half of malicious actions. A ten-value cause field is a small addition at notification time, and a large gain in comparability across the Union.

ENISA has already written the conclusion

ETL 2026 is careful work. It grades its sources, states its limits and separates reported fact from assessment. The problem sits one level below the analysis, in the classification. The report defines no threat, the taxonomy behind it is under revision, and in its dataset the motive is recorded for more than nine incidents in ten while the exploited weakness is recorded for about one in fifty.

ENISA’s outlook already states what follows from its own data. Different threat groups use similar pathways, so organisations should address common weaknesses. A threat landscape built on that conclusion would classify each incident by the weakness it exploited first, and analyse actors and motives against that cause.

The taxonomy revision is the place to make that change. TLCTC offers ten generic vulnerabilities, a rule for each boundary case, and mappings to the frameworks ENISA already uses.