Lateral movement is usually described as a network problem, yet in most enterprises it starts as an identity problem. Once an attacker holds a legitimate account, an application grant or a delegated role, the real question is no longer whether that identity can sign in. It is what else the identity is allowed to reach. Excess access tilts that answer toward the attacker, because every unjustified permission is one more authorised path to another system, dataset or service. Citadel Identity360 helps identity teams shrink that reachable set through lifecycle control, owner reviews and a connected view of who holds which access.
For a CIO or Head of IT, the issue is concrete: is your estate leaving unnecessary access in place after role changes, finished projects or accounts that should have been retired? Identity governance does not stop an intrusion while it is happening. What it does is cut the stale entitlements, broad grants and ownership gaps that turn one compromised identity into many reachable systems.
Why lateral movement belongs on the identity agenda
MITRE ATT&CK describes lateral movement as the techniques adversaries use to enter and control remote systems on a network. It notes that reaching an objective often means pivoting through multiple systems and accounts, and that using legitimate credentials with native tools may be stealthier than bringing in custom remote access tooling.
That is why identity teams should care. The foothold can be valid credentials, authentication material, an application permission or a delegated role that already exists in your estate.
Authentication establishes which identity is being presented. Authorisation decides what it can do and which resources it can touch. A successful sign-in proves only that the identity was accepted, not that its access is properly bounded.
So the security question moves from who is signed in to what this identity can effectively reach, and why. When a user, workload or application holds more authorisation than its current business need, compromising it exposes more of the environment than compromising a tightly scoped identity would.
How excess access enlarges the reachable set
Excess access means permissions exceed what the work currently requires. It appears in three familiar ways:
- Access was broad from day one because a template or a copied colleague profile was used.
- A role change added permissions and never removed the old ones.
- Temporary access was granted for a project or an incident and never expired.
Stale access is the same problem viewed through time. It is access that outlives its purpose, its owner, the employment relationship, the project or the agreed duration. It applies to employees and contractors, and equally to service accounts and machine identities, applications and AI agents.
The MITRE entry for Valid Accounts (T1078) makes the link explicit. It warns that adversaries may abuse inactive accounts, for example those belonging to people who have left the organisation, because nobody is present to notice odd activity. It also flags overlapping permissions across local, domain and cloud accounts as a concern, since an adversary may pivot across accounts and systems toward a high level of access. Its mitigations include routinely auditing accounts and permission levels, and removing accounts no longer needed.
Some jobs genuinely need wide access. The test is whether it is justified, owned, reviewed and removed once the justification ends.
Movers, leavers and expiries decide how far an attacker can go
Most access failures are lifecycle failures. A mover event should do more than add new rights. It should force a decision about what to remove, what to keep and what to revalidate. Leave the old permissions in place and a current employee keeps access tied to responsibilities they no longer hold.
The same pattern runs outside the employee lifecycle. Each of these events can make previously valid access obsolete:
- a contractor engagement reaching its end date
- a project closing or a workload being decommissioned
- the owner of a service account or agent leaving the company
- an AI agent being switched off or replaced
- a renewal that never happened
When none of those events is wired to a review or a revocation, privilege creep sets in. Changes stay additive and removal depends on someone remembering. The cost of weak deprovisioning is extra room for a compromised identity to move.
Identity lifecycle management is therefore not back-office tidying. It sets how much opportunity an attacker inherits after the first foothold.
Delegated authority hides some of the widest paths
Some of the most consequential paths are indirect. In cloud and application estates, a person may not need direct permission on a resource if they can hand authority to a service that already has it.
AWS documentation on passing a role to a service explains that the PassRole permission lets a user configure a service with an IAM role, which the service then assumes to act on the user’s behalf. The same page cautions administrators not to let a user pass a role that carries more permissions than that user should have, and gives the example of a person without storage rights who could still cause storage actions through a service.
That is a normal operating pattern, which is exactly why governance must include delegation edges, not only direct assignments. Should this identity be able to pass that role to that service, and is the role sized for the workload? Review only direct entitlements and you miss the delegated authority that quietly widens what a compromised identity can trigger.
Nested groups do something similar inside directories, as our article on group sprawl shows.
What governance can and cannot do about lateral movement
This is the strongest objection, and it deserves a straight answer. Identity governance is not an incident response tool and it does not sit in front of every request as a runtime enforcement layer. It does not replace cloud IAM, application controls, endpoint protection, monitoring or the security operations team.
What it changes is the quality of the access environment those controls work within. NIST SP 800-207 frames zero trust architecture as designed to prevent data breaches and limit internal lateral movement, and its first focus is restricting resources to those with a need to access them and granting only the minimum privileges needed for the mission. The NIST definition of least privilege describes the same discipline: a system should restrict the access privileges of users, or of processes acting for them, to the minimum necessary to accomplish assigned tasks.
Governance is how that principle survives years of reorganisations. It inventories identity-to-access relationships, assigns owners, records a business purpose, runs reviews on a schedule or after an event, and makes end dates meaningful.
Governance coordinates access decisions while connected systems apply the permissions. Expect it alone to block lateral movement and you overstate its role. Ignore it and you leave unnecessary authorisation lying around for someone else to use.
Six habits of a governance model that limits pivoting
- Connect each identity to its full access picture. A list of users is not enough. Link identities to accounts, entitlements, roles, applications, owners, purpose and approval context, including delegated and application-level access where the connected system exposes it.
- Make ownership explicit for every non-human identity. Every service account, workload identity, application grant and agent needs an accountable owner and a reason to exist. If nobody can explain why it exists, nobody can govern it. Our piece on console-created cloud service accounts covers the intake side of that problem.
- Treat role changes as subtractive triggers. A transfer or promotion should prompt a review of what comes off, not just what goes on.
- Run reviews that lead to action. Access reviews only reduce exposure when the right owner reviews the right scope and the decision is carried through to the connected system.
- Give privileged and administrative access its own scrutiny. Admin rights multiply reach, which is why privileged access reviews need reviewers who understand the systems involved.
- Prioritise by consequence and context. High privilege, sensitive data, broad delegation and poor lifecycle status deserve more attention than low-impact access. A usage signal informs a review; it is not automatic proof that removal is safe.
Where Citadel Identity360 shrinks the reachable set
Citadel Identity360 is the Astranova Labs identity governance and administration platform for human, non-human and AI agent identities across cloud, SaaS, on-premises and hybrid estates. It does not catch attackers mid-intrusion. It helps teams see, review and remove the access that gives an intruder somewhere to go.
Lifecycle events that remove access, not just add it. Citadel automates joiner, mover and leaver workflows with provisioning and deprovisioning orchestration, so a transfer or departure becomes a trigger to take access away. Integrated contractor lifecycle management keeps sponsors and engagement end dates attached to outside workers.
A connected view of access paths. The Citadel identity graph maps users, roles, applications and permissions as one network, and access path discovery traces a path from an identity to a resource, showing how the access was granted and who approved it. For a resource-first method, see our guide to tracing access paths to sensitive resources.
Cloud entitlements with their context. As part of its CIEM capability, Citadel pulls cloud entitlement data together with scopes, permissions, grants, usage and policies, and gives a 360-degree view of the key actions required. Delegation-heavy cloud roles stop being invisible to the governance team.
Risk scores you can tune. Citadel calculates customisable risk scores for the organisation, identities, departments, applications and managers. Teams aim review effort where misuse would matter most, and SoD conflict detection highlights toxic combinations.
Reviews and attestation with follow-through. A detailed access review module runs scheduled certification campaigns with risk context for each access item, and identity attestation asks owners to confirm that an identity should still exist. Revocation decisions are tracked from approval until fulfilled.
Owners for machines and agents. Service accounts, API keys and machine identities are governed from creation to decommissioning with an accountable owner at every stage. AI agents are discovered from the Microsoft Entra, AWS and Google Cloud registries and from endpoint agents that find AI agents running on endpoints, then brought into one governed inventory. MCP servers and agents are registered with owners and authorised per tool, and the AI-agent kill switch gives teams an intervention option when an agent needs to be contained.
Reach into older applications. For systems without modern provisioning interfaces, Citadel supports RPA-based application integration alongside connectors, directories, databases and file-based methods, so removal decisions can reach applications administered through their user interfaces.
An illustrative scenario
A finance analyst moves into a regional sales operations role. Their new access is provisioned on day one, but the old payments reporting role and a cloud role that can pass a data-export role to an automation service stay in place. Six months later, a phishing message captures the analyst’s credentials.
Under a weak lifecycle, the attacker inherits payments reporting and an indirect route to cloud data. Under a governed lifecycle in Citadel Identity360, the mover event opens a removal task for the finance entitlements, an access review with risk context puts the leftover cloud delegation in front of the new manager, and the decision is followed through to completion. The phishing attempt now lands on an identity scoped to its current job. This example is illustrative and does not describe a specific customer.
What IT leaders should take from this
Fewer identity pathways for lateral movement start with the access you already have. Stale permissions, orphaned accounts and unclear ownership hand a compromised identity more places to go. The leadership question is not whether access can be made perfectly safe. It is whether your organisation can justify each grant, name its owner, review it and remove it when the need ends.
FAQ: excess access and lateral movement
Is lateral movement always caused by stolen passwords?
No. Stolen passwords are one route. MITRE ATT&CK also lists techniques such as remote service sessions and alternate authentication material like tokens or tickets, and attackers can use application permissions or delegated roles that already exist.
How does excess access raise identity risk?
It gives a compromised identity more authorisation than its current task requires, which increases the number of systems and actions it can reach even if most of those permissions are rarely used.
Why do mover events matter so much?
New access is usually added quickly while old access is removed slowly or not at all. Over time that leaves people holding permissions tied to past roles, which is privilege creep.
Does Citadel Identity360 detect lateral movement?
Citadel Identity360 is an identity governance platform, not a runtime detection tool. It reduces the access an intruder could exploit through lifecycle automation, access path visibility, customisable risk scores, CIEM context, access reviews and identity attestation.
Do workloads and bots deserve the same scrutiny as staff?
Yes. They often hold broad, long-lived access with no person signing in, so each needs an owner, a purpose, periodic review and retirement.
Start with one over-reaching identity
Choose one identity that changed roles in the last year, or one service account whose owner has left, and trace everything it can still reach. Then bring it into Citadel Identity360, assign the owner, run the review and remove what no longer fits. Request Demo to walk through that path with our team, or preview the platform on the videos page.