Departing employees and changing roles between staff can result in overlooked access rights.
A disabled email account might not always mean all associated credentials, open application sessions, or privileged rights have been removed.
With any IT team, offboarding isn’t a simple task of deleting a user; it involves the directory, Microsoft Entra ID, file shares, SaaS applications, privileged accounts, and 3rd-party integrations.
A checklist helps security teams to identify and close these gaps before they become an attacker’s golden ticket.
10 Offboarding Security Risks IT Departments Need to Address Correctly
1. Active Directory Accounts Going Stale
Deleting a user’s primary account is merely the opening round. Many outdated profiles, orphaned accounts, or third-party accounts associated with departing contractors still linger in Active Directory databases.
Attackers seek to take advantage of any orphaned credentials in Active Directory when the password for a user’s account isn’t particularly strong or when an account has been unnecessarily overauthorized.
What must IT departments do?
• Pinpoint any leftover user or contractor accounts.
• Nullify the associated accounts in a timely manner, and strip out any unnecessary associations with groups.
• Go through Active Directory every so often to look for any leftover accounts or accounts that were blatantly added and shouldn’t have been in there in the first place.
2. Microsoft Entra ID Sessions and Tokens
Deleting a user from the organisation does not mean every single user session miraculously comes to an end. There are refresh tokens, application sessions, and other things that are responsible for user authentication.
Microsoft Entra ID deserves a special mention, as it’s used by users to access SaaS applications across a variety of devices.
What must IT departments do?
• Where possible, nullify the sign-in sessions and the refresh tokens.
• Drop accounts.
• Look at any accessed devices and any other associated authentication methods to address the loose ends.
• With associated applications, it is also necessary to ensure loose ends are tidied up.
3. Missed SaaS Apps
Users are using apps that have not been approved or even allowed by IT teams. This could relate to a marketing tool, a project management system, cloud storage, or a CRM system for managing customers.
These present the biggest worry, as due to the lack of centralised control, more often than not, they can be left alone for a long time after the fact, as participants use a different, standalone username.
What must IT departments do?
• Keep a list of approved SaaS apps as well as the discovered ones.
• Drop the user through the 3rd-party website, as well as the relevant identity provider.
• Transfer business-critical resources to another user/role.
4. Incredibly Permissive File Shares
Employees who have come and gone can continue accessing on-prem file shares, network drives, or cloud folders if users are granted access via static assignment and not instead by group membership.
A single over-permissive file share could be exposing client data, financial information, IP, or sensitive internal documents.
What IT needs to do:
• Identify file share permissions on file servers and cloud file services.
• Remove direct assignment and static group membership if they are no longer valid.
• Reassign file owners before disabling accounts.
5. Overlooked Privileged User Access
Privileged account access is even more dangerous than a standard user account. An employee may also have additional admin accounts for server management, database access, cloud accounts, security platforms, etc.
Simply turning off the employee’s account will not address the other admin accounts for the user.
What IT needs to do:
• Inventory all privileged accounts for their support and services.
• Remove admin roles and be sure to remove users from privileged groups as well.
• Reset any shared credentials if they have been exposed.
6. Orphaned Sharing Accounts & API Keys
Oftentimes, applications and automated processes are still using API keys and other credentials, often created or managed by the user who is no longer employed. The credential continues to function after the user is out.
In addition, some service or system accounts may be used in production systems for a service or function that would error or fail if the credentials were removed.
What IT needs to do:
• Find out where service accounts, API keys, certificates, and automation secrets are kept.
• Associate every account and credential with an owner or admin team by whom it can be managed.
• Reset any credentials that may have been leaked or are at risk.
7. VPN, Remote Desktop, and Endpoint Logins
Remote login credentials can allow unauthorised network and device access even after the employee account is disabled.
What IT needs to do:
• Disable any VPN and remote access credentials.
• Un-enrol device registrations and delete certificates if an employee has left.
• Securely reclaim or wipe managed devices.
8. Group Membership Cascades and Hidden Permissions
What to do:
• Query and validate groups and memberships (direct and inherited).
• Scrub distribution lists, security groups, application groups, site/admin roles, etc.
• Verify that no indirect or lateral access to critical (tier-0) assets remains after offboarding.
• Carefully record and validate any exceptions or in-flight requests that need to be temporarily carried over.
9. Third-Party Vendors/Contractors
External account holders tend to hang around and may have access to some systems even after the business relationship ends.
The account is theoretically still needed, especially if they will be asked to come back and do more business, but there’s no natural flow to deprovision the account like there is with full-time staffers.
What to do:
• Temporarily tie contractual accounts to a sponsor and contract end dates.
• Query and vet lists of non-employees for both vendor relationships and external identities.
• Revoke accounts/credentials/remote access as applicable for the contractor account holder.
10. Missing Approval, Audit Trail, or Verification Step
If you can’t audit it, you didn’t do it. If you can’t prove you offboarded some user, you can’t possibly be confident that you did.
What to do:
• Log when an offboard task is performed for a downstream system.
• Ensure lingering (non-failed) tasks are logged somewhere and assigned to someone (or discarded intentionally).
• Connect downstream systems to the User Service so you can prove that a user was deleted (and wasn’t in the “Do Not Delete Ever” group, etc.).
The NIST access control framework and CIS Controls have useful verbiage on both user account management and user review.
How the IGA (Identity Governance & Administration) System Helps Automate Secure Offboarding
Identity Governance & Administration (IGA) is a policy-based approach to identity management and access control.
By combining user-specific entitlements with centralised policy enforcement, Automated Identity Governance & Administration systems provide access controls to regulated systems.
Identity Governance and Administration (IGA) is a business-centric, risk-based appliance for identity lifecycle management.
Through identity governance automation, IGA solutions such as tenfold can connect HR events directly to identity and application provisioning workflows.
When termination is submitted (an HR event), defined policies can enforce compliance by deactivation, permission revocation, accountability to application owners, and logging for attestation.
Automation can also be used to find orphan accounts, require attestation workflows, and acknowledge or alert on out-of-policy risks.
Of course, these integrations, application coverage, and exceptions have to be configured. Some systems do not have auto-deprovisioning capability and still need to be logged with an owner and checked manually.
