Skip to content
HACKTECH

For universities, colleges, schools and school groups, research institutes and education technology providers

Security testing for universities and research institutions

Universities run open networks for unmanaged devices, hold years of student and staff records, and host research that other states and competitors want. We test the identity systems everyone shares, the student and research systems behind them, and the edtech platforms that collect children's data, taking the openness of the institution as given.

What an attacker wants from universities and research institutions

Ransomware stops teaching, admissions and payroll. A breach exposes personal data on students, applicants, staff and alumni, and for schools and edtech that includes children. Research is the quiet target: unpublished results, grant applications and work with commercial or defence partners, taken by groups who want the knowledge rather than a ransom. A university can rarely lock its network down like a bank, so a test has to show which controls still hold in an environment built to be open.

How universities and research institutions are attacked

  • Ransomware through exposed services and stolen credentials

    Remote desktop, VPN and legacy web applications left reachable from the internet, and credentials harvested by phishing or infostealer malware, are the usual first steps. Large flat networks and shared administrative accounts then carry the attacker to the systems that matter.

  • Account compromise at scale

    Every student and member of staff is a target, and a compromised university account opens email, cloud storage, library resources and single sign-on to everything else. Attackers then send phishing from those accounts, which looks internal because it is.

  • State-backed targeting of research

    In its 2019 assessment of the threat to universities (opens in a new tab), the UK National Cyber Security Centre judged that nation states almost certainly target universities for the data they hold, and that sensitive research may be targeted for its defence or commercial value.

  • Weak separation between networks

    Residence networks, teaching labs, research clusters and building management systems often share infrastructure, so a compromised student laptop may be a few hops from finance or a laboratory instrument.

  • Third-party edtech and cloud services

    Learning platforms, exam proctoring tools, admissions portals and the integrations between them hold sensitive data and single sign-on trust. A flaw in one shared platform affects every institution that uses it.

Frameworks that shape a test for universities and research institutions

Research organisations are among NIS2's other critical sectors, and member states may extend the directive to education institutions, in particular those carrying out critical research. Student and staff records fall under GDPR's 72-hour breach notification in Europe and, in Israel, under the Data Security Regulations, where, since Amendment 13 took effect on 14 August 2025, a controller that skips the penetration tests a high-security database requires can be fined NIS 327,560 at 2026 rates. The EU AI Act lists AI systems used for admissions or to evaluate learning outcomes as high-risk. Universities holding US Department of Defense contracts that involve Controlled Unclassified Information face CMMC 2.0 requirements for the systems that store it.

What we test for universities and research institutions

The scoping call settles which of these apply to your systems.

  • Single sign-on and identity: the identity provider, multi-factor enrolment and recovery, guest and alumni accounts, and how long access survives after someone leaves
  • Student information and admissions systems: role checks between applicants, students, staff and administrators, and bulk export endpoints
  • Learning platforms and their plugins: Moodle, Canvas or Blackboard configuration, LTI integrations, file uploads and grade changes
  • Network segmentation: residence and guest networks, teaching labs, research clusters, finance and building management systems
  • Research computing: access to high-performance computing clusters and research data storage, shared service accounts, and data leaving the institution
  • Internet-facing estate: forgotten departmental web servers, legacy applications, remote desktop and VPN services
  • Microsoft 365 or Google Workspace: sharing settings, external collaboration, app consent and mailbox rules
  • Edtech products used by schools: handling of children's data, parent and teacher roles, and API access between schools on the same platform

Services we scope for universities and research institutions

  • Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.

    Duration: 5 to 10 working days

  • An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Phishing, vishing and physical pretexting run against your staff, help desk and finance team, only under written authorisation that names the targets, pretexts and limits. Results are reported by channel and pretext, never by name: how far a convincing approach got, how many people reported it and how long the first report took to reach someone who acted.

    Duration: 2 to 4 weeks including campaign preparation

  • Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Hands-on workshops for engineers, run against a deliberately vulnerable copy of a codebase like yours. Developers exploit each bug before they fix it, so they have seen the attack their fix has to stop, and review real pull requests for the same bugs.

    Duration: 1 to 3 days on site or remote

Questions about testing universities and research institutions

Our network is open by design. What can a test prove?

That the controls you can enforce actually hold: multi-factor authentication on every account that matters, separation between student networks and administrative systems, and monitoring that would notice an attacker moving towards finance, HR or research data. The report is written for the institution you are, not for a corporate model you could never adopt.

Can you test during term time?

Yes, with windows agreed around teaching, exams and admissions deadlines. Anything that could affect availability, such as tests against the learning platform or the identity provider, runs out of hours or against a test instance.

Can a test cover research groups that run their own IT?

It should, because devolved IT is where unpatched servers and shared accounts tend to collect. We scope research environments with the group that owns them and agree what data may be touched, especially where it is personal, commercially confidential or subject to export controls.

Turn the checklist into a written scope

We pick the checks that apply to your systems and the frameworks you answer to. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.