Why deactivated users often still have access – and how to prevent this

Anyone who deactivates a user within a company usually assumes that this immediately terminates their access. In practice, however, this is often not the case. Although the user account is locked in the central identity provider, active sessions, valid tokens or locally managed accounts often still exist in connected applications. This is precisely where a significant security risk lies: organisationally, the user is already considered to have left the organisation, but technically they may still be able to access systems, data or applications under certain circumstances.

Particularly in modern IT environments featuring single sign-on, cloud services, federated identities and numerous third-party applications, this effect is not an exception but a structural problem. Anyone wishing to implement proper offboarding, robust access control and consistent identity security must therefore do more than simply mark a user as ‘deactivated’ in the directory. It is crucial that access is terminated immediately and across all systems involved.

Why a deactivated user isn’t always really ‘out’

The most common misconception in identity and access management is to equate account deactivation with the immediate revocation of access. Whilst these two processes are related, they are not technically identical. The identity provider can block new logins, but existing sessions in target applications often continue to run. Many applications manage their sessions locally and do not automatically receive real-time notification that the user has since been blocked in the primary system.Anyone who deactivates a user within a company usually assumes that this immediately terminates their access. In practice, however, this is often not the case. Although the user account is locked in the central identity provider, active sessions, valid tokens or locally managed accounts often still exist in connected applications. This is precisely where a significant security risk lies: organisationally, the user is already considered to have left the organisation, but technically they may still be able to access systems, data or applications under certain circumstances.

Particularly in modern IT environments featuring single sign-on, cloud services, federated identities and numerous third-party applications, this effect is not an exception but a structural problem. Anyone wishing to implement proper offboarding, robust access control and consistent identity security must therefore do more than simply mark a user as ‘deactivated’ in the directory. It is crucial that access is terminated immediately and across all systems involved.

Why a deactivated user isn’t always really ‘out’

The most common misconception in identity and access management is to equate account deactivation with the immediate revocation of access. Whilst these two processes are related, they are not technically identical. The identity provider can block new logins, but existing sessions in target applications often continue to run. Many applications manage their sessions locally and do not automatically receive real-time notification that the user has since been blocked in the primary system.

This is particularly relevant for zero-trust architectures. In such architectures, trust is not granted once and for all, but is continuously verified. This is precisely why event-driven mechanisms such as CAEP are so important: they help to bridge the gap between identity status and technical access enforcement.

The real solution is a well-designed IAM architecture

Organisations should not view the problem in isolation. It is not simply a matter of enabling a standard such as SCIM, CAEP or back-channel logout. It is about building an IAM architecture in which these mechanisms mesh seamlessly. A robust model starts in the primary identity system, automatically propagates status changes to the target systems, terminates active sessions and continuously reassesses security-related events.

This is precisely where the COMPRISE environment offers significant added value. In many organisations, the challenge is not that standards are unknown, but rather that they are not consistently implemented across established system landscapes. Diverse applications, proprietary interfaces, legacy authorisation models and inconsistent levels of integration mean that, although access revocation is intended, it is not technically implemented correctly in all cases.

A practical approach must therefore take into account both the architecture and the operational implementation. This includes selecting appropriate standards, analysing the target applications, verifying the actual support for provisioning and logout mechanisms, and defining clear offboarding processes. Only in this way can an identity concept be transformed into a robust security process.

What companies should be paying particular attention to right now

Anyone wishing to reduce the risk of residual access should first check which applications actually create local user accounts and how these are managed. It must then be clarified whether automated deprovisioning via SCIM is supported and whether existing sessions can be terminated immediately when a user is deactivated. Equally important is the question of how long tokens and sessions remain valid and whether security-related status changes are propagated to applications in real time.

In practice, it is often the case that critical systems, in particular, do not have full standard support. In such cases, either compensatory measures or a prioritised modernisation of the integrations is required. From a security perspective, it makes sense to focus first on privileged access, administrative accounts, external users and highly sensitive applications. It is in these areas that the consequences of residual access are particularly severe.

Conclusion: Deactivation is only effective if access is blocked everywhere

Deactivated users often retain access because identity status, target applications, sessions and tokens are not automatically synchronised in distributed environments. Simply locking the central account does not necessarily terminate existing sessions, local accounts or access tokens that have already been issued. This is precisely what creates the dangerous windows of opportunity during which former or locked-out users may still be technically active.

The solution lies in a holistic approach: SCIM deprovisioning reduces local residual accounts, back-channel logout terminates active sessions, and CAEP enables continuous, event-driven access assessment. It is only through this interplay that offboarding becomes not just an administrative formality, but also technically effective.

For organisations looking to modernise their IAM and security architecture, this is no minor issue. It is a key component of robust access control. In the context of COMPRISE, this is particularly evident: it is only through seamless integration, standardised interfaces and end-to-end automation that deactivation becomes a genuine, immediate withdrawal of access.This is particularly relevant for zero-trust architectures. In such architectures, trust is not granted once and for all, but is continuously verified. This is precisely why event-driven mechanisms such as CAEP are so important: they help to bridge the gap between identity status and technical access enforcement.