Nobody was told to switch the account off

· · Security

Someone left your business in the last year. Maybe they resigned, maybe they were let go. Now answer this: who, by name, was responsible for switching off their access, and by when? If the answer takes more than a few seconds, you have the gap this filing is about.

It is one of the most common failures in small businesses, and one of the cheapest to fix. It is also almost never a technology problem.

What happened

The Register's PWNED column carried an account from Yad Senapathy, now chief executive of the Project Management Training Institute, describing an incident at a company of more than 1,000 staff where he previously worked in IT. An employee was terminated. Nobody cut off their access. The former employee logged back in, deleted files, locked colleagues out of their accounts, and corrupted a database.

The reason was not a missing tool. It was a missing owner:

"Several days passed where the person was no longer on payroll, but their credentials were still active. Nobody had been clearly assigned to shut them off. HR thought IT would handle it once the termination was processed. IT was waiting for HR to send a formal request."

That is the whole failure, and it is worth sitting with because it is so recognisable. Two competent departments, each reasonably assuming the other had it. No malice, no incompetence, just an unowned task falling into the gap between two job descriptions.

The damage ran to hundreds of thousands of dollars plus weeks of delay on a significant project. Recovery was slower than it should have been for an ironic reason: the systems had been damaged by the person who best knew how to repair them.

Senapathy's own summary is the useful part:

"The employee wasn't some genius hacker. They just still had access after they left and nobody changed the credentials or reviewed admin rights."

He also names the aggravating factor. This person held more access than most, including shared admin credentials, so IT did not have a clear picture of what needed cutting off. One person had accumulated so much of the system in their head that closing the door behind them was a research project.

Why the checklist usually misses things

Most businesses do have some form of leaver process. It reliably covers the laptop, the building pass, and the email account, because those are visible and someone notices when they are missing.

What it misses is everything else, and everything else is where the access lives now:

  • The shared admin login for the website, the router, or the accounting system, where the credential is the same for everyone and changing it inconveniences people who are still here.
  • Software the person signed up for themselves, on a company card or a free tier, which IT never knew existed.
  • Access to systems hosted by someone else: the domain registrar, the hosting provider, the payment platform, the marketing tool.
  • Their personal device, still holding a signed-in session for a company account.
  • Their phone number or personal email, still set as the recovery contact or the second-step verification method on a business account.

That last one deserves emphasis. If a leaver's mobile is still the number that receives the login codes for a company account, they can reset their way back in long after their password was changed.

Switching the password is not always enough

There is a second, related trap, and it applies to compromised accounts as much as departing staff.

A password reset does not end a session that is already open. Modern services keep you signed in using a session token, so a browser that was already logged in usually stays logged in after the password changes. The same is true of an attacker who has stolen those session details rather than the password itself. That is one reason credential theft has become the routine way in: the thief does not need your password and is not stopped by the second-step prompt, because the session is already past it.

So the action is not "change the password". It is "change the password and end all active sessions". Nearly every business service has this: look for "sign out of all devices", "revoke sessions", or "sign out everywhere" in the security settings. Use it every time.

What to do this week

The fix is a document, not a product.

  • Name an owner and a deadline. One named person is accountable for revoking access, and the target is same-day, before the person leaves the building. Write it down. "HR notifies IT on the day the decision is made, IT revokes within four working hours" is a policy, and it is enough.
  • Build the list of systems now, not during a departure. Go through the card statement and the password manager and write down every service the business uses. This list is the offboarding checklist, and it is useful for insurance questionnaires and Cyber Essentials too.
  • End the sessions, not just the passwords. Add "sign out of all devices" to the checklist for every service, and check the recovery email, phone number, and second-step method on shared accounts.
  • Fix the shared logins. Shared admin credentials are why offboarding gets postponed: changing one inconveniences everybody. Give people their own named accounts wherever the service allows it, so removing one person affects only that person.
  • Look for anything only one person can do. If a single colleague is the only one who can reach the domain registrar, the backups, or the payment platform, that is a resilience problem as much as a security one, and it does not require anyone to behave badly to hurt you.
  • Check what is still open from last year. Pick the three most recent leavers and try to establish, positively, that their access is gone everywhere on your list. This is the exercise that finds the surprises.

How Steelwise can help

Building the list of what your business is signed into, and turning it into a leaver checklist somebody actually owns, is a short and unglamorous piece of work that pays for itself the first time you use it. Get in touch if you would like help putting yours together.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.