Join our Newsletter — 33% off our NHI Course

Why do universities struggle with duplicate accounts and stale access?

The problem usually starts upstream. HR, SIS, and credentialing systems often hold inconsistent identity data, so downstream tools create duplicate records or fail to remove access when affiliations change. In a multi-role environment, that becomes a governance issue because each stale account extends the period during which access can be misused or simply remain unnecessary.

Why duplicate records keep reappearing

Universities rarely have one authoritative identity source for the full student, employee, contractor, and alumnus population. Admissions, HR, SIS, research systems, and departmental tools each create records at different times, with different data quality and naming conventions. When those systems do not reconcile cleanly, the same person can be issued multiple accounts or reintroduced under a slightly different profile.

That is why this is usually a data coordination problem before it becomes a security problem. One system may know a person by legal name, another by preferred name, and a third by an email alias or employee number. If matching rules are weak, duplicate identities become normal, and every duplicate increases the number of places where access must later be corrected.

For universities, the control challenge is not just creating a clean record once, but sustaining identity matching across lifecycle events such as enrollment, employment changes, leave, graduation, and rehire. NHI Lifecycle Management Guide is useful here because it frames provisioning, visibility, and offboarding as one continuous governance problem rather than separate tasks.

Why stale access survives affiliation changes

Access often lingers because universities operate with overlapping roles and long tail exceptions. A person can be a student employee, teaching assistant, researcher, lab member, and alumni mentor at different points, so access decisions are not a simple join or leave event. If each role is managed in a different system, revocation can fail in one place even when it succeeds in another.

Stale access also persists when ownership is unclear. The business owner of an account may think IT will remove it, while IT assumes the department will request revocation. That gap is especially common in shared services, legacy applications, and research environments where accounts are created quickly to support a semester, grant, or project and then never reviewed again.

Identity posture programs help because they surface dormant accounts, standing access, and configuration drift before those conditions become routine. Identity Security Posture Management (ISPM) Guide aligns well with that need because it focuses on the findings that expose stale accounts and weak governance rather than treating them as isolated tickets.

Why this becomes a governance problem, not just an admin problem

In higher education, duplicate accounts and stale access matter because they widen the period during which access can be misused, forgotten, or inherited by the wrong person. The issue is not only whether a credential still works, but whether the institution can prove who owns the account, why it exists, and when it should expire.

This becomes more serious where privileged or emergency access is involved. Universities need a path for break-glass access when critical systems fail, but they also need to ensure those accounts are monitored and removed from everyday use. Break-Glass and Emergency Access Account Guide and Privileged Access Management Guide both reinforce the point that exception access must be deliberate, time bound, and auditable.

Governance breaks down fastest when access recertification is treated as a periodic checkbox instead of a lifecycle control. Top 10 NHI Issues is a helpful reference for the broader pattern of stale accounts, shared access, and excess privilege, even though the underlying lesson applies just as much to human university accounts.

Risk and Threat Considerations

Duplicate and stale accounts expand the attack surface because they create extra identities to monitor, extra credentials to protect, and extra paths to unauthorized access. In a university, that can mean a former student still reaching licensed resources, a departed staff member still using email or file access, or an old admin account surviving long after the role changed.

Failure mechanism: weak identity matching, delayed deprovisioning, and unclear account ownership allow access to outlive the affiliation that justified it.

Impact: unnecessary access persists, misuse becomes harder to detect, and a compromised stale account can provide an attacker with valid access that appears routine rather than suspicious.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
CIS Controls v8 CIS-5 — Account Management Duplicate and stale accounts are an account governance failure.
Recommendation — Enforce account lifecycle review and disable orphaned access quickly.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Stale access often persists through unmanaged credentials and tokens.
AC-2 — Account Management University duplicate accounts and stale access are fundamentally account lifecycle issues.
Recommendation — Rotate and retire authenticators when affiliations change. Maintain authoritative account inventory and remove unused accounts promptly.
ISO/IEC 27001:2022 A.5.16 — Identity management Identity management controls are directly implicated by duplicate and stale accounts.
A.5.18 — Access rights Stale access is an access-rights review and removal problem.
Recommendation — Define authoritative identity sources and reconcile them across systems. Review and revoke access rights when roles or affiliations change.

Practitioner Guidance

What to verify: confirm that each account traces to one current person, role, or service owner, and that every authoritative source of identity is reconciled on a documented schedule. If the same individual can exist in more than one system, define which attributes must match before an account is considered unique.

Decision rule: if an account cannot be tied to a current affiliation or business purpose, treat it as a revocation candidate, not as an exception to keep alive. For privileged accounts, require a separate approval path and a shorter review interval than for ordinary access.

Practitioner takeaway: universities reduce duplicate accounts and stale access by tightening lifecycle ownership across systems, not by relying on end users to notice when their access should disappear.