Who Holds the Key? Custody, Expiry and the Machine Identity Register

Every UK estate carries a second workforce. It does not appear on the organisation chart, it never sits a leaver's interview, and it rarely announces its retirement. Service accounts, client secrets, OAuth grants, TLS certificates, SSH keys, database logins and integration credentials accumulate quietly in the seams between projects, and they keep working long after the people who introduced them have moved on.

The risk is not that these identities exist. Automation depends on them. The risk is that nobody can say, with evidence, who owns a given credential, what it touches, when it was last used and what would break if it were withdrawn this afternoon. That is an uncomfortable position for any regulated firm to be in when an auditor, an incident responder or a supervisory conversation asks the question directly.

Why machine identities escape the usual controls

Human identities are managed by processes with natural enforcement points: joiners, movers, leavers, quarterly access reviews, line manager sign-off. Non-human identities have no joining date and no manager. They are created under delivery pressure, scoped generously so that the integration works first time, and documented — if at all — in a ticket that closes on go-live.

Four patterns recur across the estates we examine. Credentials are duplicated rather than reissued. Secrets sit in configuration files, pipeline variables and shared vaults with broad read access. Ownership is recorded against a team name that has since been restructured. And expiry is either absent or set so far into the future that it functions as an absence.

The consequence is a population of credentials with indeterminate purpose and no accountable human on the other end of them.

Start from evidence, not from memory

Any inventory built from workshops will be wrong. Begin with what the systems themselves report, then reconcile.

• Directory and identity provider exports. Application registrations, service principals, enterprise applications and their granted permissions, including consented Graph or API scopes and the consenting user.
• Vault and secrets-manager metadata. Creation date, last rotation, last read, reading principal, and any secret with no read activity in ninety days.
• Authentication logs. Successful and failed sign-ins for non-human principals, source address ranges, and the subset that authenticates from unexpected networks.
• Certificate and key stores. Internal certificate authorities, load balancers, message brokers, and any endpoint holding a private key.
• Estate-specific populations. Managed service accounts and Kerberos keytabs, database logins, MFT and EDI accounts, RPA bot identities, CI/CD deploy tokens, and the operational technology accounts that sit outside the corporate directory entirely.

Reconcile the union of these sources against the change record and the CMDB. The gaps in both directions are the finding: identities nobody recorded, and records pointing at identities that no longer authenticate.

Custody belongs to a person, not a team

A register that lists a team as owner is a register of orphaned credentials. Every entry needs a named custodian — an individual who can describe what the credential is for, what happens if it stops, and who would notice. That person does not have to be the original author, but they must accept the role in writing, and the acceptance must be recorded in the register itself rather than in an email.

Where no custodian can be found within a reasonable window, treat the credential as unowned and begin the withdrawal process. Absence of an owner is itself a risk statement.

Rehearse rotation as an operational event

Rotation is often assumed rather than tested. A ninety-day policy that has never been exercised is a hypothesis. Pick a sample of credentials across the estate — the oldest, the most privileged, the ones with the widest scope — and rotate them in production with the integration team watching.

What you learn matters more than the rotation itself. Whether the consumer picks up the new secret without a restart. Whether there is a second, undocumented copy in a configuration file. Whether the vendor's connector caches the old value for longer than the change window allows. These are the facts that determine whether a forced rotation during an incident becomes a routine event or an outage.

Prove revocation before you need it

Revocation is the control that matters and the one least frequently demonstrated. For each critical integration, confirm that withdrawing the credential actually terminates access: that tokens expire, that refresh grants are invalidated, that cached sessions in the consuming application are dropped, and that downstream systems do not fall back to a legacy credential nobody remembered.

Run this as a scheduled exercise, not as a theoretical review. If revocation cannot be proven, the credential cannot honestly be described as controllable.

Put expiry on the integration and OS lifecycle

Audits decay. The durable fix is to make machine identity a checkpoint in the processes that already exist. Integration designs should not be approved without a stated owning role, a rotation interval and a decommissioning condition. Build pipelines should issue short-lived credentials rather than long-lived secrets. Operating system and platform upgrades should include a sweep of accounts and services tied to the retiring component. Decommissioning checklists should require evidence of credential removal, not merely server shutdown.

A register that stays true

Treat the register as a live control with an owner, a review cadence and a quality metric — for example, the proportion of non-human identities with a named custodian and a rotation event inside the last twelve months. Report it alongside other access metrics to the same forum that reviews human access.

The test of a good machine identity audit is not the spreadsheet it produces on day one. It is whether the organisation can answer, six months later, who holds a given key and when it was last turned.