Introduction
Europe now has a much clearer architecture for coordinated vulnerability disclosure than it did five years ago.
NIS2 requires Member States to build national vulnerability-management policies and designate a CSIRT coordinator that can act as a trusted intermediary between the person reporting a vulnerability and the manufacturer or service provider that needs to fix it.12
That is a major institutional improvement.
It is not the same thing as a European safe harbour for security research.
This distinction matters because vulnerability disclosure has two different legal moments.
The first happens before the report exists:
What was the researcher legally allowed to do in order to find and validate the vulnerability?
The second happens after discovery:
How should the vulnerability be reported, coordinated, remediated and eventually disclosed?
NIS2 is much more harmonised on the second question than on the first.
Its most important practical achievement for researchers is therefore not a Europe-wide licence to test.
It is a Europe-wide expectation that Member States create a functioning route through which vulnerabilities can be responsibly coordinated.
What Article 12 actually does
Article 12 of NIS2 is operational.
Each Member State must designate one of its CSIRTs as the coordinator for coordinated vulnerability disclosure.1
The coordinator acts, where necessary, as a trusted intermediary between:
- the natural or legal person reporting the vulnerability; and
- the manufacturer or provider of the potentially vulnerable ICT product or ICT service.
The coordinator's tasks include:
- identifying and contacting affected parties;
- assisting persons that report vulnerabilities;
- negotiating disclosure timelines;
- handling vulnerabilities that affect multiple entities.
Member States must also ensure that vulnerabilities can be reported anonymously where the reporter requests it, and cross-border cases can be coordinated through the CSIRTs network.1
Those are substantive obligations.
They create a stronger European disclosure infrastructure.
Article 12 does not, however, state that:
- independent vulnerability testing is automatically authorised;
- good faith removes criminal liability;
- reporting through a CSIRT retroactively validates the preceding access;
- researchers receive a general exemption from civil liability.
For those questions, the most revealing part of NIS2 is not Article 12.
It is Recital 60.
Recital 60 recognises the liability problem explicitly
Recital 60 says that Member States should, as part of their national CVD policy, address the challenges faced by vulnerability researchers, including potential exposure to criminal liability under national law.3
It goes further.
Because vulnerability researchers may face both criminal and civil liability in some Member States, the recital encourages national guidelines on:
- non-prosecution of information-security researchers; and
- exemption from civil liability for their activities.3
That is unusually direct language for an EU cybersecurity instrument.
It tells us that the legislature understood a structural problem:
A disclosure framework is weaker if researchers know where to send a report but cannot predict the legal consequences of the testing that produced it.
At the same time, the wording matters.
Recital 60 encourages Member States to address the problem.
It does not itself create an individual right to immunity.
A recital provides context for interpretation; it is not the same legal instrument as an operative provision granting permission to perform specified acts.
So the correct reading is neither:
NIS2 did nothing for researchers.
nor:
NIS2 made good-faith hacking legal across Europe.
The reality sits between those claims.
The architecture can be summarised in four layers
This last row explains why two European researchers performing technically identical tests can still face different legal environments.
| Layer | What NIS2 does |
|---|---|
| National policy | requires vulnerability-management policy, including promotion/facilitation of CVD |
| Reporting | requires a designated CSIRT coordinator and anonymous reporting capability |
| Coordination | gives the coordinator a trusted-intermediary and multi-party role |
| Researcher liability | recognises the problem and encourages national protection, but largely leaves the legal solution to Member States |
The older Cybercrime Directive shows where authorisation can come from
Directive 2013/40/EU on attacks against information systems remains important background law.
Its definition of conduct undertaken “without right” covers access, interference or interception that is not authorised by the system owner or another right holder or is not permitted under national law.4
That final phrase matters.
It leaves room for more than owner consent.
A Member State can, in principle, define through national law that certain narrowly specified good-faith research is legally permitted.
That can change the legal analysis of whether the researcher's act was “without right”.
This is one reason statutory safe-harbour models are qualitatively different from a website saying:
We promise not to sue responsible researchers.
An organisational promise can be very useful.
National legislation can address the underlying legal permission itself.
NIS2 encourages Member States to confront that problem but does not write the national authorisation rule for them.
Europe therefore has a coordination/authorisation asymmetry
Consider the following scenario.
A researcher finds the same access-control vulnerability in the same software deployed by two organisations in two Member States.
In both cases the researcher:
- makes one controlled request;
- confirms cross-account access;
- retains minimal evidence;
- immediately reports the issue;
- does not publish until remediation.
The NIS2 disclosure architecture is similar in both countries.
Each should have a national CVD coordinator.
But the researcher's legal position may still differ substantially if:
- Country A has explicit statutory authorisation for defined good-faith testing;
- Country B relies on prosecutorial guidelines;
- Country C relies mostly on the owner's VDP;
- Country D has no clear researcher-specific protection.
That is the core European gap:
The route for reporting a vulnerability is more harmonised than the legal route by which the researcher may obtain the evidence needed to report it.
ENISA identified the problem before NIS2 was adopted
ENISA's 2022 analysis of national CVD policies already documented substantial differences across Member States.5
Its recommendations included:
- reform of criminal-law approaches and the Cybercrime Directive environment to improve legal protection for security researchers;
- clearer criteria distinguishing ethical research from malicious activity;
- incentives for researchers to participate in CVD.
The policy problem therefore predates the final NIS2 text.
Recital 60 reflects a known weakness in the European vulnerability ecosystem rather than creating a new concern from scratch.
Latvia is a useful implementation case
Latvia shows both sides of the NIS2 model unusually clearly.
Its National Cybersecurity Law already contains a structured coordinated vulnerability-disclosure regime in Sections 39 and 40.6
A person who identifies a vulnerability in the information system or electronic-communications network of an entity within the statutory scope must report it to the competent cyber-incident prevention institution under the procedure set by the law.6
The law provides for:
- defined report content;
- verification by the competent institution;
- conditional identity confidentiality;
- controlled disclosure;
- remediation deadlines;
- follow-up;
- support in communication between reporter and affected entity;
- coordination for vulnerabilities affecting several entities;
- cross-border CSIRT cooperation.
That is a recognisable NIS2-style CVD system.
It is also a useful example of the remaining gap.
As of 25 September 2026, the consolidated Latvian statute does not contain a general “good-faith researcher” clause granting an express statutory right to search the systems of covered entities simply because the research purpose is benevolent.6
The law clearly governs what happens when a vulnerability has been found.
It is less complete as a general answer to what an independent researcher may do to find and prove it.
Confidentiality is valuable, but it is not immunity
Latvia's law provides a particularly useful illustration.
A reporter may in defined circumstances request that their identity not be disclosed. The competent institution must preserve confidentiality where statutory conditions are met and there are no prima facie signs of a criminal offence.6
That is meaningful protection.
It should not be translated into:
anonymous report = legally protected research.
Identity protection and substantive legal permission are different controls.
A researcher can have:
- a confidential identity;
- a valid reporting route;
- and still face a separate question about whether a preceding technical action was authorised.
This distinction applies beyond Latvia.
Latvia's 2026 proposal targets the missing earlier stage
On 30 July 2026, CERT.LV announced a public consultation on proposed amendments to the National Cybersecurity Law that would establish rights for security researchers to search for vulnerabilities in information systems belonging to entities covered by the law.7
The consultation closed on 28 August.
Conceptually, that proposal addresses a different stage of the lifecycle.
The existing law is strongest here:
The proposed research-authorisation direction asks:
As of 25 September 2026, that general research-authorisation language is not present in the consolidated law in force.6
It should therefore be discussed as a legislative proposal, not as an existing safe harbour.
vulnerability identified
→ report
→ coordinate
→ remediate before a report exists:
what may an independent researcher lawfully do
to identify and minimally validate the vulnerability? “Safe harbour” is not one thing
Security policy discussions often use safe harbour as if it described a single legal mechanism.
It does not.
At least four different mechanisms can sit behind the label.
1. Organisational safe harbour
A company publishes a vulnerability-disclosure or bug-bounty policy and promises not to pursue researchers who stay within the rules.
Useful, but limited to the organisation's own rights and discretion.
2. Statutory authorisation
National law declares specified research activity legally permitted when defined conditions are satisfied.
This can directly affect the “without right” analysis.
3. Non-prosecution guidance
A prosecutor or competent authority states the circumstances in which good-faith security research ordinarily should not lead to prosecution.
This can improve predictability but is not necessarily the same as substantive statutory permission.
4. Civil-liability protection
The law or policy addresses exposure to damages, contract claims or other civil remedies.
NIS2 Recital 60 is important precisely because it mentions both criminal and civil exposure.3
A mature policy should say which of these mechanisms it actually provides.
A five-layer test for researcher protection
A country should not be described as “CVD-friendly” solely because it has an online reporting form.
A more useful assessment separates five layers.
NIS2 materially strengthens the first layer.
It creates policy pressure around the fifth.
The exact content of layers two through five remains heavily dependent on national law and local programme design.
| Layer | Question |
|---|---|
| Reporting right | Is there a clear route to submit the vulnerability? |
| Research authorisation | Which acts may be performed to identify and validate it? |
| Method limits | Which methods remain prohibited or require explicit permission? |
| Data handling | What may be viewed, retained, transferred or published? |
| Liability protection | What happens to criminal, civil, contractual and related exposure? |
Good faith cannot mean intent alone
Any serious researcher-protection regime needs more than:
I meant well.
Security research can be benevolent in purpose and still be recklessly intrusive in execution.
Protection is therefore usually more defensible when linked to observable behaviour:
- necessity;
- proportionality;
- minimum sufficient proof;
- avoidance of unnecessary harm;
- data minimisation;
- timely reporting;
- respect for coordinated disclosure;
- stopping once the vulnerability is sufficiently demonstrated.
Latvia's CERT.LV made that distinction explicit in August 2026 when it reminded researchers that ethical testing does not include DoS/DDoS unless explicitly authorised and that vulnerability demonstration should use the minimum necessary volume of requests and actions.8
Good faith is therefore better understood as a combination of purpose and constrained conduct.
Cloud infrastructure turns authorisation into a chain-of-rights problem
A national safe harbour does not make ownership boundaries disappear.
Imagine an organisation authorises testing of its customer portal.
The portal depends on:
- a cloud identity provider;
- a CDN;
- a payment processor;
- managed databases;
- shared SaaS infrastructure.
The organisation may have authority to permit testing of its application or tenant.
It may not have authority to permit attacks against:
- the provider's control plane;
- another customer's tenant;
- shared underlying infrastructure;
- a third party's authentication system.
The NIS2 coordinator can be extremely useful when a vulnerability needs multi-party coordination.
But coordination does not erase the chain of legal rights.
Modern vulnerability research increasingly asks not just:
What is technically in scope?
but:
Who has legal authority over each technical layer?
Data protection remains a separate problem
Even an explicit national authorisation for certain testing would not automatically settle every data-protection question.
A vulnerability test may unexpectedly expose:
- user records;
- credentials;
- health information;
- financial data;
- logs;
- private communications.
The legal and professional questions then include:
- how much data is necessary to establish the issue;
- whether it should be retained;
- how it can be transmitted securely;
- when it must be deleted;
- what may be included in a public advisory.
Research authorisation and data-processing law therefore need to fit together rather than pretending one overrides the other.
NIS2, CRA and researcher protection are different regulatory lines
The European vulnerability ecosystem now includes several overlapping obligations.
NIS2 creates national CVD coordination and CSIRT responsibilities.1
The Cyber Resilience Act requires manufacturers of products with digital elements to establish and enforce coordinated vulnerability-disclosure policies and provide a contact point for vulnerability reports.9
National law still determines much of the researcher's substantive authorisation and liability.
This can create an odd result:
A manufacturer may have an EU-law obligation to maintain a vulnerability-reporting process, while the researcher still lacks a single EU-wide rule determining whether every technical step used to discover the vulnerability was legally authorised.
A reporting obligation on the vendor is not the same thing as a testing licence for the researcher.
Would a European safe harbour solve the problem?
Greater harmonisation has obvious benefits.
It could reduce:
- legal uncertainty for cross-border researchers;
- inconsistent treatment of identical technical acts;
- friction in multi-vendor disclosure;
- the need to interpret dozens of national models for one Europe-wide product.
But a serious European rule would still need to address difficult boundaries:
- critical infrastructure;
- national-security systems;
- personal data;
- trade secrets;
- third-party assets;
- destructive testing;
- social engineering;
- persistence;
- proportionality;
- abuse of the safe harbour itself.
NIS2 did not resolve those questions centrally.
Its current model is a political compromise:
European coordination, substantial national discretion on researcher protection.
That is both its strength and its limitation.
The practical question for a researcher is not “Is this covered by NIS2?”
Before independent testing, more useful questions are:
- Who controls the system or component?
- Is there a published VDP or bug-bounty policy?
- What exactly does that policy authorise?
- Does it cover third-party infrastructure?
- Does national law add statutory research permission?
- Which methods are expressly prohibited?
- What happens if personal data or secrets appear?
- What is the stopping rule?
- Is there criminal or civil safe-harbour protection?
- Which CSIRT/CVD channel should receive the report?
NIS2 substantially improves question ten.
Professional research still depends on the other nine.
What Member States should measure if they want functioning CVD
A national CVD policy should not be judged only by the existence of a designated coordinator.
More meaningful operational indicators include:
- how easily a researcher can find the reporting route;
- acknowledgement time;
- secure communication capability;
- multi-party coordination ability;
- clarity of testing boundaries;
- existence and scope of good-faith guidance;
- treatment of civil liability;
- remediation feedback;
- correction and escalation paths when the parties disagree.
That is how CVD becomes an operating security system rather than a compliance checkbox.
Conclusion
NIS2 is a major step forward for vulnerability disclosure in Europe.
It creates the expectation that vulnerabilities can be:
reported, coordinated, remediated and handled across borders through a defined institutional system.
It also explicitly recognises that criminal and civil exposure of security researchers can undermine that system.
But NIS2 does not create one European researcher safe harbour.
The material answer remains substantially national.
Latvia illustrates the transition well: it already has a detailed statutory CVD process, while a separate 2026 legislative initiative sought to clarify the earlier question of what a security researcher may lawfully do to search for vulnerabilities in covered systems.7
The position of the European vulnerability researcher can therefore be summarised in one sentence:
Europe is increasingly clear about where a vulnerability should go after it is found. It is still less uniform about what the researcher may lawfully do in order to find it.
That is the next boundary for European CVD policy.
Frequently asked questions
Does NIS2 give security researchers legal immunity?
Does NIS2 authorise testing without the system owner's consent?
Not by itself. Authorisation may arise from national law, the relevant right holder, a VDP/bug-bounty policy or another valid legal basis.
Why does Recital 60 matter if it is not a safe harbour?
Because it explicitly identifies researcher liability as a CVD policy problem and encourages national protection. It is important interpretative and policy context, but not an individual licence to test.
Does anonymous reporting protect a researcher from liability?
No. Anonymity protects identity in the reporting process. It does not automatically legalise prior technical conduct. Latvia's own confidentiality rule is explicitly conditional.6
Does Latvia currently have a general statutory safe harbour for good-faith security research?
Does the Cyber Resilience Act create a researcher safe harbour?
No. The CRA imposes vulnerability-handling and CVD-policy obligations on manufacturers. It does not itself create a general criminal or civil immunity for independent researchers.9
Source status
EU and Latvian legal status checked on 25 September 2026. This article distinguishes binding provisions of NIS2 from recitals and from national legislative proposals. Latvia's 2026 proposed research-authorisation amendments are described as a legislative initiative, not as law currently in force.
This article analyses EU and Latvian cybersecurity law and vulnerability-disclosure policy. It is not individual legal advice.
Sources
- Directive (EU) 2022/2555 (NIS2), particularly Article 12 on coordinated vulnerability disclosure and the European vulnerability database · EUR-Lex
- Directive (EU) 2022/2555, Article 7(2)(c), requiring national policy on vulnerability management including promotion and facilitation of CVD · EUR-Lex
- Directive (EU) 2022/2555, Recital 60 on potential criminal and civil liability of vulnerability researchers and possible national non-prosecution/civil-liability protections · EUR-Lex
- Directive 2013/40/EU on attacks against information systems, particularly Article 2(d) and Articles 3–7 · EUR-Lex
- ENISA, Coordinated Vulnerability Disclosure Policies in the EU, 13 April 2022 · ENISA
- Latvia, National Cybersecurity Law, particularly Sections 39–40, consolidated text checked 25 September 2026 · Likumi.lv
- CERT.LV, “Piedāvāti grozījumi NKDL - drošības pētnieku tiesības meklēt ievainojamības subjektu informācijas sistēmās”, 30 July 2026 · CERT.LV
- CERT.LV, “Atgādinām: ētiska ievainojamību testēšana neietver DoS un DDoS uzbrukumus”, 28 August 2026 · CERT.LV
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I Part II, vulnerability-handling requirements including a coordinated vulnerability-disclosure policy and vulnerability-reporting contact point · EUR-Lex