Source of Authority

What the source of authority means in identity governance

A source of authority is the record system that defines which identity data is trusted for provisioning, deprovisioning and access decisions. In practice, it answers a governance question: when directories, HR platforms, cloud IAM systems or application stores disagree, which one is the trusted source for state and entitlement changes?

This concept matters because identity state is often distributed across multiple systems. The authoritative record may hold employment status, role, manager, group membership or lifecycle status, while another platform issues the credential or session used at runtime. If the source of authority is unclear, downstream systems can make inconsistent decisions.

Why source of authority matters in hybrid environments

Hybrid identity environments frequently split “who the person or workload is” from “where the access token or credential lives.” That separation is normal, but it creates a control dependency: downstream platforms must know which upstream system wins when attributes conflict. Without that rule, automation can provision the wrong access, fail to remove access, or preserve stale entitlements.

For practitioners, the key issue is not just technical sync, but governance. The trusted source should be explicit for each identity attribute and lifecycle event, especially when multiple business systems can create, modify or terminate records. The more systems that can write identity state, the more important it becomes to define ownership and precedence.

How authoritative identity state is used for access decisions

Source of authority influences the full identity lifecycle: joining, moving, changing role, suspension and departure. Provisioning workflows, recertification processes and access reviews all depend on knowing which record is authoritative for each attribute. If role data comes from one system and employment status from another, the organisation must decide which field drives the decision and when manual review is required.

The same logic applies to non-human identities that are governed as part of the identity estate, such as service accounts, workload identities or automation credentials. The system that owns the lifecycle of those identities should be unambiguous, because access decisions are only as reliable as the state they consume.

In well-run environments, the source of authority is paired with clear attribute ownership, reconciliation rules and exception handling. That prevents downstream tools from treating stale cache data, duplicated identity records or partially synchronised profiles as if they were canonical.

Common failure modes and operational consequences

The most common failure mode is split-brain identity state, where two systems each believe they are authoritative. Another is delayed synchronisation, where the trusted record changes but the downstream access platform has not yet converged. A third is overbroad trust, where too many systems can alter high-impact attributes without a clear control boundary.

Those failures can lead to excessive access, missed deprovisioning, duplicate accounts, broken joiner-mover-leaver workflows and audit gaps. They can also create trust erosion during incident response, because responders may not know which record to rely on when they need a rapid, defensible answer.

Risk and Threat Considerations

Unclear authority over identity records creates direct exposure because access systems may act on stale, conflicting or attacker-modified data. That can produce privilege retention after a role change, account survival after termination, or incorrect trust in a compromised directory or lifecycle source.

Failure mechanism: An attacker or internal misconfiguration can exploit ambiguity between competing record systems, then let downstream provisioning or access controls follow the wrong “trusted” source of state.

Impact: The result can be unauthorised access, delayed deprovisioning, poisoned identity data, and a weak audit trail that makes it harder to prove which system should have driven the decision.

Related resources from NHI Mgmt Group

• How should security teams choose between an open-source certificate authority and an enterprise certificate authority?
• Why can an open-source certificate authority create operational risk as certificate programs grow?
• What do teams get wrong when they assume open source is always cheaper for certificate authority management?
• What is the difference between an open-source certificate authority and an enterprise certificate authority?