Teams should assign each identity attribute and lifecycle event to one authoritative system, then document how ERP and SIS records interact when roles overlap. The goal is not to centralise every record in one platform, but to prevent conflicting truths from driving provisioning, deprovisioning, and audit errors.
How to choose the source of authority without creating a single master record
The right answer in higher education is usually attribute-based, not platform-based. A student information system, HR system, ERP, or departmental system may each be authoritative for different facts, such as status, affiliation, job role, or financial relationship. The decision is to define which system owns each attribute and event, then make downstream identity provisioning follow that rule consistently.
That approach avoids the common failure mode where teams ask, “Which system owns the person?” when the real problem is that no single system owns every identity fact. Universities often have overlapping populations, students who also work for the institution, staff who become students, and affiliates with temporary access. The authoritative source should match the business meaning of the data, not the convenience of the integration.
For identity data hygiene and source-of-truth design, Identity Data Quality and Identity Fabric Guide is the strongest reference point. It is also useful to compare how source decisions affect broader university identity operations in the Education Identity Security Guide.
What “authoritative” should mean for identity attributes and lifecycle events
Authority should be assigned to the system that creates, validates, or officially governs a specific fact. For example, SIS may be authoritative for enrollment and academic status, HR for employment status, and ERP for compensation or organizational assignment. When those facts drive access, the identity platform should consume them as trusted inputs rather than re-deciding them locally.
Lifecycle events need the same discipline. A hire, termination, matriculation, leave of absence, or role change should have one primary source, even if multiple systems observe the person. If two systems can independently initiate the same event, provisioning logic will eventually diverge, especially during edge cases like adjunct faculty, graduate assistants, or dual appointments.
This is why universities should document overlap rules explicitly, not just integration mappings. A person may be both student and employee, but that does not mean every field can be merged. The authoritative source for each attribute should be clear enough that operators can answer who wins when records conflict, which event triggers access changes, and which system is used to resolve disputes.
That operating model is well covered by the higher education identity guidance, especially where student, staff, and federated access intersect. For a deeper treatment of correlation, authoritative sources, and identity data quality, the Identity Data Quality and Identity Fabric Guide is the more precise destination.
How to keep provisioning, deprovisioning, and audits from drifting
The practical test is whether the chosen source can drive clean downstream decisions. If authoritative status is ambiguous, provisioning tends to become too permissive, deprovisioning becomes delayed, and audit trails become hard to defend. In higher education, those errors are amplified by term-based churn, temporary affiliations, and shared services spanning academics, research, and administration.
The control objective is to prevent conflicting truths from being treated as equally valid. Identity governance should consume one authoritative signal per attribute or lifecycle event, then reconcile exceptions through documented business rules. That matters most for access recertification, joiner-mover-leaver processing, and orphan detection, because those are the places where a bad source decision becomes a visible security problem.
When identity authority is tied to a lifecycle control, treat exceptions as operational debt, not a normal state. If a downstream application has to override the authoritative source repeatedly, the source model is probably wrong or too coarse. The safer pattern is to fix the source mapping and keep the exception path narrow, reviewed, and time-bound.
For lifecycle control and downstream governance, the NHI Lifecycle Management Guide offers a useful lifecycle lens, while the Identity Security Programme Guide helps teams set ownership and governance around the decision.
Risk and Threat Considerations
Conflicting authoritative sources create real security exposure because provisioning systems tend to trust whichever record appears most current, most complete, or easiest to integrate. In higher education, that can leave stale access in place after a role change, create duplicate entitlements across student and staff identities, or make audit evidence inconsistent when a record dispute arises.
Failure mechanism: Two systems assert different truths about the same person, then downstream automation applies both or chooses the wrong one. That usually produces excessive access, missed deprovisioning, or a weak audit trail that cannot explain why access was granted or removed.
Impact: The institution can accumulate entitlement drift, expose regulated student or employee data, and lose confidence in recertification, incident response, and compliance reporting. The operational risk grows quickly when identity data is reused across many applications or when temporary academic roles change faster than integrations are updated.
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 source decisions affect credential lifecycle and downstream account handling. |
| AC-2 — Account Management | Authoritative identity data drives account creation, modification, and termination. | |
| AU-6 — Audit Review, Analysis, and Reporting | Conflicting identity truth breaks audit evidence for access decisions. | |
| Recommendation — Map authoritative-source changes into credential updates and revocation workflows. Tie account provisioning and deprovisioning to the designated source record. Retain traceable source-of-authority evidence for identity changes and exceptions. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | This is directly about governing identity information and authoritative records. |
| A.5.18 — Access rights | Access decisions depend on correct identity authority and timely updates. | |
| Recommendation — Define which system owns each identity attribute and lifecycle event. Reconcile access rights whenever the authoritative source changes. | ||
Practitioner Guidance
What to prioritise: Define authoritative ownership at the attribute and lifecycle-event level first, then map each downstream consumer to that rule. The first decision should be who owns status, affiliation, and role transitions, because those fields usually drive the highest-risk access changes.
What to verify: Check whether every overlapping population has an explicit tie-break rule. A good test is whether two administrators would independently reach the same answer about who is active, what role applies, and which event triggers removal or elevation of access.
Common mistake: Treating ERP or SIS as the single source of truth for the whole identity when each system is only authoritative for part of the person record. That shortcut usually works in small environments and fails as soon as dual roles, temporary appointments, or federated services are introduced.
Practitioner takeaway: Authority should be scoped to the business fact, not the person as a whole. If your teams cannot explain which system wins for each overlap case, the identity model is still too vague to trust in production.