TL;DR: Attackers are increasingly weaponizing trust links such as OAuth tokens, service accounts, and consent flows to persist across SaaS and cloud environments, while Delinea Labs notes 524 identity-related CVEs in October, including 43 in identity products. The real failure is that identity programmes still assume trust boundaries remain stable long enough for review, rotation, and detection to catch up.
At a glance
What this is: Delinea’s November 2025 threat outlook says attackers are moving beyond password theft and using OAuth tokens, service accounts, consent flows and machine identities as the control plane for persistence in cloud environments.
Why it matters: IAM, IGA and PAM teams need to govern trust paths, not only user logins, because delegated access, static credentials and cross-tenant permissions can turn ordinary integrations into durable attacker footholds.
Context
Trust relationships in cloud and SaaS environments are now part of the attack surface. When identities can inherit permissions through tokens, consented apps, service accounts and connectors, the security model depends on assumptions about who or what can act on behalf of whom.
Delinea’s November 2025 threat outlook argues that those assumptions are breaking down. The article’s focus is not password theft alone, but the way adversaries exploit delegated access and machine identity exposure to keep access alive without obvious login activity.
For IAM and NHI practitioners, the practical problem is governance drift: the organisation may still know who owns a human account, but it may not know who owns the trust chain behind an OAuth grant, a service account or a third-party integration.
Key questions
Q: What breaks when cloud identities are not centrally governed?
A: Shadow accounts, orphaned credentials and inconsistent role definitions emerge because no single process can see the whole access picture. That breaks least privilege, complicates incident response and makes compliance evidence harder to prove, especially when workforce and service identities are managed separately.
Q: Why are OAuth tokens such a persistent SaaS security risk?
A: OAuth tokens are persistent because they often bypass MFA, carry broad delegated permissions, and remain valid long after the original approval. That combination creates durable access for attackers if a token is stolen or abused. The problem is amplified when organisations lack full visibility into connected apps and do not review grants regularly.
Q: What signs show that machine identities are outside governance?
A: Warning signs include service accounts with no clear owner, static API credentials that never expire, tokens reused across multiple systems, and integrations that are never reviewed after deployment. If the team cannot explain why a machine identity exists and who can retire it, governance is already incomplete.
Q: How should security teams respond when a stolen cloud credential is used to create new identities?
A: Teams should treat new identity creation after credential compromise as active persistence, not routine administration. The immediate response is to revoke the exposed credential, disable the abused identities, review recent policy changes, and inspect for reconnaissance or compute abuse. It is also essential to search for similar naming patterns, since attackers often create backup or service accounts to blend in.
Technical breakdown
How OAuth token abuse turns consent into persistence
OAuth tokens are bearer artefacts that allow an application or actor to access resources without re-prompting for credentials on every action. When an attacker steals or reuses a token, they can often continue operating inside a SaaS environment even after password resets or MFA prompts, because the trust decision has already been delegated. Consent flows make this more subtle: a user-approved app can receive legitimate access that later becomes an abuse path if the app, tenant relationship or token handling is compromised. The real issue is that the control point moves from authentication to delegated authorisation, where review cycles are usually weaker.
Practical implication: treat consented OAuth grants as governed access paths and review them with the same discipline as privileged accounts.
Why service accounts and static API credentials create invisible attack paths
Service accounts and static API credentials often operate without strong human ownership, interactive sign-in, or clear business context. That makes them attractive for lateral movement because they can carry standing access into systems that do not generate the same alerts as user logins. If those credentials are reused across tenants, applications or environments, they also create a wider blast radius than a single application owner may realise. In identity terms, the problem is not just that the credential exists. It is that the credential’s authority outlives the operational need that created it.
Practical implication: inventory machine identities by owner, scope and expiration so stale non-human access can be retired before it becomes a persistence channel.
How trust erosion changes cloud identity boundaries
Cloud identity relies on chained trust between tenants, applications, consent frameworks, token validation services and identity providers. When one link in that chain is weak, the attacker does not always need to break authentication directly. They can exploit the assumption that the downstream trust decision is still valid. That is why token validation flaws, reused OAuth grants and cross-tenant permissions matter together: they show that the boundary is no longer a single login event, but a sequence of delegated decisions. Once those decisions become too permissive or too persistent, identity infrastructure behaves like attack infrastructure.
Practical implication: model trust chains explicitly so every delegated permission has a defined owner, scope, revocation path and monitoring control.
Threat narrative
Attacker objective: The objective is to maintain quiet, durable access inside cloud and SaaS environments by turning legitimate trust relationships into reusable attacker pathways.
- Entry occurs through reused OAuth tokens, malicious consent flows or static machine credentials that already carry delegated access into SaaS and cloud services.
- Credential abuse then lets the attacker bypass login controls, operate under legitimate-looking authorisation and avoid obvious MFA-triggered alerts.
- Escalation happens when those tokens, service accounts or trust relationships are reused across tenants, integrations or systems, expanding reach beyond the original foothold.
- Impact is durable persistence across connected environments, with lateral movement and data access achieved through trusted identity links rather than noisy exploitation.
NHI Mgmt Group analysis
Trust erosion is now the governing failure mode in cloud identity. The central risk is no longer a password being guessed or phished. It is that delegated access, consented applications and machine identities accumulate authority that outlives the operational context that justified them. That shifts governance from login control to trust-chain control, and organisations that still treat those as separate problems are managing the wrong boundary.
OAuth consent and token reuse expose a trust economy that identity reviews do not see. Review processes built around interactive accounts miss the fact that bearer tokens and approved applications can keep working with no fresh authentication event. That means the review unit is no longer the user session alone, but the entire delegated relationship behind it. Practitioners need to treat token grants as first-class governance objects, not incidental by-products of access provisioning.
Machine identity exposure is the quietest way to expand blast radius. Service accounts and static API credentials often carry persistent authority across systems, but they rarely receive the ownership, monitoring and retirement attention given to human accounts. The result is identity infrastructure that can be reused as attacker infrastructure. The practitioner conclusion is straightforward: if no one can clearly own, scope and retire the credential, it is already outside governance.
Identity infrastructure has become attack infrastructure. Delinea’s cited vulnerabilities in token validation and service principal trust logic show that trust failures are no longer edge cases. They are increasingly part of the core control plane. That does not just demand better monitoring. It requires security teams to rethink which parts of the identity stack are assumed to be trustworthy by default, because those assumptions are now adversary targets.
Named concept: trust-chain governance. This article points to a specific control gap where organisations manage accounts and apps but not the sequence of delegated decisions linking them. When that chain is unmanaged, revocation, monitoring and ownership all fail at different points. Practitioners should treat the trust chain as the governed object, because that is where persistence now hides.
What this signals
Trust-chain governance: cloud identity programmes now need to manage the delegated relationship, not just the primary login. That means consented apps, service accounts and cross-tenant grants should all sit inside the same lifecycle and review model, because the attacker is increasingly working through the links between identities rather than the identities themselves.
Adaptive authentication alone will not solve this problem. The harder issue is that many cloud access paths now look legitimate after issuance, so the control has to shift toward issuance review, ownership assignment and revocation discipline for machine identities and delegated grants.
For practitioners
- Map delegated trust paths Inventory OAuth grants, service accounts, connectors and static credentials together so you can see which identities inherit authority from which approvals or integrations.
- Review consented applications Reassess app consents that can access mail, files or cloud resources without a fresh user challenge, especially where those grants span tenants or business units.
- Assign owners to machine identities Require a named business and technical owner for every service account and API credential, including an expiry date and a documented revocation path.
- Correlate token behaviour and cross-tenant activity Tune detection to look for unusual token reuse, consent patterns and API calls that move across tenants or SaaS boundaries without normal sign-in evidence.
- Shorten the lifetime of static credentials Replace persistent secrets with scoped, time-bound alternatives where possible, and remove any credential that continues to work after its original purpose has expired.
Key takeaways
- Cloud attackers are increasingly using delegated trust paths such as OAuth tokens, consent flows and service accounts to persist without obvious login activity.
- The evidence in this outlook points to token reuse, machine identity abuse and cross-tenant trust relationships as the main mechanisms expanding attacker reach.
- Identity teams need to govern delegated access as a first-class control surface, or cloud infrastructure will continue to behave like attacker infrastructure.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party integrations and consent flows are a key abuse path in the article. |
| NHI-05 — Overprivileged NHI | The article highlights service accounts and tokens with broader authority than their task requires. | |
| NHI-07 — Long-Lived Secrets | Static credentials and reusable tokens are central to the persistence pattern described. | |
| Recommendation — Review third-party grants and revoke any integration that no longer needs delegated access. Constrain non-human identities to the minimum permissions required for each delegated action. Replace long-lived machine credentials with time-bound alternatives and revoke expired secrets promptly. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes token theft, credential reuse and pivoting across SaaS environments. |
| Recommendation — Map token abuse to credential access and lateral movement so detections focus on reuse across tenants and apps. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing delegated permissions and entitlements. |
| Recommendation — Use PR.AA-05 to review and reduce delegated access across apps, tokens and service accounts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Reusable OAuth tokens and static credentials fall under authenticator lifecycle control. |
| Recommendation — Apply IA-5 to govern issuance, rotation and revocation of machine credentials and tokens. | ||
Key terms
- Trust-chain governance: The discipline of governing the full sequence of delegated permissions that allows one identity, application or service account to act on behalf of another. In cloud environments, the security question is not only who signed in, but which grants, tokens and connectors still confer authority downstream.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Consent flow: A consent flow is the authorization journey that records and enforces what a user or agent is allowed to access. In multi-tenant MCP, different tenants may require different consent steps, scopes, or assurance levels, so consent becomes part of identity design rather than a UI detail.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org