Skip to main content
Identity Authority
Category: Identity Lifecycle

Authoritative Source

Also known as: Authoritative Identity Source, System of Record
Simply put

An authoritative source is the trusted system that holds accurate, verified information about a person or thing and is treated as the definitive answer for that data. For example, an organization's HR system is often the authoritative source for who its employees are. Other systems rely on this source rather than making their own independent determination.

Formal definition

An authoritative source is the entity or system designated as the trusted origin of record for specific identity attributes or entitlement data, such that dependent systems accept its values with high confidence. In NIST terms, it is an entity that has access to, or verified copies of, accurate information from an issuing source so that a credential service provider (CSP) can rely on its accuracy. In IGA deployments it typically drives identity lifecycle processes: the HR system commonly serves as the authoritative source for workforce identities, feeding provisioning, deprovisioning, and access decisions downstream. Authoritativeness is scoped per attribute or data domain rather than absolute, so a given deployment may designate different authoritative sources for different attributes (for example, HR for employment status and a separate directory for contact data). This is a governance and data-integrity concept and does not by itself perform runtime authentication or authorization enforcement.

Why it matters

The authoritative source is the anchor of trust for identity data across an organization. When downstream systems accept a source's values with high confidence rather than making independent determinations, the accuracy of that source directly shapes the correctness of provisioning, access decisions, and eventual deprovisioning. If the designated authoritative source is wrong, stale, or compromised, those errors propagate to every dependent system, which is why establishing clear authoritative sources is foundational to sound identity governance.

A common and consequential example is the reliance on the HR system as the authoritative source for workforce identities. When HR records an employee's departure or role change, that event ideally triggers deprovisioning or entitlement adjustments downstream. Where an authoritative source is not clearly designated or its feed is delayed, orphaned accounts and lingering access can persist, expanding the attack surface and complicating access certification. Because authoritativeness is scoped per attribute rather than absolute, ambiguity about which system is definitive for a given attribute can produce conflicting data and reconciliation problems.

It is important to note that this is a governance and data-integrity concept. Designating an authoritative source improves the trustworthiness of the identity data feeding access processes, but it does not by itself perform runtime authentication or authorization enforcement. Those functions remain the responsibility of separate enforcement components, and treating an authoritative source as if it enforced access at runtime would misstate its role.

Who it's relevant to

Identity Governance Leads
Designating authoritative sources per attribute is a core governance decision. It determines which system's data drives lifecycle processes such as provisioning, deprovisioning, and access certification, and it establishes accountability for data accuracy across dependent systems.
IAM Engineers
Engineers implementing joiner-mover-leaver flows typically configure the HR system or another designated source as the trigger for downstream provisioning and deprovisioning. Understanding that authoritativeness is scoped per attribute helps avoid conflicts when multiple sources hold overlapping data.
Compliance and Audit Officers
Access reviews and certifications rely on the assumption that identity data originates from a trusted source of record. Clear designation of authoritative sources supports the integrity of audit evidence and helps demonstrate that access decisions trace back to accurate, verified information.
Security Architects
Architects define which systems are treated as definitive for identity data and how dependent systems consume it. Because a compromised or stale authoritative source propagates errors downstream, its selection and protection are architectural decisions with broad blast-radius implications.

Inside Authoritative Source

System of Record (SoR)
The designated authoritative system that owns a given identity attribute or set of attributes. For example, an HR system is typically the authoritative source for employee identity data such as legal name, employment status, and department, while a directory may be authoritative for account credentials.
Attribute Ownership Scope
The specific attributes for which a source is considered authoritative. A system can be authoritative for some attributes and non-authoritative for others; ownership is defined per attribute rather than per identity as a whole in most deployments.
Provisioning Trigger
The role of the authoritative source in initiating identity lifecycle events. Changes in the authoritative source (a joiner, mover, or leaver event) typically drive downstream provisioning and deprovisioning through IGA processes, often via connectors or SCIM.
Data Flow Direction
The authoritative source is the origin of truth from which attributes flow outward to consuming systems and directories. Consuming systems should not overwrite authoritative attributes back into the source unless explicitly designated for reconciliation.
Precedence and Conflict Resolution
Rules that determine which source wins when multiple systems hold overlapping attributes. An authoritative-source model defines precedence so that conflicting values are resolved in favor of the designated owner for that attribute.
Reconciliation and Synchronization
The processes that keep consuming systems aligned with the authoritative source. This includes detecting drift, correcting out-of-band changes, and, depending on configuration, flagging discrepancies for governance review.

Common questions

Answers to the questions practitioners most commonly ask about Authoritative Source.

Is the authoritative source the same as the identity provider (IdP)?
No. These are distinct roles that are often confused. An authoritative source is the system designated as the system of record for a particular set of identity data or attributes, for example, an HR system that is authoritative for employment status, or a directory that is authoritative for group membership. An identity provider is a runtime component that asserts a principal's authenticated identity to relying parties, typically via a federation protocol such as SAML 2.0 or OpenID Connect. The IdP may consume data that originates from one or more authoritative sources, but being authoritative for an attribute is a governance and data-ownership concern, whereas issuing authentication assertions is a runtime concern. A single system can play both roles, but they should not be treated as interchangeable.
Can a single system be the authoritative source for everything about an identity?
In most deployments, no, authority is typically scoped per attribute or per data domain rather than granted wholesale over an identity. An HR system may be authoritative for a worker's legal name, employment status, and department, while a separate system is authoritative for entitlements, and yet another for contact details or credentials. Treating one system as authoritative for all attributes tends to break down because different attributes are owned and maintained by different business functions. Defining authority at the attribute level, rather than at the whole-identity level, is generally the more accurate and maintainable approach, though the exact partitioning depends on organizational structure and data governance decisions.
How do you designate a system as an authoritative source during an identity integration?
Designation is a governance decision that is then reflected in configuration. Typically you document which system owns which attributes, define the direction of data flow so that the authoritative source feeds downstream systems rather than the reverse, and configure synchronization or provisioning (for example via SCIM or a directory sync process) to propagate changes outward. Downstream systems should generally be configured to treat the synchronized attributes as read-only for the domains where another system is authoritative, to prevent conflicting updates. The specifics vary by vendor tooling and connector capabilities.
What happens when two systems each claim authority over the same attribute?
Conflicting authority is a common source of data integrity problems and usually requires an explicit reconciliation strategy. Depending on configuration, options include designating a single precedence order so one source always wins for that attribute, splitting authority so each system owns a distinct subset of records, or introducing a mastering layer that applies survivorship rules. The appropriate resolution is a governance decision rather than a purely technical one, and it should be documented so provisioning flows and access reviews reference a consistent source of truth.
How does an authoritative source relate to the joiner-mover-leaver lifecycle?
In many identity governance and administration (IGA) deployments, the authoritative source acts as the trigger for lifecycle events. A new record appearing in an authoritative HR source can initiate joiner provisioning, an attribute change such as a department transfer can drive mover workflows and entitlement adjustments, and a status change to terminated can trigger leaver deprovisioning. Because these events drive provisioning and downstream access, the timeliness and accuracy of the authoritative source directly affect how quickly access is granted or revoked. Note that this describes lifecycle administration, not runtime enforcement of access.
How should access certifications and reviews treat data from an authoritative source?
During access reviews and certification campaigns, the authoritative source is typically used as the reference for validating attributes such as employment status, manager relationships, and organizational assignment that reviewers rely on to make decisions. If the authoritative source is stale or incomplete, reviewers may certify access based on incorrect context, which undermines the review. For this reason, many governance programs verify that authoritative data is current before running campaigns and flag records that cannot be traced back to an authoritative source. This is a governance activity distinct from runtime authorization decisions made by a policy decision point.

Common misconceptions

A single system is the authoritative source for an entire identity.
Authority is typically scoped per attribute, not per identity. In most deployments an HR system is authoritative for employment attributes, a directory for account state, and yet another system for entitlements. Treating one system as authoritative for everything usually misrepresents how the data actually flows.
Being an authoritative source is a runtime access enforcement function.
An authoritative source is an identity governance and administration (IGA) and data-management concern that feeds provisioning and reconciliation. It is distinct from runtime enforcement components such as a PDP, PEP, or PIP that evaluate access at request time, although a PIP may retrieve attributes that ultimately originated from an authoritative source.
The authoritative source and the directory (for example an LDAP directory) are the same thing.
A directory is often a consuming or downstream system that receives attributes from an authoritative source such as an HR system, though a directory can itself be authoritative for the attributes it owns (for example account credentials). The two roles should be defined explicitly rather than assumed to be identical.

Best practices

Define authority at the attribute level, documenting which system owns each attribute rather than declaring a single system authoritative for all identity data.
Establish explicit precedence and conflict-resolution rules so that overlapping attributes across systems have a deterministic winner during reconciliation.
Drive joiner, mover, and leaver provisioning from the designated authoritative source to ensure lifecycle events originate from a consistent point of truth.
Implement reconciliation to detect and remediate drift between the authoritative source and consuming systems, and route unexpected discrepancies to governance review where appropriate.
Keep authoritative-source data management separate from runtime enforcement, ensuring that any attributes consumed by a PIP or policy engine trace back to a clearly identified source of truth.
Restrict write-back into authoritative attributes so consuming systems and directories cannot silently overwrite the source unless a reconciliation path is explicitly designed for it.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps