Non-Human Identities: The Credentials Nobody Offboards
Your organisation has a process for staff leaving and no equivalent for the service accounts, API keys and workload identities that now outnumber your people several times over. Those credentials do not change jobs, forget passwords or trigger reviews. They accumulate, they keep their permissions, and they are the reason a leaver’s departure closes one door while leaving several others open.
What counts as a non-human identity
The category is broader than most inventories allow for. It includes Active Directory service accounts, cloud service principals and managed identities, API keys issued to partners, tokens held by continuous integration systems, certificates used for mutual authentication, and the credentials embedded in appliances so they can query your directory. CISA’s recommended practices for identity and access management make the point that these accounts need the same lifecycle discipline as human ones, and in most estates they receive far less.
Why they collect privilege
Machine credentials grow because narrowing them is risky and widening them is quick. An integration fails at three in the morning, somebody grants a broader role to restore service, and the change is never revisited because everything works. Nobody wants to be the person who breaks a nightly job by removing a permission. Over a few years this produces accounts with rights that no person in the organisation holds, protected by a password set when the account was created and stored in a document several teams can read. The result is an account nobody would approve today, doing work nobody can fully describe.
“Ask who owns each service account and watch the room go quiet. Ownership is the control that fixes everything else, because an owner can answer whether it is still needed, what it touches and when the credential was last changed. Without an owner, every other question ends in nobody wanting to be responsible for turning it off.”
William Fieldhouse, Director, Aardwolf Security Ltd
Building an inventory that stays useful
List them by where they authenticate rather than by team, since that is how you find them all. Pull service accounts from the directory, service principals and managed identities from each cloud tenant, keys from your API gateway, and tokens from the build system. Record an owner, a purpose, the permissions held and the date the credential last changed. Add last used, which is the most valuable column of all: an account unused for six months is a candidate for disabling, and disabling before deleting gives you a safe way back if something breaks.
Reducing the standing risk
Replace long-lived secrets wherever the platform allows it. Workload identity federation issues a short-lived token to a specific workload, removing the stored key entirely, and managed identities do the same inside a cloud tenant. Where a static credential must remain, keep it in a vault with automated rotation and alert on use from unexpected sources. Cloud and identity penetration testing checks what these identities can actually reach, which is usually the part that surprises people, and if you are scoping this work for the first time, request a testing quote covering identity as its own workstream rather than an afterthought in an infrastructure test.
Frequently asked questions about machine identities
These questions come up as soon as an identity inventory begins.
Can you apply multi-factor authentication to service accounts?
Not in the usual sense. The equivalent controls are short-lived credentials, network restrictions on where the account may authenticate from, and tight scoping so a stolen credential reaches very little.
How do you retire one safely?
Disable rather than delete, monitor for failures over a full business cycle including month end, then remove. Deleting first is how a quarterly finance job fails three weeks later with nobody remembering the change.
