It fails when admissions, HR, alumni, guest access and research tools each maintain their own view of the same person. That creates duplicate records, orphaned access, inconsistent deprovisioning and unclear ownership. The control gap is not lack of identity data. It is lack of a single relationship model that governs transitions across systems.
Where identity governance breaks down in separate-system management
identity governance fails at the handoff points between systems, not inside any one system. When admissions, HR, alumni, guest access and research platforms each keep their own record, no single process can reliably answer who owns the person, which status is current, or when access should change. Governance becomes fragmented, and exceptions start to look normal.
The practical failure is not just duplicated data. It is that each application begins to act like its own source of truth for identity state, entitlement history and lifecycle events. That makes joiner, mover and leaver decisions slow, inconsistent and hard to audit, especially when an access decision depends on information held somewhere else.
At scale, this is why identity governance programs often stall even when the directory, IAM stack or workflow tooling looks healthy. The control objective is broader than synchronization. A foundational IAM and IGA model is needed so that ownership, authority and lifecycle rules are defined once and then applied across the systems that consume them.
Why separate system ownership creates duplicate records and orphaned access
Separate system ownership usually creates mismatched lifecycle events. One platform may still believe a person is active while another has already changed their role, sponsor or relationship to the institution. That is how duplicate identities, stale entitlements and orphaned access emerge, particularly where guest, contractor, student and alumni populations move across boundaries that were never designed to share a common identity model.
The deeper issue is that the institution is managing records, not relationships. If a person can exist as several local identities, then deprovisioning one account does not necessarily remove the others, and recertification becomes partial rather than complete. Joiner-Mover-Leaver controls work only when the transition logic is authoritative enough to follow the person across the systems they touch.
Institutions also underestimate the ownership problem. If no one is accountable for the cross-system identity, every team can truthfully say it handled its own system correctly while the institution still ends up with access that no longer matches the real-world relationship.
What a single relationship model changes for governance and review
A single relationship model changes the governance question from “what does this system know?” to “what relationship does this person have to the institution right now?” That is the right abstraction for admissions, HR, research collaboration, alumni engagement and external guest access, because it lets lifecycle rules follow status changes rather than local database conventions.
This also improves access review quality. Reviewers can assess a coherent picture of why access exists, whether the relationship still justifies it, and whether similar access is already active elsewhere. Access review design matters most when review evidence is tied to the underlying relationship, not just a list of entitlements pulled from one application.
Where the relationship model is weak, role design and segregation controls also become unreliable. Rules may be technically correct inside each system but still fail institutionally because they do not account for overlapping status, sponsor changes or delayed offboarding across domains. A role model built around stable relationships is more durable than one built from isolated application snapshots.
Risk and Threat Considerations
Separate-system governance creates exposure because access can survive the event that should have removed it. That increases the chance of dormant or excessive access, but it also makes misuse harder to spot because no single system has the full lifecycle picture. In institutional environments, the most dangerous failures are usually quiet ones: access that is still technically valid, yet no longer defensible.
Failure mechanism: A local system change does not propagate to the other systems that still carry the person’s identity, status or entitlements. The result is duplicate records, missed deprovisioning, lingering guest or alumni access, and inconsistent approval or recertification outcomes.
Impact: Unauthorised access persists beyond the valid relationship, audit evidence becomes fragmented, and investigators cannot confidently determine which system should have removed access first.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity transitions depend on timely credential lifecycle control across systems. |
| AC-2 — Account Management | Separate systems fail when accounts are not centrally governed through the lifecycle. | |
| AC-6 — Least Privilege | Orphaned access often persists as excessive privilege after relationship changes. | |
| Recommendation — Use IA-5 to revoke and rotate authenticators when a person's status changes. Use AC-2 to inventory, provision, review and disable accounts across all connected systems. Use AC-6 to limit access to the minimum required by the current relationship. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity Management | The issue is governance of identities across multiple systems and lifecycle states. |
| A.5.18 — Access Rights | Inconsistent removal and review of access rights is the core governance failure. | |
| Recommendation — Define one identity management process that governs status changes consistently across platforms. Review and remove access rights when the relationship no longer justifies them. | ||
Practitioner Guidance
What to prioritise: Establish one authoritative relationship model for the person, then map every consuming system to that model. The first governance win is not a bigger review queue, it is a clear decision on which events change status and which system owns those transitions.
What to verify: Check whether deprovisioning, role change and sponsor change are tested across system boundaries, not only within each application. If the test only confirms local account closure, the control is incomplete.
Practitioner takeaway: Identity governance fails most visibly where ownership is local but lifecycle is enterprise-wide; the fix is to govern the relationship once, then force every system to inherit that decision.
Related resources from NHI Mgmt Group
- Why is it important to integrate identity and data governance?
- What breaks when organisations manage endpoint privilege separately from cloud and workload identity governance?
- Should organisations manage cross-border transfers separately from identity governance?
- Where does identity governance fail when IAM and PACS are run separately?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org