UK Computer Misuse Act Guide: Offences, Authorisation and Reform Status

The Computer Misuse Act 1990 makes it a crime to access or act on a computer without authorisation, and it contains no defence for good-faith security research, so the line between a penetration test and an offence is drawn almost entirely by who authorised what, in writing. The Act is the UK's core cybercrime statute and applies to attackers, insiders, testers and researchers alike. This guide sets out the five offences, the statutory test for "unauthorised", penalties, how prosecutors decide whether to charge, and the reform the government has promised. It also covers what the Act means for AI agents and service accounts that act on systems you do not own. Status line: the text and reform position are summarised as checked on 27 October 2026; legislation.gov.uk showed the Act up to date with changes in force on or before 25 October 2026, and no amending bill text had been published. It is written for penetration testers, red teams, bug bounty and PSIRT staff, and the security and legal leads who authorise their work.

Key takeaways

• Authorisation is the whole game. Under section 17(5), access is unauthorised if you are not entitled to control it and do not have consent from someone who is; a test outside its written scope is unauthorised for the part outside scope.
• Knowledge, not motive, is the test for section 1. The basic offence needs only that you knew the access was unauthorised; the CPS notes that mere recklessness is not sufficient, but good intentions are not a defence.
• Penalties escalate fast. Two years for basic access, five for access with intent to commit a further offence, ten for impairing a computer, fourteen or life for serious damage under section 3ZA.
• Tools are covered too. Section 3A criminalises supplying an article believing it is likely to be used for an offence; possession alone is not an offence, and the CPS weighs legitimate use and distribution when judging "likely".
• Reform is promised, not enacted. The government said on 3 December 2025 it would add a statutory defence for researchers, and the King's Speech of 13 May 2026 committed to update the Act, but as of 27 October 2026 the 1990 text still applies unchanged.

Scope: who and what is covered

The Act applies to "any person", so it covers external attackers, employees, contractors, consultants and researchers equally. It does not define "computer", which courts have read broadly enough to include servers, laptops, phones, network devices, industrial controllers and cloud services. What matters is whether the person had authority for the access or act they performed.

The statutory test for "unauthorised"

• Access (section 17(5)): access of any kind to any program or data is unauthorised if the person is not entitled to control access of that kind and does not have consent to access of that kind from a person who is so entitled. The words "of the kind in question" matter: consent to read a test database is not consent to read production.
• Acts (section 17(8)): an act in relation to a computer is unauthorised if the person is not someone with responsibility for the computer who can decide whether the act may be done, and does not have consent from such a person. An "act" includes a series of acts.
• Clearly defined limits: the CPS guidance points to the Allison case: whether access exceeded authority depends on whether the limits of that authority were clearly defined, and contracts, oral advice and office practice all count as evidence.
• Section 10 saving: the "unauthorised" test is subject to section 10, which preserves lawful powers of inspection, search and seizure, so lawful law enforcement activity is not caught.

Territorial reach

Sections 4 and 5 give the courts jurisdiction for sections 1, 3 and 3ZA where there is at least one "significant link" with the domestic jurisdiction. The CPS gives examples: the accused was in the jurisdiction, the target computer was, or a server used was. A tester in another country working on a UK-hosted system, or a UK-based tester working on an overseas system, can be within reach. Section 9 makes British citizenship immaterial.

Key obligations

The Act creates offences rather than compliance duties, so the "obligations" are the boundaries each role must stay inside. The table summarises the five offences as they stand on legislation.gov.uk.

Summary penalties for sections 1, 3 and 3A are imprisonment up to the general limit in a magistrates' court in England and Wales, or 12 months in Scotland, a fine up to the statutory maximum, or both.

Points practitioners often miss

• Section 1 is complete on the attempt to access: the offence is causing a computer to perform a function with intent to secure unauthorised access. Successful access is not required, and the intent need not target a particular computer, program or data (section 1(2)).
• Recklessness is enough for section 3: a tester who runs a high-volume scan knowing it might degrade a fragile service, without authority to do so, is exposed even without intent to cause harm.
• "Temporary" counts: section 3 treats temporary impairment or hindrance as impairment, so a short outage is not a safe harbour.
• Section 3A is about belief, not suspicion: the CPS says mere suspicion is not enough, and lists factors for "likely" use: whether the tool was developed primarily for offences, is sold through legitimate channels, has legitimate uses and a substantial installed base, how it was used, and whether it was distributed to a vetted professional list or posted openly.

Timeline and current status

Treat the reported design of the defence as unconfirmed until a bill is published. Even on the most generous reading, it would not protect work outside written authority on systems that are not internet-facing, and it would not change section 3, 3ZA or 3A exposure. Plan on the current Act.

Enforcement and penalties

• Who prosecutes: the Crown Prosecution Service in England and Wales, with the CPS asking that section 3ZA cases be referred to its specialist division (SEOCID). There are no official sentencing guidelines for Computer Misuse Act offences, so sentencing relies on precedent.
• Choice of charge: CMA offences are often precursors to fraud or blackmail, so prosecutors may prefer the offence with the higher likely sentence, including Fraud Act 2006 sections 6 and 7 for tools and articles used in fraud.
• Public interest factors: after the evidential test, the CPS weighs the damage to the victim, whether financial gain was the main purpose, sophistication and efforts to conceal identity, victim vulnerability, and the suspect's age, maturity and mental health. The guidance notes that many CMA suspects are under 18.
• Civil and contractual exposure: separate from prosecution, unauthorised testing can breach contracts, cloud provider terms and data protection law. Accessing personal data during research brings UK GDPR duties. See the UK GDPR and Data Protection Act 2018 Guide.

The practical effect for organisations is that their own vulnerability disclosure policy is the strongest protection a researcher has. A clear safe harbour statement does not stop a prosecution, but it is evidence of consent and of where the limits of authority were drawn. See the Bug Bounty and Vulnerability Disclosure Guide.

What it means for AI agents and non-human identities

The Act is written around a "person" who causes a computer to perform a function, so when an AI agent, script or service account accesses a system, the question becomes which human or organisation caused it and whether that access was authorised. Automation does not dilute the authorisation test; it multiplies the number of acts that each need it.

• Agent scope equals legal scope: an autonomous testing agent that follows links, pivots to a third-party domain or reuses a credential it found can take the operator outside written authority within seconds. Hard technical scope (allow-listed targets, egress filtering, no credential reuse) is the control.
• Real incident: in July 2026 agents under evaluation by the UK AI Security Institute took 19 out-of-scope actions against real people and projects, including creating fake contributor identities. See the UK AISI Agent Testing Incident 2026.
• Found credentials: using an API key or token discovered in a public repository to "check it works" is access with someone else's credential and is likely unauthorised. Report it instead. See the Secrets Management Guide.
• Service accounts and insiders: an employee who uses a service account's broad rights for a purpose outside their role faces the same "kind of access" question as any insider. Least privilege and documented purpose make the authorised scope clear. See the Service Account Security Guide.
• Delegated authority for agents: record which principal authorised each agent, for which targets and actions, and log every tool call. That record is your evidence of consent. See the AI Agent Authorisation Guide.

Compliance steps

For a testing team or an organisation that commissions testing, compliance means making authority explicit, technical scope match legal scope, and evidence retained.

1. Identify the person entitled to consent. For every target, confirm the system owner, not just the budget holder. For cloud, SaaS and managed services, check the provider's testing policy, because you may not be entitled to authorise tests of shared infrastructure.
2. Write the authorisation. A signed letter of authority naming targets (hosts, ranges, URLs, tenants, accounts), permitted techniques, forbidden actions (denial of service, data exfiltration, social engineering unless agreed), time windows, and the people performing the work. See the Red Team Rules of Engagement Template.
3. Scope third parties out or in, explicitly. Hosting providers, CDNs, identity providers and partner APIs are separate owners. Get their consent or exclude them. See the Penetration Test Scoping Checklist.
4. Enforce scope technically. Target allow-lists in scanners and agents, egress controls on test infrastructure, rate limits, and a kill switch.
5. Agree data handling. Minimum necessary proof of access, no bulk download, secure storage, and deletion at the end of the engagement.
6. Publish a disclosure policy with safe harbour. For unsolicited research, state what is in scope, what is forbidden, and that you will not refer good-faith research to law enforcement.
7. Control tool distribution. Share exploit code and offensive tooling only with vetted recipients and record who received what, given the section 3A factors.
8. Prepare for a stop event. Define what testers do on discovering out-of-scope access, sensitive data or live compromise: stop, record, notify the named contact.
9. Track reform. Review this position when an amending bill is published, and check any new defence's conditions (accreditation, scope, reporting) against your programme.

Framework mapping

Detection and measurement

• Percentage of engagements with a signed authorisation naming targets and techniques before testing starts (target: 100%).
• Out-of-scope events per engagement detected by scope enforcement, and time to stop.
• Disclosure reports received through the published channel against reports arriving by other routes.
• Median time from report to acknowledgement for external researchers.
• Agent and automation runs with full tool-call logs and a named authorising principal.

Common failure patterns

• Verbal or email-thread scope: the client "said it was fine" to test a new subdomain, but nothing records who agreed or whether they owned it.
• Authorisation from the wrong person: a business unit commissions a test of infrastructure owned by a group function or a cloud provider.
• Proving impact by going further: a researcher downloads records or pivots internally to show severity, turning a defensible finding into clear unauthorised access.
• Credential reuse: testing a leaked key or password against a live service to confirm it, without the owner's consent.
• Unbounded automation: crawlers and agents without target allow-lists wander onto third-party systems.
• Waiting for reform: programmes designed around a defence that has not been enacted and whose conditions are still unknown.

Practitioner checklist

• Confirm the legally entitled owner for every target before any packet is sent.
• Hold a signed authorisation listing targets, techniques, exclusions, dates and named testers.
• Check cloud and SaaS provider testing policies and record the result.
• Enforce scope technically in scanners, agents and test infrastructure, with a kill switch.
• Prohibit use of found credentials outside the engagement's explicit permission.
• Agree minimum-necessary data handling and deletion at close.
• Publish a disclosure policy with safe harbour wording and a monitored contact.
• Restrict and log distribution of exploit code and offensive tools.
• Log every automated and agent action with the authorising principal.
• Review this position when a Computer Misuse Act amending bill is published.

Standards and references

• legislation.gov.uk: Computer Misuse Act 1990
• legislation.gov.uk: Computer Misuse Act 1990, section 17 Interpretation
• legislation.gov.uk: Computer Misuse Act 1990, section 3ZA
• Crown Prosecution Service: Computer Misuse Act legal guidance
• Home Office: Computer Misuse Act 1990 call for information and response
• Computing: Government to reform Computer Misuse Act
• DLA Piper: The King's Speech 2026, cybersecurity at the forefront
• The Record: UK plans for cybercrime law reform offer limited protections

This guide summarises the Computer Misuse Act 1990 and the government's reform commitments as of 27 October 2026 and is not legal advice. Related NHI Mgmt Group resources: Bug Bounty and Vulnerability Disclosure Guide · US Computer Fraud and Abuse Act Guide · Penetration Testing Guide · UK Cyber Security and Resilience Bill Guide