How should organisations build a single customer view without creating duplicate identities?

Start by defining authoritative sources for key identifiers, then establish deterministic and probabilistic matching rules that determine when records should merge. The goal is not to centralise every field, but to create a governed profile with clear ownership, auditability, and exception handling for conflicts or uncertainty.

Why This Matters for Security Teams

A single customer view sounds like a data-quality problem, but it quickly becomes an identity governance problem when duplicate records, merged profiles, and conflicting source systems start driving access, consent, fraud checks, and service decisions. If the matching logic is weak, organisations can over-merge two people into one profile or under-merge one person into many profiles, creating security, privacy, and operational failures at the same time.

That risk is especially visible when identity data intersects with secrets, service accounts, or partner-facing workflows. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, a reminder that identity sprawl is rarely confined to customers alone. The same governance gaps that create duplicate customer profiles also create duplicate or orphaned non-human identities, which then complicate audit trails and downstream trust decisions. A broader control baseline such as the NIST Cybersecurity Framework 2.0 helps frame the issue as a resilience and governance problem, not just a master-data exercise. In practice, many security teams encounter duplicate identities only after a denial, fraud alert, or privacy incident has already exposed inconsistent record ownership.

How It Works in Practice

Building a governed customer view starts with defining which attributes are authoritative and which are only supporting signals. A common pattern is to treat government-issued or contract-backed identifiers as high-confidence match keys, then use lower-confidence attributes such as email, phone, device, address, and behavioural signals to support deterministic or probabilistic matching. The important point is that merge logic must be explicit, reviewable, and reversible.

Security teams should align the identity layer with the source-of-truth layer rather than trying to centralise every field. That means assigning ownership for each attribute, recording where it came from, and preserving a history of changes so that merged records can be audited later. Where matching confidence is below threshold, the system should queue records for manual review rather than forcing an automatic join. This is where governance becomes operational: the organisation needs clear rules for merge, split, suppression, and exception handling.

• Use deterministic matching for strong identifiers with stable provenance.
• Use probabilistic matching only with documented thresholds and human review paths.
• Keep a golden record, but preserve source values and lineage for auditability.
• Define conflict rules for consent, address, contact preference, and identity proofing strength.
• Reconcile merges and unmerges through change control, not ad hoc admin action.

For practitioners, the most useful analogue is the discipline recommended in NIST Cybersecurity Framework 2.0, where asset and identity governance are treated as managed control functions rather than one-time cleanup tasks. NHIMG research on JetBrains GitHub plugin token exposure illustrates the broader pattern: when identity and credential ownership are unclear, exposure persists longer and remediation becomes inconsistent. These controls tend to break down in heavily siloed organisations because each line of business applies its own matching logic and no one owns the final reconciliation rule set.

Common Variations and Edge Cases

Tighter matching often reduces duplication, but it also increases false positives and operational overhead, so organisations must balance customer experience against identity risk. That tradeoff becomes sharper when records are created across web, mobile, call centre, and partner channels, each with different data quality and verification standards. Current guidance suggests that there is no universal standard for the exact match threshold, because tolerance for merge errors depends on the use case.

Edge cases matter most where identity proofing is weak or where multiple people legitimately share attributes. Shared household email addresses, recycled phone numbers, business contacts used for consumer enrolment, and international naming conventions can all defeat simplistic matching rules. In regulated environments, privacy and consent requirements may also prevent unrestricted profile aggregation, so the view must be scoped by lawful purpose and data minimisation principles. A single customer view should not become a single point of exposure.

NHIMG’s broader identity guidance in the Ultimate Guide to Non-Human Identities reinforces a practical lesson: when identity records are over-consolidated without strong lifecycle controls, revocation, attribution, and audit all suffer. Best practice is evolving toward governed identity fabrics with lineage, policy-based joins, and explicit split-merge workflows rather than fully automatic profile collapse. That approach is most reliable until organisations need real-time cross-border identity resolution with incomplete proofing, because jurisdictional privacy rules and inconsistent source data make deterministic merging unsafe.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• How should organisations roll out passkeys in a federated user pool without creating duplicate accounts?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?