Joiner-mover-leaver automation, access reviews, approval routing and NHI ownership all run on identity attributes, and when those attributes are missing, stale or wrong, every one of those controls fails quietly. A blank manager field sends approvals to nobody, a contractor who is not in HR never gets a leaver event, a reused employee ID merges two people, and a service account owner who left two years ago means nobody certifies it. This guide covers how to decide which system is authoritative for each attribute, the defects that matter most, correlation and matching rules, measurement, remediation and the controls that stop bad data coming back. It is for IAM and IGA engineers, HR systems teams and identity data owners. It expands on the shorter Identity Data Quality Guide, which introduces the topic and the identity fabric concept.
Key takeaways
- Authority is per attribute, not per system. HR may own employment status and job, a vendor management system owns contractor end dates, the directory owns UPN and the CMDB or IGA owns NHI ownership; write it down in an attribute authority matrix.
- A small set of attributes carries most of the risk. Unique identifier, status, end date, manager, worker type and owner (for NHIs) drive the controls that fail first.
- Every identity needs an authoritative record. Accounts with no source record, such as contractors outside HR and service accounts outside any inventory, have no lifecycle and become orphans.
- Measure quality like a control. Completeness, validity, uniqueness, timeliness and consistency per attribute, tracked monthly with owners, turn a vague data problem into a fixable backlog.
- Fix at source, not in the directory. Corrections made downstream are overwritten at the next sync; remediation has to flow back to the system of record.
Why identity data quality is a security problem
| Defect | Control it breaks | Effect |
|---|---|---|
| Missing or wrong manager | Approval routing, access reviews, leaver notifications | Requests stall or go to the wrong person; reviews rubber-stamped by someone who does not know the user |
| Missing end date for contractors | Leaver automation | Accounts survive the contract; access continues |
| Identity not in any authoritative source | All lifecycle automation | No leaver event can ever fire, so the account becomes an orphan |
| Reused or duplicate identifiers | Correlation and provisioning | A rehire or namesake inherits a previous person's access; accounts merged incorrectly |
| Stale department and job code | Birthright access and role-based rules | Movers keep old access and gain new access (privilege creep) |
| Wrong worker type | Policy (MFA, data access, conditional rules) | Contractors treated as employees or vice versa |
| Departed or blank NHI owner | NHI certification, rotation, incident response | Service accounts and keys nobody will certify or rotate |
| Late status changes | Timely deprovisioning | Terminations entered days after the person left |
NIST SP 800-53 SI-18 asks organisations to check the accuracy, relevance, timeliness and completeness of personal data and correct or delete what is wrong. Data protection law points the same way: Article 5(1)(d) of the UK GDPR, the accuracy principle, requires every reasonable step to correct or erase inaccurate personal data without delay. Identity data is personal data, so poor quality is a compliance issue as well as a security one.
Authoritative sources and the attribute authority matrix
An authoritative source is the system whose value wins when systems disagree. The mistake is naming one system "the source of truth" for everything. Build a matrix instead.
| Attribute | Employees | Contractors and partners | Non-human identities | Notes |
|---|---|---|---|---|
| Unique person or object ID | HR (employee ID) | Vendor management system or IGA-issued ID | Inventory or IGA-issued ID | Never reused; independent of name and email |
| Status and dates (start, end, leave) | HR | Vendor management system or sponsor | Owner, with review date | End date mandatory for non-employees |
| Manager or sponsor | HR | Sponsor recorded at onboarding | Owner and backup owner | Validate that the manager is active |
| Job, department, cost centre, location | HR | Vendor management or sponsor | Application or service | Drives birthright and roles |
| Worker type | HR | Vendor management | Fixed: workload, service, agent | Maps to NIST IA-4(4) user status |
| Legal and display name | HR | Vendor management | Naming standard | Normalise diacritics for login names |
| Login name, UPN, email | Directory or IdP (generated) | Directory or IdP | Directory or platform | Generated once, unique, not re-derived on name change |
| Phone and MFA methods | IdP (user-registered, verified) | IdP | Not applicable | HR phone numbers are not an MFA source |
| Entitlements | Target applications, governed by IGA | Same | Same | IGA holds intended state; applications hold actual state |
Non-employees: the most common gap is that contractors, partners, interns and volunteers exist only in the directory, created by hand. Give them an authoritative record in a vendor management system or the IGA platform, with a sponsor and a mandatory end date. See the Contractor Identity Lifecycle Guide.
Non-human identities: service accounts, workload identities, API keys and AI agents need an authoritative inventory with owner, purpose and review date, otherwise their data quality cannot even be measured. See the Service Account Inventory Template and the NHI Ownership Guide.
Identifiers, matching and correlation
Correlation links an HR record to directory and application accounts. Weak correlation causes both orphans (accounts linked to nobody) and wrong merges (accounts linked to the wrong person).
- Use an immutable identifier: Microsoft's cloud HR provisioning guidance uses Employee ID as the default matching attribute (for example, Workday WorkerID mapped to the AD employeeID attribute) and requires it to be populated and unique before the first full sync. Names and emails change; employee IDs should not.
- Never reuse identifiers: NIST SP 800-53 IA-4 calls for preventing reuse of identifiers for a defined period. Reuse is how a new joiner inherits a former employee's mailbox or access.
- Define match precedence: where several matching attributes are used, evaluate them in a fixed order and stop at the first match; send ambiguous matches to a human queue instead of guessing.
- Know which identifiers are enforced unique: in SCIM (RFC 7643), userName must be unique across the service provider and is case-insensitive, whereas externalId is set by the client and the server does not enforce its uniqueness. Do not rely on externalId for correlation unless your own process guarantees it.
- Plan rehires and conversions: in Microsoft's model, a rehire who keeps the old employee ID has the existing AD account re-enabled; a new ID creates a new account. An employee converted to a contingent worker gets a new account and the old one is disabled on the conversion date. Decide your policy explicitly, because re-enabling an old account can restore old group memberships.
- Uncorrelated accounts are findings: every application account that does not match an authoritative identity is either an NHI to inventory, a shared account to govern or an orphan to disable. See the Shared and Generic Accounts Governance Guide.
Data quality dimensions and rules
Use standard data quality dimensions and write a testable rule for each critical attribute.
| Dimension | Example rule | Typical failure |
|---|---|---|
| Completeness | Every active non-employee has an end date and a sponsor | Blank end dates on contractor records |
| Validity | Manager references an active identity; cost centre exists in finance master data | Manager who left last year |
| Uniqueness | One active identity per employee ID; one owner record per NHI | Duplicate identities after rehire |
| Consistency | Directory department equals HR department within one sync cycle | Manual edits in the directory overwritten or diverging |
| Timeliness | Terminations recorded in HR before or on the last working day | Leavers entered days later, after payroll cut-off |
| Accuracy | Sample checks with managers confirm job and team | Re-organisations not reflected in HR |
Mandatory attributes at create: Microsoft notes that null values in mandatory attributes such as first name, last name, CN or UPN cause account creation failures in HR-driven provisioning; use expression mappings for safe defaults and flag the record for correction rather than silently inventing data.
Ownership and remediation workflow
Data quality fails when everyone can see the problem and nobody owns the fix. Assign each rule to the team that owns the source attribute, not to IAM.
| Rule failure | Owner | Fix route | Interim control |
|---|---|---|---|
| Manager missing or inactive | HR operations | Correct in HR; IGA picks it up at next sync | Route approvals and reviews to a fallback approver such as the department head |
| Contractor without end date or sponsor | Procurement or vendor management | Complete the record; sponsor confirms need | Set a default end date of 90 days and notify the sponsor |
| Termination recorded late | HR and line managers | Process change: managers trigger the leaver event, payroll follows | Allow managers to request immediate suspension |
| Uncorrelated application account | Application owner | Link to an identity, inventory as NHI or disable | Disable after a fixed deadline |
| NHI owner left or moved | Owner's former manager, then platform owner | Transfer ownership; re-attest purpose | Flag for certification; block credential renewal until owned |
| Duplicate identity | IAM operations with HR | Merge under the surviving ID, review merged access | Suspend the duplicate |
Decision guidance: where HR data is good and almost everyone is an employee, HR-driven provisioning straight to the directory is enough. Where the workforce includes many contractors, partners or acquired companies with their own HR systems, put an identity data layer between sources and targets so that each population has an authoritative feed and conflicts are resolved by rule, not by the last system to write.
Implementation roadmap
- Profile (month 1): extract HR, directory, IdP, vendor management and NHI inventory data. Measure each critical attribute against the rules above. Count identities with no authoritative record.
- Agree authority (months 1 to 2): build the attribute authority matrix with HR, procurement, IT and security, and name a data owner per attribute.
- Clean critical attributes (months 2 to 4): fix managers, end dates, worker types and NHI owners at source. Disable orphans after an owner search with a fixed deadline, keeping them disabled (not deleted) for a recovery period.
- Harden the pipeline (months 3 to 6): enforce mandatory fields and validation in HR and vendor management forms; make the directory read-only for HR-owned attributes; enable deletion safeguards in provisioning (Microsoft recommends the skip out of scope deletions flag, especially with scoping filters).
- Test before changing flows: changing scoping filters or attribute mappings in Microsoft's HR provisioning triggers a new initial cycle. Run it in staging first and, for large tenants (Microsoft cites more than 30,000 users), stage the initial cycle by narrowing the scoping filter.
- Operate (month 6 onward): publish a monthly data quality scorecard, route rule failures to the owning team as tickets, and add data quality to the IGA programme's KPIs.
Rollback: before bulk corrections, export the current state; apply changes in batches with a reversible script; keep deletion protection on so a bad mapping disables nothing at scale. Small organisations can start with a spreadsheet matrix and a monthly script that compares HR and directory exports. Large organisations usually need an identity data layer (an IGA platform or identity fabric) that holds the merged identity and the lineage of each attribute; see the Identity Lifecycle Event Design Guide for how events flow from that layer.
Detection and measurement
- Provisioning errors: Microsoft records all HR provisioning activity in Entra provisioning logs and provides a Provisioning Insights workbook; a provisioning job with a high error rate goes into quarantine. Treat sustained errors as a data quality incident.
- Drift: nightly comparison of authoritative and downstream values for critical attributes.
- Orphan creation: new accounts created outside the provisioning flow (no matching authoritative record).
- Activity after end date: sign-ins by identities whose authoritative end date has passed are a direct signal of a broken lifecycle (ATT&CK T1078 Valid Accounts).
| Metric | Target |
|---|---|
| Active identities with an authoritative source record | 100% |
| Active identities with a valid, active manager or sponsor | Above 99% |
| Non-employees with an end date within policy (for example, 12 months maximum) | 100% |
| NHIs with an active owner | 100% |
| Uncorrelated accounts in critical applications | Falling to zero |
| Median delay from last working day to termination record | Zero days |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-4 Identifier Management; IA-4(4) Identify User Status | Unique, non-reused identifiers and worker type |
| NIST SP 800-53 Rev 5 | SI-18 Personally Identifiable Information Quality Operations | Accuracy, timeliness and completeness checks |
| NIST SP 800-53 Rev 5 | AC-2 Account Management; AC-2(1) Automated System Account Management | Lifecycle depends on correct data |
| NIST CSF 2.0 | PR.AA-01; ID.AM-08 | Identity management; lifecycle management of assets and data |
| CIS Controls v8.1 | 5.1 Establish and Maintain an Inventory of Accounts; 5.3 Disable Dormant Accounts | Inventory accuracy and orphan removal |
| ISO/IEC 27001:2022 Annex A | A.5.16 Identity management; A.5.18 Access rights | Identity lifecycle and provisioning |
| UK GDPR | Article 5(1)(d) accuracy | Legal duty to keep personal data accurate |
Common failure patterns
- Directory as a hand-edited source: help desk staff correct titles and managers in AD, which are then overwritten by HR or diverge permanently.
- Contractors outside every system of record: created by IT on request with no end date, so they never leave.
- Email as the correlation key: name changes and alias reuse break links or merge the wrong people.
- Re-enable on rehire: an old account comes back with all its old group memberships.
- Owner fields that decay: NHI owners are recorded once and never revalidated when the owner moves or leaves.
- Clean-up without prevention: a one-off data clean-up project with no validation at entry, so quality returns to the old level within a year.
Lessons from incidents
In the Colonial Pipeline ransomware attack, the entry point was a legacy VPN profile that was no longer in use but had never been disabled, with no MFA. Whatever the exact process gap, an account that survives after its purpose has ended is the typical outcome of identity data that no longer reflects reality: no end date, no owner, no authoritative record to trigger removal.
Practitioner checklist
- Publish an attribute authority matrix covering employees, non-employees and NHIs, with a named owner per attribute.
- Give every identity an authoritative record, including contractors and service accounts.
- Correlate on an immutable, never-reused identifier, not email or name.
- Write testable quality rules for ID, status, end date, manager, worker type and owner.
- Make HR-owned attributes read-only downstream and fix data at source.
- Decide rehire and conversion handling explicitly, including what happens to old access.
- Enable deletion safeguards and stage changes to provisioning mappings.
- Disable uncorrelated and orphaned accounts after a time-boxed owner search.
- Publish a monthly data quality scorecard and route failures to owners as tickets.
Standards and references
- NIST: SP 800-53 Rev 5 Security and Privacy Controls (IA-4, SI-18)
- IETF: RFC 7643 SCIM Core Schema
- Microsoft: Plan cloud HR application to Microsoft Entra user provisioning
- ICO: Principle (d) Accuracy
- NCSC: 10 Steps, Identity and access management
Related NHI Mgmt Group resources: Identity Data Quality Guide · Joiner-Mover-Leaver Guide · Identity Lifecycle Event Design Guide · Access Reviews Guide · SCIM Provisioning Guide