Security Research Legal Safe Harbours Guide: CMA, CFAA, NIS2 CVD and National Policies

Security researchers who find vulnerabilities in systems they do not own still carry real criminal and civil risk, and most "safe harbours" are prosecutorial policies or contract promises rather than statutory defences. This guide compares the legal position under the UK Computer Misuse Act 1990, the US Computer Fraud and Abuse Act, the DMCA section 1201 security research exemption and the EU NIS2 coordinated vulnerability disclosure framework, and shows what a vulnerability disclosure programme (VDP) owner can and cannot promise. It is written for researchers, PSIRT and VDP owners, bug bounty managers and in-house counsel who need a comparative view. Status checked on 27 October 2026 against legislation.gov.uk, the US Code, the eCFR, the US Department of Justice and EUR-Lex. This is not legal advice.

Key takeaways

• The UK has no statutory research defence. The Computer Misuse Act 1990, as revised up to 25 October 2026, contains no defence for security research; Home Office reviews ran in 2021 and 2023 without a published change to the Act.
• The US protection is a charging policy, not a law. Since May 2022 the DOJ directs federal prosecutors to decline good-faith security research under the CFAA, but the policy does not change the statute and the page says nothing about state prosecutors or civil suits.
• Van Buren narrowed, but did not remove, CFAA risk. The Supreme Court's 2021 "gates-up-or-down" test asks whether you could enter the system or area, not why you were there.
• The DMCA exemption is explicitly not a safe harbour from other laws. 37 CFR 201.40(b)(18) permits circumvention for good-faith research but states the research may still incur liability under other laws, including the CFAA.
• NIS2 pushes Member States to protect researchers but does not do it for them. Recital 60 encourages guidelines on non-prosecution and an exemption from civil liability; whether a researcher is protected depends on national law.

Scope: who and what is covered

This page covers unsolicited and programme-invited research on systems the researcher does not own: web applications, APIs, devices and cloud services. Authorised penetration testing under a signed contract is a different position, because written authorisation from the system owner removes the "unauthorised" element of most offences. See the Computer Misuse and Anti-Hacking Laws Guide for the wider offence landscape.

Key obligations

UK: Computer Misuse Act 1990

• Section 1, unauthorised access to computer material: maximum on indictment in England and Wales is two years' imprisonment, a fine or both. Merely logging in with credentials you found, or browsing an exposed admin panel, can meet the test if you know the access is unauthorised.
• Section 3, unauthorised acts impairing operation: covers intent or recklessness as to impairing a computer, a program or data; maximum ten years on indictment. Aggressive scanning or fuzzing that degrades a service is the research risk here.
• Section 3ZA, serious damage: maximum 14 years, or life where the act causes or risks loss of life, illness or injury, or serious damage to national security. Inserted by the Serious Crime Act 2015 from 3 May 2015.
• Section 3A, articles for use in an offence: making, supplying or obtaining tools for use in a section 1, 3 or 3ZA offence. Publishing proof-of-concept code is where researchers meet this section.
• Reform status: the Home Office ran a call for information from 11 May to 8 June 2021 (response 7 February 2023) and a consultation from 7 February to 6 April 2023 (outcome added 14 November 2023). The Act as revised to 25 October 2026 still contains no research defence. See the UK Computer Misuse Act Guide.

US: CFAA, DOJ policy and Van Buren

• The offence: 18 U.S.C. 1030(a)(2) prohibits intentionally accessing a computer without authorisation, or exceeding authorised access, and thereby obtaining information from a protected computer. A first offence carries up to one year; up to five years where it is for commercial advantage or private financial gain, furthers another crime or tort, or the information is worth more than $5,000.
• "Exceeds authorized access": defined in 1030(e)(6) as using authorised access to obtain or alter information the accesser is not entitled to obtain or alter. In Van Buren v. United States (3 June 2021, 6-3, Barrett J.), the Court held this means obtaining information from areas of the computer that are off-limits, under a "gates-up-or-down" inquiry, not misuse of information you were entitled to reach.
• The DOJ charging policy: Justice Manual 9-48.000, updated May 2022, defines good-faith security research as "accessing a computer solely for purposes of good-faith testing, investigation, and/or correction" of a security flaw or vulnerability, done in a way designed to avoid harm and used primarily to promote security or safety. Declination is expected where evidence shows good-faith research. Research done to extort the owner is not good faith. Prosecutors must consult the Computer Crime and Intellectual Property Section (CCIPS).
• Civil exposure remains: 1030(g) lets anyone who suffers damage or loss sue, where a qualifying factor applies (for example loss of at least $5,000 in a one-year period), within two years of the act or discovery. A charging policy does not affect this. See the US Computer Fraud and Abuse Act Guide.
• DMCA section 1201: 37 CFR 201.40(b)(18) exempts circumvention of access controls on a lawfully acquired device, or on a system with the owner's or operator's authorisation, solely for good-faith security research carried out in an environment designed to avoid harm. Paragraph (b)(18)(iii) states the research may still incur liability under other laws, including the CFAA, and that the exemption is not a safe harbour from them.

EU: NIS2 and national CVD policies

• Recital 60: Member States, in cooperation with ENISA, should facilitate coordinated vulnerability disclosure through a national policy. Because researchers "could in some Member States be exposed to criminal and civil liability", Member States are encouraged to adopt guidelines on non-prosecution of information security researchers and an exemption from civil liability for their activities.
• Designated coordinator CSIRTs: ENISA, as secretariat of the EU CSIRTs Network, supports the CSIRTs that Member States designate as CVD coordinators; they cooperate within the network when a vulnerability may significantly affect entities in more than one Member State. A researcher can report through the national coordinator rather than directly to a hostile vendor.
• National variation: each Member State decides whether to add legal protection. The Netherlands has run a national CVD guideline since 2013 (originally the Responsible Disclosure guideline). Check the national transposition law and prosecution guidelines before relying on any protection. See the NIS2 Transposition Tracker.
• Cyber Resilience Act: manufacturer reporting obligations under CRA Article 14 apply from 11 September 2026; they bind manufacturers, not researchers, but they raise the chance that a reported vulnerability reaches a CSIRT quickly. See the EU Cyber Resilience Act Guide.

Timeline and current status

Status line: correct as of 27 October 2026. UK reform proposals, US state laws and national NIS2 transpositions can change the position at any time.

Enforcement and penalties

The practical lesson from every regime: minimise data access, stop at proof, never degrade service, and never tie disclosure to payment. Each of those is a factor the DOJ policy, recital 60 and VDP terms all turn on.

What it means for AI agents and non-human identities

• Found secrets are the most common trap: a researcher who finds an API key or service account token in a public repository has found a vulnerability; using it to log in is unauthorised access under CMA s1 and CFAA 1030(a)(2). Good VDPs tell researchers to report, not test, discovered credentials. See the Non-Human Identity (NHI) Guide.
• Automated and AI-driven testing still has a human author: an AI agent that scans out of scope or causes impairment exposes whoever ran it. Scope, rate limits and stop conditions must be enforced in the agent's tooling, not only in the policy text. See the AI-Assisted and Autonomous Penetration Testing Guide.
• Authorisation should name machine access: VDPs should say whether researchers may create test accounts, call APIs with their own tokens, or interact with AI agents and LLM features, so the "gate" in Van Buren terms is clear.

Compliance steps

For VDP and bug bounty owners:

1. Publish a written authorisation. State that good-faith research within scope is authorised and that you will not pursue civil action or refer it for prosecution. You cannot bind prosecutors or third parties, so say so.
2. Define scope and gates precisely. List domains, APIs and apps; say what is out of scope (third-party SaaS, production data, social engineering, denial of service).
3. Set data rules. Access only what is needed to prove the issue, do not retain personal data, and report discovered credentials without using them.
4. Cover third parties. Where assets run on cloud or SaaS providers, state that you cannot authorise testing of the provider's own infrastructure.
5. Offer a coordinator route. Point researchers to the national CSIRT where one is designated as CVD coordinator, and publish a security.txt contact.
6. Train legal and PR teams. Agree in advance that a good-faith report is never met with a threat letter.

For researchers: keep notes and timestamps, stop at proof of concept, avoid downloading data, never demand payment outside a published bounty, and use a coordinator where the vendor is unresponsive. See the Bug Bounty and Vulnerability Disclosure Guide and the Vulnerability Disclosure Policy Template.

Common failure patterns

• "Safe harbour" wording that over-promises: a VDP cannot exempt a researcher from criminal law or from claims by third parties.
• Treating the DOJ policy as immunity: it binds federal prosecutors only and does not touch 1030(g) civil suits.
• Testing found credentials: the most frequent way good-faith researchers cross the line.
• Scope silent on cloud providers: researchers test the provider and the organisation cannot authorise it.
• Disclosure tied to payment: conduct that looks like extortion falls outside every policy described here.

Practitioner checklist

• Publish a VDP with explicit authorisation and a no-legal-action commitment for in-scope good-faith research.
• State the limits: no binding effect on prosecutors, regulators or third parties.
• List in-scope assets and excluded activities, including denial of service and data exfiltration.
• Instruct researchers to report, not use, discovered secrets and tokens.
• Name the national coordinator CSIRT and publish a security.txt contact.
• Review the policy against the CMA, CFAA and each national NIS2 law where you operate.
• Set rules for AI agent and automated testing: rate limits, stop conditions, logging.
• Recheck the legal position yearly, especially UK CMA reform and national NIS2 transpositions.

Standards and references

• legislation.gov.uk: Computer Misuse Act 1990
• Cornell LII: 18 U.S. Code 1030, Fraud and related activity in connection with computers
• US Department of Justice: Justice Manual 9-48.000, Computer Fraud and Abuse Act
• Supreme Court of the United States: Van Buren v. United States
• eCFR: 37 CFR 201.40, Exemptions to prohibition against circumvention
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• ENISA: Vulnerability Disclosure
• GOV.UK: Review of the Computer Misuse Act 1990

Related NHI Mgmt Group resources: Bug Bounty and Vulnerability Disclosure Guide · Computer Misuse and Anti-Hacking Laws Guide · Vulnerability Disclosure Maturity Model · ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide. This guide summarises security research laws and safe harbour policies as of 27 October 2026 and is not legal advice.