Identity sprawl is the accumulation of identities, accounts and permissions that an organisation can no longer reliably connect to their purpose, owner or lifecycle. It grows when business change creates access faster than teams reconcile it. A new application, contractor engagement or automation project can leave another set of records behind. Citadel Identity360 addresses the governance problem by connecting identity relationships, lifecycle work and access reviews, helping teams understand what exists and decide what should remain.
Identity sprawl is a relationship problem
A large identity population is not automatically sprawl. An enterprise can have many accounts and still know which business identity each belongs to, why it exists and who decides its future. The problem starts when those connections become uncertain.
One employee may legitimately use several application accounts. A service account may support an important production job. Neither should be labelled unnecessary merely because it increases the count. The governance question is whether those accounts have an accountable owner, appropriate permissions and a workable path for change or retirement.
Citadel Identity360 makes those relationships visible through its identity graph and access-path discovery. The useful outcome is not a smaller number for its own sake. It is a clearer explanation of access and a repeatable way to act on decisions. This article follows that ownership problem rather than treating identity sprawl as a synonym for every technology inventory issue.
Three records that should not be confused
A business identity explains the relationship
A business identity represents the person or accountable entity behind activity. For a worker, the relationship might include their employment or engagement. For a machine identity, responsibility lies with the team that operates the workload. An owner is not simply the last administrator who touched the account.
An account exists within a system
An application account is a local representation that may have its own identifier and status. Several accounts can relate to the same person. A shared administrative account creates a different accountability problem from a named user account, even when both appear in one export.
Permissions describe what access allows
Roles, group memberships and direct grants determine what the account can reach or do. A complete account inventory can still conceal excessive access if the permissions and their relationships are missing. Citadel’s graph links users, roles, applications and permissions, giving that distinction practical meaning.
The knowledge-centre definition of an identity repository provides background on identity data. A repository becomes useful for governance when teams can explain the relationships, not merely accumulate another copy of the records.
Why ordinary change leaves extraordinary residue
Sprawl does not need a dramatic incident to begin. Separate teams create access to solve immediate problems. The residue appears when the original reason changes but the access does not receive equivalent attention.
A department transfer adds a new role while an older role remains. A project team creates a technical account and later reorganises. A contractor receives access through an application owner who never learns the engagement has ended. An integration project records local accounts using names that do not match the central directory.
These are illustrative patterns, not claims about their prevalence. They show why counting directory users alone cannot settle the question. The directory may know who works for the company while a business application retains an independent view of who can operate it.
Citadel’s lifecycle orchestration connects joining, moving and leaving to provisioning and deprovisioning work. That brings decisions into an operating process rather than relying on an administrator remembering each application after the business event has passed.
Separate identity sprawl from neighbouring problems
The subject overlaps with application and group management, but each question needs a different boundary:
- Identity sprawl: which identities and accounts exist, who is responsible and whether their access still has a purpose.
- Application sprawl: which services the organisation uses and why their portfolio has expanded.
- Group sprawl: how membership structures multiply, overlap or obscure access paths.
- Permission accumulation: how an identity keeps rights beyond its current need, even when every account has a known owner.
An identity programme can encounter all four without solving them through the same cleanup exercise. Retiring a redundant application is different from correcting access within a necessary one. Deleting groups is different from understanding the grants their members inherit.
This article concentrates on identity relationships and governance decisions. It does not prescribe SaaS procurement policy, group naming conventions, credential rotation architecture or application replacement. Those deserve their own operational plans.
A standards-based starting point for ownership
NIST SP 800-53 Rev. 5 provides relevant account-management and least-privilege controls. AC-2 addresses account management, including account managers, authorisation, account changes and reviews. AC-6 addresses least privilege. These controls provide a way to organise questions, not an instruction to delete every unfamiliar account.
The NIST Cybersecurity Framework 2.0 provides another useful reference. Its PR.AA-01 outcome concerns managing identities and credentials for authorised users, services and hardware. PR.AA-05 addresses access permissions, entitlements and authorisations being defined, managed, enforced and reviewed, incorporating least privilege and separation of duties.
CISA’s Zero Trust Maturity Model version 2.0 includes identity among its five pillars. It is a maturity model, not proof that an identity inventory by itself establishes a complete security architecture. Together these references support a disciplined approach to ownership, permissions and change without turning a dashboard into a security conclusion.
Start with questions that expose broken connections
Before commissioning another inventory, decide which uncertainty the programme must resolve. A useful first review can ask:
- Which application accounts cannot be connected to a person or accountable service owner?
- Which identities have permissions whose business purpose is no longer understood?
- Which access changes remain unfinished after an approved decision?
- Which people changed responsibilities without a review of retained access?
- Which non-human identities depend on knowledge held by one departing administrator?
Each answer should lead to investigation, not automatic deletion. An unfamiliar service account may run a critical process. An unmatched identity might reflect inconsistent identifiers rather than an unauthorised user. An apparently redundant grant may support an approved operational responsibility.
Citadel’s identity-risk views help focus attention, while business and application owners provide the context needed to decide. Treat an alert as a reason to investigate, not a substitute for an accountable decision.
Follow one transferred worker across the estate
Consider an illustrative employee who moves from purchasing into a reporting role. The new team requests reporting access. The previous purchasing permissions remain in a separate application, and a local support account uses an older username.
A simple headcount report shows one active employee and no obvious issue. An application-only report shows several active accounts without explaining their relationship. The governance view needs the connection between the business event, the accounts and the permissions that may no longer fit.
An application owner reviews the purchasing rights. The decision leads to removal work that is followed through to completion. The reporting access remains because it matches the new responsibility. The local support account is investigated rather than deleted solely because its name looks unusual.
This example illustrates containment of sprawl without promising that a product independently understands every business purpose. Citadel supplies lifecycle and relationship context; accountable people decide what the role requires. The resulting evidence also has a clearer story than an unexplained list of disabled accounts.
Machine identities need continuity, not guesswork
Service accounts, API keys and machine identities introduce a different ownership problem. A worker can leave while the process they built continues running. The credential may remain useful, but responsibility for it must not disappear with its creator.
Citadel’s non-human identity lifecycle management keeps an accountable owner associated with these identities from creation through decommissioning. That supports questions about purpose, permission and retirement. It does not justify retiring a production identity before dependencies and operational responsibility are understood.
AI agents add another relationship: the tools an agent may use. Citadel discovers agents through the central registries available in Microsoft Entra, AWS and Google Cloud. Keep that registry boundary explicit when defining the agent population for a review. Agent and MCP ownership, specific tool permissions and a configuration file generated inside Citadel establish the governed access model for compatible MCP clients.
An agent kill switch provides intervention or containment. It should not be described as eliminating all identity residue or terminating every dependent process. The ownership work still matters after an intervention.
What Citadel changes in the operating routine
Citadel Identity360 addresses sprawl through connected governance activities rather than an isolated cleanup campaign. The relevant capabilities are:
- Map relationships: the identity graph exposes connections among identities and access structures; access-path discovery explains the grant route and its approver.
- Orchestrate lifecycle changes: provisioning and deprovisioning work follows joiner, mover and leaver events across the governed estate.
- Review existing access: scheduled campaigns present risk context with AI-generated recommendations, leaving reviewers responsible for retaining or revoking access.
- Identify risky combinations: toxic-combination monitoring and an identity risk score help teams investigate exposure without promising pre-grant blocking.
- Respond to changing context: risk-based access management adjusts access policy using behaviour, context and risk levels.
Password management also has a place when credential handling is part of the operational problem. Citadel provides enterprise-ready password controls. That is different from deciding whether an account should exist; credential controls and identity ownership answer related but separate questions.
For a fuller explanation of how these parts work together, see the access governance system guide. The practical test is whether a team can explain one confusing relationship and carry the resulting decision into the relevant workflow.
Make the cleanup repeatable without broad deletion
Choose a bounded application population and identify its business owner, identity source and change process. Agree how unmatched records will be investigated. Record the decision about an identity before starting any retirement work, particularly where automated processes may depend on it.
Citadel supports different integration methods across hybrid estates, including APIs, directories, databases, files and batch processing. RPA extends configured administration workflows to applications operated through their own interfaces. Governed manual fulfilment covers steps assigned to administrators. Collection and change are different operations; an export alone does not remove access.
The user access management explainer describes the operating responsibilities behind those changes. Keep remediation status visible until the approved work is fulfilled, and use recurring reviews to revisit access that remains appropriate today but may change later.
If the programme needs evidence for an engagement, connect those records to the relevant audit question. The identity evidence guide provides background on preparing access records; for a specific request, define the population, date range and source. A lower account count is not the same as evidence that the right decisions were made.
The continuous compliance comparison explains why ongoing operational records and periodic examination have different jobs. Apply that distinction here: investigate ownership during normal work, then retain enough context to explain the decision later. Reconstructing a purpose after the original owner has left is a harder starting point.
Where compliance teams coordinate the work, the CMS explainer separates programme oversight from its identity inputs. Identity operations should supply those inputs without treating its application inventory as the entire enterprise control programme. Agree the responsible owner for each unresolved question instead of moving responsibility between teams indefinitely.
Questions teams ask when their inventory stops making sense
Is every duplicate account a problem?
No. Multiple accounts can serve distinct authorised purposes. Investigate whether their relationship, owner and permissions are understood. Similar names or a high account count do not establish that an account is unnecessary.
Can identity sprawl exist in a small organisation?
Yes. The defining issue is lost context, not a minimum employee count. A few disconnected applications and unclear ownership can create uncertainty even when the total identity population appears manageable.
Does a central directory resolve the whole problem?
A directory is valuable, but local application accounts and non-human identities may have separate lifecycles. Governance needs to relate those records to accountable owners and access decisions rather than assuming directory membership explains every grant.
Should ownerless service accounts be deleted immediately?
No. Investigate purpose and dependencies, establish responsibility and plan the appropriate change. Blind removal can disrupt a legitimate workload. Ownership and operational review should precede retirement decisions.
Where do access reviews help most?
Reviews help owners reconsider existing entitlements using the relevant context. They complement lifecycle work rather than replacing it. A revoke choice also needs subsequent fulfilment; otherwise the decision remains unfinished.
How can a team tell whether the situation is improving?
Look for better explanations and completed decisions: fewer unresolved ownership questions, clearer grant paths and less unfinished lifecycle work. Define the population and measurement method before comparing results. Do not treat a smaller inventory alone as proof of better governance.
Bring a confusing identity relationship into the demonstration
Select an application where accounts, owners and permissions no longer line up cleanly. Use Citadel Identity360 to explore the identity graph, lifecycle handling and review decision for that population. Request Demo with that scenario, or use the product video preview to choose the workflow you want to examine first.