A source of truth can simply be the system that currently holds the data, while an authoritative identity source is the system trusted to drive identity decisions. The distinction matters because only the authoritative source should govern provisioning, revocation, and recertification for a given identity class.
What makes a source of truth different from an authoritative identity source?
A source of truth is the system that stores or presents the current record. An authoritative identity source is the system trusted to decide identity state for a given class of identities. In practice, that means one system may hold the latest data, while another must govern provisioning, revocation, and recertification decisions.
Why the distinction matters in identity governance
The difference is operational, not semantic. A directory, HR platform, ticketing system, or CMDB can all be a source of truth for some data element, but only the authoritative identity source should drive lifecycle actions for the identity attributes it owns. Treating every current record as authoritative creates duplicate ownership, conflicting updates, and bad access decisions.
That distinction is easiest to see when identity data is fragmented. HR may own employment status, a contractor system may own engagement dates, and an application registry may own technical attributes. NHIMG’s Identity Data Quality and Identity Fabric Guide explains why authoritative sources, correlation, and attribute quality have to be designed explicitly rather than assumed from whichever system happens to be freshest.
For identity controls, the practical question is not “where is the data?” but “which system gets to decide?” If the answer is unclear, provisioning and deprovisioning decisions become inconsistent, and downstream systems start compensating with local exceptions that are hard to audit.
How authoritative identity sources should be used
An authoritative identity source should own the specific attributes and decisions it is responsible for, such as start date, end date, manager, worker status, role assignment, or account eligibility. Other systems can reference those values, cache them, or enrich them, but they should not override the authority boundary without an explicit governance decision.
That is why joiner, mover, and leaver workflows matter. NHIMG’s Joiner-Mover-Leaver (JML) Guide ties authority to lifecycle events, which is the point where identity data turns into provisioning, access removal, and recertification action. If the authoritative source is wrong or delayed, the entire lifecycle chain inherits that error.
The same pattern applies beyond people. NHIMG’s NHI Lifecycle Management Guide shows the analogous problem for non-human identities, where ownership, rotation, and offboarding must follow the system that actually governs the identity, not merely the system that stores a copy of its metadata.
How to tell which system is authoritative
The authoritative identity source is usually defined by policy and ownership, not by technical convenience. A good test is whether the system is trusted to create, change, suspend, or retire identity records for that class of subject. If multiple systems can do that independently, you do not have a single authoritative source yet, you have a collision waiting to happen.
Another useful test is whether the system can support audit and recertification decisions without manual reconciliation. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives links authority to governance evidence, which is the right lens for deciding whether a source is merely informative or actually decision-grade.
When the answer is “we use that system because it is the cleanest dataset,” be careful. Clean data is helpful, but authority is stronger than cleanliness. A system can be stale and still authoritative if it is the approved decision source, and a system can be current and still non-authoritative if it only reflects data that another system controls.
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-2 — Identification and Authentication (Organizational Users) | Identity authority affects who can be trusted for access decisions and lifecycle actions. |
| IA-9 — Service Identification and Authentication | Authoritative sources matter for non-human identities that authenticate to systems and APIs. | |
| AC-2 — Account Management | The question turns on which system drives provisioning, revocation, and recertification. | |
| Recommendation — Align identity decisions to the approved authoritative source for organizational users. Use the authoritative identity source to govern service and workload credentials. Base account lifecycle actions on the authoritative identity source. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity authority determines which system governs identity records and lifecycle events. |
| A.5.18 — Access rights | The distinction affects which source should drive access grants and removals. | |
| Recommendation — Assign each identity class a single approved authority for record changes. Tie access-right changes to the authoritative identity source rather than to replica data. | ||
Practitioner Guidance
What to prioritise: Separate attribute ownership from record storage. For each identity class, document which system is authoritative for status, attributes, and lifecycle actions, then make every downstream system consume that decision rather than infer it.
What to verify: Confirm that provisioning, revocation, and recertification are driven from the approved authority, not from whichever source is easiest to query. If a system can change access but cannot prove why it was trusted to do so, the model is too loose.
Common mistake: Teams often call the freshest system the source of truth and stop there. That works for reporting, but identity governance needs a stronger rule: freshness matters, yet authority determines who may decide.
Practitioner takeaway: Use source of truth for data accuracy, but use authoritative identity source for access decisions and lifecycle control, because only the latter defines who should be allowed to govern the identity.
Related resources from NHI Mgmt Group
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between aggregated identity signals and direct source-of-truth verification in identity verification?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?