A list nobody has
Someone asks who can log into the AWS account and the answer is a shrug. The GitHub organisation has members nobody recognises. A contractor who finished last year still appears in the Google Workspace admin panel. The CRM has shared logins used by several people. The office manager suspects a former employee still gets alerts from the website's hosting account.
Nobody made a mistake exactly. Access was added whenever someone needed it and rarely taken away.
How access sprawls
- New tools are signed up by whoever needs them, with personal or shared logins.
- Contractors and agencies are given access for a project, and nobody removes it at the end.
- Leavers have their email closed, but their accounts in other tools stay active.
- Admin rights are granted to fix one problem and never taken back.
- Service accounts and API keys are created for integrations, and nobody knows which are still used.
The deeper cause is that there is no single place where identity lives. Each tool has its own users, so each tool has to be cleaned separately, and nobody has time to do all of them.
Why it matters
| Situation | Risk |
|---|---|
| Former staff with live accounts | Access to customer data, finances or systems after they have left |
| Former suppliers with admin rights | Their security becomes your security |
| Shared logins | No record of who did what, and no way to remove one person |
| Too many admins | More accounts that can do serious damage if compromised |
| Forgotten API keys | Integrations with access nobody is watching |
It also shows up when someone asks. Customers, insurers and auditors increasingly want to know how you control access and remove it when people leave. Without a list, the answer is a description of good intentions rather than evidence.
Most of these accounts will never be misused. The trouble is that you cannot tell which ones, and an account nobody watches is exactly what an attacker looks for after stealing a password.
How we audit access and keep it tidy
- List your systems. We build an inventory of cloud accounts (AWS, Azure, Google Cloud), servers, code repositories, domain and DNS, email, and the SaaS tools the business uses, including the ones signed up informally.
- Export every user and permission from each system, including service accounts, API keys and SSH keys.
- Match accounts to people and roles with your team, marking leavers, former suppliers, shared logins and excessive admin rights.
- Remove or reduce what is stale, after confirming with the owner, and rotate credentials that former people may know.
- Centralise identity. Where tools support it, we connect them to single sign-on through Microsoft Entra ID or Google Workspace, so one account per person controls access to many systems, with multi-factor authentication enforced.
- Grant access by role rather than by individual request, so a new starter gets the right set and a leaver loses all of it together.
- Set up the routine: a joiner and leaver checklist, and a regular access review where each system owner confirms who should still be there.
We keep this proportionate. A small business does not need an enterprise identity programme; it needs a list, fewer admins, single sign-on where it is easy, and a habit of checking.
After the clean-up
You can answer who has access to what, for each important system. When someone leaves, disabling their company identity removes most of their access in one step, and the checklist covers the rest. Admin rights are held by a small number of named people. And a regular review stops the sprawl returning.
Quick self-check
- You could not produce a list of who can access your cloud account today.
- Former employees or suppliers may still have working logins.
- Several people share one login for important tools.
- Many people have admin rights they do not use.
- There is no checklist for removing access when someone leaves.