Who is accountable when orphaned university accounts remain active?

Accountability usually sits with the identity, security, and application owners together, because orphaned accounts are created by process gaps rather than one isolated team. Frameworks such as NIST Cybersecurity Framework 2.0 expect clear ownership of access governance, so responsibility should be assigned before the next recertification cycle.

Why This Matters for Security Teams

Orphaned university accounts are not just an administrative cleanup issue. They are an access governance failure that can outlive the student, contractor, or staff relationship that created the account. Once an inactive identity remains enabled, it can be used for email access, cloud applications, research systems, and federated services long after the original business need has ended. That is why accountability should be explicit, not implied. The expectation in NIST Cybersecurity Framework 2.0 is that access governance has named ownership, measurable review, and repeatable remediation.

This is also where identity sprawl becomes operational risk. In higher education, accounts often originate in separate HR, registrar, IAM, departmental, and research workflows, so no single team sees the full lifecycle. NHIMG research on DeepSeek breach shows how quickly exposed access can become a security event when credentials or identities are left in circulation. In practice, many security teams discover orphaned account only after an audit, a phishing incident, or suspicious logins rather than through deliberate lifecycle control.

How It Works in Practice

Accountability for orphaned accounts usually sits across three functions: the identity team operates the lifecycle controls, the security team defines policy and exception handling, and the application or data owner validates whether the account still has a legitimate use. The key is to assign a primary owner for each stage of the identity lifecycle so that “someone else’s system” does not become “no one’s problem.” Current guidance suggests that recertification alone is not enough unless it is tied to authoritative source data and enforced deprovisioning.

A practical model is to map every account to a source of truth and a disposal trigger.

• When a student graduates, alumni status or a retention policy should define whether email and collaboration access stays active.

• When a researcher leaves, the department must confirm whether the account is tied to grant data, shared lab assets, or delegated administration.

• When a contractor ends, the sponsoring manager should confirm the business end date and the identity team should revoke access automatically.

That lifecycle approach is stronger when it is backed by a clear review cadence and audit evidence. NIST CSF 2.0 supports accountable access governance, while NHIMG’s DeepSeek breach coverage is a reminder that lingering access often becomes visible only after exposure, not before. Organisations should also align identity records with application ownership so recertification emails go to people who can actually approve removal, not just to a mailbox that forwards indefinitely. These controls tend to break down in federated university environments where departmental autonomy and multiple directory sources prevent a single authoritative offboarding event.

Common Variations and Edge Cases

Tighter access governance often increases administrative overhead, requiring organisations to balance stronger control against academic flexibility. That tradeoff is most visible in universities, where guest lecturers, visiting scholars, emeritus staff, and cross-institutional research partners may need time-limited access that looks “orphaned” unless the business context is documented. Best practice is evolving here, and there is no universal standard for how long some categories of access should remain available.

One common edge case is shared or delegated departmental administration. If a department owns the application but central IT owns the directory, accountability can be split unless both sides agree on who can approve exceptions and who must revoke them. Another edge case is alumni access, where continued use of a mailbox or portal may be intentional, but should be clearly distinguished from active employee status. The safest operational pattern is to treat every exception as time-bound, reviewed, and owned by a named sponsor rather than by a generic team queue.

Where universities use multiple identity stores, the real risk is not only missing deprovisioning but also inconsistent status between systems. That is why audit trails, source-of-truth mapping, and periodic reconciliation matter more than a single annual review.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• Who is accountable when access is left active after a role change or departure?
• Who is accountable when access remains active after a mass exodus?
• Who is accountable when segregation of duties fails in accounts receivable?