5 Cyberattacks That Shaped NIS2: The EUR 10B+ Disasters Behind Europe’s Cybersecurity Law

The NIS2 Directive did not emerge from a policy vacuum. Each of its 10 mandatory security measures under Article 21 traces back to a documented failure — a real attack that exposed a real gap in how European organisations managed cyber risk. Understanding which incident drove which provision is not merely historical curiosity. It tells you why the requirement is framed the way it is, what auditors are looking for when they review your controls, and where the regulation has the most enforcement teeth.

This guide covers the five attacks that most directly shaped NIS2’s architecture: WannaCry (2017), NotPetya (2017), SolarWinds (2020), Colonial Pipeline (2021), and the Viasat KA-SAT hack (2022). For each, we trace the specific attack vector, the governance failure it exposed, and the NIS2 article it produced. For an overview of what NIS2 requires across all 10 measures, see our complete NIS2 Directive guide.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

WannaCry (2017): When Unpatched Systems Became a Liability

At 07:44 UTC on 12 May 2017, ransomware began spreading across 150 countries. Within hours, 300,000 computers were encrypted. WannaCry used EternalBlue, an NSA exploit leaked two months earlier by the Shadow Brokers group, to propagate automatically across unpatched Windows systems — no user click required [1].

The UK National Health Service bore the most visible damage. Up to 70,000 NHS devices were affected, including MRI scanners, blood-storage refrigerators, and theatre equipment. Roughly 20,000 patient appointments were cancelled. Emergency services were diverted as hospitals could not access patient records. The total cost to the NHS reached £92 million [1]. Renault halted production at multiple plants. Nissan’s UK manufacturing also stopped.

The attack’s defining characteristic was not sophistication — the kill switch was activated within hours — but scale of exposure. A critical patch (MS17-010) had been available for two months before the attack. Organisations across Europe had simply not applied it. The failure was not technical; it was procedural.

The NIS2 response: WannaCry made patch management a legal obligation. Article 21(2)(e) of NIS2 requires entities to implement security measures covering “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” [7]. This is not a soft recommendation. It mandates documented vulnerability management procedures — an explicit response to the patch-lag failure WannaCry exposed.

Article 21(2)(g) adds the mandatory foundation: “basic cyber hygiene practices and cybersecurity training” must be in place for all staff. WannaCry spread partly because employees in affected organisations did not recognise the threat vector or understand patching urgency. Under NIS2, that training gap is an enforcement finding, not an oversight [7].

Article 21(2)(a), requiring documented “policies on risk analysis and information system security,” closes a further gap: no policy, no accountability. Organisations that had no formal asset inventory — common in 2017, still common now — could not know which systems required patching. NIS2 mandates the baseline that makes Article 21(2)(e) operationally possible.

NotPetya (2017): The EUR 10B+ Attack That Proved Cross-Border Coordination Was Missing

Six weeks after WannaCry, a second attack began in Ukraine and within hours had spread across the global shipping, logistics, and pharmaceutical sectors. NotPetya used the same EternalBlue exploit but added a credential-harvesting module and targeted the MeDoc accounting software used by thousands of Ukrainian businesses — making it a supply chain attack before the term was widely understood [2].

The economic damage was without precedent. Maersk, the Danish shipping group, lost an estimated USD 200–300 million: 45,000 PCs and 4,000 servers were destroyed, 76 port terminals across the world went dark for ten days [2]. Merck reached a USD 1.4 billion insurance settlement. FedEx’s TNT Express division lost approximately USD 300 million, with some systems permanently unrecoverable. Saint-Gobain reported losses of around USD 384 million. Total global damage exceeded USD 10 billion [2].

The attack prompted a debate at NATO level about whether a cyberattack with consequences comparable to an armed attack could trigger Article 5 collective defence — a debate that had no clean answer, because no cross-border coordination framework existed to manage the response [4]. The EU separately began drafting a framework for a joint diplomatic response to malicious cyber activities, acknowledging that the existing architecture was inadequate [4].

NotPetya also demonstrated something NIS1 had not accounted for: when a critical-sector entity like Maersk — operating 76 ports globally — goes dark, the disruption cascades across every supply chain that runs through those ports. There was no early-warning mechanism, no mandatory information sharing between member states, no common crisis management protocol.

The NIS2 response: Article 16 of NIS2 establishes the European Cyber Crisis Liaison Organisation Network (EU-CyCLONe), a formal mechanism for cross-border coordination during large-scale cyber incidents. This was a direct institutional response to the chaos of 2017’s twin attacks. NotPetya’s damage to Maersk — an operator of essential services in multiple jurisdictions simultaneously — is precisely the scenario EU-CyCLONe exists to coordinate.

Article 21(2)(c) mandates “business continuity, such as backup management and disaster recovery, and crisis management.” Maersk’s ten-day recovery was prolonged because its backup architecture was inadequately tested and its crisis management plan had not anticipated a scenario where all primary systems were simultaneously destroyed. NIS2 makes tested recovery capability a baseline requirement, not a recommendation. Article 21(2)(d) addresses the MeDoc supply chain vector — more on that in the SolarWinds section below. For a detailed breakdown of how NIS1 and NIS2 differ on these coordination obligations, see our NIS1 vs NIS2 comparison.

SolarWinds (2020): How 18,000 Organisations Were Compromised Through a Trusted Update

The SolarWinds attack was disclosed in December 2020 — the same month the European Commission proposed the NIS2 Directive. The timing was not coincidental. SolarWinds demonstrated exactly what the Commission had been warning about: a single compromised service provider could cascade into thousands of end-customer organisations without any of them making a single security mistake of their own.

The attackers, later attributed to Russian intelligence, began laying groundwork in August 2019. By March 2020, they had injected the SUNBURST backdoor into legitimate Orion software updates [11]. Between April and November 2020, approximately 18,000 organisations — including government agencies and major enterprises — installed the malicious update as a routine software upgrade. The attack vector was not a phishing email, not a brute-force password attack. It was a trusted software update from a vendor organisations had explicitly approved [11].

The governance failure was architectural. No regulatory framework required organisations to assess the cybersecurity practices of the vendors supplying their software. No obligation existed to monitor software supply chains for integrity. Managed service providers — who, like SolarWinds Orion, sit at the intersection of hundreds of customer networks simultaneously — had no sector-specific security obligations under NIS1. A single breach of one MSP was equivalent to breaching every customer simultaneously.

Between 2020 and 2021, supply chain attacks increased fourfold [5]. The SolarWinds case was the most visible, but not unique.

The NIS2 response: Article 21(2)(d) now requires that “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” be addressed as a mandatory measure [7]. Under Article 21(3), entities must specifically account for “vulnerabilities specific to each direct supplier” and evaluate “the overall quality of products and cybersecurity practices of their suppliers” [7].

Recitals 83–85 expand the obligation: entities must “assess and take into account the overall quality and resilience of products and services, the cybersecurity risk-management measures embedded in them, and the cybersecurity practices of their suppliers” [8]. Recital 84 explicitly brings managed service providers and managed security service providers under a “high degree of harmonisation at Union level” — the direct legislative response to the MSP attack-surface problem SolarWinds made undeniable [8].

In practice, NIS2 Article 21(2)(d) compliance requires a documented supplier security policy, risk assessments per ICT supplier, contractual security clauses, and an ongoing supplier register [10]. For organisations working through this requirement, our NIS2 supply chain security guide covers the full implementation framework.

Colonial Pipeline (2021): The Attack That Set the 24-Hour Clock

On 7 May 2021, DarkSide ransomware encrypted Colonial Pipeline’s systems. Colonial operated the largest refined oil pipeline in the United States, delivering over 100 million gallons of fuel daily along the US East Coast. The company took its pipeline offline as a precaution, triggering a five-day fuel shortage that prompted the US federal government to declare a state of emergency across 17 states.

The attack vector was a single compromised VPN credential — and the account had no multi-factor authentication [source: Huntress/CISA public reporting]. DarkSide obtained the password (later found in a leaked credential database) and accessed Colonial’s network through a remote access system that was not protected beyond a username and password.

Colonial paid USD 4.4 million in ransom. US authorities later recovered 64 of the 75 bitcoins. The recovered amount — approximately USD 2.4 million — represented the only portion of the ransom the company saw again.

Beyond the ransom, Colonial Pipeline exposed two regulatory gaps that the EU had been watching. First, there was no mandatory incident reporting timeline. Colonial did not notify federal regulators for roughly 24 hours after discovering the attack, and the public did not learn of the incident until the pipeline had already been shut down. Second, critical infrastructure operators had no legal obligation to implement basic access security controls like MFA — the single technical measure that would have blocked the attack entirely.

The NIS2 response: Article 23 of NIS2 establishes a tiered mandatory reporting structure: a significant incident must trigger an initial warning to the competent authority within 24 hours, indicating whether unlawful or malicious acts are suspected and whether cross-border implications exist. A full incident notification follows within 72 hours with a preliminary impact assessment. A comprehensive final report is due within one month [5][6]. For a detailed breakdown of these timelines and what counts as a “significant incident,” see our NIS2 incident reporting guide.

Article 21(2)(j) requires “the use of multi-factor authentication or continuous authentication solutions” where appropriate [7]. In any system accessible via remote access — as Colonial’s OT-adjacent systems were — MFA is now a baseline expectation, not an optional enhancement. The attack also reinforced Article 21(2)(i)’s requirements around “access control policies and asset management”: organisations must know which accounts exist, which have remote access, and which credentials may have been exposed.

Supply chain attacks increased fourfold and cloud infrastructure attacks fivefold between 2020 and 2021, with Germany experiencing a 360% rise in ransomware attacks in 2021 alone [5]. Colonial Pipeline became the reference case that made incident reporting mandatory.

Viasat KA-SAT (February 2022): The Attack That Added Space to NIS2

On 24 February 2022 — the same morning Russia launched its ground invasion of Ukraine — the KA-SAT satellite network operated by Viasat went dark across Europe. Attackers had compromised a VPN installation at Viasat’s management facility in Turin on February 23, then used that access to distribute AcidRain, a wiper malware designed to permanently destroy modem firmware, via the satellite’s software update mechanism [3].

Within hours, 5,800 Enercon wind turbines in Germany lost remote monitoring and control capability [3]. The turbines themselves continued generating power — the immediate energy output was not lost — but operators could not monitor performance, adjust output, or respond to fault conditions remotely. ENISA later characterised the disruption as demonstrating how satellite infrastructure vulnerabilities “transcend sectoral and geographical boundaries,” affecting communications, emergency services, and energy management simultaneously across multiple countries [9].

Disruptions extended to Germany, Scandinavia, and the United Kingdom. On 10 May 2022, the European Union, United States, and United Kingdom formally attributed the attack to Russia [3].

The governance gap Viasat exposed was categorical: satellite infrastructure was not classified as critical infrastructure under NIS1. The operator of a communications satellite network that could disable wind farm management systems across an entire member state had no mandatory cybersecurity obligations under EU law. The attack demonstrated that the original NIS1 sector list — drafted in 2016 — reflected a threat landscape that no longer existed.

The NIS2 response: Space is listed explicitly as a sector of high criticality in Annex I of NIS2. Satellite operators are now essential entities subject to the full Article 21 obligation set. ENISA’s guidance specifically references supply chain security, information sharing, encryption, and component testing throughout the equipment lifecycle [9].

Article 21(2)(c)’s business continuity requirement directly addresses the Viasat scenario: remote management loss is a disruption of normal operations even when underlying infrastructure continues functioning. Under NIS2, operators must document recovery procedures for the loss of management and monitoring capability — not only for total system failure. The attack was a reminder that resilience planning must account for partial loss of control, not just catastrophic failure.

From Incident to Provision: The Legislative Paper Trail

The table below maps each attack’s specific failure vector to the NIS2 provision it produced. This is the lens through which regulators and auditors will review your programme — not as a general cybersecurity standard, but as a response to documented failures.

Incident	Attack Vector	Governance Gap	NIS2 Provision
WannaCry (May 2017)	Unpatched Windows systems (EternalBlue)	No mandatory patch management; no cyber hygiene baseline	Art. 21(2)(e) vulnerability management; Art. 21(2)(g) cyber hygiene
NotPetya (June 2017)	Supply chain entry via MeDoc; self-propagating wiper	No cross-border crisis coordination; no tested recovery at scale	Art. 16 EU-CyCLONe coordination; Art. 21(2)(c) business continuity
SolarWinds (Dec 2020)	Compromised software update from trusted vendor	No MSP security obligations; no supply chain due diligence requirement	Art. 21(2)(d) supply chain; Art. 21(3); Recitals 83–85 MSP scope
Colonial Pipeline (May 2021)	Stolen VPN credential; no MFA	No mandatory reporting timeline; no MFA legal requirement	Art. 23 (24h/72h reporting); Art. 21(2)(j) MFA
Viasat KA-SAT (Feb 2022)	Satellite management network compromise; AcidRain wiper	Space sector outside NIS1 scope; no satellite operator obligations	Annex I space sector; Art. 21(2)(c) continuity for management loss

What This Means for Your Compliance Programme

The five incidents above produced specific, auditable requirements. The practical implication differs by role:

If you are a CISO or IT security manager: Regulators reviewing your Article 21 programme will look for evidence that your controls address the actual attack vectors these incidents demonstrated. Patch management procedures, supplier security assessments, MFA on all remote access points, and tested business continuity plans are not checkbox items — they are the minimum evidence baseline for each provision.

If you are a compliance officer or legal counsel: Article 23’s incident reporting obligation activates the moment a significant incident is suspected, not confirmed. The 24-hour initial notification window is not contingent on completing a root cause analysis. Your incident handling procedure must be in place before the event, not drafted during it.

If you are an SME owner or non-technical executive: The plain-language version of NIS2 is this: the five attacks above showed that organisations without basic controls — patching, MFA, supplier vetting, recovery planning — caused disproportionate damage to the wider economy. NIS2 makes those controls mandatory and assigns liability to management when they are absent. Article 20 holds management boards personally accountable for cybersecurity risk oversight.

Frequently Asked Questions

Did the NIS2 Directive explicitly reference these attacks in its text?
The Directive’s 144 recitals do not name individual incidents. They reference categories of threat — supply chain attacks, state-sponsored actors, cascading cross-sector disruptions — that map directly to these events. The legislative record and Commission impact assessments make the connection explicit.

If my organisation was not affected by any of these attacks, does NIS2 still apply?
Scope under NIS2 is determined by sector (Annex I/II) and size thresholds, not by incident history. If you operate in an essential sector with 50+ employees or €10M+ annual turnover, you are likely in scope. The incidents above explain why the requirements exist — they do not define who must comply.

How is the NIS2 incident reporting obligation different from GDPR breach notification?
GDPR breach notification applies when personal data is compromised. NIS2 Article 23 applies when operations are significantly disrupted, regardless of whether personal data is involved. Colonial Pipeline’s attack triggered no GDPR notification obligation; under NIS2, the 24-hour clock would have started immediately. The two regimes operate in parallel and can trigger simultaneously.

Why did SolarWinds matter so much given it was a US attack?
The SUNBURST campaign compromised European government agencies and enterprises alongside US targets. More importantly, it demonstrated a structural vulnerability — MSPs as a force-multiplier for attackers — that existed identically in Europe. NIS2’s timing (proposed December 2020, same month as SolarWinds disclosure) reflects how directly the attack influenced the Commission’s drafting priorities.

Sources

[1] WannaCry ransomware attack — Wikipedia

[2] How Did NotPetya Cost Businesses Over $10 Billion In Damages? — CyberRanges

[3] Viasat hack — Wikipedia

[4] NotPetya and WannaCry Call for a Joint Response — NATO CCDCOE

[5] Defining the reporting threshold for a cybersecurity incident under NIS2 — Journal of Cybersecurity, Oxford Academic

[6] NIS2 Articles 21 and 23: Overview — Eye Security

[7] NIS2 Article 21 — nis-2-directive.com

[8] NIS2 Preamble, Recitals 81–90 — nis-2-directive.com

[9] From Cyber to Outer Space: Securing Commercial Satellite Operations — ENISA

[10] NIS2 Supply Chain Security Explained — DLA Piper

[11] SolarWinds Supply Chain Attack Timeline — Palo Alto Unit42