Privilege escalation: why access control is an operations problem
Why most serious incidents begin inside the perimeter, and how to think about privilege management as a continuous process rather than a project.
Most companies spend significant resources defending the perimeter: firewalls, intrusion detection systems, antivirus. That is reasonable. But incident statistics tell a different story: a large share of serious breaches originate not from outside, but from inside - through accounts with excessive rights that are already in.
This is not necessarily malicious action. More often it is a compromised account, a configuration error, or a former employee whose access was not revoked in time.
What privilege escalation is
Privilege escalation is a situation where a subject - a user, a process, a program - gains access to resources or actions that go beyond their legitimate authority.
This happens two ways. Vertical escalation: an ordinary user gains administrator rights. Horizontal escalation: a user gains access to another user's data at the same level.
In a corporate environment both forms are common - and most often they appear not as attacks, but as the result of careless access management.
How excess rights accumulate
Rights have a tendency to only grow. An employee needs temporary access to a system for a project - it is opened and never closed. A developer needs admin rights in the production database for debugging - and they stay permanently. A departing employee was in several access groups - the account was deactivated, but service tokens and API keys remained.
Over time the picture becomes opaque. Nobody knows exactly who has what rights. Nobody remembers why a specific account needs a specific access.
This is not a sign of a bad team. It is a sign of a missing process.
Why this is an operations task, not a project
Access management cannot be "done once." Rights need to be reviewed regularly because the situation constantly changes: people join and leave, roles change, projects end, systems come and go.
The project approach looks like this: clean things up, report it done, forget. Six months later everything is back to where it was.
The operations approach looks different: there is an onboarding process that grants the minimum necessary rights; there is an offboarding process that reliably closes all access points; there is a regular audit - quarterly or twice a year - that checks whether actual rights match current roles.
The practical minimum
Not every company can afford a full IAM system right now. But there is a minimum that is realistic for most:
- An up-to-date list exists: who has access to what, on what basis.
- Offboarding includes an explicit access checklist - not just deactivating the AD account.
- Privileged access (admin rights, production data access) is granted explicitly and with a defined expiry, not by default.
- Once a quarter someone looks at the list of privileged accounts and asks: is this access still needed?
This is not sufficient for mature security. But it is meaningfully better than doing nothing.
A question for the manager
One question worth asking your team: if an employee resigned yesterday - within how many hours do they guaranteed lose all access to all systems? If the answer is "we don't know" or "it depends on the system" - that is the starting point for the conversation.