Non-human identities (NHIs) include service accounts, OAuth applications, workloads, integrations, and automations. They authenticate through API keys, CI/CD secrets, workload tokens, and other credentials that often sit beyond human-focused identity controls.
Most identity programs still begin at the login page. Meanwhile, integrations and pipelines expand the identity attack surface without an HR event, MFA prompt, or access review to slow them down.
Together, four documented incidents from 2023 to 2025 expose two recurring gaps: teams could not reliably tell which credentials were still active or which tokens outside parties held. Non-human identity security closes those gaps before a valid credential becomes an attacker’s easiest route in.
Key Takeaways
- In the documented incidents of 2023 to 2025, attackers abused valid non-human access or exposed the credentials behind it rather than defeating authentication. The paths included an unrotated service token, an over-privileged OAuth application, CI secrets exposed by a compromised dependency, and a vendor integration’s OAuth tokens.
- Rotation programs can fail at the credentials believed to be unused. Cloudflare rotated thousands after the October 2023 Okta compromise and missed one service token and three service accounts for that reason.
- Authentication controls built for people often do not see these paths. NIST's digital identity guidelines state that they do not explicitly address machine-to-machine authentication.
- A vendor integration's token is part of your identity attack surface, and revoking it fast depends on knowing it exists before the vendor calls.
- Test any platform against the incident classes it claims to cover. It should find the credential, show its last use, name its owner, and list what it reaches.
- Least privilege for non-human identities combines intended purpose with observed use, and it needs revisiting whenever either changes.
Why Non-Human Identity Security Is a Growing Priority
Non-human identity security moved up the agenda because several instructive intrusions of the last three years turned on machine credentials. The organizations that responded published how, so the evidence is primary. It also comes from a handful of cases, which limits what it proves.
Attackers stopped needing the login page
Phishing-resistant MFA and conditional access make a human sign-in harder to abuse. The credentials in the incidents below sit elsewhere. They include a Bitbucket service account, an app granted rights through OAuth 2.0 authorization, a build job's token, and a sales tool's integration token. None of them waits for a prompt a person could refuse.
Midnight Blizzard shows where the two meet. The group's foothold at Microsoft was a legacy test tenant account without MFA, a login-page failure. The escalation that followed ran mainly through OAuth applications, along a privilege escalation path that sign-in controls were not placed to inspect.
Why 2025 made it a named risk category
In 2025, OWASP published its Non-Human Identities Top 10, a shared vocabulary for these failures. Its long-lived secrets entry covers keys, tokens, and certificates "with expiration dates that are too far in the future or that don't expire at all."
The same year produced two of the four incidents below, one reported by CISA and one by Google. Four incidents do not measure prevalence. They do show how several identity and credential types created documented attack paths, so an auditor’s question about machine credentials deserves a specific answer.
The Security Risks Created by Non-Human Identities
The non-human identities security risks that appear in public post-mortems fall into four patterns, each involving a different kind of identity. The OWASP mapping in the last column is an editorial judgment, not OWASP's own classification.
| Risk | Documented incident | Credential or access involved | Closest OWASP 2025 entry |
|---|---|---|---|
| Credentials believed unused | Cloudflare, November 2023 | One service token and three service account credentials | NHI7 Long-Lived Secrets |
| Over-privileged application identity | Microsoft, January 2024 | A legacy test OAuth application with elevated access | NHI5 Overprivileged NHI |
| Secrets exposed through CI/CD | tj-actions/changed-files, March 2025 | Potentially exposed access keys, GitHub PATs, npm tokens, and private RSA keys | NHI2 Secret Leakage |
| Tokens held by a third party | Salesloft Drift, August 2025 | Compromised OAuth tokens tied to the Drift integration | NHI3 Vulnerable Third-Party NHI |
Credentials believed to be unused
Cloudflare detected a threat actor on its self-hosted Atlassian server on November 23, 2023, according to its post-incident report. The credentials came from the October 2023 Okta compromise. Cloudflare rotated thousands of them but, in its words, "failed to rotate one service token and three service accounts" from that set. Its explanation: "mistakenly it was believed they were unused."
Those service account credentials reached real systems. One was a Smartsheet service account with administrative access to Jira, and another a Bitbucket service account for source code. With stolen service tokens in hand, the actor reached Jira and Confluence on November 15 and set up persistence on November 22. It viewed 120 of 11,904 repositories, and Cloudflare treated 76 as exfiltrated without confirming it. Cloudflare reports that no customer data or systems were affected.
Applications holding more than they need
Microsoft detected Midnight Blizzard on January 12, 2024. Its guidance for responders describes a password spray against a legacy test tenant account without MFA. From there, the actor compromised "a legacy test OAuth application that had elevated access to the Microsoft corporate environment."
The actor created more malicious OAuth apps and a new user account to consent to them. It then used the legacy app to grant the Exchange Online full_access_as_app role, which allows access to mailboxes. A test application that still held elevated access carried the actor into corporate mail. Microsoft's advice to responders includes auditing the privilege of all identities, service principals included.
Secrets that leave through the pipeline
In March 2025, CISA reported that tj-actions/changed-files, a popular third-party GitHub Action, had been compromised (CVE-2025-30066). Secrets at risk included access keys, GitHub Personal Access Tokens (PATs), npm tokens, and private RSA keys. The affected window ran from March 12 to March 15, 2025.
A job's secrets share a runner with every step in that job, including third-party code the repository owner did not write. GitHub's advisory says the malicious script read secrets from the runner's process memory and printed them to workflow logs. CISA told users to "rotate all identified secrets immediately as they should be considered compromised." The alert describes exposure, not confirmed downstream breaches. Each team still had to work out which of its secrets were in scope.
Tokens a vendor holds for you
Google Threat Intelligence Group (GTIG) tracked a group it calls UNC6395 from as early as August 8 to at least August 18, 2025. Its report says the actor used "compromised OAuth tokens associated with the Salesloft Drift third-party application" to reach Salesforce customer instances. The tokens belonged to an integration customers had connected, and Salesloft, working with Salesforce, later revoked all of them.
GTIG assessed the actor's main intent as harvesting credentials. It searched the Salesforce data for AWS access keys, passwords, and Snowflake tokens that could help it move laterally inside other platforms. GTIG told customers to revoke and rotate the credentials tied to Drift integrations, which assumes they already knew which integrations existed.
Why Traditional IAM Approaches Fall Short
Traditional identity and access management (IAM) was designed around a person proving who they are at a sign-in. The credentials above were issued to software, so controls tuned for that moment had little to inspect.
The login page is where IAM looks
Enterprise IAM rests on the identity provider, single sign-on coverage, MFA, and HR-fed lifecycle events. Each assumes a person, an employment record, and a session that starts with a prompt. NIST SP 800-63-4, finalized in 2025, says "'person' refers only to natural persons." It also says its guidelines "do not explicitly address" machine-to-machine authentication.
That scope is reasonable for a document about people. It leaves a gap in programs that measure themselves against it. Interactive factors do not fit an unattended process, and the stronger substitutes (federated workload identity, short-lived credentials) sit outside the human-centered program. The legacy IAM architecture problem comes down to where the system was built to look.
Rotation without usage data is a guess
The usual objection is that secrets are vaulted and rotated. Cloudflare set out to rotate every credential exposed in the Okta compromise. The ones it skipped were the ones it believed nobody used, and those were the ones the attacker used.
Vaulting protects a stored secret. On its own, it does not establish which identities are active, what each can reach, or which credentials a third party holds. Without last-use evidence, a team either breaks a production job it did not know about or skips a credential it thought was safe.
What to Look for in a Non-Human Identity Security Platform
A non-human identity security platform earns its place by answering, with evidence, the questions these responders had to reconstruct after the fact. Test it against those incidents, on your own credentials rather than a demo tenant.
Six questions to put to any platform
| Capability | Question to ask | Incident it answers |
|---|---|---|
| Inventory across issuing systems | Does it inventory identities and credential metadata across cloud IAM, SaaS, CI/CD, and secrets stores beyond the IdP? | Cloudflare |
| Last-use evidence | Can it show when each credential last authenticated, and to what? | Cloudflare |
| Ownership | Does it name an accountable person for every identity and flag those with no owner? | Microsoft |
| Effective reach | For one identity or token, can it show every system, role, and access path it reaches, including through chained grants? | Microsoft |
| Third-party and pipeline grants | Can it list OAuth grants, integration tokens, and CI secrets, including which vendor, workflow, or system holds each one? | Salesloft Drift, tj-actions |
| Abnormal-use detection | Does it alert when a machine credential is used from a new source or at unusual volume? | Cloudflare |
Timing is why the last row matters. At Cloudflare, eight days passed between the actor reaching Jira and detection. That row overlaps with identity threat detection and response (ITDR), so ask whether a candidate's detections cover machine credentials. Keep the certificate and key lifecycle out of scope unless a vendor claims it, since it has its own tooling.
Buy, extend, or build
If the gap is discovery and usage evidence across many issuing systems, evaluate a platform. If the estate is one cloud and one CI system, extend native controls first. Cloud IAM reporting and CI secret settings will likely close these paths sooner than a new procurement.
Building in-house tends to handle inventory and stall at reach, because effective access across chained grants means modeling each provider's permission logic. Cloud infrastructure entitlement management (CIEM) tools answer reach for cloud roles, so ask how a candidate handles SaaS and OAuth grants.
Applying Least Privilege and Continuous Governance
Observed use gives teams one practical measure of least privilege: compare the access an identity used over a representative window with the access it holds. The difference is part of the margin an attacker inherits. Microsoft's legacy test application, holding elevated access to the corporate environment, shows that margin at its widest.
Measure privilege from observed use
NIST SP 800-207A (September 2023) applies zero trust to services. It calls for policies "based on application and service identities in addition to the underlying network parameters and user identities." Service identities get their own policy, sized to what they do.
Right-sizing starts from access logs: what the identity called, which data it touched, and from where. Scopes it never exercised over a representative window become candidates for removal. Rare elevated operations, such as a migration, fit just-in-time access better than a standing grant.
Continuous means event-driven
Governance on a calendar misses the moments when risk changes. Useful triggers include a new scope, an owner leaving, a credential passing your idle threshold, or a vendor breach notice. Review frequency beyond those events depends on what the credential reaches and the control framework you report against.
This is where non-human identity governance solutions and security tooling meet. Governance tools typically handle ownership, certification, and lifecycle, while security tools handle detection and blast-radius analysis. Both need the same inventory. Identity security posture management (ISPM) sits in the overlap, addressing standing weaknesses that ITDR watches for active abuse.
Building a Scalable Non-Human Identity Security Strategy
A busy team can secure non-human identities by sequencing the work by attack path rather than by identity type. Each path has a clear test for when it is closed.
Sequence the work by incident class
- 1.Inventory what exists and when it last authenticated. Inventory identities and credential metadata across cloud IAM, SaaS admin consoles, the CI/CD platform, and secrets stores. Treat unowned identity accounts as orphaned accounts, and unowned credentials as orphaned access until someone claims them.
- 2.List what third parties hold. Enumerate OAuth grants and integration tokens by vendor, with scopes. A vendor's breach notice will ask for this list.
- 3.Shrink what pipelines carry. Pin third-party actions to full commit SHAs, not version tags, since the tj-actions attacker repointed existing tags to a malicious commit. Where the CI platform supports it, replace stored cloud keys with workload identity federation.
- 4.Right-size application privileges. Start with identities holding tenant-wide or administrative roles, and compare their grants with observed use.
- 5.Rotate from evidence. Let last-use data set the order, and tie frequency to what each credential reaches.
When everything looks urgent, start with the incident class your team would take longest to contain. For many teams that is the third-party token, because it lives in someone else's infrastructure and the first warning may come from the vendor.
Rehearse the vendor-breach day
Pick one integration with broad read access, such as a CRM connector, and run the day its vendor reports stolen tokens. Time how long the team takes to list every token that vendor holds and revoke them without breaking unrelated workflows. Then decide which credentials stored in the exposed data need rotating. GTIG gave Drift victims that instruction, because the actor searched stolen data for secrets.
Run a second scenario from the tj-actions pattern: which workflows ran a compromised dependency during a known window, and which secrets could they read? Fold both answers into the identity incident response plan, so the next notice starts from a list.
How NewCore Secures Human, Machine, and AI Identities
Across the incidents above, Cloudflare's unrotated service token authenticated cleanly, as did Microsoft's legacy test application and the OAuth tokens behind the Drift integration. None of these attackers needed an exploit at the identity layer. Attackers aren't breaking in. They're logging in.
Responders lacked a fast answer to one question: what else could this identity reach? Cloudflare reconstructed the actor's access after the fact, and Drift customers had to trace every credential connected to one integration. We see blast radius as an identity-graph question, worth answering before the incident.
- Ask NewCore: Ask "What's the blast radius if this token is compromised?" and see every affected identity, app, session, and access path in one answer. Sessions can be revoked from the same screen. Risk removed: rebuilding a stolen credential's reach after the fact.
- Identity Discovery: Connects HRIS, directories, IdPs, IGA, PAM, cloud, SaaS, and AI platforms, and continuously indexes identities, accounts, credentials, and access relationships across connected systems. Risk removed: the credential nobody knew was still live.
- Agent Guardian: Issues scoped, short-lived credentials on demand, so the agent never holds the service provider's standing credential. Risk removed: the long-lived token an AI agent would otherwise carry.
- Agentic Governance: Covers autonomous workloads that run under their own workload identity, where policy becomes the ceiling from commissioning through retirement. Risk removed: machine access with no ceiling.
NewCore does not replace the secrets manager, the PAM vault, a CIEM tool, or the certificate authority. It supplies the view across them: discovery beyond the IdP, natural-language blast-radius questions, and brokered agent access for humans, machines, and AI agents alike.
The credential already works. Know what it reaches before someone else does. Request a Demo →
Frequently Asked Questions
How is non-human identity security different from secrets management?
Secrets management stores, issues, and rotates credentials, and a secrets management platform is often its backbone. Non-human identity security is broader. It asks which identities exist, what each can reach, who owns it, and whether a stolen one is in use. A vault can protect a secret and still not know a third party holds a copy.
Are OAuth apps and SaaS integrations non-human identities?
In most frameworks, yes. An OAuth application or SaaS integration can authenticate with its own token and hold scopes that persist beyond a person’s active session. The Midnight Blizzard and Drift incidents both ran through this type. Some organizations track integrations under third-party risk instead, which can work if someone still inventories the grants and can revoke them.
How can a team tell whether a service account is still in use before rotating it?
Start with authentication logs from the systems the account signs in to. Then check the consuming side: scheduled jobs, pipeline definitions, and application configs that reference it. A quiet log over a short window is weak evidence, since some jobs run only at quarter-end or year-end. Where the evidence stays unclear, a controlled disablement with monitoring and a rollback plan can reveal what still depends on the account.
Does identity threat detection and response cover non-human identities?
Partly, and coverage varies by product. Detections built around human sign-ins, such as impossible travel or repeated MFA prompts, do not translate directly to a service account or an OAuth app. Ask a vendor which detections apply to machine credentials, and which data sources they depend on. Posture findings about standing exposure often feed the same workflow.
What should be revoked first after a SaaS vendor reports a breach?
Usually the OAuth tokens and API keys the vendor's integration holds into your environment. After the Drift campaign, GTIG told affected organizations to revoke and rotate the credentials tied to the integration. It also told them to search integrated platforms for secrets the actor could have collected. The right order depends on scopes, and an existing inventory decides how fast it goes.
