By NHI Mgmt Group Editorial TeamPublished 2025-12-10Domain: Governance & RiskSource: Britive

TL;DR: NOBELIUM’s campaign against cloud service providers and downstream customers relied on password spraying, token theft, API abuse, and delegated administrative rights to move laterally and reach privileged accounts, according to Britive Team’s analysis. Standing privilege and broad trust relationships remain the core governance failure, not a cloud platform flaw.


At a glance

What this is: This is an analysis of how NOBELIUM exploited trusted provider-customer relationships and standing privileges to reach cloud administrative access.

Why it matters: It matters because IAM and NHI teams need to control delegated access, not just perimeter entry, when third parties can manage customer tenants.

👉 Read Britive Team’s analysis of NOBELIUM’s cloud provider compromise


Context

Cloud service provider relationships often require delegated access, but that convenience becomes a governance problem when privileges remain standing and broadly scoped. In this case, the primary risk is not a defect in the cloud platform itself, but the trust model around service-provider access and downstream customer tenancy administration.

For IAM and NHI practitioners, the lesson is that service accounts, delegated admin roles, tokens, and other secrets can become an attacker’s bridge if they are not tightly scoped, monitored, and time-bound. The starting position described here is common in multi-tenant operations, which is why it creates such a broad attack surface.


Key questions

Q: How should security teams govern delegated admin access from cloud providers?

A: Security teams should scope delegated admin access by tenant, task, and time, then require explicit ownership and revocation. The goal is to prevent a provider account from becoming a permanent backdoor into customer environments. Delegated access should be reviewed as a privileged NHI, not as a routine partner entitlement.

Q: When does standing privilege create unacceptable cloud risk?

A: Standing privilege becomes unacceptable when the same identity can reach administrative functions continuously, especially across multiple tenants or environments. That risk rises further if the access is shared, unmonitored, or tied to long-lived tokens. In cloud operations, persistent privilege is a blast-radius problem, not just an access-control issue.

Q: What is the difference between delegated access and least privilege?

A: Delegated access is a business arrangement that lets one organization operate inside another’s environment. Least privilege is a control model that limits what that access can do, for how long, and under what conditions. A delegated relationship can still be least privilege if it is tightly scoped and time-bound.

Q: Why do cloud trust relationships matter so much for NHI governance?

A: Cloud trust relationships matter because attackers often target the identity path instead of the platform itself. If a provider, token, or automation account is over-privileged, that trust can be reused to reach customer systems. NHI governance must therefore cover every machine-operated identity that can inherit trust across organizations.


Technical breakdown

How delegated administration becomes an NHI attack path

Delegated administration lets a provider manage a customer tenant using rights that look legitimate inside the customer environment. That model is efficient, but it creates a durable trust chain between organizations. If attackers compromise a provider account, steal a token, or abuse an API path, they can inherit that delegated trust and act with the provider’s effective privileges. The technical issue is not authentication alone. It is the combination of standing entitlement, broad scope, and limited temporal constraint. Once those credentials exist, they can be reused until revoked, which turns a temporary foothold into persistent access.

Practical implication: Map every delegated admin path to a named owner, scope, and expiry so provider access cannot outlive the task.

Why standing privilege expands the blast radius in cloud environments

Standing privilege means access stays continuously available rather than being issued only when needed. In cloud environments, that often includes management plane permissions, tenant administration, and access to workloads through API-driven control paths. Because cloud operations rely heavily on identity, attackers do not need to break the platform if they can reuse legitimate access and then move across linked services. The blast radius grows when the same principal can administer multiple resources, tenants, or customers without step-up checks, approval, or short-lived credentials. This is why privilege scope matters as much as credential strength.

Practical implication: Replace persistent admin rights with time-bound, task-scoped access for both human operators and non-human identities.

How token theft and API abuse support lateral movement

Tokens and API keys are attractive because they often bypass interactive login controls once stolen. When attackers obtain a valid token from a service provider or managed service workflow, they can query, modify, or chain actions across cloud services without triggering the same friction as password-based access. API abuse then becomes the mechanism for privilege escalation and lateral movement, especially where audit logging is incomplete or alerting is weak. In practice, the risk increases when secrets are reused across environments, stored without rotation discipline, or embedded in automation that lacks strong identity checks.

Practical implication: Treat tokens and API keys as high-risk NHIs and rotate them on a schedule tied to exposure, not convenience.


Threat narrative

Attacker objective: The objective is to inherit provider-level trust and use it to reach customer cloud administration without needing direct platform compromise.

  1. Entry via password spraying, token theft, API abuse, and spear phishing against provider-side identities and downstream trust relationships.
  2. Escalation through standing delegated administrative rights that allow the attacker to operate as a tenant administrator inside customer environments.
  3. Impact through lateral movement across cloud environments and control of privileged accounts, workloads, and administrative functions.

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


NHI Mgmt Group analysis

Standing privilege is the real vulnerability here, not the cloud service model. NOBELIUM’s tradecraft worked because customer organizations allowed ongoing administrative access to survive beyond the moment it was needed. That is a governance failure in IAM and NHI management, not a defect in cloud tenancy architecture. Practitioners should treat persistent provider rights as high-risk access that requires the same scrutiny as any other privileged path.

Provider trust chains create identity blast radius. When a service provider can manage multiple customer tenants, compromise in one place can become access in many places. The practical lesson is that identity scope must be bounded by customer, role, time, and task. Teams that do not separate these dimensions will continue to overestimate the safety of shared operational models.

Least privilege only works when it is enforceable at runtime. Reviewing access annually is not enough if provider rights remain active for months or years. Short-lived elevation, approval workflows, and continuous monitoring are the only controls that meaningfully reduce exposure once a trust relationship exists. Practitioners should move from static delegation to just-in-time authorization.

Cloud security programs must classify delegated admin accounts as NHIs. These identities are machine-operated, long-lived, and often over-scoped, which makes them central to both prevention and detection. If teams inventory only human administrators, they miss the identities attackers are most likely to exploit. The right posture is to manage delegated access as a privileged NHI category with explicit lifecycle controls.

From our research:

What this signals

Identity blast radius is now a programme-level metric. Once provider accounts, service identities, and tokens can administer customer tenants, the question is no longer who logged in. It is how far that identity can move before detection or revocation stops it. Teams should pair delegated access reviews with the OWASP NHI Top 10 to map abuse paths.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey, over-privilege is becoming the default rather than the exception. That makes static delegation especially dangerous because the same control gaps that affect AI agents also affect partner automation and managed service identities.

Programmes that still treat cloud partner access as an onboarding issue will miss the operational reality. Access needs to be continuously bounded, monitored, and revoked when the task ends. Aligning this work with 52 NHI Breaches Analysis helps teams see the recurring pattern: privileged machine identities become the shortest path to broad compromise.


For practitioners

  • Inventory delegated admin paths Map every CSP, MSP, and partner account that can administer customer tenants. Record scope, owner, approval method, and expiration for each delegated right.
  • Replace standing privilege with JIT access Issue tenant administration only for the duration of the task and revoke it automatically afterward. Require step-up controls before any privileged cloud action.
  • Audit and minimize service-provider access Review all partner entitlements, remove unused delegated rights, and verify MFA where interactive access still exists. Focus on accounts that can reach admin controls or modify workloads.
  • Rotate and monitor privileged tokens Treat API keys, tokens, and certificates used by automation as high-risk secrets. Rotate them on a strict schedule and alert on unusual use across cloud control planes.

Key takeaways

  • Provider and customer trust chains become a breach path when privileged access is left standing.
  • Cloud compromise often follows identity misuse, not platform exploitation, which makes NHI controls central to defense.
  • Teams should move delegated administration to task-scoped, revocable access with stronger monitoring and lifecycle control.

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.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Standing privilege and token abuse map directly to NHI credential lifecycle risk.
NIST CSF 2.0PR.AC-4Provider access should be restricted by least privilege and monitored continuously.
NIST Zero Trust (SP 800-207)Zero Trust applies to cross-tenant provider access and continuous verification.

Replace persistent delegated rights with time-bound access and rotate exposed secrets immediately.


Key terms

  • Delegated Administrative Access: Delegated administrative access is a permission model that allows one organization or identity to manage another organization’s environment. In cloud operations, it is useful for support and service delivery, but it becomes a security risk when rights are broad, persistent, or poorly monitored.
  • Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. For non-human identities and cloud administrators, it expands the attack surface because compromise of the account immediately provides reusable high-risk access.
  • Identity Blast Radius: Identity blast radius is the amount of damage an attacker can cause after compromising a single identity. In NHI governance, it depends on scope, duration, and connected systems, which is why over-privileged service accounts and tokens are especially dangerous.
  • Just-In-Time Access: Just-in-time access is a control pattern that grants elevated permissions only for a narrow task window and then removes them. It reduces exposure for privileged non-human identities by preventing long-lived access from being used as a persistent foothold.

Deepen your knowledge

Cloud privilege blast-radius control is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment relies on delegated admin rights or partner automation, this is directly relevant to your governance model.

This post draws on content published by Britive Team covering the NOBELIUM campaign against cloud service providers and downstream customers: About the Latest NOBELIUM Compromise. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-12-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org