Match and merge is the process of correlating multiple accounts and records to one real person and then consolidating them into a single identity view. It helps reduce duplicates, improve confidence in identity data, and support more accurate access governance and audit readiness.
How Match and Merge Works
Match and merge is a record-correlation process, not just a deduplication rule. It compares identifiers, attributes, and relationship signals across systems, then decides whether multiple records belong to the same person before consolidating them into a unified identity view.
The value comes from treating identity data as a governed dataset with confidence thresholds and survivorship rules. When the matching logic is too loose, unrelated people can be merged; when it is too strict, duplicates persist and downstream access decisions remain fragmented.
In practice, the process often sits between data quality tooling and identity governance. It depends on source trust, field standardisation, and consistent handling of aliases, name changes, contact drift, and duplicate account creation across business systems.
Why It Matters for Identity Governance
Match and merge improves audit readiness because reviewers can trace one person across multiple accounts, records, and business systems. That makes entitlement review, identity proofing follow-up, and account inventory much more reliable than working from disconnected source records.
It also reduces the chance that a person inherits inconsistent access decisions because they appear as several separate identities. A consolidated view helps teams spot orphaned accounts, conflicting attributes, and duplicate joiner-mover-leaver events before they turn into governance gaps.
When organisations manage many upstream systems, the quality of the merged identity becomes as important as the existence of the merge itself. Poorly governed merges can hide uncertainty, so the surviving identity should retain enough provenance to explain where each attribute came from and why it was trusted.
Common Failure Modes
Match and merge fails most often at the boundaries of certainty. Shared names, reused contact data, incomplete source feeds, and inconsistent formatting can create false positives, while sparse or outdated data can prevent true matches from being recognised.
Another common weakness is overreliance on a single strong identifier. If the process merges records because one field matches but ignores conflicting evidence elsewhere, the resulting identity view may look clean while silently carrying a corrupted history.
For teams that also manage NHI Mgmt Group's Ultimate Guide to Non-Human Identities, the same discipline matters for service and workload records that are often created, renamed, or retired faster than humans. Matching logic still needs clear evidence and traceability, even when the subject is a machine-facing account rather than a person.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Match and merge supports accurate account inventory and access review. |
| 5 — Account Management | Identity consolidation depends on controlled account lifecycle and duplicate detection. | |
| Recommendation — Reconcile duplicate identities before access reviews so entitlements are validated against one trusted record. Standardise account lifecycle data so merges reflect the current authoritative owner and status. | ||
| NIST CSF 2.0 | ID.AM-01 — Inventory of Physical Devices and Systems | Consolidated identity views depend on knowing which records and accounts exist. |
| GV.OV-01 — Organizational Context | Match and merge requires governance over authoritative sources and identity confidence rules. | |
| Recommendation — Maintain a complete identity and account inventory so duplicate records can be found and correlated. Define ownership for identity data sources and approve the rules used to merge records. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Record consolidation is relevant when duplicate or stale machine identities expose credentials and access paths. |
| Recommendation — Eliminate duplicate machine identities that can obscure exposed secrets and stale access. | ||
Practitioner Guidance
Governance implication: Treat match and merge as a controlled decision process, not a one-time cleanup task. Define which attributes are authoritative, what level of evidence is required to merge, and how to review disputed or low-confidence matches.
What to watch for: Pay attention to merges that are driven by weak identifiers, because those are the cases most likely to create hidden access and audit errors. In environments with high identity sprawl, the most valuable control is often not faster merging, but better visibility into why a merge was accepted.
Risk and Threat Considerations
Bad match-and-merge logic can create a security problem as much as a data quality problem. A false merge can combine two different people into one identity view, while a missed merge can leave duplicate accounts active and obscure who actually holds access.
Failure mechanism: Attackers and insiders can benefit when identity resolution is inconsistent, because fragmented records make ownership, review, and revocation harder. Overmerged identities can also cause the wrong attributes or entitlements to follow a record into another context.
Impact: The result can be excessive access, failed recertification, inaccurate audit evidence, and slower incident response when teams cannot trust the identity record they are investigating.
Related resources from NHI Mgmt Group
- What breaks when sandbox validation does not match actual execution in agent systems?
- What should organisations do when identity reviews do not match operational reality?
- What breaks when agents can trigger their own next tasks after a merge?
- Who is accountable when ISO 27001 controls do not match actual access behaviour?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
