As phishing remains the leading vector for initial access, according to the ENISA Threat Landscape 2025, a terminated employee's account cannot be treated as a mere technical formality. It is a potential channel for unauthorized entry, especially when access is distributed across IAM, VPN, SaaS applications, repositories, cloud resources, and service accounts.
Therefore, offboarding must be more than just an HR procedure; it should be a managed 24-hour security transaction with a clear trigger, designated owners, forced termination of active sessions, network access closure, auditing of local SaaS accounts, and the transfer of rights to critical resources before user deletion.
Anatomy of risk: why a 'forgotten' account becomes an entry point
The Cisco Cybersecurity Readiness Index 2025 identifies Identity Intelligence as a key pillar of readiness against modern cyber threats. For offboarding, this translates to a simple practical requirement: an organization must know exactly where an employee's identity exists, what permissions they hold, and which sessions or tokens remain active after their status changes in the central directory.
The problem arises when the central IAM is not the single source of truth. An employee can be quickly disabled in an IdP or Active Directory, but access may persist in a SaaS application with a local account, a VPN session without forced termination, a personal API key, or a shared service account where the password was never changed.
In a broader context, identity misuse carries a tangible financial cost: the CFCA Global Fraud Loss Survey 2025 notes that subscription fraud, which can include the misuse of identities, leads to billions in annual global losses. While this is not a direct assessment of losses from corporate offboarding, it illustrates why identity has become a distinct object of risk control.
A separate scenario involves access to web resources or administrative panels. Google Search Central documentation regarding hacked content describes the risks of unauthorized access, which can lead to content replacement, injection, or concealment. For corporate teams, this is another argument against leaving 'dormant' accounts after termination.
Typical points of failure to check in every offboarding process:
- SaaS access persists because the user was managed locally rather than through a centralized IAM or SSO;
- An active VPN session is not terminated due to the lack of a forced session timeout or manual tunnel disconnection;
- The password or secret of a shared service account is not rotated after a developer or administrator leaves the team;
- Ownership of critical files, repositories, cloud resources, or API keys is not transferred before the user is blocked or deleted.
Step 1: central IAM and forced session revocation
The first step is to identify the primary source of identity: IdP, Active Directory, Google Workspace, or another central directory. This is where the employee's status must change, and all dependent systems must receive this update via integrations, rules, or a controlled operational process.
However, blocking an account does not always mean all active sessions are terminated. In modern SaaS and cloud services, a user may have web sessions, mobile sessions, OAuth tokens, or other long-term authorizations. Therefore, the protocol must include a specific action: Session Revocation—the forced termination of active sessions and tokens where supported by the service.
A practical sequence for the first few hours: receive a confirmed HR trigger, block the user in the central IdP, revoke active sessions, remove the user from access groups, verify delegated rights, and record the result in an audit log. If some services do not support automatic revocation, they must be included in a manual checklist.
Step 2: VPN, corporate networks, and PAM
After the central IAM, the network perimeter must be closed: VPN, access to corporate networks, bastions, administrative consoles, and Privileged Access Management (PAM) systems. It is especially important to check not only future access rights but also current active sessions.
If a VPN session remains active after a user is blocked in the directory, the organization maintains an open network channel. Therefore, the offboarding playbook must include actions for forced termination of VPN tunnels, verification of session timeouts, and revocation of privileged roles in PAM. For accounts with administrative rights, this should be a priority within the first few hours, not a final step at the end of the day.
In a Zero Trust architecture, this control must be continuous: access to a resource is not considered secure simply because the user has already authenticated. For offboarding, this means that a change in identity status must quickly affect all access channels, not just new login attempts.
Step 3: inventory of SaaS and local accounts
The most complex part of offboarding is SaaS applications that are not connected to SSO or SCIM. This is where the gap between the HR event and actual access revocation often occurs: the user is already blocked in the central directory, but the local account in the service remains active.
The target architecture is to integrate all corporate SaaS into a central IAM provider and manage the account lifecycle via SSO and, where possible, SCIM. This allows for tying creation, role changes, and deactivation to a single source of identity. If a service does not support such integration, it should not remain 'invisible': a registry is required, detailing the system owner, access type, deactivation method, and expected execution time.
For practical control, SaaS should be divided into three groups: those integrated with IAM and managed automatically; those partially integrated, requiring administrator verification; and local or exceptional systems that are deactivated manually. The third group must be regularly reconciled with HR data and the offboarding log.
Step 4: service accounts, secrets, and ownership transfer
Service accounts are dangerous because they often do not formally belong to one person but are effectively controlled by a specific developer, administrator, or team. If an employee had access to a shared password, secret, private key, or API token, blocking their personal account does not eliminate this risk.
Therefore, offboarding for technical roles must include a specific procedure: inventory of personal and shared keys, rotation of secrets, verification of repositories and cloud resources, and the transfer of ownership for system or group accounts. Deleting a user before transferring ownership is dangerous: it can lead to a loss of control over a resource or leave an active key without a clear owner.
The rule for service accounts is simple: they must have a designated owner, minimal necessary permissions, regular secret rotation, and usage auditing. Automation is useful here, but it does not replace the need for confirmation: who checked the keys, what exactly was rotated, and where this was recorded.
The 24-hour protocol: audit trails instead of verbal confirmations
The 24-hour window should be treated as an internal security SLA: not 'when the administrator has time,' but a controlled process with a deadline, owners, and proof of execution. Each action must leave a trail: who initiated the offboarding, who blocked the account, which sessions were revoked, which SaaS were checked, which secrets were rotated, and to whom ownership was transferred.
Automated tools significantly accelerate offboarding, but in environments with high security requirements, they should not be the only proof. It is worth maintaining an independent audit trail: tickets, system logs, confirmations from application owners, and a final record of process completion within 24 hours.
In custom development projects and the construction of secure corporate systems, Intecracy Group—an alliance of independent companies linked by partner agreements and share exchanges—can implement such mechanisms at the architectural level: IAM integration, role management, event logging, and account lifecycle control. If a solution is built on the UnityBase platform, relevant platform mechanisms can be used, including Domain metadata, generated API, RBAC/RLS, and audit trails; specific advanced access control capabilities depend on the edition. This does not replace a corporate IAM, but it helps make the application layer manageable and auditable.
Hourly offboarding transaction checklist
Below is a practical guide for the 24-hour window. The specific order may vary depending on the architecture, but all points must be covered by the protocol.
- Hour 1: Block the account in the primary source of identity: IdP, Active Directory, Google Workspace, or another directory.
- Hour 2: Forcefully revoke active web sessions, OAuth tokens, and personal access tokens in cloud services where supported.
- Hour 4: Deactivate access to VPN, corporate networks, bastions, and Privileged Access Management systems; terminate active sessions.
- Hour 8: Check SaaS systems not integrated with SSO or SCIM and manually block local accounts.
- Hour 12: Rotate secrets, passwords, and keys for shared service accounts to which the employee had access.
- Hour 16: Transfer ownership of critical files, code repositories, cloud resources, API keys, and automations.
- Hour 24: Close the offboarding ticket, collect confirmations from system owners, and record the full audit trail.
Reliable offboarding does not guarantee the complete elimination of insider risks. However, it drastically reduces the attack surface, removes 'dormant' accounts from the corporate environment, and provides the CISO and IT director with verifiable proof that access was revoked not 'sometime after termination,' but within a defined window.
FAQ
How do I forcefully close an active user session in Office 365 or Google Workspace during an urgent termination?
First, block the user in the central identity source, then initiate a sign-out or revoke sessions for active sessions and tokens via the administrative console or available API/CLI. Afterward, check mobile and web sessions, access groups, and record the action in the audit log. The specific command depends on your tenant configuration and organizational policies.
What should be done with API keys and service accounts created by a terminated developer?
You must not simply delete the personal account; you need to conduct an inventory of keys and secrets, transfer ownership to a system or group account, rotate shared passwords and tokens, and check repositories, cloud resources, and automations where these keys may have been used.
How can offboarding be automated for SaaS applications that are not integrated with SAML/SSO?
For such services, a registry of local accounts is required, including the system owner, deactivation method, and target execution time. Automation can be built around tickets, reminders, APIs where available, and mandatory reconciliation with HR status. In the long term, such SaaS should be prioritized for SSO/SCIM integration or for replacing the access management process.