TL;DR: Attackers are increasingly using legitimate credentials, tokens, service accounts and SaaS integrations to move through environments instead of breaking in, according to Delinea Labs December 2025 Threat Outlook. The security problem is no longer authentication alone, but the trust assumptions embedded in identity, automation and federation controls.
At a glance
What this is: This analysis argues that modern attackers are bypassing perimeter-style intrusion and using authentic identity pathways, especially tokens, service accounts and automation secrets, to move faster and quieter.
Why it matters: It matters because IAM, PAM and NHI programmes now have to govern identity as an attack surface across human, machine and automation flows, not just as a login mechanism.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
👉 Read Delinea's analysis of how identity attacks are evolving faster than defenders can adapt
Context
Identity attacks are attacks that use valid credentials, tokens, service accounts or delegated access paths to enter and move through environments. The primary issue is not whether authentication works, but whether the organisation can tell which identities are trusted, which are over-permissioned and which are being used outside their intended scope. In this case, the primary keyword is identity attacks, and the article's core finding is that attacker success increasingly depends on exploiting identity trust.
For IAM and NHI teams, that shift matters because the control plane now spans users, service accounts, API keys, SCIM flows, SaaS integrations and automation credentials. Once those identities are treated as normal operational plumbing rather than governed assets, attackers inherit the same trust relationships the business relies on. That makes lifecycle control, privilege scope and continuous monitoring more important than point-in-time authentication checks.
The article's examples, from supply-chain malware to AI-assisted intrusion, show a common pattern: identity mechanisms are being used exactly as designed, but for attacker purposes. That is not a niche threat pattern. It is the direction of travel for both machine identity abuse and broader enterprise access governance.
Key questions
Q: How should security teams reduce risk from compromised service accounts and tokens?
A: Start by mapping where service accounts, API keys and tokens can authenticate, then remove standing access wherever possible. Limit each identity to a narrow purpose, separate build and runtime credentials, and monitor for use outside normal systems. The goal is to make a stolen secret difficult to reuse across environments.
Q: Why do machine identities increase lateral movement risk in cloud and SaaS environments?
A: Machine identities often have persistent access, broad integration reach and fewer human friction points than user accounts. If one is compromised, attackers can reuse it across connected systems, admin APIs and automation workflows. That turns a single secret into a path for broader compromise.
Q: What do organisations get wrong about authentication in identity security?
A: Many teams treat successful authentication as evidence of trust, when it is only evidence that a credential was accepted. In modern environments, attackers often use valid tokens, provisioned accounts or integration credentials. Governance has to focus on whether the identity should be allowed to act, not only whether it can log in.
Q: Who is accountable when a compromised token is used to move across multiple systems?
A: Accountability usually spans identity owners, platform owners and security operations because the failure is distributed across issuance, scope, monitoring and revocation. In practice, frameworks such as Zero Trust and NHI governance require named ownership for each trust path, not just for the initial login event.
Technical breakdown
Why valid credentials are now the entry vector
The core mechanism is authentication abuse. Attackers do not need to defeat the identity provider if they can obtain tokens, service account credentials, CI/CD secrets or SaaS session material that already confer access. In practice, these materials often arrive through code repositories, preinstall scripts, exposed configuration, compromised developer machines or weak federation hygiene. Once valid credentials are in play, traditional perimeter indicators lose value because the session looks legitimate. For IAM teams, the technical problem is not only issuance, but where credentials are stored, how long they remain valid and which systems can mint or reuse them.
Practical implication: treat credential exposure paths, not only login failures, as the primary detection surface.
How service accounts and tokens enable lateral movement
Machine identities become the bridge between initial access and broader compromise. A service account or token is often scoped for convenience rather than strict task limitation, so once abused it can reach adjacent systems, cloud resources or automation tooling without triggering immediate suspicion. In SaaS and cloud environments, attackers exploit that trust by chaining integrations, SCIM provisioning, admin APIs and unattended automation. The result is lateral movement that looks like normal machine traffic but is actually attacker-driven use of standing identity relationships. This is why NHI governance and PAM now overlap operationally.
Practical implication: inventory machine-to-machine trust paths and reduce standing access that can be reused across systems.
Why AI speeds up the intrusion lifecycle
AI does not replace identity abuse. It compresses the time between recon, credential harvesting, privilege escalation and pivoting, which reduces defender reaction time. When AI supports the operator, the intrusion lifecycle can run at machine speed, with faster experimentation across credentials, faster targeting of exposed systems and faster pivoting once access is obtained. That matters because many defensive processes still assume human-paced activity, where analysts can observe, review and contain before the campaign completes. AI-assisted operations make that assumption much less reliable.
Practical implication: align detection, containment and escalation thresholds to machine-speed attacker behaviour, not human-paced response assumptions.
Threat narrative
Attacker objective: The attacker aims to turn trusted identity pathways into silent, repeatable access that supports lateral movement, credential harvesting and downstream exfiltration or extortion.
- Entry begins when the attacker authenticates through legitimate identity pathways, using stolen tokens, service credentials or SaaS integrations instead of forcing a perimeter breach.
- Escalation follows as the attacker reuses over-scoped access, stale machine identities or federation trust to reach additional systems and administrative functions.
- Impact occurs when the attacker pivots across environments, harvests more credentials, or launches ransomware and exfiltration from trusted accounts that look operational rather than malicious.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authentication without authorisation is now the dominant failure pattern. The problem is not that authentication stopped working, but that too many environments treat successful authentication as proof of legitimate intent. That assumption breaks once tokens, service accounts and federation flows are available to attackers. The implication is that identity governance must separate proof of identity from proof of acceptable use.
Identity blast radius is becoming the real control variable. When machine identities outnumber human identities and remain valid across multiple systems, a single compromised secret can reach far beyond its original purpose. Excessive privilege, stale credentials and weak offboarding turn identity into a multiplier for attack reach. Practitioners should judge programmes by how far one compromised identity can travel, not by how many logins are protected.
Identity risk now crosses human, machine and automation boundaries. Developers, CI/CD systems, SaaS connectors and privileged admin accounts are increasingly part of the same kill chain. That means classic IAM and NHI work can no longer be separated cleanly into user-only or workload-only programmes. The practitioner conclusion is that lifecycle, privilege and monitoring controls have to be designed as one access system.
Runtime trust in automation is an emerging named concept worth tracking. Modern attackers are exploiting the assumption that automation and provisioning flows are trustworthy because they are internal and operational. Once those flows are abused, the enterprise is effectively authorising attacker movement at machine speed. Security teams need to recognise automation itself as a trust boundary, not just a convenience layer.
Machine-speed intrusion compresses defender decision time below current review cycles. AI-assisted operators can run reconnaissance, credential use and lateral movement before many organisations finish their first triage loop. That is not merely faster crime. It is a structural mismatch between attacker tempo and governance tempo. The practitioner takeaway is that delayed review models are increasingly outpaced by the threat.
From our research:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- From our research: Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- The practical consequence is that identity attack paths remain hard to see, which makes the NHI Lifecycle Management Guide a useful next step for rotation, offboarding and access review.
What this signals
Identity attacks are now a programme design issue, not just a detection issue. If authentication can be reused as an attack path, then identity governance has to cover issuance, scope, trust relationships and revocation as one control system. The organisations most exposed are the ones still separating IAM, PAM, developer secrets and SaaS provisioning into disconnected ownership models.
Identity blast radius should become a board-level metric. A single compromised token is only as dangerous as the number of systems it can reach, which means visibility into service accounts and integration paths is becoming a core risk indicator. That is why the shift from point-in-time authentication to lifecycle-managed access matters for both human and machine identities.
With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the governance gap is structural, not accidental. Teams should expect attacker tradecraft to keep following the easiest trust paths unless identity scope is reduced and continuously validated.
For practitioners
- Inventory every identity trust path Map where tokens, service accounts, SCIM connectors, SaaS integrations and CI/CD secrets can authenticate, then rank them by lateral movement potential and business criticality.
- Reduce standing privilege on machine identities Remove long-lived access that allows a compromised token or service account to move across environments, especially where privilege was granted for convenience rather than a specific task.
- Harden developer and automation secret storage Move credentials out of code, local environments and unmanaged config files, then require controlled issuance and revocation for build and deployment pathways.
- Tune detection for identity abuse, not just malware Alert on anomalous token use, suspicious provisioning activity, unusual SaaS authentication and machine identities reaching systems they rarely touch.
- Shorten response playbooks for machine-speed intrusions Pre-authorise containment steps for compromised identities so analysts can revoke credentials, disable sessions and break trust chains before the attacker completes lateral movement.
Key takeaways
- Identity attacks succeed when attackers can reuse valid credentials, not when they need to defeat authentication outright.
- Machine identities, tokens and SaaS integrations create attack paths whose size is determined by privilege scope and lifecycle control.
- Security teams need to manage identity blast radius, secret handling and machine-speed response as one operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | The article centres on exposed and reused NHI credentials as an entry path. |
| NIST CSF 2.0 | PR.AC-1 | Identity-based entry and privilege abuse map directly to access control governance. |
| NIST Zero Trust (SP 800-207) | SC.L7 | The piece argues for continuous verification and reduced trust in identity paths. |
Inventory and control all NHI secrets, then remove exposed credentials from code, configs and automation.
Key terms
- Identity Attack: An identity attack is any intrusion that uses valid credentials, tokens, service accounts, or provisioning trust to gain access or move through systems. It succeeds by abusing accepted identity pathways rather than by forcing a perimeter breach, which makes ownership, scope and lifecycle control central to defence.
- Machine Identity: A machine identity is a non-human identity used by software, workloads, integrations or automation to authenticate and act. In practice, it includes service accounts, API keys, certificates and tokens, all of which need explicit ownership, limited scope and lifecycle controls because they can be reused by attackers if exposed.
- Identity Blast Radius: Identity blast radius is the amount of access, lateral movement and operational impact that a single identity can create if it is compromised. It is a useful governance measure because the same stolen secret can be low risk in one environment and catastrophic in another, depending on privilege and reach.
- Standing Privilege: Standing privilege is access that remains available over time instead of being granted only when needed. For machine identities and automation, standing privilege is especially risky because it gives attackers reusable reach if the credential is stolen or the account is left active beyond its intended lifecycle.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
This post draws on content published by Delinea: Identity attacks are evolving faster than defenders can adapt. Read the original.
Published by the NHIMG editorial team on 2025-12-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org