Trust erosion is the new identity risk in cloud environments

At a glance

What this is: This monthly threat outlook argues that attackers are shifting from password theft to trust exploitation across OAuth, machine identities, and SaaS consent paths.

Why it matters: It matters because IAM, NHI, and PAM teams now need to govern tokenised trust chains, not just authenticate users and rotate secrets.

By the numbers:

• A dataset of 183 million credentials surfaced on Have I Been Pwned, 16 million of which were new.
• Across the ecosystem, 524 identity-related CVEs were recorded in October, including 43 within identity products themselves.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Delinea's November 2025 threat outlook on trust erosion and identity abuse

Context

Identity risk is no longer limited to stolen passwords. In cloud and SaaS environments, attackers increasingly target OAuth tokens, service accounts, and consent flows because those assets inherit trust and often outlive the humans or apps that created them. That makes the problem an NHI governance issue as much as a detection issue.

The article’s central claim is that trust itself has become the attack surface. That matters for IAM and PAM teams because the weakest link is often not a login page but a token, connector, or delegated permission that still appears legitimate inside the environment.

Key questions

Q: How should security teams govern OAuth tokens and service accounts in cloud environments?

A: Treat OAuth tokens and service accounts as governable identities, not just technical artefacts. Assign ownership, scope permissions tightly, review dormant grants, and revoke anything that no longer has a clear business purpose. The goal is to stop trusted access from becoming permanent attacker leverage across SaaS and cloud systems.

Q: Why do machine identities increase blast radius when trust is reused across tenants?

A: Machine identities increase blast radius because they often carry reusable trust into multiple systems without human-style friction such as MFA prompts or step-up checks. If the same token or service account is accepted in several places, one compromise can become tenant pivoting, lateral movement, and persistent access.

Q: What do security teams get wrong about app consent and low-code integrations?

A: Teams often treat consent as a one-time user action instead of a lifecycle-managed access grant. That creates stale permissions, hidden connectors, and approval paths attackers can repurpose. Consent needs ownership, review, and revocation controls just like privileged access.

Q: Who is accountable when a third-party connector expands the identity attack surface?

A: Accountability should sit with the business owner of the integration and the identity team that approved the trust relationship. If a connector can expose data or extend access, it needs a named owner, an approval record, and a revocation path when the relationship changes.

Technical breakdown

OAuth token abuse and tenant pivoting

OAuth tokens are bearer credentials, so possession often matters more than user presence. When adversaries reuse tokens across SaaS tenants, they bypass interactive authentication and can move through approved integrations without triggering the same signals as password theft. In practice, the threat is amplified when tokens are long-lived, broadly scoped, or tied to third-party apps that were approved once and then forgotten. This is why token abuse is both an authentication and an authorisation problem, not just an incident-response problem.

Practical implication: inventory OAuth grants, scope them tightly, and review dormant third-party app consent before attackers pivot through them.

Machine identities and service accounts as lateral movement paths

Service accounts, API keys, and static credentials behave differently from human logins because they often lack user-centric controls such as MFA prompts, activity-based review, or clear ownership. Once exposed, they can be reused for lateral movement across cloud and SaaS systems, especially when privileges were assigned for convenience and never revisited. The article’s emphasis on machine identity exposure reflects a broader pattern: identity infrastructure becomes attack infrastructure when non-human credentials are invisible, over-scoped, or unmanaged.

Practical implication: assign ownership to every service account, remove standing excess privilege, and monitor machine identity use as a primary attack path.

Consent flows and low-code trust boundaries

Low-code platforms such as copilots and app builders create trust relationships through user-approved permissions, connector grants, and delegated access. The risk is not the platform itself but the way legitimate approval flows can be repurposed to create malicious access that looks normal to the destination system. This blurs the line between authorised business integration and attacker-controlled persistence. Security teams need to treat consent as an access control event with lifecycle, monitoring, and revocation requirements.

Practical implication: review consent grants as lifecycle-managed access, not one-time user actions, and enforce revocation when risk changes.

Threat narrative

Attacker objective: The objective is durable, low-noise access to cloud and SaaS environments through trusted identity pathways rather than overt compromise.

1. Entry occurs when attackers obtain or reuse valid OAuth tokens, machine credentials, or consented application access instead of forcing a traditional login.
2. Escalation follows when those credentials are used to bypass MFA, pivot across tenants, or reach systems that trust the token more than the requester.
3. Impact is persistent access inside SaaS and cloud environments, with expanded blast radius through reused trust relationships and unmanaged machine identities.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trust chains have become the new perimeter failure. This outlook is not really about passwords disappearing, it is about permissions and delegated trust replacing the login screen as the attacker’s preferred entry point. OAuth grants, SaaS connectors, and service accounts can all preserve legitimacy while transferring risk across systems. The practical conclusion is that identity governance now has to follow trust relationships end to end, not just user authentication events.

Machine identities remain the most under-governed trust assets in most enterprises. Service accounts and static credentials are used because they are convenient, but convenience turns into persistence when ownership, visibility, and rotation are weak. The article’s examples show that attackers increasingly work through credentials that were never intended to behave like human identities. Practitioners should treat unmanaged machine identity as an exposure class, not a configuration detail.

Consent-driven access is now a lifecycle problem, not a one-time approval problem. Low-code and SaaS ecosystems let users approve access that can later become excessive, stale, or maliciously repurposed. That means revocation, monitoring, and re-certification need to apply to app consent and connector grants with the same seriousness as privileged human access. The implication is that access governance must expand beyond accounts to include trusted relationships themselves.

Identity infrastructure is now attack infrastructure. The rise in identity-related CVEs, combined with repeated abuse of tokens and machine credentials, shows that the control plane has become a target plane. This does not mean more authentication layers are the answer by themselves. It means architecture, telemetry, and governance have to assume that valid identity artefacts will be stolen, reused, and chained across environments.

Ephemeral trust debt: the article describes a category of risk where credentials, consents, and integrations outlive the moment they were granted. That debt accumulates quietly because the access still looks valid. The practitioner takeaway is that every delegated trust relationship needs an owner, a review trigger, and a revocation path before it becomes an attacker’s persistence mechanism.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams are still trying to govern machine identity with partial inventories.
• For deeper breach pattern context, see 52 NHI Breaches Analysis for recurring exposure paths and control failures.

What this signals

Ephemeral trust debt: security programmes will increasingly fail if they treat delegated access as a one-time approval rather than a living control object. The operational signal is simple: if tokens, consents, and connectors cannot be owned, reviewed, and revoked on demand, they will outlast the business purpose they were meant to serve.

The next maturity step is convergence between IAM, PAM, and NHI governance. Teams that still separate human access reviews from service account oversight will miss the attack path that starts with a consent grant and ends with tenant-wide persistence. For baseline control language, align to the Ultimate Guide to NHIs and validate cloud trust assumptions against CISA cyber threat advisories.

With 92% of organisations exposing NHIs to third parties, the governance issue is no longer edge-case risk but ecosystem design. That means security leaders should expect identity review, SaaS governance, and vendor risk management to converge around trust chains rather than individual accounts.

For practitioners

• Map every trust-bearing credential Inventory OAuth tokens, service accounts, API keys, and connector grants together so the team can see where trust is delegated outside interactive authentication. Prioritise the systems that can cross tenant, SaaS, or cloud boundaries.
• Review third-party consent and connector sprawl Re-certify app consents, low-code connectors, and delegated permissions on a fixed schedule and revoke anything that no longer has an owner or business purpose.
• Treat machine identity ownership as mandatory Assign a named owner for every non-human credential, define the expected use case, and alert when it is used outside that pattern. Unowned credentials should be escalated as governance defects, not just hygiene issues.
• Shorten the lifetime of reusable trust artefacts Rotate static secrets, expire tokens where possible, and remove standing permissions that let a single compromise persist across multiple services or tenants.

Key takeaways

• Attackers are increasingly exploiting trusted identity artefacts such as OAuth tokens, service accounts, and consent grants instead of relying on password theft.
• The scale problem is structural, with identity-related CVEs climbing and visibility into machine identities still deeply incomplete.
• Enterprises need lifecycle controls for delegated trust, including ownership, review, scope reduction, and revocation, or trust will become persistence.

Key terms

• OAuth Token: A credential that lets an application act on behalf of a user or service without repeating the login flow. In identity security, the risk is that possession can confer access across systems even when the original user is not present, making scope and lifetime critical governance concerns.
• Machine Identity: A non-human identity used by software, services, or workloads to authenticate and exchange trusted access. These identities often rely on static secrets, certificates, or tokens, so ownership, rotation, and monitoring matter more than user experience.
• Consent Grant: An approval that allows an application or connector to access data or functions within a trusted environment. It becomes a security control only when it is reviewed, owned, and revocable; otherwise it can create hidden long-lived access that outlives the original business need.
• Trust Chain: The sequence of identities, permissions, integrations, and delegated access relationships that enables systems to work together. When one link is overly broad or unmanaged, the entire chain can become an attacker path even if the initial credential looked legitimate.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Delinea: Trust eroding, Delinea Labs November 2025 Threat Outlook. Read the original.