Cloned Account

What cloned accounts are used for

A cloned account is a fast way to create a new identity record from an existing one, usually by carrying across attributes, groups, roles, or profile fields. That makes provisioning efficient, but it also means the new record can inherit access that was appropriate for the source account and not for the new person, job, or context.

In practice, cloned accounts sit at the intersection of convenience and control. They are often created during onboarding, reclassification, transfers, or temporary access requests, but the copied baseline must still be treated as a provisional starting point rather than proof of entitlement.

Why cloned accounts are risky

The core risk is privilege carryover. If the source account contains stale memberships, elevated roles, or exceptions granted for a previous task, those permissions can be duplicated into the new account before anyone has validated whether they still make sense.

That creates an exposure window where a user may have access beyond their job need, and where the organisation may believe provisioning is complete even though entitlement review has not caught up. Identity teams often pair clone-based provisioning with access recertification because the clone itself does not prove that the inherited access is justified.

How cloned accounts should be validated

Validation starts with comparing the cloned record against the intended role, not against the source account. The important questions are whether each copied attribute is needed, whether any inherited group memberships should be removed, and whether the account should be subject to the same approval trail as a fresh joiner or mover request.

This is also where joiner-mover-leaver controls matter. A cloned account should be checked against current HR or system-of-record data, then reviewed for least privilege before it is released for use. Where the source account has broad access, the clone should be treated as suspect until it has been trimmed down.

For teams building access governance, the CIS Controls v8 are useful because they emphasise account management, access control, and audit logging around user access state.

Safer ways to use cloning

Cloning is best used as an operational shortcut, not as an entitlement decision. A good process copies only the minimum necessary profile data, then applies role-appropriate access rules, approval checks, and expiry handling for anything temporary.

Where the cloned account will be used for a service, automation, or other non-person actor, it should be governed as a distinct identity with its own lifecycle and review cadence. The same discipline applies when the environment depends on access boundaries or temporary elevation: the copy should never become a permanent substitute for governed provisioning.

Risk and Threat Considerations

Cloned accounts can preserve hidden privilege, which makes them an attractive shortcut for accidental overprovisioning and, in some environments, deliberate abuse. If cloning bypasses normal entitlement checks, a stale or overly privileged source record can propagate access into a fresh account and create immediate lateral movement or data exposure potential.

Failure mechanism: The clone inherits entitlements, roles, or exceptions from the source account before those permissions are revalidated, so the new record becomes active with access that was never reapproved for the new context.

Impact: Excess access can lead to unauthorized data access, policy violations, and harder post-incident cleanup because the copied permissions make it less obvious what should have been granted in the first place.

Practitioner Guidance

What to watch for: Treat cloned accounts as a temporary convenience state, not a completed access decision. If your process clones profiles across users, departments, or environments, the important control is the review step after cloning, because that is where inherited access must be trimmed, justified, or removed.

Governance implication: Ownership should sit with the identity or access control process, not with the person requesting the account. A cloned account should be traceable to the source record, the approval basis, and the final entitlement set so that reviewers can see exactly what changed.

Related resources from NHI Mgmt Group

• What happens when a human uses an NHI account?
• What happened in the demo account left active in production scenario and what does it reveal?
• What makes a super NHI different from an ordinary service account?
• When does a service account become a compliance problem?