Deprovisioning: Are You Really Removing Access, or Just Disabling an Account?

In identity management, a lot of attention is given to login, MFA, SSO, passwords, passkeys, permissions, and access models. Organizations invest in increasingly advanced authentication and authorization mechanisms, build access request processes, design roles, policies, and approval paths.

But there is one phase of the identity lifecycle that is still too often underestimated.

Deprovisioning.

In other words: removing access.

At first glance, it sounds simple. An employee leaves the company, the account is disabled, access disappears. Problem solved. Except that, in reality, this is often where the problem begins. Because deprovisioning is not only about disabling an Active Directory account or blocking an email inbox. True access removal means revoking or invalidating every possible way a person, technical account, or machine identity can act across all systems, applications, and environments.

And that is much harder than it seems.

Creating Access Is Easy. Removing It Is Not.

In most organizations, the access granting process is relatively well defined. A new employee joins the company. HR starts the onboarding process. IT creates the account. A manager approves permissions. The user gets access to email, business systems, SaaS applications, VPN, repositories, project tools, and cloud environments. Of course, this can also be complex, but organizations usually give this phase a lot of attention.

Why? Because without access, the user cannot work. The problem is that the same level of attention is not always given to the moment when that access should disappear. And from a security perspective, this moment is critical. An employee changes departments. A contractor finishes a project. An administrator moves to a different role. A supplier contract ends. A service account is no longer used. Yet an API token, certificate, SSH key, or SaaS application access still works.

That is where the risk appears.

Deprovisioning Is Not Just About a User Account

One of the biggest mistakes is assuming that access is centralized and easy to remove. Many organizations still believe that disabling one main account is enough, and that all dependent access will automatically disappear.

In practice, access is distributed.

It may exist in:

• Active Directory
• Entra ID
• SaaS systems
• admin panels
• DevOps tools
• cloud environments
• on-premises applications
• VPN
• databases
• APIs
• certificates
• tokens
• technical accounts
• shared logins

Then there is shadow IT: applications and services used outside official IT control.

A user may have gained access to a tool that nobody centrally monitors. They may have been added to a workspace by another user. They may have generated a token that remains active after they leave. That is why disabling an account in one system does not mean that access has truly been removed. It only means that the most visible part of the problem has been addressed.

The Most Common Deprovisioning Blind Spots

In practice, the greatest risk is often not where the organization looks most often. It is not only about active employee accounts. The real problem is access left behind after organizational changes, completed projects, or old integrations.

1. Orphaned user accounts

These are accounts belonging to people who no longer work for the organization, but still exist in selected systems. Sometimes they are inactive, sometimes nobody monitors them, and sometimes they still hold permissions.

2. Zombie service accounts

These are technical accounts that were once needed, but today nobody knows who owns them. These accounts often have elevated permissions because they were created to “just work.” If they have no owner, nobody verifies whether they are still necessary.

3. API keys and tokens

A user may change roles or leave the company, but a previously generated token may still allow access to data or systems. Long-lived tokens that do not automatically expire are especially dangerous.

4. Certificates, SSH keys, and trusted technical credentials

These can remain active long after a person or system has stopped serving its original purpose.

5. Shared accounts

If multiple people use the same login, it becomes difficult to clearly identify who actually had access, who used it, and whose access should be removed. All of this shows that deprovisioning is not a simple administrative task. It is one of the key processes in identity security.

Why Is This So Dangerous?

Some security breaches do not start with active users. They start with accounts the organization has forgotten. A former employee still has access to a SaaS application. A contractor kept a key to a repository. A technical account has excessive permissions. An integration token still works after the project has ended. An administrator changed roles, but some old privileges remained active. From an attacker’s perspective, this is an ideal situation. These types of access are often less monitored. They do not generate obvious alerts. Nobody expects activity from them, but at the same time, nobody actively removes them. If an attacker takes over such an account or credential, they can gain access without having to break the main security controls. Then the problem is not a lack of MFA, a weak password policy, or the absence of an IAM tool. The problem is that access that should have disappeared still exists.

Deprovisioning Must Be a Process, Not a Checklist

In many companies, offboarding still relies on manual task lists. Someone has to remember to remove access from one system. Someone else has to remove the user from another application. Another person has to check VPN, licenses, groups, repositories, project tools, and financial systems. This model only works up to a point. The more applications, cloud services, integrations, technical accounts, and external teams there are, the higher the risk that something will be missed. And in a modern environment, even one missed access path can become a real security gap. That is why deprovisioning should be treated as a continuous, automated, and auditable process.

Deprovisioning should be:

1. Immediate

Removing access should not take days or weeks. When an employee leaves, a contract ends, or an incident occurs, access should be revoked within minutes.

2. Automated

The best source of signal is usually the HR system or workforce management process. A change in employee status should automatically trigger the right actions in IAM, IGA, directories, applications, and dependent systems.

3. End-to-end

The process cannot be limited to user accounts only. It must also cover technical accounts, integrations, tokens, certificates, and machine identities.

4. Auditable

The organization must be able to prove that access has been removed. It is not enough to assume that it happened. There must be a record of actions, execution status, and reporting capability.

5. Continuous

Deprovisioning should not happen only when someone leaves the company. It should also be triggered by role changes, team changes, project completion, supplier changes, or application retirement.

Access Should Expire by Default

One of the most important principles of modern identity security is the assumption that access should not be permanent. If access is needed only for the duration of a project, it should expire when the project ends. If a technical account exists for a specific integration, it should have an owner, a defined scope of responsibility, and a review date. If a token is generated for a specific purpose, it should have a limited lifetime. Access that must remain active should be explicitly justified. This reverses the traditional way of thinking. Instead of assuming that once access is granted, it stays active until someone manually removes it, organizations should assume that access expires unless there is a clear reason to keep it. This approach significantly reduces the risk of forgotten accounts, excessive permissions, and uncontrolled credentials.

What Should You Check in Your Organization?

A good starting point is a set of simple questions:

• Do you know which systems are covered by automated offboarding and which still require manual handling?
• Can you identify all active accounts belonging to former employees and contractors?
• Do technical accounts have owners?
• Do tokens, API keys, certificates, and SSH keys have expiration dates?
• Does a role change automatically remove old permissions, or does it only add new ones?
• Can you prove to an auditor that access has actually been removed?

If the answer to some of these questions is “we don’t know,” then deprovisioning is probably not yet fully under control.

Conclusion

Identity security does not end when a user logs in successfully. It also does not end when access has been granted correctly. The real maturity test is whether the organization can remove access quickly, completely, and in a way that can be proven. Because identity security rarely fails at the moment access is granted. It fails when access is not removed. That is why deprovisioning should not be treated as an administrative formality at the end of the employee lifecycle. It should be one of the central processes of IAM, IGA, and Zero Trust.

So the question is not:

Do we disable accounts when employees leave?

The real question is:

Are we truly removing access everywhere it can still work?