STUDENT DATA
IS NOT EXPENDABLE.
A stolen student record cannot be reissued. We test the platforms holding those records, the federated identity in front of them, and the integrations quietly granted access to both.
THE EDUCATION THREAT MODEL
The records outlive the institution's interest in them
A twelve-year-old's identity data has decades of exploitable life and no credit file to alert anyone. Unlike a card number it cannot be reissued. That asymmetry is why student information systems are worth attacking long after the student has left.
An identity estate designed for openness
Federated identity across Shibboleth and SAML, thousands of accounts rotating annually, self-service enrolment, alumni credentials that never expire, and researchers who need administrative rights on their own machines. Every one of those is a reasonable academic requirement and an authentication weakness.
Integrations nobody centrally approved
Individual departments and teachers procure learning tools directly, each granted OAuth scopes or an LTI integration into the platform holding student records. The institution carries the breach obligation for vendors it never assessed and sometimes cannot enumerate.
WHAT DRIVES THE REQUIREMENT
For an education institution, testing is rarely optional. Student data obligations (FERPA, COPPA, and GDPR where it applies) and parent expectations all assume the systems have been adversarially tested.
FERPA
Governs access to education records in US institutions, including the disclosure implications of third-party vendors handling those records.
COPPA and state student privacy laws
Apply where services reach children under 13 and impose specific consent and data handling constraints on EdTech providers and the districts using them.
GDPR / UK GDPR
Applies to institutions and platforms handling data of students in scope, with heightened expectations where subjects are children.
Research funder and export control obligations
Grant conditions and controlled research programmes impose security requirements on the infrastructure holding the work, independent of the institution's own policy.
WHAT WE TEST
Student data & core platforms
- LMS and SIS authorisation testing across student, staff, and admin roles
- Grade, transcript, and enrolment record integrity
- Student PII retrieval through APIs, exports, and reporting
- Parent and guardian portal access boundaries
- Assessment and proctoring platform abuse
Identity & third-party integrations
- Shibboleth and SAML federation configuration and assertion handling
- LTI and OAuth scope review across integrated learning tools
- Alumni, contractor, and dormant account lifecycle
- Self-service enrolment and password reset abuse
- Directory and attribute release to third parties
Campus & research infrastructure
- Network segmentation between administrative, academic, and residential networks
- Research data and intellectual property access controls
- Cloud tenancy and SaaS configuration review
- Email and collaboration platform security
- Legacy departmental systems reachable from the core network
HOW WE WORK
The work runs in parallel across roles, federation and integrations, scheduled around the academic calendar.
Record and identity mapping
Trace where student records live and every identity path that reaches them, including the departmental tools and integrations not on the central inventory.
Threat modelling
Extortion operators who publish student data to force payment, credential-stuffing against a large and reused account base, students probing grading systems, and espionage against research.
Agentic exploitation
Agent swarms work authorisation across every role pair, federation handling and integration scopes in parallel, exploiting what they reach. Activity is scheduled around term dates, examinations and enrolment periods.
Evidence and control mapping
Findings mapped to FERPA and the privacy regimes in scope, written for both a technical team and a governing body that must understand the exposure.
WHAT YOU RECEIVE
WHEN EDUCATION BREAKS
Public disclosures worth reading closely. Three of the four arrived through a third party the institution had procured but could not audit.
MOVEit / National Student Clearinghouse
2023Zero-day exploitation of a managed file transfer product exposed student records held on behalf of hundreds of institutions.
One vendor product placed unrelated colleges in the same breach. Most had no direct relationship with the software.
Los Angeles Unified School District
2022Ransomware operators exfiltrated hundreds of gigabytes, including student psychological assessments, and published them when payment was refused.
The most sensitive category of student record proved to be the extortion leverage.
Illuminate Education
2022An EdTech vendor breach exposed student data from New York City public schools and other districts.
Districts carried the notification duty for a platform they had procured but could not audit.
Accellion FTA, university sector
2021Exploitation of a legacy file transfer appliance used across the sector exposed student and employee records at multiple universities.
End-of-life infrastructure survives in education because replacing it is unfunded, not because anyone believes it is safe.
FREQUENTLY ASKED
When can testing safely happen in an academic year?+
Not during enrolment, examinations, or results publication. Those windows concentrate both system load and the consequences of disruption. We schedule active testing into vacation periods or quiet weeks and agree the calendar before scoping is finalised.
Do you test student data without exposing it?+
We prove access, we do not collect it. Showing that one student account can retrieve another's record needs the identifier and the response status, not the contents. Where synthetic accounts can be provisioned we use those exclusively.
Can you assess the EdTech tools departments bought directly?+
We can assess the access they hold: the OAuth scopes granted, the LTI configuration, what data flows to them, and what an attacker controlling that integration could reach in your platform. Testing the vendor's own product requires the vendor's authorisation, which we will not proceed without.
We are an EdTech platform, not an institution. Does this differ?+
Yes. As a platform you are the multi-tenant provider, so the emphasis moves to district and school isolation, roster synchronisation, and the security review your customers run before purchase. The threat model is closer to SaaS, with children's data raising the regulatory floor.
Find out what one student account can reach
Tell us which platforms hold your records and how identity federates across them. We will scope around your academic calendar.