Least privilege in practice: why access needs to shrink, not just grow faster

In many companies, access rights accumulate by the same logic. An employee joins - they are given access to a system. Their responsibilities grow - another access is added. They move to a different team - the old access stays, new access is added on top. They leave - revocation happens a week later, or not at all.

A few years in, the picture looks like this: nobody knows who has access to what. An audit is impossible because there is no current registry. Rolling anything back is impossible because it is not clear what is still in use.

This is not a story about malicious intent. It is a story about the absence of a lifecycle.

Why least privilege stays on paper

The principle is well known: every user and every system should have exactly as much access as is needed to do their job - and no more.

In practice it breaks down for a few consistent reasons.

Granting access is fast and easy. Revoking it requires knowing what to revoke. If the revocation process is inconvenient or not automated, it gets deferred.

Nobody wants to be blamed for "breaking something by removing access". This creates persistent pressure toward expanding permissions, not narrowing them.

Role changes inside a company often do not reflect in systems. Moving from engineering to product management does not automatically trigger a rights review.

The result: access rights move in one direction - they accumulate.

What happens when this is not addressed

The consequences come in two forms - external and internal.

External scenario: a compromised employee account with accumulated permissions gives an attacker access to far more than the employee's actual role required. The attacker moves through systems using what was granted "just in case" at some point in the past.

Internal scenario: a former employee or contractor retains access after the relationship ends. In most cases this is not used maliciously - but sometimes it is. And even when it is not, the company is carrying a risk it does not need - the same risk described in the context of remote contractors as a second risk perimeter, from a different angle.

In both cases the problem is not that something bad happened. The problem is that something bad became possible, because of decisions made once for the sake of convenience.

What actually works in practice

You do not need to build a complex identity management system to substantially improve the situation. A few practices deliver results at reasonable cost.

Regular audits of active access - quarterly or twice a year. Not necessarily automated, but systematic. Who is in the system, what rights they hold, whether they are still active.

A mandatory checklist at the point of departure and role change. Not one responsible person, but two - the manager and IT. A defined list of systems where access is revoked immediately.

A distinction between role-based access and task-based access. Task-based access is granted for a period and revoked automatically or on an event.

Documenting the reason for granting elevated access. If nobody can remember a year later why it was issued, that is sufficient grounds for revocation.

Questions for a quick self-assessment

If you are not sure where you stand, honest answers to a few questions will give you a baseline:

1. Do you have an up-to-date list of who has access to which systems?
2. When was the last time you audited active accounts?
3. How recently did an employee leave without having their access revoked on the day of departure?
4. Do you have contractors or temporary staff with access that remained active after the work ended?
5. If a regular employee's account were compromised tomorrow - which systems would the attacker reach?

These are not exam questions. They are a diagnostic. If the answers are uncomfortable, that is a signal that access lifecycle needs attention before it needs investigation.