Good-Faith Security Research in Europe: Where Is the Authorization Boundary?

Article 12 of NIS2 requires each Member State to designate one of its CSIRTs as a coordinator for coordinated vulnerability disclosure. The coordinator is meant to act as a trusted intermediary between the person reporting a vulnerability and the manufacturer or provider of the affected ICT product or service.1

NIS2 is unusually candid about the remaining legal problem. Recital 60 notes that vulnerability researchers can be exposed to criminal and civil liability in some Member States and encourages national guidelines on non-prosecution and exemptions from civil liability.1

That wording is important for what it does not say. NIS2 does not itself create blanket EU-wide immunity for vulnerability research.

The older Directive 2013/40/EU on attacks against information systems points in the same direction. It defines conduct “without right” as conduct not authorised by the owner or another right holder of the system, or not permitted under national law.2 National law therefore remains central to the boundary between permitted research and unlawful access.

ENISA has been documenting this problem for years. Its work on national CVD policies shows significant variation between Member States and specifically identifies researchers' legal exposure as an issue that national CVD frameworks need to address.3

In other words, Europe has moved further on coordination than on authorization.

“Good-faith security research” is a useful expression, but it can become misleading if treated as a status a researcher simply claims.

Consider two researchers who discover the same broken object-level authorization flaw.

The first uses a controlled request to show that one account can reach an object belonging to another account, retains the minimum evidence needed to explain the finding, stops, and reports it.

The second continues enumerating identifiers, downloads a large data set and explores unrelated functions because the initial weakness has made that technically possible.

Both may say that their purpose was defensive. Their conduct is materially different.

A workable policy therefore needs criteria that can be examined after the event without relying only on someone's stated intent. Scope, necessity, proportionality, impact, data handling, reporting and the stopping point all matter.

This is also why a “stop when proven” principle should not be reduced to a rigid request count. Some vulnerabilities require more than one step to establish reliably. The stronger question is whether each additional step had a defensible relationship to identifying, validating or reporting the finding.

Latvia's National Cybersecurity Law already regulates coordinated vulnerability disclosure in Articles 39 and 40. A person who identifies a vulnerability in the information system or electronic communications network of an entity covered by the law must report it to the competent cyber-incident prevention institution without delay and no later than five working days. The report must include, among other things, the methodology or sequence of actions used to identify the vulnerability.5

CERT.LV operates Latvia's vulnerability reporting platform and performs the national CVD coordination role. The platform rules effective from 1 August 2026 contain practical obligations for researchers, including compliance with programme-specific conditions, proportionate testing intensity and a prohibition on using a vulnerability in a way that harms the resource or its operator.10

CERT.LV made the operational boundary even clearer in August 2026. Its guidance states that DoS and DDoS testing is not considered ethical vulnerability testing unless a specific programme expressly permits it, and that a researcher should use the minimum requests and actions needed to demonstrate a vulnerability.12

There is an important distinction here.

The statutory CVD process and the scope of an individual platform programme are not the same thing.

The law governs the national disclosure and coordination process. An organisation's programme can give a researcher a much clearer statement of which resources and methods the organisation has agreed may be tested. The existence of a reporting route should not be read as unlimited technical permission to explore everything associated with an organisation.

The distinction matters because similar tools can appear in very different authorization models.

Latvia separately regulates penetration testing and security scanning for entities covered by the National Cybersecurity Law in Cabinet Regulation No. 397. The rules address when penetration tests are required, who may perform them and additional conditions for critical ICT infrastructure.8

That is different from an independent researcher finding and validating a vulnerability.

This is a conceptual comparison, not a universal legal classification. National law and programme language still matter.

The practical point is simpler: a bug-bounty reward does not expand scope; a disclosure channel does not turn an independent researcher into a contracted penetration tester; and a contracted tester may have authority to perform actions that an independent researcher does not.

The public-consultation material for draft 26-TA-1830 states the problem directly. Latvia already had a CVD platform, but participation by organisations was low, leaving researchers with legal risk when acting outside formally registered programmes. The draft was intended to provide a legal framework for good-faith participation in CVD and a general permission to access data in covered systems or networks for the purpose of discovering vulnerabilities.6

That proposed permission was not unlimited. The draft tied it to three constraints: the activity had to be necessary to identify, verify and report the vulnerability; it could not impose a disproportionate load; and it could not endanger security, confidentiality, integrity, availability or operational continuity.6

My comments during the consultation focused on the problem hidden inside those apparently simple words. “Necessary”, “disproportionate” and “endanger” need an operational meaning when a researcher is deciding whether to send the next request.

I proposed minimum necessary testing as a practical assessment principle rather than as a self-created legal defence: gather enough evidence for a credible, reproducible vulnerability report and do not expand the activity merely because the vulnerability makes further access technically possible.

That principle also needs an escape valve. Sometimes the evidence is genuinely ambiguous. If resolving that ambiguity requires broader access, more data or a riskier technique, the safer transition is from independent validation to explicit additional authorization or coordinated testing.

I asked Latvia's Ministry of Justice to examine the relationship between the proposed research boundary and the Criminal Law provisions dealing with unauthorised system access, interference and tools.

The Ministry expressly stated that its response was non-binding and that it was not involved in drafting 26-TA-1830. That limitation should stay attached to any use of its analysis.13

Within that limitation, its response is still instructive.

The Ministry described the draft as allowing only actions directly necessary to identify, verify and report a vulnerability. Once a sufficient minimum of information had been obtained, deeper exploitation should stop. It also discussed Section 244 of Latvia's Criminal Law: the subjective element described by the Ministry includes direct intent and a specific purpose of committing a criminal offence. In the Ministry's wording, possessing or using a security tool without criminal intent, for example for good-faith testing, is not punishable by itself.13

It would be a mistake to turn that into the slogan “good intentions make hacking legal”. They do not.

Latvia's Criminal Law provisions contain their own elements. Section 241 addresses unauthorised access in defined circumstances. Section 243(1) and (2) address specified unlawful actions involving information and intentional system interference, with substantial harm among the elements of those basic offences. Section 244(1) covers the listed unauthorised dealings in certain tools when done for the purpose of committing a criminal offence.9 The facts still matter.

The better lesson is that intent is only one part of a defensible research record. Permission, necessity, technical effect and the decision to stop remain relevant.

Access-control vulnerabilities often prove themselves with information the researcher was never meant to see.

I therefore asked Latvia's Data State Inspectorate to consider how personal-data rules apply to good-faith vulnerability research and CVD. Its written response rejected any assumption that CVD sits outside the GDPR. The Inspectorate said the assessment depends on the purpose of the processing, the type and amount of data, the researcher's actual role, and what happens to the data after the vulnerability is found.14

The response also illustrates why labels can be misleading. A researcher working on the data controller's instructions may occupy a different GDPR role from an independent researcher who chooses the system, purpose and means of the processing. The Inspectorate noted that identifying a lawful basis can be difficult for an independent researcher, particularly where special-category data is involved.14

For this article, the operational takeaway is deliberately narrow: unexpected data access is not a reason to continue extracting data simply to make the impact look more dramatic. Retain only what is genuinely needed to document and report the finding, and move the problem into a coordinated channel.

The full GDPR question deserves its own analysis; reducing it to a paragraph here would create more confidence than the law supports.

The old mental model is a website owned and operated by one organisation.

A modern service may instead look like this:

organisation app → CDN/WAF → cloud account → managed identity provider → SaaS component → payment provider → analytics platform

An organisation may be perfectly entitled to authorize testing of its own application and tenant configuration while having no power to authorize testing of another provider's underlying platform or other customers.

This matters in both directions.

Researchers should not assume that a domain name creates permission across every technical dependency. Resource owners should not publish vague research policies that invite testing without explaining third-party boundaries.

Directive 2013/40/EU itself refers to authorization by the owner or another right holder of the system or part of it.2 That wording maps more closely to modern infrastructure than the idea of one universal “system owner”.

I do not think the available European or Latvian sources support one universal legal checklist that guarantees safety. They do support a more modest decision discipline.

1. What is the basis for testing this resource?

Is there an explicit programme, contractual authorization, another clear permission, or a national legal basis that plausibly covers this activity? Is the exact resource actually within that boundary?

2. What will the next action prove?

There is a difference between a step needed to turn a weak signal into a reproducible finding and a step taken mainly to see “how far this goes”.

3. Can the same fact be established with less impact?

Fewer requests, test accounts, metadata instead of content, a non-destructive technique, or coordination with the operator may produce the same evidential value.

4. Does the next action cross another party's rights?

Cloud, SaaS, identity, CDN and payment dependencies can create a new authorization question even when the original application is clearly in scope.

5. Could the decision trail be explained later?

This is not a self-issued safe harbour. It is factual hygiene. Record what was known at the time, what question the next step was meant to answer, what happened, and why testing continued or stopped.

These five questions are my practical synthesis of the sources and institutional material. They are not a statement of law.

The Latvian correspondence does not support a claim that “the authorities agreed with my model”, and I would not present it that way.

The Ministry of Justice offered a specific but non-binding criminal-law analysis. The Data State Inspectorate recognised genuine data-protection questions and said the purpose, scope and boundaries of the intended processing needed further clarification. The Prosecutor General's Office treated parts of the request as outside its competence and accepted the submission for information.15

The National Cybersecurity Centre said proposals within the scope of draft 26-TA-1830 would be assessed together with the other public-consultation comments.16

That mixed picture is more useful than manufactured consensus.

The researcher experiences one technical event. Public law may divide it into cybersecurity policy, criminal law, data protection, programme terms, evidential questions and sector-specific rules. A mature CVD framework has to connect those domains well enough that responsible conduct is reasonably predictable before a dispute occurs.

NIS2 already supplies the coordination architecture. The remaining work is largely about the boundary around research itself.

A national framework does not need to make every form of testing lawful. Nor does it need to require a bespoke contract before every minimal validation step. It does need to answer a few practical questions with greater consistency:

• when a published policy or national rule gives meaningful permission to validate a vulnerability;
• which techniques are outside that permission by default;
• how necessity and proportionality should be assessed using the information available to the researcher at the time;
• what a researcher should do when protected data appears unexpectedly;
• how third-party infrastructure affects scope;
• how a researcher can obtain rapid guidance or additional permission when the finding cannot be safely validated within the default boundary.

The most useful safe-harbour concept is therefore not “researchers are immune if they mean well”. It is a conditional model in which protection follows clearly described conduct.

ENISA's comparative work on European CVD policies points in the same general direction: national legal frameworks and CVD policies need to reduce legal uncertainty while retaining criteria that distinguish responsible research from malicious activity.3

The hardest part of good-faith vulnerability research is not writing the report. It is knowing when enough testing has become enough evidence.

Europe has made substantial progress on what happens after a vulnerability is reported: CVD coordinators, national processes and an increasingly mature vulnerability ecosystem. The permission boundary before that report remains much less uniform.

Latvia's 2026 debate is useful because it makes the missing layer visible. A researcher needs enough room to establish that a security defect is real. A system operator needs protection against open-ended exploration, disruption and unnecessary data access. Both interests can exist at the same time.

My preferred boundary is deliberately practical: prove the defect, not the maximum damage you could cause with it. When reliable proof requires broader access or a materially riskier action, that is usually the point to switch from independent validation to explicit coordination.

That is a more useful standard than the label “ethical hacker”, because it can be examined in the conduct itself.

The legal and public-source material in this article was rechecked on 25 September 2026 against current Latvian law, EUR-Lex, CERT.LV, ENISA and Latvia's TAP legislative portal.

The Latvian case-study section also draws on my 2026 public-consultation submissions and written institutional responses in my archive. I have kept the distinction between (a) law in force, (b) a draft proposal, (c) an authority's written view and (d) my own policy analysis.

One other institutional response received during this work is marked as restricted-access information. Its contents are not used or quoted here.

This article is technical and public-policy analysis, not individual legal advice.