Duplicate Identities Create Hidden Risk Across SaaS and Enterprise Systems

Duplicate identities appear when one person holds several accounts across directories, SaaS applications and enterprise systems, and nothing reliably ties those accounts back to that person. It looks like a data hygiene issue, but it is a governance problem, because a reviewer, an offboarding workflow or an auditor can only act on the access they can actually see. Citadel Identity360 starts from the authoritative identity record and works outward, attaching lifecycle events, ownership, access reviews and identity attestation to the person rather than to whichever account happens to be easiest to find.

This article covers one specific pattern: uncorrelated accounts that belong to the same human being. Our guide to identity sprawl deals with the wider loss of context across identities, accounts and permissions, and the access governance system explainer shows where account correlation sits inside a governance platform. Here the question is narrower: what happens to visibility, reviews, offboarding and evidence when one employee quietly becomes three records?

Duplicate identities, defined for governance work

There is no single standardised technical definition of a duplicate identity. For governance purposes a working one is enough: two or more account records, in the same system or in different ones, that belong to one person but are not consistently linked to that person in the organisation’s identity view.

An account is always local to a system, and holding accounts in many applications is normal. The trouble begins when the link back to the person is missing, wrong or held only in someone’s memory.

Standards point in the same direction. In NIST SP 800-53, IA-2 asks organisations to uniquely identify and authenticate organisational users, and IA-4 covers how identifiers are assigned and when their reuse is prevented. NIST SP 800-63A describes identity resolution as determining that a claimed identity corresponds to a single, unique individual within the population served. Written for identity proofing, the lesson still carries across: one person should resolve to one identity, however many accounts hang from it. The NIST Cybersecurity Framework 2.0 states the outcome in PR.AA-01: identities and credentials for authorised users, services and hardware are managed by the organisation.

Four situations are easy to confuse, and each calls for a different response:

• Linked multiple accounts: one person, several accounts, each tied to that person on purpose. A standard login plus a separate administrator account is the classic case.
• Duplicate identities: the same person appears as two or more records with no reliable link between them, so each record is governed as if it were someone else.
• Orphaned accounts: accounts no longer associated with a current, legitimate user. An orphaned account has lost its owner, while a duplicate may still have one who is simply hidden.
• Shared accounts: the reverse problem, where several people sit behind one login.

Where the extra records come from

Duplicates build up wherever separate systems create people independently and nobody reconciles the results. These patterns are illustrative, not measured:

• Rehires and returning contractors set up as new joiners instead of being matched to their earlier record.
• Contractor to employee conversions, where the agency account survives next to the new staff account. Our contractor lifecycle guide explains why an engagement’s close should trigger removal.
• Name and email changes that some applications treat as a new user.
• Self-service SaaS invitations sent to an alias or personal address by a team that bought the tool directly, a pattern explored in our post on SaaS sprawl.
• Local application logins created by an administrator to fix an urgent problem and never tied to the directory.
• Mergers and acquisitions, where two directories run side by side for a period and some people deliberately receive an account in each so work can continue.

That last case matters because a duplicate-looking record can be intentional. The governance question is not whether a person has more than one account. It is whether each account is expected, owned and on a defined path to review or retirement.

How split records blur the access picture

When a person’s access is split across unlinked accounts, a reviewer may see one record and reasonably assume it is the whole picture. That is a governance blind spot rather than a technical failure.

To govern any person’s access, you need clear answers to four questions:

• what the person can reach, across every account
• which account is accountable for which entitlement
• which review decision applies to which grant
• which record reflects the current lifecycle state

Scattered answers cause two distortions. Access held by one person can look like access held by two, which fragments accountability. And the combined reach of those records is never evaluated as a whole, so a conflict between permissions held on different accounts can go unnoticed until someone traces it by hand.

Reviews that look complete and are not

Access certification exists to confirm that people still hold the right access. That only works when the campaign includes the relevant accounts, applications, roles and relationships. NIST SP 800-53 AC-2 expects organisations to specify authorised users, group and role membership and access authorisations for each account, and to review accounts for compliance with account management requirements.

Duplicate identities undermine that in three ways. A person can be counted separately in different systems. A reviewer may see only part of that person’s access. And a tidy campaign report can hide gaps when a disconnected application sits outside the review scope.

Duplicates do not automatically make a review invalid, but fragmented records make completeness harder to establish. A useful standard is that each review item should make the application, account, entitlement, owner, reviewer, decision and remediation status clear. Our access review evidence checklist sets out what auditors tend to expect from each of those elements.

Leavers and movers expose the hidden accounts

Offboarding is where fragmented records become expensive. Disabling the primary directory account does not remove every separately managed account, and an unlinked account is exactly the one a leaver workflow is likely to miss.

Role changes follow the same logic: a mover gains new access while old permissions linger on an account the transfer process never touched.

The control expectations are clear. AC-2 asks organisations to align account management with personnel termination and transfer processes. Enhancement AC-2(3) calls for disabling accounts that are no longer associated with a user or individual, within a period the organisation defines, and AC-2(1) supports automated account management. Some applications also hold their own sessions, so access can outlast a directory change until those sessions end.

For IT leaders, the right question is not whether a ticket was raised. It is whether the change was carried through in every system in scope. Our post on revocation tracking covers that distinction, and the identity lifecycle page explains the events behind it.

Evidence weakens when account ownership is unclear

Duplicate identities do not falsify logs. The risk is ambiguity: when the records cannot show the full account population, the link between each account and its owner, or the status of remediation, evidence becomes harder to trust. AC-2(4) expects automatic auditing of account creation, modification, enabling, disabling and removal, and that record means far more when every account resolves to a known person.

Five questions expose the gaps during IT compliance audits:

1. Can you list every account and access-bearing identity in scope?
2. Can each account be tied to a current, named owner?
3. Can you show who approved each change and when it happened?
4. Can you show that access was removed across covered systems after a departure or role change?
5. Are disconnected applications and manual removal steps visible rather than assumed?

Good answers support audit readiness; they help produce evidence rather than promise an audit outcome.

A working sequence for resolving duplicates

Treat cleanup as investigation, not bulk deletion:

1. Name the authoritative sources. HR for employees, the contractor register for contractors, and a named source of truth for every other population.
2. Agree the linking attribute. Prefer a stable identifier such as an employee number over a display name or email address, and record which attribute each application actually stores.
3. Collect accounts from every system in scope, including disconnected applications through exports.
4. Treat every unmatched account as a case with an owner, never as an automatic deletion.
5. Decide each case: link the account to its person, keep it as an approved secondary account with a stated purpose, or retire it through the lifecycle process.
6. Fix the process that created it, whether that is the rehire flow, the conversion path or a self-service invitation route.
7. Check again at the next review cycle, so the cleanup becomes routine instead of a one-off project.

Citadel Identity360 and the split-record problem

Citadel Identity360 governs people, workloads and agents across cloud, SaaS and on-premises estates, and several capabilities speak directly to split records.

Lifecycle anchored to the person. Joining, moving and leaving are driven from the authoritative record, with provisioning and deprovisioning orchestrated across connected and disconnected applications. A rehire or transfer starts from the person, so new accounts begin tied to the right identity.

Ownerless accounts brought forward. Risk analytics surface orphaned account exposure, meaning accounts without active owners, so the records most likely to be forgotten land in front of someone who can decide. Machine identities such as service accounts and API keys keep a named owner from creation to decommissioning.

A single map of what someone holds. Citadel’s identity graph links each user to roles, applications and permissions, while access path discovery shows how a grant came about and who approved it. Once an account is attributed to the right person, it sits next to everything else that person can reach.

Certification and identity attestation. Citadel’s detailed review module schedules certification campaigns and puts recommendations and risk context beside each item. Identity attestation asks managers and owners to vouch that an identity remains valid, a natural point to raise an account nobody recognises.

Risk scores shaped to your priorities. Scores are customisable and cover the organisation, each department, application and manager, and every individual identity, so teams can choose which population to untangle first.

Cloud entitlements and agents. Through its CIEM capability, Citadel collects cloud entitlement data together with scopes, permissions, grants, usage and policies, and presents an all-round view of the actions that need attention. AI agents surfaced from the Entra, AWS and Google Cloud registries, or found on endpoints by installed agents, each get an accountable owner, and a kill switch allows containment.

Reach into older applications. Integration options cover REST, SOAP, SCIM, LDAP, JDBC, files, SFTP, batch, mainframe and custom connectors. RPA-based integration carries approved changes into applications operated through their own screens, governed manual fulfilment handles what remains, and every change is followed through to completion.

Citadel runs as SaaS, in a private cloud or on-premises. Roughly 400 hours of customisation come with the plan, which can go towards a rehire workflow or a report listing accounts still awaiting attribution.

One rehire, three records: an illustration

Picture a finance analyst who leaves, returns through an agency, then is rehired as staff. Three records now exist: the original directory account, an expense application login under the agency email address, and the new staff account. In Citadel Identity360, the new joiner workflow starts from the HR record. The agency account carries the contractor’s sponsor and end date, so it comes up for removal when the engagement closes. The next certification campaign shows the expense application access with risk context, and the manager’s identity attestation gives a clear point to ask about the earlier record. The analyst and the company are hypothetical, not a customer.

FAQ on duplicate identities

Does holding several accounts mean someone has a duplicate identity?

No. Several accounts can be legitimate and deliberate. The governance test is whether each one is linked to the person, has a clear purpose and owner, and appears in the organisation’s identity view.

Why can a central directory miss accounts a person holds?

Many applications create and manage users through their own processes, and parallel directories after an acquisition add more. A central view is only as complete as the sources connected to it.

If an employee’s main account is disabled, is their SaaS access gone too?

Not in every environment. Separately managed accounts, manual removal steps and application sessions can all keep access alive, so the change needs to be carried through in each system in scope.

Do duplicate records mean we will fail an audit?

Not by themselves. They make ownership, inventory completeness, review scope and removal evidence harder to show, which is why resolving them before an audit pays off.

Should duplicate accounts be deleted as soon as they are found?

No. Investigate first. A record that looks redundant may support an approved purpose or a running process, so link, keep with a stated purpose, or retire it through the normal lifecycle.

Trace one person across every system

Choose one leaver or one rehire from the past quarter and list every account that person held, in every application. Then bring that population into Citadel Identity360 so each unlinked or ownerless account becomes an assigned decision. Request Demo and bring that list with you, or watch the Citadel videos first for a preview.