The Account That Never Resigns: Registering Non-Human Identities in UK Estates

Most organisations can produce a list of employees within minutes. Far fewer can produce a credible list of the identities that act on their behalf but never appear on a payroll. Service accounts, API keys, OAuth client credentials, managed identities and integration accounts form a parallel workforce: always on, often privileged, and rarely reviewed with the same rigour as human access. The risk is not merely that these credentials exist. It is that their lineage is lost. When the application that created an account is decommissioned, the account can remain. When the contractor who requested an API key leaves, the key can remain. When a system is migrated, the integration identity can remain attached to the old platform and the new one. The result is a shadow population with no clear owner, no defined purpose and no retirement path.

A register is the obvious control, but a register maintained as a spreadsheet is usually a snapshot of good intentions. It decays. The practical question is not whether to keep a register but how to make it accurate enough to be useful and durable enough to survive audit. For UK organisations, that means treating non-human identities as an asset class with a lifecycle, not as a footnote to joiners and leavers.

Begin with a population, not a spreadsheet

The first mistake is to start with a template. A template invites completeness on paper and omission in practice. Start instead with a population definition: which identities are in scope? Directory service accounts, cloud IAM roles, API keys, OAuth clients, integration platform users, robotic process automation bots, scheduled tasks, database logins, and any credential that can act without a human present. The scope should be explicit and reviewed. It should also be pragmatic: a UK local authority may have thousands of service accounts in Active Directory, while a mid-sized software company may have fewer directory accounts but hundreds of cloud identities and API keys.

Discovery: triangulate, do not trust a single source

No single system holds the truth. Directory logs show authentication, but not the business purpose. Cloud consoles show key age, but not the system dependency. Source code repositories show secrets, but not whether they are live. Procurement records show contracts, but not which integration account belongs to which supplier. A workable discovery phase triangulates at least four sources: the directory and identity provider; cloud IAM and secrets managers; application and integration inventories; and finance or procurement records for third-party services. The output is a candidate list, not a register. The register begins when each candidate is assigned a purpose and an owner.

The minimum viable record

A register that tries to capture everything becomes unmaintained. A minimum viable record is better. For each identity, record: a stable identifier; the identity type; the business purpose in plain language; the owning role, not just a person; the systems and data it can reach; the privilege level; where the credential is stored; the rotation method; the last observed use; the dependency or service it supports; and the retirement trigger. These fields are enough to answer the questions auditors actually ask: who owns this, what is it for, what can it reach, and when was it last reviewed?

Ownership is a role, not a name

Assigning a named individual feels precise, but it is fragile. People move, leave, or change responsibilities. Assign ownership to a role — for example, the integration lead for the finance system or the platform owner for the customer data platform — and record the current post-holder as a separate field. This makes the register resilient to staff turnover and makes accountability visible. It also forces a useful conversation: if no role can be found to own an identity, that identity may not have a legitimate business purpose.

Rotation and retirement triggers

Rotation should not be a calendar exercise divorced from use. A service account that has not authenticated in 90 days is not necessarily safe; it may be dormant and forgotten. A key that is rotated every 90 days but shared across three teams is still a shared secret. The register should record the rotation method and the last rotation date, but it should also record the dependency. Retirement triggers are more valuable than rotation schedules: the decommissioning of an application, the end of a supplier contract, the migration of an integration, the departure of a managed service provider, or the closure of a project. Each trigger should produce a review task, not an assumption that someone else will remember.

Reporting that stands up to audit

Audit committees and internal auditors rarely need a list of every service account. They need evidence that the population is known, owned, reviewed and bounded. Useful metrics include: the percentage of in-scope identities with a named owning role; the percentage with a recorded purpose; the number of identities with credentials older than the agreed rotation period; the number dormant beyond a defined threshold; the number of exceptions approved and their expiry dates; and the coverage of discovery sources. These metrics should be reported on a regular cycle, with a clear owner for remediation. In the UK, this also aligns with the expectations of frameworks such as ISO/IEC 27001 and the National Cyber Security Centre's identity and access management guidance, as well as the accountability principles of UK GDPR when non-human identities can reach personal data.

A 90-day start

A pragmatic first phase is 90 days. Weeks one to three: define scope and identify discovery sources. Weeks four to six: extract candidate identities and deduplicate. Weeks seven to nine: assign owning roles and purposes for the highest-privilege and most exposed identities first. Weeks ten to twelve: establish a review cadence, agree rotation and retirement triggers, and publish the first dashboard. Do not wait for a perfect register. A register that covers 80% of privileged non-human identities with named owners is more useful than a theoretical model that covers none.

The account that never resigns is not a glitch. It is a design consequence of automation. UK organisations that treat non-human identities as a governed population — discovered, owned, reviewed and retired — will find that the invisible workforce becomes visible, and therefore manageable.