Non-human identity management is the practice of governing every credentialed identity that is not a person, from Active Directory service accounts and Entra ID service principals through to API keys, OAuth grants and workload identities. The goal is to give that population the same accountability you already enforce for people, which sounds unremarkable until you look at the numbers. By CyberArk’s 2025 count, machine identities outnumber your humans 82 to 1, and in the same reporting half of security leaders said they had an incident linked to a compromised machine identity in the previous year. We think those two figures explain each other. Most organizations cannot say who owns which credential, and an unowned credential fails quietly.
What counts as a non-human identity
The label covers anything that authenticates without a person behind the keyboard. In a typical enterprise estate that means six overlapping populations.
- Service accounts in Active Directory, including gMSAs, running services and scheduled tasks.
- Service principals and app registrations in Entra ID, authenticating with client secrets or certificates.
- Managed identities in Azure, where the platform holds the credential.
- OAuth grants held by third-party SaaS integrations acting against your tenant.
- API keys and tokens for CI/CD, cloud services and internal APIs.
- Workload identities for Kubernetes pods, GitHub Actions runs and other compute.
The categories differ in mechanics, but in our experience they all fail the same way. A credential never expires, carries more privilege than the job needs, and belongs to no one. Every problem in this article, including the breach we walk through below, traces back to that pattern.
Why non-human identity management fails in most organizations
When we look at an identity estate, the gaps rarely surprise anyone in the room. They are structural, and the OWASP Non-Human Identities Top 10 for 2025 reads like a catalogue of them.
The first gap is accountability. PAM controls, access reviews and joiner-mover-leaver processes were built around people, which means a machine population 82 times larger mostly sits outside them. Governance only works when each identity has a named human owner who knows what it does, what data it touches and how to revoke it. Without that name, every later control has nobody to answer to.
The second gap is time. Improper offboarding and long-lived secrets sit at NHI1 and NHI7 on the OWASP list, and both grow from the same habit. The engineer leaves, the project ends, the integration gets replaced, and the secret keeps working because nobody knows what would break if they rotated it.
The third gap is privilege, which accumulates because granting a broad scope once is easier than scoping repeatedly. The Graph permission ending in .All, added years ago to unblock a deployment, is still there, and nobody remembers why.
What breaks when service accounts are invisible: the Drift case
If that sounds abstract, the Salesloft Drift breach makes it concrete. Between August 8 and 18, 2025, the actor tracked as UNC6395 used OAuth tokens stolen from Salesloft’s Drift chat integration to pull data out of the Salesforce tenants of more than 700 organizations by Google’s count. The victims who disclosed publicly included Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint and Zscaler, which tells you how little a mature security program protected anyone here. The attackers exported account, contact, case and opportunity records, then mined the text for AWS keys, Snowflake tokens and passwords. Salesloft revoked every active Drift token and Salesforce removed the app pending investigation, and the Salesforce platform itself was never compromised.
What strikes us most about Drift is that nothing in it was a software vulnerability. One vendor’s token store became access to 700 tenants because the tokens carried broad read scopes, and they carried broad read scopes because that is how the integration was installed on day one. A single integration identity then queried at export volume, partly through Tor exit nodes, and went unflagged, because almost nobody baselines what their OAuth integrations normally do. If your audit cannot say which third-party grants exist in your tenant, what they can read and who approved them, you are carrying the same exposure and simply have not met your UNC6395 yet.
How to assign ownership and lifecycle
Our advice after incidents like Drift is unglamorous. Run non-human identities through the same lifecycle you run people through, with the owner standing in for the employee.
- Inventory first. Enumerate service accounts, service principals, OAuth grants and keys across cloud, SaaS and on-prem. Automated discovery beats spreadsheets, but either way the record must hold owner, purpose, privilege and credential expiry.
- No owner, no identity. An identity nobody claims within a defined window becomes a decommission candidate. Disable it, wait out a quarantine period, then delete. Orphaned accounts that keep working are exactly what fails an audit, because you cannot prove who had access or when it was reviewed.
- Create through a request path. New identities get an owner, a scoped permission set and an expiry at birth, and broad scopes are a justified exception rather than a default.
- Tie rotation to the owner’s lifecycle. When the owner changes roles or leaves, the credentials they controlled get rotated as part of offboarding. A credential that survives its owner’s departure is a control failure, not operational noise.
- Review on a cycle. For Entra ID, access reviews can cover service principals holding privileged directory roles, and for everything else the owner re-attests purpose and privilege at least annually.
Ownership records tell you what should exist. Telemetry tells you what actually happens, and that difference is where the next section earns its keep.
Service principal audit in Entra ID: three detection queries
On a Microsoft estate the telemetry is better than most teams realize. Entra ID writes service principal and managed identity sign-ins to dedicated tables, AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs, separate from user sign-ins, though you have to route them to Log Analytics or Sentinel yourself because they are not collected by default. The three queries below cover the questions we ask first in any service principal audit, and they map to ATT&CK T1078.004 (cloud accounts), T1098.001 (additional cloud credentials) and T1528 (steal application access token).
The first question is which principals are stale but still credentialed, because every one of them is attack surface with no business justification left.
Data source: AADServicePrincipalSignInLogs (Entra ID, via diagnostic settings to Log Analytics or Sentinel)
AADServicePrincipalSignInLogs
| summarize LastSignIn = max(TimeGenerated), SignIns = count()
by ServicePrincipalName, ServicePrincipalId, AppId
| where LastSignIn < ago(90d)
| order by LastSignIn ascThis needs at least 90 days of retention, and it only surfaces principals that signed in at least once inside the window. Principals with zero recorded sign-ins stay invisible here, so enumerate them from Microsoft Graph and diff against this table for the full picture.
The second question is whether anyone has added new credentials to an existing app, because a fresh secret on a dormant registration is a classic persistence move.
Data source: AuditLogs (Entra ID audit log, via diagnostic settings)
AuditLogs
| where OperationName has "Certificates and secrets management"
| extend Actor = coalesce(
tostring(InitiatedBy.user.userPrincipalName),
tostring(InitiatedBy.app.displayName))
| project TimeGenerated, OperationName, Actor,
TargetApp = tostring(TargetResources[0].displayName),
ActorIP = tostring(InitiatedBy.user.ipAddress)Expect legitimate rotations from your own automation, and tune by known actor accounts rather than suppressing the alert.
The third question is whether a principal has started signing in from infrastructure it has never used, which is exactly the anomaly that went unwatched in the Drift case.
Data source: AADServicePrincipalSignInLogs (Entra ID, via diagnostic settings)
let history = AADServicePrincipalSignInLogs
| where TimeGenerated between (ago(30d) .. ago(1d))
| where ResultType == "0"
| distinct ServicePrincipalId, IPAddress;
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == "0"
| join kind=leftanti history on ServicePrincipalId, IPAddress
| summarize NewIPs = dcount(IPAddress), IPs = make_set(IPAddress, 20)
by ServicePrincipalName, ServicePrincipalIdFalse positives come from autoscaling egress and vendor IP churn, so alert on volume and rarity together rather than on any single new address. Thomas Naunheim’s audit reference for managed identities and service principals and the Sentinel service principal escalation queries are good public starting points to extend from. Baselining and tuning this class of detection is routine work for a monitoring team, and it is the bulk of what our AI-driven SOC engagements operationalize for identity telemetry.
Two platform controls raise the ceiling if you hold Workload ID Premium licensing. Conditional Access scoped to workload identities can restrict single-tenant service principals to known locations and block on risk, and ID Protection raises workload identity risk detections for leaked credentials and anomalous sign-ins. Mind the scope limit, though. Conditional Access covers single-tenant principals you register, not multitenant or Microsoft first-party apps, so it would not have touched an integration like Drift.
Mitigation: eliminate standing secrets where the platform allows
The cheapest secret to audit is the one that does not exist, so we steer every estate toward the same order of preference. Managed identities come first for Azure resources, because the platform issues and rotates the credential and there is nothing to leak from a pipeline variable. Workload identity federation comes next for GitHub Actions, Kubernetes and external compute, where the workload exchanges its own platform token for an Entra token and no stored secret exists to steal. Certificates over client secrets come last, for the cases where a stored credential is unavoidable, with expiry short enough that rotation is exercised rather than theoretical.
This ordering matters more as agentic AI enters the estate, because every agent is a new non-human identity with the same ownership, scoping and audit questions. If your organization is writing AI policy right now, test whether it actually governs the identities agents run on rather than just the models.
Frequently asked questions
Non-human identity, machine identity, service account: what is the difference?
Machine identity and non-human identity are near-synonyms, and vendors argue about the boundary more than practitioners do. Service accounts are one subtype, the on-prem directory kind. Non-human identity is the broadest term and includes the API keys and OAuth grants that machine identity discussions sometimes leave out.
Who should own non-human identities?
The team that owns the workload, one named person per identity, with the IAM function owning the register, the lifecycle rules and the exceptions. We advise against central IAM ownership of every account, because it does not scale to an 82-to-1 ratio and it disconnects the owner from the revocation decision.
How often should service account credentials rotate?
Where secrets must exist, set expiry so rotation happens at least yearly and is proven to work. Rotation frequency is the lesser question, though. Eliminating standing secrets through managed identities or federation removes the rotation problem instead of scheduling it.
Do non-human identities need MFA?
No, MFA is a human control. The equivalents are credential strength, meaning certificates or federation over passwords, plus Conditional Access restrictions on location and risk, plus anomaly detection on sign-in behavior.
Bottom line
Inventory every non-human identity, give each one a named owner, and treat an ownerless account as a decommission order. Kill standing secrets where the platform allows, and put detection on whatever remains, starting with stale principals, new credential adds and never-seen infrastructure. Drift showed what skipping this costs across 700 tenants in ten days, and the queries above are where we would start before your integrations get the same attention.