When an employee leaves a company, disabling their accounts can look like one of the simplest tasks in cybersecurity. Yet a case recently described by The Register demonstrates how a basic failure in employee offboarding can escalate into a major security incident, causing hundreds of thousands of dollars in damage and delaying an important project for weeks.
The incident was shared by Yad Senapathy, CEO of the Project Management Training Institute, who recalled an experience from earlier in his career while working in IT at an organization with more than 1,000 employees. The company terminated an employee, but the departure process contained a critical oversight: nobody actually revoked the former worker’s access to internal systems.
For several days after leaving the company, the employee’s credentials remained active. That window was enough for the former worker to reconnect to corporate systems and deliberately cause damage, including deleting files, locking other employees out of accounts and corrupting a database. What should have been a routine administrative process had effectively left a privileged insider with functioning credentials and little preventing them from returning to the environment.
The underlying problem was not a sophisticated technical vulnerability or an advanced cyberattack. Instead, it was an organizational failure involving unclear responsibility between human resources and IT. HR apparently expected the technology team to disable the accounts once the termination had been processed, while IT was waiting for HR to formally request that the access be removed. With neither side clearly responsible for completing the task within a defined deadline, the employee’s credentials remained operational.
That communication failure became particularly dangerous because the former employee had considerably more privileges than an ordinary user. The individual reportedly retained access to shared administrative credentials, account-management capabilities and project-tracking systems. Those systems provided pathways into additional resources, creating a chain of access that allowed the former employee to disrupt multiple parts of the organization’s infrastructure.
The financial consequences were severe. Senapathy estimated that the damage ultimately cost the organization hundreds of thousands of dollars, while recovery efforts delayed an important project by several weeks. The situation was complicated further because the employee responsible for damaging the systems was also one of the people who understood them best, leaving the remaining staff with the difficult task of recovering infrastructure without the knowledge of the person who had previously managed significant parts of it.
The case illustrates why insider threats should not automatically be associated with highly sophisticated attackers. A disgruntled employee does not necessarily need malware, zero-day vulnerabilities or advanced hacking techniques when valid credentials already provide access to sensitive infrastructure. From the perspective of many security controls, a former employee using an account that has not been disabled can initially look almost identical to a legitimate worker signing into the environment.
This makes identity management one of the most important layers of modern enterprise security. Organizations frequently invest significant resources in firewalls, endpoint protection, vulnerability management, intrusion detection and sophisticated security monitoring, but those defenses become much less effective when an attacker can simply authenticate with legitimate credentials that the company forgot to revoke.
Employee offboarding should therefore be treated as a security event rather than purely an HR procedure. The moment a termination becomes effective, organizations should have a predefined workflow that disables the employee’s primary identity, invalidates active sessions, revokes authentication tokens and removes access to applications, infrastructure, cloud services and administrative interfaces.
For employees with elevated privileges, the process needs to go significantly further. Shared passwords may need to be rotated, API keys replaced, SSH keys removed, certificates revoked and service accounts reviewed. Organizations should also examine whether the departing employee created automation, scheduled jobs, integrations or other mechanisms capable of continuing to interact with systems after their personal account has been disabled.
Cloud and SaaS environments make this problem even more complicated. An employee might have accounts across Microsoft 365, Google Workspace, AWS, Azure, GitHub, Jira, Slack, Salesforce and dozens of specialized applications. Some services may use centralized single sign-on while others maintain independent credentials, meaning that disabling the primary corporate account does not necessarily eliminate every possible route back into the organization.
OAuth integrations introduce another layer of complexity because applications can sometimes continue operating through previously granted tokens. Similarly, API credentials or personal access tokens may remain valid independently of the employee’s password. A mature offboarding process therefore needs to identify credentials beyond conventional usernames and passwords and determine which authentication mechanisms must be revoked or rotated.
The incident described by Senapathy also demonstrates the risks associated with shared administrative credentials. When several administrators know the same password, organizations can lose the ability to reliably determine who performed a particular action. More importantly, removing one employee may require changing credentials used by several other people or systems, which can make administrators reluctant to rotate them quickly.
Modern privileged access management practices attempt to reduce this dependency by giving administrators individual identities rather than permanent shared credentials. Temporary elevation, just-in-time access and tightly controlled privileged accounts can make it easier to revoke one person’s permissions without disrupting everyone else. These approaches also create clearer audit trails, allowing security teams to associate sensitive actions with specific identities.
Another lesson concerns excessive concentration of technical knowledge. The organization had allowed one employee to accumulate substantial understanding and control over important systems. That created both a security risk and an operational dependency, because removing the employee also removed knowledge that the company needed to recover from the incident.
Organizations can reduce this risk through documentation, cross-training, peer reviews and separation of duties. Critical systems should not depend entirely on a single administrator who understands their architecture, credentials, recovery procedures and operational dependencies. Even without malicious behavior, the sudden departure of such an employee can create serious business continuity problems.
Automation can also dramatically reduce the opportunity for human error during offboarding. Instead of relying on someone in HR to email someone in IT, termination events can trigger predefined identity-management workflows. These workflows can automatically disable accounts, revoke sessions, remove group memberships, notify security teams and create tasks for application owners responsible for systems that cannot be automatically disconnected.
Timing is especially important when an employee is terminated involuntarily. In these situations, disabling access hours after the termination meeting may already be too late. Account revocation should ideally be coordinated with the termination itself so that access disappears immediately when the employee is informed that their employment has ended.
Security teams should also consider monitoring activity around employee departures. Attempts to download unusual quantities of data, access repositories unrelated to normal responsibilities, create new credentials or modify administrative permissions shortly before departure can indicate elevated risk. Such monitoring needs to respect applicable employment and privacy regulations, but organizations should have mechanisms for detecting suspicious activity involving privileged accounts.
The principle of least privilege provides another important defense. Employees should only have access to the resources required for their responsibilities, and privileges accumulated through previous roles should be periodically reviewed and removed. Without these reviews, long-serving employees can gradually accumulate access to numerous systems, turning their accounts into increasingly powerful targets and making eventual offboarding considerably more difficult.
This is particularly relevant when employees change roles internally. Someone who moves from infrastructure engineering to another department may retain permissions from their previous position unless the organization performs regular access certification. Years later, security teams may discover that the employee still has administrative privileges nobody remembered existed.
Effective identity governance therefore requires continuous lifecycle management rather than a single check when someone joins or leaves the company. Access should be reviewed when employees are hired, when they change teams, when they receive temporary privileges and when they depart. Privileged access should receive even greater scrutiny because the potential consequences of forgotten permissions are substantially higher.
The case also exposes an organizational problem that appears repeatedly in security incidents: ambiguous ownership. HR assumed IT would perform the technical work, while IT expected HR to initiate the request. Both processes may have seemed reasonable independently, but the gap between them created the vulnerability.
Security procedures should eliminate this ambiguity by assigning explicit ownership and measurable deadlines. A termination workflow should identify who initiates the process, who confirms account revocation, who handles privileged credentials and who verifies that the process has been completed. For high-risk departures, security personnel may also need to independently confirm that no unexpected access remains.
Organizations can test these procedures in much the same way they test disaster recovery plans. Security teams can periodically select former employees and verify whether their accounts, tokens, VPN access, SaaS identities, repository permissions and administrative privileges have actually been removed. Discovering that a former employee can still access a forgotten database months after leaving should be treated as evidence of a systemic identity-governance problem.
The Register’s own article provides a striking example of how common these gaps can be. Its author recalled leaving a previous employer and losing access to email, chat and shared drives, only to discover months later that credentials for an externally hosted database still worked when a former manager asked for assistance accessing it. The primary corporate accounts had been removed correctly, but an external system had apparently escaped the offboarding process.
The most important lesson from these incidents is that security failures do not always begin with sophisticated exploitation. Sometimes the organization has already given the attacker everything required to cause damage and simply forgets to take it back.
A company can deploy advanced endpoint detection, zero-trust architectures and sophisticated threat intelligence, but none of those investments eliminate the need for disciplined identity lifecycle management. When an employee leaves, every credential, privilege and access path associated with that identity needs to be understood and appropriately revoked.
In the incident described by Senapathy, the damage could reportedly have been prevented through same-day access removal, reviews of shared accounts and policies preventing a single individual from becoming the sole owner of critical systems. Those controls are technically straightforward compared with many modern cybersecurity defenses, but their effectiveness depends on organizations implementing them consistently.
Ultimately, employee offboarding is not simply the final administrative step in someone’s employment. It is the final stage of that person’s identity lifecycle inside the organization, and failures at that stage can transform legitimate credentials into an immediate insider threat. The hundreds of thousands of dollars reportedly lost in this case provide an expensive reminder that sometimes the most important security control is simply making sure the door actually locks after someone leaves.