Source of Truth and Identifier Strategy

Overview

Every IAM integration breaks the same way: systems can't agree on who someone is. The IdP says it's john.doe@company.com. HR says it's 12345. Active Directory says it's jdoe. The legacy app says it's JOHND. When these don't correlate, you get duplicate accounts, failed provisioning, broken SSO, and audit evidence that can't trace access back to a person.

The canonical identifier question: What single, immutable identifier uniquely identifies a person across all systems in your enterprise? This isn't a technical question with a technical answer—it's an architectural decision with organizational implications.

The attribute precedence question: When HR says someone's department is Finance and AD says it's Accounting, which one wins? When do we allow exceptions? Who arbitrates conflicts?

Getting this wrong creates:

Duplicate identities in IGA (certification misses access, SoD violations undetected)
Failed correlation (orphan accounts pile up)
Provisioning failures (target systems reject or create duplicates)
Audit gaps (can't prove who had access when)
Merger integration hell (two companies, two identifier schemes, infinite conflicts)

This decision must be made early and enforced consistently. Retrofitting identifier strategy is painful.

Key Decisions

Decision	Options	Recommendation	Notes / Gotchas
Workforce immutable ID	email / UPN / employeeID / GUID	employeeID from HR	Email changes (marriage, typo fix); UPN changes (domain migration)
External immutable ID	email / partner-assigned / IGA-generated GUID	IGA-generated GUID with partner ID as secondary	Externals often lack stable enterprise identifiers
Authoritative source hierarchy	Single / Multiple with precedence / Federated	Single source where possible; explicit precedence if multiple	Federated models are complex and drift-prone
Attribute precedence	HR-first / Directory-first / Hybrid with rules	HR-first for person attributes; directory may own technical attributes	Document exceptions explicitly
Identifier propagation	Each system generates own / Propagated from authoritative	Propagate canonical ID to all systems where supported	Enables correlation; not all systems support custom IDs
Conflict resolution	HR always wins / Case-by-case / Automated rules	HR wins for person data; documented exceptions with owner	Conflict = data quality issue to remediate
Rehire handling	Same ID / New ID	Same ID to preserve history	Different ID if legal/security requires separation

Attribute	Source 1 (Highest)	Source 2	Source 3	Notes
Legal name	HR	-	-	HR is authoritative for legal name
Display name	HR	Self-service override	-	Allow personalization within bounds
Department	HR	-	-	HR is authoritative
Cost center	HR	Finance override	-	Finance may correct for projects
Manager	HR	-	-	HR is authoritative
Job title	HR	-	-	HR is authoritative
Work location	HR	Facilities override	-	Facilities knows physical location
Email	Derived (IGA rule)	-	-	Generated from name + domain rules
UPN	Derived (IGA rule)	-	-	Generated from email or name rules
Phone	HR	Self-service	-	HR default; user can update

Identifier Strategy Examples

Population	Canonical ID	Format	Generated By	Propagated To
Employees	employeeID	Numeric (e.g., 12345)	HR system	AD, IdP, IGA, apps
Contractors	contractorID	Alphanumeric (e.g., CTR-12345)	Contractor portal or IGA	AD, IdP, IGA, apps
Partners	partnerGUID	UUID	IGA (on first feed)	IdP, partner apps
Customers	customerID	UUID or email	Customer IAM (CIAM)	Customer-facing apps
Service accounts	serviceAccountID	Naming convention	ServiceNow/ITSM	AD, apps

Anti-Patterns to Avoid

Anti-Pattern	Problem	Better Approach
Email as primary ID	Email changes on name change, company change, typo fix	Use stable employeeID; email as correlation fallback
UPN as primary ID	UPN changes on domain migration, format changes	Use stable employeeID; UPN as correlation fallback
Each system generates own ID	No correlation possible; siloed identities	Propagate canonical ID to systems that support it
No defined precedence	Conflicts resolved ad-hoc; inconsistent data	Explicit precedence matrix with exception process
Recycling IDs	Former employee's access leaks to new person	Never recycle; use new IDs or suffixes
Different IDs pre/post M&A	Can't correlate legacy access; audit gaps	Namespace or prefix; maintain mapping table

Implementation Approach

Phase 0: Discovery (2-3 weeks)

Inputs: System inventory, current identifier usage, HR data model Activities:

Inventory all identity-consuming systems
Document current identifier usage per system
Profile HR identifier quality (uniqueness, completeness, stability)
Identify M&A or multi-HR situations
Document current attribute sources and conflicts

Outputs: Identifier landscape assessment, data quality report, conflict inventory

Phase 1: Strategy Design (2-3 weeks)

Inputs: Discovery outputs, business requirements Activities:

Define canonical identifier per population (employee, contractor, external)
Define attribute precedence matrix
Define conflict resolution process
Define exception handling (who approves, how documented)
Plan identifier propagation to downstream systems

Outputs: Identifier strategy document, precedence matrix, exception process

Phase 2: Data Remediation (3-6 weeks, varies)

Inputs: Strategy, current data state Activities:

Remediate HR data quality issues (missing IDs, duplicates)
Build identifier mapping for M&A situations
Configure attribute propagation rules in IGA
Build correlation rules based on identifier strategy
Test correlation accuracy

Outputs: Clean authoritative data, configured propagation, validated correlation

Phase 3: Operationalize (2-3 weeks)

Inputs: Configured systems, documented processes Activities:

Train HR and IT on identifier and attribute governance
Implement monitoring for correlation failures
Implement monitoring for attribute conflicts
Document runbooks for common issues

Outputs: Operational processes, monitoring, trained teams

Phase 4: Ongoing Governance

Activities:

Monitor correlation success rates
Review and resolve exceptions
Update precedence rules as business changes
Handle M&A identifier integration
Periodic data quality audits

Deliverables

Identifier strategy document — canonical ID per population, rationale, exceptions
Attribute precedence matrix — source × attribute × precedence rank
Correlation rule specification — how systems match identities
Exception handling process — who approves, documentation requirements
M&A identifier mapping — how acquired entity IDs map to enterprise IDs
Data quality metrics — uniqueness, completeness, correlation success

Risks & Failure Modes

Risk	Likelihood	Impact	Early Signals	Mitigation
HR data quality blocks strategy	H	H	Missing employeeIDs, duplicates, nulls	Pre-flight data audit; HR remediation project
Systems can't accept canonical ID	M	M	Legacy apps with fixed ID format	Maintain mapping; correlation fallback
M&A creates ID conflicts	M	H	Overlapping employeeIDs from acquired company	Namespace IDs; maintain mapping; plan integration
Attribute precedence not followed	M	M	Inconsistent data across systems	Automated propagation; monitoring; governance
Identifier strategy undocumented	H	M	Tribal knowledge; inconsistent decisions	Documentation; training; process enforcement
Email used as ID despite strategy	H	M	Email-based correlation fails on name change	Technical enforcement where possible; monitoring

KPIs / Outcomes

Identifier coverage: % of identities with canonical ID populated (target: 100%)
Correlation success rate: % of accounts successfully correlated (target: greater than 98%)
Attribute consistency: % of identities with consistent attributes across systems (target: greater than 95%)
Exception rate: % of identities requiring manual exception handling (target: fewer than 2%)
Conflict resolution time: Average time to resolve attribute conflicts (target: fewer than 5 business days)

Workshop Questions

Security / IAM

What's the canonical identifier for workforce identities today? Is it consistent?
What happens when someone's name changes? Does their identifier change?
How do you handle M&A—do acquired employees get new identifiers?

HR / HRIS

Is employeeID unique, never reused, and always populated?
When does employeeID get assigned (offer, hire date, first day)?
How are contractors and contingent workers identified?

IT / Integration

What systems can accept a custom identifier vs. generate their own?
What's the correlation key used today for account matching?
Are there known conflicts between HR and directory data?

Requirements Gathering Checklist

What is the canonical immutable identifier for each population (employees, contractors, externals)?
Is the canonical identifier unique, never reused, and always populated in the authoritative source?
What is the authoritative source for each identity attribute (name, department, manager, email)?
What's the attribute precedence when sources conflict?
What systems can accept a custom identifier vs. must generate their own?
How are M&A situations handled—do acquired employees get new IDs?
What's the correlation strategy for systems that can't use the canonical ID?
What's the exception process when precedence rules don't fit a situation?
Who owns data quality for the authoritative source?
What monitoring exists for correlation failures and attribute conflicts?
What's the rehire policy—same ID or new ID?
What documentation exists for current identifier strategy (or is it tribal knowledge)?