Identity security for education

Schools and universities draw ransomware for simple reasons: directories with tens of thousands of identities, constant turnover, small security teams, and service accounts set up when the SIS went in back in 2012 and never reviewed since. An attacker needs one compromised credential and a graph full of over-permissioned paths to climb.

Why education identity environments are uniquely vulnerable

A large university might have 80,000 identities across students, faculty, staff, researchers, visiting scholars and contractors. Each semester brings a wave of new accounts and a wave that should be removed but often isn't. A student worker gets admin access for a campus job, graduates, and the access stays. A research group's shared service account outlives its grant with the same permissions.

K-12 districts have the same problems at a different scale: staff accounts shared across buildings, service accounts for student information systems, learning platforms and cafeteria point-of-sale, and IT teams of three or four running thousands of objects across sites. Nobody has time for manual access reviews with 200 password reset tickets at the start of the school year.

FERPA and student data protection

The Family Educational Rights and Privacy Act (FERPA) protects the privacy of student education records. Institutions that receive federal funding must restrict access to student data to school officials with a legitimate educational interest. That means different things for a registrar, a financial aid counselor and a research assistant, but in the directory they often end up in the same groups.

FERPA doesn't prescribe technical controls the way HIPAA does, but the Department of Education's guidance makes clear that institutions need reasonable methods to control access to education records. When a departed TA's account still reaches the SIS database through a nested group three levels deep, "we didn't know" isn't a defensible position.

How GraphnAI addresses education identity challenges

Find the stale accounts that pile up every semester

Stale detection has a threshold for each account type. Users go stale after 90 days, which covers the gap between graduation and cleanup. Service accounts go stale after 180 days, which catches grant-funded compute accounts that outlived their purpose. Computers go stale after 30. The inventory shows each stale account's permissions and groups, so you can tell the harmless ones from the ones that still reach student records. Change the threshold for a semester-end audit.

Quantify over-permission across diverse populations

A Computer Science faculty member legitimately needs different access from one in English. Peer-group analysis compares identities within the same domain, department and title, so a CS faculty member is a finding only when they hold far more than other CS faculty. It relies on the department and title fields in your directory, so fill them in.

See the attack paths through your graph before an attacker does

Critical junction analysis ranks the accounts where many attack paths meet on the way to your Critical assets, such as your most privileged groups and roles. On a campus these are often the memberships and delegation chains that connect student accounts to administrative ones. Fix the junctions first and you shrink what one compromised account can reach.

Detect credential attacks in the busy weeks

The hard weeks are the start of semester, when thousands of accounts are provisioned and resets spike, and summer break, when fewer staff means slower response. The detection engine raises alerts for brute force against administrative accounts, password spray across student populations, and Kerberoasting against your SIS and LMS service accounts. Each alert shows the identity's type, whether it's Tier 0 and how many attack paths lead from it to Tier 0. It needs a collector that forwards your domain controllers' Windows security events.

Remediate safely with a team of three, using Select Fire™

Small teams can't afford to break something and spend a week fixing it. Select Fire shows who loses access before anything runs. Safe mode writes a script that reports what it would do first, and Semi-Auto runs each change after you authorize it. Full-Auto is off until an admin arms it, and then runs only the reversible actions you allow, such as disabling an account, never unattended on Tier 0 or Tier 1 targets. If sign-in failures spike afterwards, it undoes the change or hands it to a person.