What is Cybersecurity Early Warning?
Every warning system ever built has faced the same quiet enemy, and it isn't blindness. It's being ignored.
This page sets out what the term means, where it came from, and what separates a warning system that gets acted upon from one that teaches its own recipients to look away.
A definition, and where it came from
At its simplest, cybersecurity Early Warning is the practice of spotting a problem — an exposed service, a vulnerable system, a compromised host, a leaked credential — and getting that knowledge to the organisation responsible for it before it turns into an incident.
Everything else on this page builds on that one sentence. It is proactive by design: the point is to act on a confirmed exposure while it is still only an exposure, not to offer post-breach support after someone notices that horses have left the barn.
The word has a lineage worth knowing, because it tells you what problem the field was trying to escape. "Early Warning" took hold in national CSIRT and NCSC programmes at the moment those teams stopped waiting by the phone. For years the model was reactive: something goes wrong, someone reports it, the CSIRT responds, for good reason: the "RT" for Response Team is literally in the name.
But a national CSIRT that only answers the reports it receives is reading a single page torn out of a very long book. The teams that moved to Early Warning inverted the posture: they began telling their constituents what they could already see, continuously, outbound, before anyone thought to ask. The phone and email stopped being the only way in.
That inversion is what separates Early Warning from three neighbours it's often confused with:
- Incident response works on confirmed incidents, after detection. Early Warning works on exposure, before an incident is confirmed at all.
- Threat intelligence feeds push raw indicators to whoever subscribes. Early Warning takes on the harder, less glamorous job underneath: matching that data to a specific owner and delivering it as something a human can actually act on.
- Vulnerability disclosure handles a newly discovered flaw, reported by whoever found it to the party who can fix the software. Early Warning deals with problems that are already known, where the hard part is finding and reaching the people still running affected systems. The research literature draws the same boundary, and calls that second activity vulnerability notification.
Same two words, opposite directions
The term now carries real institutional weight. Here it pays to be precise, because the EU's NIS2 legislation uses "early warning" twice, for two different things pointing in opposite directions, the kind of collision that trips up anyone who cites only one half.
Article 23(4)(a)
An obligated entity's first mandatory report to its own CSIRT, within 24 hours of becoming aware of a significant incident. An organisation confessing about a problem that has already happened.
Article 11(3)(b)
CSIRTs must proactively provide "early warnings, alerts, announcements and dissemination of information… to essential and important entities concerned… on cyber threats, vulnerabilities and incidents, if possible in near real time." This is the proactive direction this page is about.
Beyond the wording, NIS2 goes further. Article 11(3) also authorises CSIRTs to run proactive scanning of entities' publicly accessible systems, specifically "to detect vulnerable or insecurely configured network and information systems and inform the entities concerned": discovery, then notification, ahead of an incident, whatever label you hang on it. That clause is the operational core of early warning as this page defines it, stated in law without ever needing the contested phrase.
A second anchor: the Cyber Solidarity Act
NIS2 is no longer the only EU instrument that names this capability, and the newer one describes it as infrastructure rather than a task. The Cyber Solidarity Act (Regulation (EU) 2025/38, in force since February 2025) establishes a European Cybersecurity Alert System, built from National Cyber Hubs and Cross-Border Cyber Hubs joining on a voluntary basis, to "enhance detection, analysis and data processing capabilities in relation to cyber threats and the prevention of incidents in the Union."
A National Cyber Hub is a "single entity acting under the authority of a Member State" able to "act as a reference point and gateway to other public and private organisations at national level": a description of the layer this page calls national, written into EU law and funded through the Digital Europe Programme.
Two approaches, opposite ends of the network
None of this is theoretical: many national programmes already run public services under this name, or a direct translation of it. It is worth separating the two approaches early, because they attack the same problem from opposite ends of the network.
Exposure-based warning watches an organisation from the outside (internet scan data, threat feeds, compromise indicators) and notifies it of exposed, vulnerable, or compromised assets. This is the approach this page is about.
Sensor-based warning places detection sensors inside networks, typically of critical-infrastructure operators, and warns on what those sensors see.
Both are legitimately early warning, and the same national teams often run both. They are complementary, not competing.
scans · feeds · indicators
scans · feeds · indicators
Arctic Security has worked in this space since before "early warning" was the phrase for it: its roots are in data-sharing work with national CSIRT teams like NCSC-FI that predates the current terminology by well over a decade, and it has shipped products under the "early warning service" name for several years. We use the term because the field itself converged on it, reinforced by national programmes across several countries and written directly into EU law, not because any one organisation owns it. Nobody does.
The failure this exists to prevent
The failure Early Warning exists to prevent is almost embarrassingly simple to state: an incident that happens even though the information to stop it already existed.
Incidents happen far more often than they should, and most of the time it is not because the detection failed. The signal landed in the wrong inbox, or arrived in a format nobody could parse at 4pm on a Friday, or got buried under so much low-value chatter that no human was ever going to dig it out.
“"The signal was there. It was correct. It just never reached the person who could have acted on it."
The smoke alarm test
A smoke alarm's entire worth rests on firing at exactly the right threshold: not for burnt toast, not for a fire two doors down, but for a real threat in this room that needs you to move now. An alarm that shrieks at every wisp loses its authority the way the boy who cried wolf lost his: people learn the sound means nothing, remove the batteries, and are caught unawares when the real fire comes.
Alert fatigue
Teams facing floods of alerts retrain their own attention to treat the stream as weather. The result isn't a slower response: it's the absence of one. The alerts still arrive. Nobody is home.
At national scale this gets structurally harder: a CSIRT co-ordinates delivery across an entire constituency, each organisation with its own internal relay to run before the warning reaches the person who owns the asset. Getting a warning cleanly to the right organisation, at a volume that organisation can genuinely absorb, is a demanding task, and why that distinction matters so much is the subject of the next section.
There is also a structural reason the intermediary layer exists at all. The Shadowserver Foundation, whose free daily reports are the backbone data source for much of this field, publishes the share of IPv4 address space whose announcing network subscribes directly to those reports: by its own figures, 46% in 2023 and 49% in 2024. For the remainder, just over half, nobody at the network announcing it has asked for the data. Whether anything reaches the organisation running an affected system depends on someone else passing it on, and in most countries that someone is the national CSIRT. The intermediary is not an inefficiency in the chain. For most of the internet, it is the only link there is.
More than one thing has to go right at once
The requirements sort into four areas: miss any one and the whole thing drifts back toward noise.
Relevance & precision
Fire only past a threshold worth acting upon. Keep false positives as low as possible: they are exactly how a system teaches its recipients to stop reading it. Match warnings to the assets the recipient actually owns.
Actionability
Arrive in time to act, carry enough context to move on, not merely be alarmed by, and arrive at a volume the recipient can genuinely absorb.
Delivery
The warning passes through several sets of hands. Each layer's job is to carry it as far as it legitimately can: a complete, valuable contribution in its own right.
Trust
Built slowly through the service itself: consistently accurate, relevant warnings worth acting upon. Every false positive spends trust; every high-value warning earns it back.
of its own;
hands the data off
and rarely past a subsidiary boundary
EU law recognises the delivery half explicitly, and separately from the duty to know things: NIS2 Article 10(3) requires each CSIRT to maintain "an appropriate, secure, and resilient communication and information infrastructure through which to exchange information with essential and important entities and other relevant stakeholders." The obligation is not only to see the problem: it is to have a working means of telling the people it concerns.
This layered shape is not only our reasoning. Independent, peer-reviewed research on EU cybersecurity information sharing reaches it from the outside: Rajamäki and Katos (2020) propose a layered "trust realm" architecture in which "transitive trust should not be guaranteed or offered," while Simola (2019) documents unclear allocation of responsibility between national authorities as a recurring, real-world obstacle. Both are summarised in Further Resources below.
Whatever the scale, these four areas hold: inside a single security team, inside a large multi-entity organisation, and across a national constituency. What changes is the number of hands the warning passes through and the mechanism at each step. The requirements themselves do not change.
Four building blocks
They are unglamorous on purpose; the glamour is what gets systems into trouble.
Connect data sources that matter
A continuous diet of threat and exposure data (internet scan results, vulnerability intelligence, compromise indicators, leaked-credential data) from feed providers such as Shadowserver and others. The raw feed is not the value; the value is entirely what you build on top of it.
Know what you’re protecting
Before a finding can be routed anywhere, it has to be matched to an asset, and that asset to an owner. Continuous asset discovery (domains, subdomains, IP ranges, cloud footprint) makes that match possible. Without it, even excellent data piles up at the door.
Model who’s responsible for what
A national constituency has thousands of independent entities, each with internal structure it never exposes upstream. The system needs a real model of ownership at its own layer, not a flat mailing list, or delivery collapses back into the shared-inbox problem. Each layer models down to the boundary it can actually see.
Deliver in a form people will use
Notification design, API access, reporting cadence, the ability to mute known noise: these unglamorous choices decide whether a technically flawless warning gets acted on or archived unread. This is where the relevance work shows up, day to day, in the life of a tired analyst.
Because delivery is a relay, the right tooling depends on which leg you're running: a national programme needs tooling for delivering cleanly to a large, heterogeneous crowd of organisations; an individual organisation needs tooling for the last-mile problem of reaching the one person responsible.
A genuine fork in the road
There is no single correct turn. Neither path is free: they simply spend the effort in different currencies, at different times.
Open-source or in-house
Frameworks such as IntelMQ, or software written and maintained at the CSIRT itself. A legitimate, proven path, not a poor cousin. Transparent all the way down, nothing to licence, and the backbone of production national-scale Early Warning for over a decade.
The trade-off: a standing commitment to maintenance and internal development: pipeline configs, harmonization mappings, upgrades, and documentation good enough that the system outlives the people who built it. Teams that budget this honestly run it well for a very long time.
Purpose-built platform
Running on a platform built for the job (Arctic Hub for the national/sectoral layer, EWS Flex and EWS Classic as managed services for the organisational layer) quietly absorbs the pipeline, harmonization, and upgrade work the other path asks the team to own.
The trade-off: a subscription line instead of a standing maintenance burden. All of these are ways of implementing the practice this page describes. They are not the only ways, and not, on their own, the whole chain.
The maintenance item is the one teams most often underestimate. It is a well-worn pattern across open-source security tooling: what is fully capable on day one can turn fragile a few years and a couple of staff departures later, roughly in proportion to how much documentation and maintenance discipline the team kept up along the way. Teams that walk this path with the trade-off in full view, and budget the ongoing effort honestly, tend to run it well for a very long time. Teams that treat it as a one-off build tend, eventually, to find out otherwise.
There is a fitting symmetry: IntelMQ re-implemented the architecture of AbuseHelper, which came from the same team that now builds Arctic Hub. The family tree is smaller than it looks.
Each category answers a different question
You can run a real programme on a single strong source: the Shadowserver feeds alone cover many of the categories below. Most programmes then layer in several open-source feed providers, each adding coverage to one or more of the categories listed here, and eventually add a few commercial sources on top where the free data leaves gaps.
Internet-facing exposure & scan data
Non-profit scanners like Shadowserver continuously scan the public internet and share the results with national CSIRTs at no cost: exposed or misconfigured services, vulnerable software versions, compromised hosts, honeypot observations. Usually the backbone.
Malicious infrastructure & reputation
Spam sources, scanning infrastructure, brute-force origins: often the first external sign of a compromise the organisation hasn’t noticed.
Phishing & malware indicators
Live phishing URLs, malicious domains, C2 infrastructure: sometimes someone impersonating you to your own customers.
Leaked credentials & breach data
Breach corpora matched against your domains surface a risk scanning simply cannot see.
DNS, passive DNS & certificates
Passive DNS and CT logs feed asset discovery directly: subdomains, forgotten infrastructure, shadow IT.
Peer & sector sharing
CERT-to-CERT channels, ISACs, and the informal heads-up between teams who trust each other. Some of the earliest warnings ever travelled this way.
Vulnerability prioritisation (a layer on top)
A raw CVE list is not actionable at scale: the overwhelming majority of CVEs are never exploited by anyone. Cross-referencing exposure against actively-exploited catalogues like CISA KEV turns "theoretically vulnerable" into "this is being exploited right now."
No team needs all of these on day one, and reaching for all of them at once is its own failure mode. Most programmes start with broad exposure data (the Shadowserver-style backbone), then layer in vulnerability prioritisation, then breach and credential data, then sector-specific sources as the programme matures and the team's capacity to actually act on more signal grows to meet it. Adding sources faster than the delivery and relevance work can absorb them doesn't build capability: it rebuilds, from scratch, the noise problem this page opened with.
What the evidence shows
Early Warning is easy to argue for in principle. Measuring how well it works is harder, and the published literature is thinner than the field tends to assume. It is worth setting out honestly, because it points directly at what a programme should spend its effort on.
Almost all the measurement that exists concerns notification: taking a problem that is already known, working out who owns the affected systems, telling them, and counting how many fix it. A 2026 review in ACM's Digital Threats: Research and Practice assembled fifteen large-scale disclosure and notification operations and set their outcomes side by side. Four findings matter for anyone building this capability.
Notification works, modestly
The study that established the methodology (Li et al., 2016) found its best-performing approach moved an additional 11% of contacts to act compared with a control group, that at most 18% of the affected population remediated, and that repeat notifications did not improve on the first. A warning that reaches an owner is a necessary condition for remediation, not a sufficient one, and a programme that measures itself on notifications sent rather than issues closed will flatter itself considerably.
Construction matters more than sender
Li et al. (2016) found direct notification beat routing the same data through CERTs. A 2026 randomised trial on 786 compromised German websites (Hennig et al.) varied the sender between a university, hosting providers, and the federal CERT: no significant difference between them, though every one beat the control. Overall remediation was 42%, and most owners who had not acted had received the warning and dismissed it as spam.
What does move the number is the notification itself: Maass et al. (2021) found a more-than-twofold spread (76.3% against 33.9%) between its best and worst constructed arms, both far ahead of a 9.2% control.
The receiving end has its own economics
Interviews with 24 shared-hosting organisations across 11 countries (Stivala et al., 2026) found most of them handle vulnerability notifications routinely, and remediation still stalls. The obstacles were not technical: strict responsibility boundaries, with web application problems treated as the customer's domain, and thin margins against a high daily volume of compromises. Anyone designing a warning for a recipient class should understand that recipient's incentives, not only its inbox.
What the evidence does not yet contain
A deliberate search of the 2023–2026 literature found no peer-reviewed evaluation of a standing national CSIRT early warning programme operating as a service. The field has measured experiments, not programmes. Nobody can currently show that a national service reduces national exposure, and nobody can show that it does not. A programme that instrumented its own delivery and remediation outcomes, and published the result, would be producing evidence that does not presently exist anywhere.
Read together, these results speak directly to the delivery chain in section 05. Institutional standing does not, by itself, make a warning land: what separated every notified group from the control group was that a usable warning arrived at all. What determines whether it does is accurate matching to the right organisation, enough context to act on, a volume the recipient can absorb, a channel they actually read. That is the operational substance of sections 05 and 06, not presentation layered on top of them.
For teams who want to go deeper
Data Harmonization Ontology
Arctic Security's public reference for standardising the vocabulary used across disparate threat-data feeds, maintained since the early days of national CSIRT data-sharing work.
Shadowserver Foundation
Non-profit provider of internet scan and compromise data used broadly across the national CSIRT community.
FIRST
The Forum of Incident Response and Security Teams: the primary international community for CSIRT and incident response practitioners.
Rajamäki & Katos (2020)
"Information Sharing Models for Early Warning Systems of Cybersecurity Intelligence". Peer-reviewed review drawing on 50+ sources and eight ECHO-project case studies; proposes the layered "trust realm" architecture that parallels this page's delivery-chain argument.
Simola (2019)
"Comparative Research of Cybersecurity Information Sharing Models". Found unclear allocation of responsibility between national authorities to be a recurring obstacle to effective EU cybersecurity cooperation.
Simola & Lehto (2020)
"National Cyber Threat Prevention Mechanism as a part of the E-EWS". Case study on Finland's HAVARO system, its strengths and limitations as a national Early Warning mechanism, and what it implies for EU-level integration.
Chen & van der Ham-de Vos (2026)
"Vulnerability Disclosure or Notification? Best Practices for Reaching Stakeholders at Scale". ACM DTRAP review of fifteen large-scale disclosure and notification operations; the source of the remediation figures in the Evidence section.
Li et al. (2016)
"You've Got Vulnerability: Exploring Effective Vulnerability Notifications". USENIX Security. Established the notification-campaign methodology, including the direct-versus-CERT delivery comparison.
Maass et al. (2021)
"Effective Notification Campaigns on the Web: A Matter of Trust, Framing, and Support". USENIX Security. The 76.3% vs 33.9% best-arm/worst-arm spread on notification construction.
Hennig et al. (2026)
"Towards enhancing strategies for creating effective vulnerability notifications". Computers & Security. Randomised trial on 786 compromised websites; sender identity made no statistically significant difference.
Stivala et al. (2026)
"Behind the Curtain: How Shared Hosting Providers Respond to Vulnerability Notifications". IEEE S&P. Interviews with 24 hosting organisations across 11 countries on the receiving end's economics.
This page is a reference, not a pitch
But if you're building or evaluating an Early Warning capability, here's where Arctic Security's own work fits on the map you've just read.
Arctic Hub
The platform for running Early Warning at national scale.
EWS Flex
Continuous monitoring implementing Early Warning for large, multi-entity organisations.
EWS Classic
Continuous monitoring implementing Early Warning for a single organisation.
CSIRT Development Programme
Free first year and sliding-scale access, making commercial tooling available for everyone.
Thinking through where your programme sits on this path?
Talk to our team about which link in the chain is worth strengthening next.