Nobody Ever Resigns: Putting Machine Identities Through the UK Leaver Process

Most UK organisations can produce a reasonably defensible answer to a simple question: who works here? HR holds the record, the identity team holds the account, and the leaver process closes the loop, however imperfectly. Ask a different question — who, or what, is currently authenticated to our systems? — and the confidence tends to evaporate. The answer includes people, but increasingly it is dominated by things: service accounts running overnight batches, API keys connecting a payment provider to a finance system, integration users synchronising a CRM with an ERP, scheduled tasks with stored credentials, and vendor support accounts that were enabled for a migration and never switched off.

These are non-human identities, and in many mid-market UK estates they now outnumber human ones. They do not resign, take parental leave, or appear in a monthly starter-leaver report. That is precisely the problem: they sit outside the discipline that governs people, while often carrying broader and longer-lived access than any individual employee.

Why the drawer matters

The phrase "keys in the drawer" is not a metaphor for most operations teams. It describes a real pattern: a credential created under time pressure, documented in a ticket or a wiki page, handed to a contractor, and then left in place because nobody is certain what depends on it. The system works, the integration runs, and the question of ownership is deferred indefinitely.

This is not primarily a security failure, although it becomes one. It is an operational ownership failure. A credential without a named owner has no one to notice when it should be rotated, no one to challenge its scope, and no one to confirm it has been removed when the vendor contract ends or the system is retired. In an estate of any size, that gap accumulates quietly until an incident or an audit forces it into view.

UK regulators and frameworks increasingly expect this to be managed rather than assumed. The NCSC's guidance on identity and access management treats service accounts as part of the same access control problem as user accounts. Cyber Essentials asks organisations to control administrative accounts, and the ICO's expectations under UK GDPR apply equally to a machine identity that can read personal data. None of this requires a large security function; it requires a register, an owner, and a routine.

Start with an inventory you can defend

An audit of non-human identities begins with enumeration, and enumeration is harder than it sounds. Credentials are spread across directories, cloud consoles, integration platforms, application configuration files, scheduled job definitions, and the occasional spreadsheet maintained by an operations analyst. No single system holds the full picture.

The practical approach is to work from the systems outward rather than from a central list inward. For each significant application, ask the platform team or managed service provider to export the accounts, tokens and connection objects it holds. Include local application accounts, database logins used by applications, OAuth client credentials, service principals, SSH keys, and any shared mailbox or integration user that authenticates to something.

Record, at minimum: the identifier, the system it authenticates to, the business process it supports, the credential type, when it was created, when it was last rotated, and who requested it. The last two fields are often blank, which is itself a finding worth reporting.

Expect duplication and contradiction. The same integration may appear three times under different names. A vendor may hold an account that your own team cannot see. A retired application may still have an active service principal because decommissioning removed the server but not the directory object.

Give every credential a name against it

The most valuable outcome of the audit is not a spreadsheet. It is the assignment of a named owner to every non-human identity. Not a team, not a mailbox, not "IT" — a person who can answer for it.

Ownership should be assigned to the role that understands the business process the credential supports, not automatically to the infrastructure team. The integration between the warehouse system and the finance ledger belongs to whoever owns finance operations, with technical support from the platform team. This distinction matters because the owner is the person who must confirm, at review time, that the credential is still needed, still appropriately scoped, and still has a live business justification.

Where no owner can be found, that is the finding. An unowned credential is a candidate for removal, but removal requires care: the correct sequence is to establish what depends on it, agree a decommissioning window with the relevant process owner, monitor for failed authentications, and then revoke. Rushing this step is how operational incidents are created.

Test rotation and revocation before you need them

A register that is never exercised becomes stale within a quarter. The audit should include a small number of controlled tests: rotate one credential and confirm the dependent process still runs; revoke a test account and confirm the revocation takes effect within the expected window; check that a leaver's personal credentials cannot be used to reach a system where a shared service account also exists.

These tests reveal uncomfortable truths. Rotation may break an integration because the new secret was not propagated to every consumer. Revocation may be delayed by caching or by a token lifetime that nobody documented. Both outcomes are useful, provided they are discovered in a planned test rather than during a live incident.

Close the loop when systems and vendors leave

The final discipline is retirement. When a system is decommissioned, its identities should be removed as part of the same change. When a vendor contract ends, the vendor's support accounts and any credentials issued to their staff should be revoked and evidenced. When a member of staff who created an integration leaves, the credentials they created should be reviewed, not inherited silently.

This is the point at which machine identities can be brought into the existing joiner-mover-leaver process rather than managed separately. The mechanism is straightforward: add a non-human identity section to the change and leaver checklists, require an owner field at creation, and include the register in the periodic access review that most UK teams already run, however reluctantly.

The aim is not a perfect inventory. It is a defensible one: every credential accounted for, every credential owned, and every removal evidenced. Machine identities may never resign, but they can be managed with the same seriousness as the people they increasingly outnumber.