access debt: why permissions outlive their purpose

Access is granted for a reason: a project, a role, a deployment, a two-week contract. The reason has an end date. The permission usually doesn’t. What stays behind is access debt: permissions that no longer match any current need, held by people, apps and keys that nobody is watching. It costs nothing until someone uses it. The fix is a short, regular review of the few systems where a stale permission would hurt, with an owner and a reason attached to every elevated account.

what it looks like

Picture an ordinary year at a 150-person company that runs on SaaS.

An engineer gets admin rights to production for a migration in March. The migration ships. The admin rights stay. A contractor joins the GitHub organisation for a six-week project. The project ends, the contract ends, the account stays. Someone in marketing connects a meeting-notes app to their calendar with one click on “Allow”. They stop using it in June. The app’s access to the calendar does not stop.

None of these is a mistake on the day it happens. Each was the fastest way to get legitimate work done. That is why access debt grows in every company that grants access faster than it reviews it, which is most of them.

why switching off the account isn’t the end

The usual mental model of offboarding is a single switch: disable the person in the directory and they’re out. In a SaaS company, the directory is only one of the doors.

Access point	Why disabling the directory account can miss it
Active sessions	Microsoft’s own guidance for Entra ID lists disabling the account, revoking sign-in sessions and disabling devices as separate steps. A token already issued can keep working until it expires
OAuth grants to third-party apps	The grant belongs to the app. Google Workspace lists every connected app separately in the Admin console, under API controls
Local accounts	Accounts created directly inside a tool, outside single sign-on, don’t know the directory exists
Shared credentials	A shared login for a social account, a supplier portal or a test environment keeps working for everyone who ever knew the password
API keys and personal tokens	Created by a person, used by a script, often still valid after the person leaves
Tools bought on a card	If IT never knew the tool existed, IT never removes anyone from it

Disabling the directory account is necessary. It just isn’t an inventory.

why nobody catches it

There is no signal. Technical debt makes builds slower and features later, so someone complains. A dormant admin account makes no noise at all. It shows up in two places: an audit, or an incident.

There is no owner. HR closes payroll. IT gets a ticket for the accounts it knows about. The manager who asked for the admin rights has moved on to the next project. Each of them did their part, and the access still exists.

Revoking costs more than granting. Granting takes ten seconds and makes someone happy. Revoking takes investigation, carries the risk of breaking something, and makes someone ask why. Without a routine that forces the question, the cheap option wins every time.

why it matters more than it used to

Verizon’s 2025 Data Breach Investigations Report found that credential abuse was the most common way into an organisation, the initial access vector in 22% of breaches, ahead of exploited vulnerabilities at 20%. The same report found that a third party was involved in 30% of breaches, double the year before. A stale account or a forgotten app grant is exactly the kind of door those numbers describe: a valid login that nobody expects to be used.

There is also a quieter cost. When a customer’s security questionnaire or an auditor asks “who has admin to your production systems?”, a company carrying access debt needs days to answer, and the answer is usually wrong the first time.

what to do this month

You don’t need a tool to start. You need one list and one meeting.

1. Pick your five systems. The ones where a wrong person with admin would hurt most. In a SaaS company that is usually the identity provider, cloud infrastructure, source code, payments and the customer database or CRM.
2. List everyone with admin or owner rights in each. People, service accounts and API keys. Export from the tool itself, not from memory.
3. Give every line an owner and a reason. The owner is a person who can say “yes, this is still needed”. The reason fits in one sentence. A line without both is a candidate for removal.
4. Check the connected apps. In Google Workspace or Microsoft 365, open the list of third-party apps with access to company data. Look for apps nobody recognises and apps with broad scopes such as full mail or drive access.
5. Remove carefully, then set a date. Before revoking an account used by a script or an integration, find what depends on it. Then put the next review in the calendar. Quarterly is a reasonable default for these five systems.

This is also what the frameworks ask for. NIS2, in Article 21, lists access control policies among the risk-management measures in-scope companies must take. ISO/IEC 27001:2022 includes access rights review in its controls, and NIST SP 800-53 control AC-2 covers account management, including disabling accounts that are no longer needed. A one-page list with owners, reasons and review dates is the evidence all three are looking for.

the review that keeps access debt small

1. five systemsthe ones where admin hurts most
2. list adminspeople, service accounts, keys
3. owner and reasonfor every line
4. remove and schedulenext review in the calendar

if you have to buy something or justify a budget

Frame it as an audit finding waiting to happen. “Someone might hack us” invites a debate about likelihood. “We cannot produce a current list of who has admin to our five critical systems” is a fact the board can check, and it will be the first question in any audit, customer questionnaire or cyber-insurance renewal.

Then size the problem before you size the tool. If the five-system review takes an afternoon and finds a handful of stale admins, a spreadsheet and a quarterly calendar reminder may be the right answer. If it takes a week, turns up dozens of unknown apps, and has to be repeated every quarter across 50 tools, that is the point where software that inventories SaaS access starts paying for itself.

Which of your five systems would take you longest to answer “who has admin here, and why”?