Client
A research-intensive European university with tens of thousands of current students and staff, and a far larger population of alumni and former employees
Sector
Higher Education & Identity
Engagement
Directory data minimisation, privileged access redesign and export monitoring - two-quarter programme.
What the client needed
The university's identity system had been built to answer one question, who is this person and what may they open, and over twenty years it had become the place everything about a person was kept. Home addresses, national identifiers, emergency contacts and employment details sat beside the login records of people who had left a decade earlier. Recent breaches at other institutions, including a Danish technical university whose directory was downloaded using stolen staff credentials, prompted the chief information officer to ask a plain question: if one valid staff login were stolen tomorrow, how much could it read, and who would notice?
How we worked
- Catalogued every attribute in the directory and sat down with registry, HR, estates and research offices to record which process needed each one. About a third had no current owner.
- Moved national identifiers and next-of-kin details into a separate vault reachable only by the two services that genuinely need them, and replaced the identifier in the directory with a reference.
- Set deletion rules that apply to every personal field for former users, including identifiers, with a documented exception route for alumni records and legal holds.
- Separated directory administration and bulk-export rights from everyday staff accounts, with hardware-key sign-in and time-limited elevation.
- Added rate limits and alerting on volume of reads per account, tested by a red team using an ordinary staff login, and wired the alerts to a staffed channel.
- Drafted a notification plan covering people who have left and no longer have a working university address, with legal review in advance.
Measured results
All figures verified with the client. Record counts and institution name withheld in line with our standard confidentiality terms.
- The directory now holds a fraction of the personal attributes it did before, and every remaining field has a named owner and a stated purpose.
- National identifiers no longer sit in the main directory. A stolen everyday staff login cannot read them.
- The red team's attempt to export a large block of records with a normal staff account was stopped by the rate limit, and the alert reached the security desk in under ten minutes.
- Former users' personal data now follows a single deletion schedule, and the first clear-out removed several hundred thousand obsolete attribute values.
- The notification plan has been tested once in a tabletop exercise with legal, communications and the data protection officer.
"We had spent years asking whether people could get into the system. We had hardly asked what was in it. Taking things out turned out to be the strongest control we added, and the cheapest."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
Every department had a reason to keep its field. Registry wanted national identifiers to match returning students, HR wanted next-of-kin details for emergencies, and alumni relations wanted addresses forever. None of them was wrong, and none of them needed those values in the directory that every application queries. The first month went on separating "needed by a person in an emergency" from "convenient for an application", and on getting the data protection officer and the heads of those functions into one room to agree it.
Why we removed data before adding detection
Alerting on large reads is worth having, but it only catches an attacker who is slower than your response. Taking the sensitive fields out of reach changes what a successful theft is worth. We did both, in that order, and the order mattered: the volume alerts were tuned against a much smaller and quieter dataset, so the thresholds could be low without drowning the desk in false positives.
Where the real exposure was
We expected the weakness to be the directory software. It was the population of accounts that could read it. Dozens of departmental service accounts and long-standing staff logins had broad read rights granted for projects that had finished years earlier. Trimming those did more for risk than any product change, and it cost almost nothing.
Lessons learned
Retention rules that skip identifiers are the usual gap, because someone always has a reason to keep them. Make that reason explicit and move the field somewhere narrower, rather than leaving it in the shared place. Test alerts with a real, ordinary login, not an administrator's. And plan how to reach people who have left, because the email address you held for them stops working long before the risk does.
If your identity directory has grown into a general record of people and you are unsure what a stolen login could read, we would be glad to talk. Email sales@halfteck.com.