Non-Human Identity Security: Ownership, Lifecycle and Monitoring

A legacy test application nobody remembered owning gave a state-linked actor access to corporate mailboxes at one of the world’s largest software companies. Microsoft’s own account of the intrusion describes it plainly: the actor guessed its way into a non-production test tenant account that had no multifactor authentication, found a legacy test OAuth application with elevated access to the corporate environment, and used it to grant a role that allows access to mailboxes.

No human identity was the weakness at the end of that chain. An application was. It held standing privilege, it had no one watching it, and it had outlived whatever purpose it was created for.

That pattern is the real subject of non-human identity security. The hard part is not finding service accounts, API keys, OAuth grants, workload identities and automation tokens. Discovery tools do that. The hard part is that each of them has a creator and almost none has an owner, and a credential without an owner cannot be rotated, scoped down or retired by anyone with the authority to do it.

Why non-human identities escape the controls built for people

Identity programs grew up around people. People join, move and leave. HR systems record it. Access reviews have a manager to ask. Multifactor authentication catches a stolen password.

Non-human identities have none of that scaffolding. Nothing fires when a service account’s creator changes teams. A token issued for a pilot keeps working after the pilot ends. A secret copied into a pipeline variable is not covered by any access review, because the access review looks at accounts, not at where credentials ended up.

The category is also wider than most inventories assume:

• Service accounts and local application accounts in directories, databases and operating systems.

• API keys and static tokens issued by SaaS platforms, cloud providers and internal services.

• OAuth applications and consent grants, including third-party integrations that act on behalf of your tenant.

• Cloud workload identities: managed identities, service principals, IAM roles and the trust relationships between them.

• Pipeline and automation credentials used by build systems, infrastructure-as-code runners and scheduled jobs.

• Bots, robotic process automation and AI agents that call systems with delegated or standing access.

OWASP maintains a dedicated Top 10 for non-human identities. Improper offboarding, secret leakage and over-privileged identities sit among its leading risks. That is a practitioner community’s judgment rather than measured prevalence, but it matches what incident reports keep showing.

Ownership is the control everything else depends on

Ask who owns a service account and the usual answer is the person who created it. That is a creator, not an owner. Creators change jobs. An owner is accountable for the identity’s purpose, its privilege and its end date, and must still be there to answer for it next year.

A workable ownership record is short. It needs a named accountable person or team, the business purpose, the system the identity serves, the privileges it holds and why, and an expiry or review date. It also needs a rule for what happens when the owner leaves. If the joiner-mover-leaver process does not trigger reassignment of non-human identities, the record decays within a year and nobody notices.

Decision for security leaders: treat an identity with no accountable owner as an unmanaged risk, and set a deadline after which it is disabled or escalated. Without that rule, ownership stays a spreadsheet column.

Lifecycle: where the risk actually accumulates

Human identity lifecycle is mature. The non-human equivalent is usually missing stages. The table shows the questions each stage should answer and what tends to happen when it is skipped.

Third-party integrations deserve their own line in that lifecycle. In a widely reported campaign, Google Threat Intelligence Group described an actor using stolen OAuth tokens from a third-party chat integration to query customers’ Salesforce data, then searching the exported records for credentials such as cloud access keys. The tokens belonged to an integration the customer had authorized and probably stopped thinking about. Each such grant is a non-human identity in your estate, whether or not it appears in your inventory.

Where possible, remove the secret instead of managing it. Workload identity federation and managed identities let a workload prove who it is without holding a static credential. They are not available everywhere, but wherever they are, the lifecycle problem shrinks to a trust relationship you can review.

Monitoring: the advantage most teams do not use

Non-human identities are easier to baseline than people. A pipeline credential calls the same few APIs from the same few networks at predictable times. An integration reads one dataset. When behavior departs from that, the signal is cleaner than anything a human account produces.

Useful detections follow from the lifecycle rather than from a generic alert list:

• A credential used from a network, region or runtime it has never used before.

• A new secret, key or certificate added to an existing identity.

• A new OAuth application created, or consent granted with high-privilege permissions, especially mailbox, directory or storage scopes.

• A dormant identity that becomes active.

• A role assignment or trust-policy change that widens what a workload identity can assume.

• One identity reading far more objects, or far more varied ones, than its history shows.

These are identity threat detection and response use cases. They only work if the identity has an owner who can say whether a change was expected, and a logging path that reaches whoever triages the alert. Teams often discover that cloud and SaaS audit logs capturing these events are not enabled or not retained long enough to investigate with.

Why programs stall, and a better order of work

The usual first step is a full inventory. It tends to produce a very large list, no owners and no way to decide what matters. The program then stalls under its own findings.

A more useful order starts from consequence. Take the identities that can change identity infrastructure, read mailboxes or bulk data, or administer cloud accounts. Assign owners to those first. Cut their privilege. Shorten or remove their secrets. Put monitoring on them. Then widen the circle. This is also where posture management earns its place: it ranks what to fix, while ownership and monitoring decide whether the fix lasts.

The test for any program is not coverage. Pick the ten most privileged non-human identities in your environment and ask who owns each, when it was last used, what it can reach and what would retire it. If those answers take weeks to assemble, the gap is operational. It is a question of whether identity risk is run as a continuing service with owners, review cycles and monitoring, or as a project that ends with a report. That is the capability worth evaluating before buying another tool.

Sources

• Microsoft Security Response Center. Midnight Blizzard: Guidance for responders on nation-state attack

• Google Threat Intelligence Group. Analysis of OAuth token theft and Salesforce data access linked to the Salesloft Drift integration

• OWASP. Non-Human Identities Top 10

• OWASP Cheat Sheet Series. Secrets Management Cheat Sheet