The identity shape of a school or university
The defining feature is volume and turnover. Everything else follows from it:
- The population churns constantly. A new intake every year, leavers every summer, and research and teaching staff who move between institutions. At that rate, accounts go stale and access outlives the person.
- The application estate is enormous. A virtual learning environment, a student records system, email, library systems, dozens of SaaS teaching and research tools each department chose for itself. Every one is another login.
- Machines are shared. Lab and library workstations are used by whoever sits down. A password typed there is typed on a machine hundreds of people touch.
- The help desk is overwhelmed by one thing. Password resets and lockouts, concentrated brutally in the first weeks of term, on a team that can’t scale to meet them.
Nowhere else is one identity team responsible for so many accounts, changing so fast, across so many systems.
Where the exposure concentrates
Attackers know the shape too. Student and staff credentials are phished at scale because they open email, research systems and — through reuse — a great deal else. A single set of working credentials can reach a virtual learning environment, a mailbox, and whatever those were reused on.
The harder lifecycle problem is not always whether the account exists. It is whether access still matches the person’s role — student, researcher, staff member or alumni — because in education those roles change while the person stays.
And the research side raises the stakes: universities hold data that is genuinely worth stealing, and the accounts that reach it are held by people who move institutions and reuse passwords like everyone else.
What the obligations are
Mirket doesn’t confer compliance — no product does. These are the obligations an institution is measured against, read from the identity side.
| Obligation | What it expects of access |
|---|---|
| GDPR — Art. 32 | Appropriate technical measures for access to personal data — student records, staff data, research subjects — including how access is granted, reviewed and removed |
| NIS2 | Research organisations and certain education-sector entities may fall within national NIS2 scope. MFA, access control and incident detection support the identity-security measures required by covered organisations |
| Cyber Essentials | Strong access control and MFA are core controls for institutions seeking certification and organisations working with UK public-sector requirements |
Where to start
1. Put connected applications behind central authentication
Single sign-on federates the learning platform, email, student records and SaaS applications to the institution’s central identity. Disable that identity and federated access stops across connected applications, instead of relying on separate passwords and login paths at each one.
2. Take password resets off the help desk
Self-service password reset and account unlock absorb the first-weeks-of-term reset spike without requiring the help desk to scale with the student population. The user proves who they are with the second factor they already carry, so the check is stronger than a phone call as well as faster.
3. Make MFA easy enough to use at education scale
With authentication centralised through SSO, MFA can protect connected applications from the same authentication layer instead of being deployed separately application by application. Passwordless authentication further reduces the passwords students forget, reuse and enter into the wrong login page.
The controls have to be pleasant, because a user base this size will route around anything that isn’t.
4. Adapt authentication to a mobile population
Students, researchers and staff legitimately authenticate from different devices, networks and countries. Adaptive authentication can keep ordinary access simple while challenging sign-ins whose context is genuinely unusual.
5. Protect shared lab and library machines
Shared workstations are another authentication surface, and the browser is not the only place a password gets typed. Mirket can require MFA for Windows logon and RDP, extending identity verification beyond browser applications to the operating system itself.
What changes
| Today | With Mirket |
|---|---|
| Every application becomes another login | Connected applications authenticate through the institution’s central identity |
| Leavers may retain separate application login paths | Disable the central identity and federated access stops |
| The help desk drowns in resets at the start of term | Users reset passwords and unlock accounts themselves |
| Passwords are reused across applications and shared machines | Passwordless authentication reduces password exposure where supported |
| Shared lab and library PCs rely on password-only Windows logon | Windows logon can require MFA |
| Every login gets the same authentication friction | Adaptive policy raises authentication only when context deserves it |
Related
Solutions — Self-Service Password Reset · Passwordless Authentication · Adaptive Authentication · Operating System Logon MFA · On-Premise SSO
Products — Single Sign-On · Multi-Factor Authentication · Secure Self-Service