Nobody Revoked His Access. He Noticed.
There's a particular breed of corporate own-goal that never goes away, no matter how many times it blows up in someone's face. Failing to revoke system access when you fire someone is one of them.
Yad Senapathy, now CEO of the Project Management Training Institute in Dallas, learned this lesson the hard way during his earlier career in IT at a company with over a thousand staff. Someone got terminated. Nobody turned off their accounts. The ex-employee, understandably furious, logged back in and made the organisation regret it, deleting files, locking out colleagues, and corrupting a database before anyone caught on.
The credentials stayed live for days after the person left payroll. HR assumed IT would handle it. IT was waiting on a formal request from HR. Classic organisational gap, where responsibility exists in theory and nowhere in practice.
'When nobody is clearly responsible and there is no set deadline, these things can easily get missed until there is already a problem,' Senapathy told The Register.
What made it worse was the scope of access this person still had. Shared admin credentials, account controls, project tracking systems, each of which opened doors to further systems. One set of live credentials became a master key. The damage ran to hundreds of thousands of dollars and added weeks of delay to a major project.
The recovery was grimly ironic. The person best placed to fix the damage was the one who had caused it.
Senapathy is clear that this wasn't a sophisticated attack. No zero-days, no clever exploits. Just an angry former employee with credentials that should have been dead on departure. 'We'd let one person collect so much system knowledge that shutting the door behind them took longer than it should have,' he said.
His prescription is simple: offboarding checklists need to treat access revocation with the same urgency as getting the laptop back. Same-day deletion of access, an immediate review of shared credentials, and a standing policy against any single person owning an entire system without oversight.
None of that is technically difficult. It just requires someone to actually be responsible for doing it.
For what it's worth, this problem is not rare. The author of the original piece noted that months after leaving a job, their former boss rang to ask if they could still access an external database. They could, without any difficulty.
The lesson here isn't about sophisticated threats or nation-state actors. It's about the mundane, preventable, embarrassingly common failure to do the obvious thing when someone walks out the door.