Universities run an open network for tens of thousands of transient users, hold financial aid, health and research data worth stealing, and protect it with central teams that rarely control every department. Higher education is not a single enterprise: it is a federation of faculties, research groups, residences, clinics, sports operations and commercial spin-outs, each with its own systems and budgets. This guide covers the threat picture as government sources describe it, the regulation that applies in the UK and US (GLBA through Title IV, FERPA, UK GDPR and research security rules), the controls that differ from the general enterprise case, and a phased way to roll them out around the academic calendar. It is written for university CISOs, central IT security teams, research computing leads and the governance staff who answer to boards and funders.
Key takeaways
- Almost every university is hit every year. In the UK Cyber Security Breaches Survey 2025, 91% of higher education institutions identified a breach or attack in the previous 12 months, against 43% of businesses, and phishing was involved in 97% of further and higher education cases.
- Financial aid data carries a federal security programme. US institutions in Title IV programmes have agreed to the FTC Safeguards Rule (16 CFR Part 314); the Department of Education treats findings as an administrative capability issue that can affect aid participation.
- Research is a target in its own right. State-backed actors seek research data and intellectual property, and US funders now require research security programmes and training; controlled research may also fall under NIST SP 800-171.
- Your biggest data stores are SaaS. The learning platform, student information system and research collaboration tools hold most student data, and the Canvas Instructure breach showed how one vendor token can expose thousands of institutions at once.
- Segment the open campus rather than closing it. Separate student, research, administrative and building networks, protect a small set of crown jewels hard, and accept a lower-trust posture for the rest.
Why higher education is different
General enterprise security guidance assumes one owner, a managed fleet and a stable workforce. Universities break all three assumptions.
- Decentralised ownership: faculties and research groups buy their own systems, run their own servers and sometimes their own firewalls. Central IT sets policy but often cannot enforce it without academic governance support.
- Unmanaged devices by default: most students, many researchers and visiting academics bring their own laptops and phones. Device-based controls only work for staff and lab equipment.
- Extreme identity churn: a whole cohort arrives every autumn, leaves every summer, and many keep alumni access. Staff hold several roles at once (lecturer, researcher, student, clinician). See the Education Identity Security Guide.
- Openness is the mission: research collaboration across institutions and countries, public Wi-Fi via eduroam, public websites with thousands of pages and conference systems all widen the attack surface by design.
- Mixed regulated data: a single university can hold student records, financial aid data, payment card data, health records from a teaching hospital or counselling service, export-controlled research and personal data of research participants.
- Seasonal peaks: enrolment, clearing, fee payment, exams and graduation are when attackers send the most convincing lures and when downtime costs the most.
Threat picture
The UK Cyber Security Breaches Survey 2025 education findings (fieldwork August to December 2024) give the clearest comparative data. The higher education sample was only 32 institutions, so treat the figures as indicative rather than precise.
| Measure (CSBS 2025) | Higher education | Further education | Businesses overall |
|---|---|---|---|
| Identified a breach or attack in last 12 months | 91% | 85% | 43% |
| Phishing among those that identified one | 97% (FE and HE combined) | 85% | |
| Two-factor authentication on any networks or applications | 100% | 94% | 40% |
| Formal incident response plan | 75% | 83% | 23% |
| Governors or senior management updated at least quarterly | 91% | 81% | Varies by size |
The pattern is high attack volume against institutions that already have the basic controls on paper. The gap is usually coverage (MFA everywhere, not just on email) and speed (how long a compromised account stays live).
| Threat | How it shows up in universities | ATT&CK technique | Priority control |
|---|---|---|---|
| Credential phishing and account takeover | Lures timed to enrolment, payroll, fee deadlines and IT password expiry; compromised student accounts used to phish staff internally | T1566 Phishing; T1078 Valid Accounts | Phishing-resistant MFA for staff and admins, fast containment of compromised accounts |
| Password spraying | Large, predictable username formats (student numbers) and legacy protocols that skip MFA | T1110.003 Password Spraying | Block legacy authentication, smart lockout, breached-password screening |
| Ransomware and data extortion | Entry through unpatched VPN or web apps, then encryption of virtualisation and file servers and theft of HR and student data | T1190 Exploit Public-Facing Application; T1133 External Remote Services; T1486 Data Encrypted for Impact | Patch internet-facing systems first, immutable backups, separated admin identities |
| Research data theft | State-linked actors after research data, unpublished results and IP, often through collaborators' accounts and unmanaged research servers | T1078 Valid Accounts | Research security programme, enclaves for sensitive projects, Trusted Research checks |
| SaaS and vendor compromise | Learning platform, SIS, admissions and alumni systems breached at the supplier, exposing many institutions together | T1078 Valid Accounts | Vendor due diligence, token and integration governance, contract notification clauses |
| Denial of service | Hacktivist and student-originated DDoS against websites, VPN and exam platforms | T1498 Network Denial of Service | Upstream DDoS protection through the national research network or provider |
| Payroll and supplier fraud | Direct deposit changes after account takeover, invoice fraud against procurement | T1566 Phishing | Out-of-band verification of bank detail changes |
For the identity techniques behind most of these, see the Phishing-Resistant MFA Guide and the Ransomware Prevention Guide.
Regulation and obligations (status checked October 2026)
| Obligation | Applies to | Security requirements that matter |
|---|---|---|
| FTC Safeguards Rule (16 CFR Part 314) via the Title IV Program Participation Agreement | US institutions and third-party servicers in federal student aid programmes | Written information security programme with a Qualified Individual, risk assessment, safeguards, testing, staff policies, service provider oversight; incident response plan and annual report to leadership for institutions holding information on 5,000 or more consumers. Most amended provisions effective 9 June 2023 |
| FERPA (20 U.S.C. 1232g; 34 CFR Part 99) | US institutions receiving Department of Education funds | Controls on disclosure of education records; access limited to school officials with a legitimate educational interest; rights transfer to students at postsecondary entry |
| UK GDPR and Data Protection Act 2018 | UK institutions processing student, staff and research participant data | Article 32 security of processing; Article 33 notification to the ICO within 72 hours of becoming aware of a reportable breach |
| US research security (NSPM-33, CHIPS and Science Act) | Institutions receiving federal research funding; programme certification above $50 million a year in federal science and engineering support | Research security programme certification, annual research security training for covered individuals (NSF requirement effective 2 December 2025), foreign support disclosure |
| NIST SP 800-171 and CMMC | Research under contracts that involve Controlled Unclassified Information, including defence research | 110 security requirements in Rev. 2 (as referenced by DFARS) or the Rev. 3 catalogue, assessed through CMMC for defence contracts |
| PCI DSS | Any department taking card payments: fees, shops, accommodation, events | Cardholder data environment scoping, MFA into the CDE, quarterly scans |
| UK Trusted Research (NPSA guidance) | UK academia collaborating internationally | Guidance rather than law: due diligence on partners, protecting sensitive and dual-use research |
- GLBA in practice: the Department of Education's Federal Student Aid office (announcement GENERAL-23-09) states that GLBA findings from compliance audits are resolved through its evaluation of administrative capability, that noncompliant institutions must submit a Corrective Action Plan, and that repeated noncompliance can lead to action affecting Title IV participation. It specifically highlights encryption of customer information in transit and at rest and MFA for anyone accessing it. See the GLBA Safeguards Rule Guide.
- FERPA and security: FERPA is a privacy law, but its access rules drive role-based access in the student information system and learning platform. See the FERPA Guide for Security Teams.
- Controlled research: keep CUI work in a defined enclave rather than trying to bring the whole campus into scope. See the CUI Guide and the NIST SP 800-171 and CMMC 2.0 Guide.
- UK reporting: UK institutions should know in advance who decides on ICO notification and how the 72-hour clock is tracked. See the UK GDPR and Data Protection Act 2018 Guide.
Priority controls for universities
Most universities already own the tools. The difference between a contained incident and a closure is usually coverage and enforcement of a short list of controls.
- MFA everywhere it reaches data: enforce MFA for all staff and researchers on email, VPN, SIS, finance, HR and cloud consoles, with phishing-resistant methods (FIDO2 security keys or platform passkeys) for IT administrators, finance staff and anyone with bulk access to student records. Extend to students, with non-smartphone options and a recovery process that scales to a full cohort. Block legacy authentication protocols that bypass MFA.
- Separate privileged identities: administrators use dedicated admin accounts without mailboxes, from managed devices, with just-in-time elevation where available. Departmental IT staff with domain or tenant rights are in scope, not just central IT. See the Privileged Access Management Guide.
- Patch the perimeter first: VPN gateways, remote access, web portals, file transfer and research-facing services exposed to the internet, with remediation of known exploited vulnerabilities in days rather than in the monthly cycle. Departmental servers need the same scanning even if central IT does not run them. See the Attack Surface Management Guide.
- Immutable, isolated backups: protect virtualisation, file shares, SIS and finance databases with backups that cannot be deleted with domain credentials, and test restores of the student record system before term. See the Backup Security and Immutable Backup Guide.
- Network segmentation: separate residential and student Wi-Fi, eduroam visitors, research networks, administrative systems, building management and lab instruments. Treat residence networks like a public ISP. See the Network Segmentation Guide.
- EDR on every managed endpoint and server: including research servers and lab PCs, with a route for instruments that cannot run an agent (isolate them instead). See the EDR Guide.
- Email authentication and filtering: DMARC at enforcement for the main domain and the many departmental subdomains that send mail. See the DMARC, SPF and DKIM Guide.
- Vendor and SaaS governance: inventory OAuth grants, LTI tools and API integrations into the learning platform and SIS, require breach notification and security terms in contracts, and limit who can approve new integrations. See the SaaS and OAuth App Governance Guide.
Research security and research computing
Research environments need different controls from administrative IT because the users, data and funders differ.
| Research data tier | Examples | Typical controls |
|---|---|---|
| Open | Published datasets, public code, teaching materials | Standard account security, integrity of public repositories |
| Sensitive personal | Health, interview and survey data on research participants | Ethics approval conditions, encryption at rest, access by named project members, data protection impact assessment |
| Commercially sensitive | Industry-funded projects, pre-patent results | Project-scoped storage, contract security clauses, export of data logged |
| Controlled (CUI, export-controlled) | Defence or dual-use research | Dedicated enclave assessed against NIST SP 800-171, US-person or nationality checks as required, separate identities |
- Trusted Research checks: due diligence on international partners and visiting researchers before access is granted, following the NPSA Trusted Research guidance in the UK and the institution's research security programme in the US.
- Federated access with assurance: research collaborations rely on eduGAIN federations. Release minimal attributes, use REFEDS assurance and MFA signalling, and commit to Sirtfi (the Security Incident Response Trust Framework for Federated Identity) so a compromised account can be handled across institutions. See the Federation and Trust Relationships Guide.
- HPC and research cloud: SSH keys, API tokens and service accounts on clusters and research cloud accounts outlive the projects that created them. Expire them with the grant.
- Collaborator and visitor accounts: sponsored accounts with an end date, a named sponsor and quarterly review. See the Research Institution Identity Security Guide.
Where identity fits
Identity is the control plane in higher education because the network cannot be trusted and many devices are unmanaged. Three areas carry most of the risk.
- Lifecycle at cohort scale: drive student accounts from the SIS and staff accounts from HR, define what ends at graduation, withdrawal and staff exit, and remove access within a defined time. See the Joiner-Mover-Leaver Guide.
- Help desk recovery: peak-period resets are the easiest route around MFA. Verify identity for staff resets with a call-back or in-person check. See the Account Recovery and Help Desk Security Guide.
- Machine identities: integration accounts between the SIS, learning platform, library systems and identity provider, plus LTI keys and API tokens, often have read access to every student record. Inventory them, scope them and rotate them. Short-lived, bound tokens limit the damage when a vendor is breached.
Implementation: a phased programme around the academic year
- Phase 1, first 90 days (ideally in the summer vacation): enforce MFA for all staff and block legacy authentication; separate admin accounts; patch or isolate internet-facing systems with known exploited vulnerabilities; confirm immutable backups exist for SIS, finance, HR and virtualisation, and run one test restore. Pilot MFA changes with IT and one faculty first, keep a break-glass account excluded and monitored, and keep the previous conditional access policy ready to restore if lock-outs spike.
- Phase 2, before enrolment: student MFA with self-service enrolment and a staffed recovery desk; communications that tell students exactly which messages IT will and will not send; refreshed help desk verification; extra monitoring for impossible travel and mass mail forwarding rules during the first six weeks of term.
- Phase 3, first term: segmentation of building management, lab instruments and residences; EDR coverage across departmental servers; integration and OAuth inventory for the learning platform and SIS; GLBA risk assessment and Qualified Individual report to the governing body where applicable.
- Phase 4, year one: research data tiers and enclaves; Sirtfi and federation assurance; tabletop exercise with senior leadership, communications and registry staff on an exam-period ransomware scenario (see the Tabletop Exercise Guide); supplier contract updates at renewal.
- Ongoing: termly access reviews for privileged and sponsored accounts, annual research security training tracking, and a decision log for exceptions granted to departments.
Decision guidance: central, federated or shared
| Decision | Smaller institution or college | Large research university |
|---|---|---|
| Security operations | Use the national research network's CSIRT services, a shared or managed SOC and platform-native detection | In-house SOC or co-managed service with research-network threat feeds; departmental IT feeds central logging |
| Departmental IT | Centralise; few departments can justify their own infrastructure | Federated model with mandatory minimum standards, central scanning and the right to isolate non-compliant systems |
| Controlled research | Decline or use a partner's assessed environment | Dedicated enclave with its own identity, logging and assessment scope |
| Student MFA | Platform authenticator app plus hardware tokens for exceptions | Same, with risk-based prompts to reduce friction across very large populations |
Detection and measurement
- Log sources: identity provider sign-ins and MFA events, email audit logs (forwarding rules, OAuth consents), VPN, SIS and learning platform admin and API audit logs, EDR, DNS and firewall logs from the research network edge.
- Detections worth building first: new inbox forwarding rules to external addresses; bulk API reads by integration or support accounts; sign-ins to staff accounts from student network ranges followed by payroll changes; MFA registration of a new method shortly after a password reset.
| Metric | Target to aim for |
|---|---|
| Staff and researcher accounts covered by enforced MFA | 100%, with exceptions logged and time-limited |
| Median time to contain a compromised account (disable, revoke sessions, reset) | Under one hour in working hours |
| Internet-facing known exploited vulnerabilities open beyond 14 days | Zero |
| Leavers with active access 7 days after leaving date | Zero for staff; defined alumni state for students |
| Critical systems with a successful test restore in the last term | 100% of SIS, finance, HR and virtualisation |
| Third-party integrations into SIS and LMS with a named owner and scoped permissions | 100% |
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| MFA and account management | PR.AA-03 | IA-2, AC-2 | 5, 6 | 5.16, 5.17, 8.5 |
| Patching internet-facing systems | ID.RA-01 | SI-2, RA-5 | 7 | 8.8 |
| Backups and recovery | PR.DS-11 | CP-9 | 11 | 8.13 |
| Supplier and SaaS risk | GV.SC-05 | SR-6, SA-9 | 15 | 5.19, 5.20 |
| Awareness and phishing | PR.AT-01 | AT-2 | 14 | 6.3 |
| Incident response | RS.MA-01 | IR-4 | 17 | 5.24, 5.26 |
For a programme-level view, see the NIST CSF 2.0 Guide.
Common failure patterns
- MFA on email but not on the VPN or legacy protocols: attackers simply use the path without a second factor. Audit every authentication path, including IMAP, SMTP AUTH and departmental VPNs.
- Departmental servers outside central visibility: an unpatched research web server or departmental file share becomes the entry point. Central scanning and a right to isolate are the minimum.
- Integration tokens that never expire: long-lived API tokens in the SIS and learning platform, and at suppliers, turn one breach into bulk data theft.
- Help desk resets during clearing and enrolment: volume pressure leads staff to skip verification, which is exactly when social engineering peaks.
- Backups reachable with domain admin credentials: ransomware operators delete or encrypt them before the main payload. Isolated identities for backup administration close this.
- Alumni and visitor accounts that never end: accounts with mail and file access years after the person left are a steady source of compromised credentials.
Lessons from incidents
The Canvas Instructure breach in 2026 is the clearest recent example of sector-wide exposure through a shared platform. According to the incident analysis, a stored cross-site scripting payload in a support ticket ran in a support agent's session, yielded a privileged token, and that token was used to pull usernames, email addresses, enrolment data and messages through Canvas APIs; Instructure's FAQ referred to around 8,800 institutions. A second intrusion days later used a different flaw to mint a new token through the OAuth flow. The lessons for universities are practical: ask suppliers how support access is scoped and logged, require short-lived tokens and notification terms in contracts, prepare student communications for follow-on phishing that uses stolen course and enrolment details, and keep your own record of which integrations hold which data so you can scope impact quickly.
Practitioner checklist
- Enforce MFA for all staff and researchers on every authentication path, block legacy protocols, and use phishing-resistant methods for administrators and finance.
- Separate admin accounts, including departmental IT, and protect backup administration with isolated identities.
- Remediate known exploited vulnerabilities on internet-facing systems within days, including departmental and research servers.
- Keep immutable backups of SIS, finance, HR and virtualisation and test a restore every term.
- Segment residences, eduroam, research, administration, building management and lab instruments.
- Confirm GLBA Safeguards Rule elements are in place for financial aid data, with a named Qualified Individual reporting to the governing body.
- Inventory SIS and learning platform integrations, scope their tokens, and add security and notification terms to supplier contracts.
- Stand up research data tiers, an enclave for controlled research, and tracking for research security training.
- Join federation security frameworks (Sirtfi) and set end dates and sponsors for all visitor accounts.
- Exercise an exam-period ransomware scenario with leadership and communications staff every year.
Standards and references
- US Department of Education, Federal Student Aid: Updates to the Gramm-Leach-Bliley Act Cybersecurity Requirements (GENERAL-23-09)
- US Department of Education: What is FERPA?
- US National Science Foundation: Research Security
- UK Government: Cyber Security Breaches Survey 2025, Education Institutions Findings
- NPSA: Trusted Research
- REFEDS: Sirtfi, Security Incident Response Trust Framework for Federated Identity
- NIST: SP 800-171 Rev. 3
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Education Identity Security Guide · Research Institution Identity Security Guide · Cybersecurity for Schools Guide · GLBA Safeguards Rule Guide · Ransomware Prevention Guide. This guide summarises regulatory obligations for security practitioners and is not legal advice.