Because they preserve access that no longer matches business need. If a leaver account stays active or a new user inherits another person’s excessive permissions, an attacker can abuse valid access paths without needing to break authentication. That turns administrative convenience into a standing exposure window.
Why stale accounts and copy-based provisioning are an access risk
Stale accounts and copy-based provisioning both create privilege that outlives the business reason for it. A leaver account can remain valid after role change or departure, while copied access can inherit permissions the new user never needed. The risk is not only excess access, but also the persistence of valid credentials and entitlements that attackers can reuse.
Stale accounts are especially problematic because they often evade ordinary attention. A dormant account with a valid password, token, or session path may sit unnoticed until it is reactivated by misuse, while copied accounts can embed old project access, admin rights, or cross-environment permissions that no one revalidates. That makes the account itself a standing trust assumption.
Copy-based provisioning is attractive operationally because it is fast, but it tends to transfer uncertainty as well as access. When administrators clone another person’s profile or group membership, they often copy inherited permissions, exceptions, and historical baggage. The result is role creep, inconsistent approvals, and a wider blast radius than the business actually intended.
How access drift turns convenience into exposure
Access risk grows when provisioning is disconnected from role change, manager review, or entitlement recertification. If joiner, mover, and leaver events are not tightly controlled, the organisation can end up with users who retain access from previous jobs, temporary assignments, or emergency exceptions long after those needs expire.
The core failure is that access becomes cumulative instead of current. Instead of reflecting the minimum set of permissions needed for today’s work, the account carries forward yesterday’s permissions. That is dangerous because valid access is much easier to abuse than compromised authentication, and it can support lateral movement, data access, or privileged actions without triggering an obvious login failure.
For practitioners, the practical question is whether provisioning is authoritative or merely convenient. If access is granted by copying rather than by a defined entitlement model, the organisation should expect hidden privilege to accumulate over time. A clean process produces accounts that are explainable; a copied account often produces accounts that are only approximately right.
What to verify before you trust the provisioning model
In a healthy access model, every active account should have a current owner, a current business purpose, and a revocation path when that purpose ends. The most important check is whether stale and copied access is being detected and removed quickly enough to keep the access surface aligned with actual need.
Access reviews should focus on the accounts most likely to drift: leavers, movers, copied profiles, shared administrative accounts, and accounts with exceptions. If you cannot show who approved the access, why it exists, and when it will be removed, the account is already carrying avoidable risk. A good provisioning model can explain the entitlement without requiring institutional memory.
When the process depends on copying, the control must compensate with stronger review and tighter boundaries. That usually means limiting the template source, preventing blind inheritance of privileged groups, and checking whether the copied account crossed environment, system, or role boundaries that should have required explicit approval.
Risk and Threat Considerations
Stale and copied accounts matter because they preserve valid access paths after the original business justification has gone. An attacker does not need to break authentication if an unused account, over-permissioned clone, or forgotten entitlement still works.
Failure mechanism: access drift leaves live credentials and entitlements in place after role change, departure, or template-based provisioning, so the environment contains accounts that are technically valid but no longer legitimate.
Impact: those accounts can be abused for unauthorized access, privilege escalation, lateral movement, and stealthy data exposure, especially when the account retains inherited admin rights or cross-system access.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers revocation and lifecycle control for credentials used by stale accounts. |
| AC-2 — Account Management | Directly governs account creation, review, and disablement for stale or copied access. | |
| AC-6 — Least Privilege | Addresses excess permissions inherited through copy-based provisioning. | |
| Recommendation — Revoke unused authenticators promptly and tie credential lifecycle to offboarding and role change. Define account lifecycle rules and disable accounts when business need ends. Limit copied access to the minimum entitlements needed for the current role. | ||
| CIS Controls v8 | CIS-5 — Account Management | Matches the need to manage active, dormant, and overprivileged accounts. |
| Recommendation — Inventory accounts, remove stale access, and review privileged assignments regularly. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale accounts and leaked access often persist because offboarding fails to remove access. |
| NHI-05 — Overprivileged NHI | Copy-based provisioning commonly creates excess permissions and inherited privilege. | |
| Recommendation — Automate offboarding so access, tokens, and keys are removed when the business need ends. Constrain provisioning templates so new accounts do not inherit excess privilege. | ||
Practitioner Guidance
What to prioritise: treat stale accounts and copied entitlements as lifecycle defects, not just housekeeping issues. The highest-value work is to remove unused access, reduce template inheritance, and make revocation part of the normal joiner-mover-leaver flow rather than a separate cleanup exercise.
What to verify: check that copied access is compared against an approved role or entitlement baseline, and that leaver and mover events actually trigger deprovisioning. If an account can survive a job change without review, the provisioning control is too weak to trust.
Common mistake: assuming that a copied account is safe because it was created for a real employee. The source account may already contain exception access, so cloning often spreads risk instead of accelerating secure onboarding.
Practitioner takeaway: the control objective is not just to create accounts faster, but to ensure every active account has a current, defensible reason to retain each permission.
Joiner-Mover-Leaver (JML) GuideIAM and IGA BasicsAccess Reviews and Certification Guide
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How can organisations reduce the risk of stale API keys and machine tokens?
- Why does role-based access control create extra risk for service accounts?
- Why do service accounts and secrets with standing access increase risk in cloud environments?