SolarWinds-style cloud compromise exposed the cost of privileged access

At a glance

What this is: This analysis ties the SolarWinds compromise to privileged cloud credentials, showing how attackers used trusted access paths to move from a foothold to elevated control.

Why it matters: It matters to IAM and NHI practitioners because service accounts, tokens, certificates, and cloud admin roles can turn a software compromise into a broad identity and access failure.

👉 Read Britive Team's analysis of SolarWinds privilege abuse in cloud environments

Context

A compromise in trusted software becomes an identity problem when attackers can reuse privileged cloud access instead of forcing new authentication. In the SolarWinds case, the issue was not only malware execution but the ability to manipulate cloud identity controls, hijack service accounts, and operate through trusted permissions. That is the core NHI governance gap: modern cloud environments often assume privilege is stable when attackers are actively reshaping it.

For IAM teams, this is a reminder that attack paths now run through accounts, roles, certificates, and federated trust relationships. Britive Team frames the incident as a warning about visibility and privilege control, and that framing is typical for organizations still treating cloud permissions as static. The better reading is that NHI governance must treat privileged access as a moving target, not a fixed control set.

Key questions

Q: How should security teams reduce the risk of cloud privilege abuse after a supply chain compromise?

A: Security teams should assume a trusted software foothold can become identity control. The response is to inventory privileged cloud identities, remove standing elevation where possible, enforce task-scoped access, and monitor certificate, federation, and service principal changes as high-priority events. The goal is to shrink the attacker's usable window and limit how far one compromised identity can reach.

Q: Why are service accounts and certificates so dangerous in cloud attacks?

A: Service accounts and certificates are dangerous because they can validate trust or issue access without a human login flow. If attackers steal or modify them, they can create durable access that looks legitimate to the platform. That makes rotation, scope control, and ownership assignment essential for non-human identity governance.

Q: What is the difference between least privilege and Zero Standing Privilege?

A: Least privilege limits what an identity can do, while Zero Standing Privilege also limits when that access exists. Least privilege can still leave permanent roles in place. Zero Standing Privilege removes the standing entitlement and grants it only when needed, which reduces the time attackers can reuse elevated access.

Q: How can organisations spot obfuscated privilege changes before they become a breach?

A: Organisations should watch for trust changes that expand authority without a matching business request. Examples include new federation certificates, added credentials on service principals, and unexpected permission grants. Those changes should trigger review in the SIEM and be compared against approved identity baselines and ownership records.

Technical breakdown

How privileged cloud credentials enable lateral movement

In cloud environments, privileged credentials do more than authenticate a session. They can authorize configuration changes, create trust relationships, and grant access to downstream services. Once an attacker has a trusted foothold, the next step is often not password theft but permission abuse: modifying identity providers, adding certificates, or expanding service principal rights. That is why cloud identity compromise can spread faster than traditional endpoint intrusion. The attacker is not fighting the system from outside. They are operating inside the control plane with legitimate-seeming actions.

Practical implication: Practitioners should map which cloud identities can modify trust, not just which ones can log in.

Why service accounts and SAML trust are high-risk NHI assets

Service accounts, OAuth applications, and SAML signing certificates are all non-human identities with persistent authority. If those identities are over-privileged, compromised, or poorly monitored, they can be used to mint new access without triggering obvious user-centric controls. In the SolarWinds pattern, trusted authentication pathways were the mechanism, which means the weakness was architectural rather than purely procedural. Identity systems that do not distinguish between human login risk and machine trust risk leave a gap attackers can exploit through normal administration paths.

Practical implication: Security teams should inventory every privileged NHI that can issue or validate trust tokens.

Zero standing privilege in cloud administration

Zero Standing Privilege means elevated access exists only when needed and disappears when the task ends. In cloud administration, that reduces the time window in which attackers can reuse a stolen role, token, or certificate. It also limits the amount of standing authority hidden inside service principals and automation accounts. The control works best when paired with continuous discovery and session-bound approval, because privilege can otherwise accumulate silently across cloud subscriptions and identity systems. The underlying principle is simple: permanent admin access creates permanent blast radius.

Practical implication: Replace persistent elevated roles with task-scoped access and automatic expiry wherever possible.

Threat narrative

Attacker objective: The objective was durable, trusted cloud control that could support deeper compromise while blending into normal administration activity.

1. Entry occurred through a supply chain compromise in SolarWinds Orion, which gave attackers a trusted foothold inside the victim environment.
2. Escalation followed as the actors moved laterally into Microsoft Azure, manipulated Azure Active Directory, hijacked cloud service accounts, and created new accounts with elevated permissions.
3. Impact was achieved by using trusted privileges to alter defenses, hide activity in logs, and open paths to additional cloud services and downstream users.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Privileged access, not just software compromise, is the decisive failure mode in cloud intrusions. The SolarWinds pattern shows that attackers do not need to break every control if they can reach a trusted identity path. Once they can modify identity settings, create accounts, or alter certificates, they inherit the environment's own trust model. Practitioners should treat cloud identity control as an intrusion surface in its own right.

Identity blast radius is the right concept for understanding modern cloud risk. When one service account, application credential, or federation trust can reach multiple environments, the compromise radius becomes structural rather than accidental. That means access reviews must consider what an identity can change, not just what it can read. The practical conclusion is that high-value identities need separate governance, stronger monitoring, and smaller scopes.

Zero standing privilege must extend to machine identities, not only humans. Many organizations still reserve JIT thinking for employees while leaving service accounts and application credentials permanently enabled. That gap is exactly where attackers look for durable access. The governance answer is to expire privilege by default across human and non-human identities alike.

Cloud trust relationships are now part of the attack path, so they require continuous review. Federation certificates, SAML trusts, OAuth application permissions, and service principal grants can all be converted into attacker control if they remain too broad or too durable. This makes periodic review insufficient on its own. Teams need continuous detection of trust changes and explicit ownership for every privileged NHI.

SolarWinds remains a reminder that obfuscated privilege is often invisible to tools built around user-centric assumptions. Logs may show normal administration while the underlying intent is malicious. That is why IAM programs need controls that reason about machine identities, trust issuance, and privilege propagation. Practitioners should build for anomaly detection around authority changes, not just login events.

From our research:

• 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to the 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to the 2024 Non-Human Identity Security Report.
• For the wider context on access abuse patterns, see the 52 NHI breaches Report for recurring failure modes and root causes.

What this signals

Identity governance must now assume that cloud privilege can be rewritten from inside the environment. The practical shift for practitioners is moving from periodic review to continuous detection of permission drift, trust modification, and certificate changes. With 35.6% of organisations already citing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, per the 2024 Non-Human Identity Security Report, the problem is operational rather than theoretical.

Identity blast radius is the more useful planning metric than account count. A small number of over-privileged service accounts, federation trusts, or automation identities can create a much larger compromise surface than a broad set of low-risk users. Practitioners should prioritise the identities that can alter trust, not just those that can access data.

Non-human identity governance now sits at the intersection of zero trust and cloud control-plane monitoring. Teams that already map privileged paths can extend that work to certificates, OAuth grants, and SAML configurations, then tie those events into response playbooks. That is how the programme turns from static access review into active control of trust propagation.

For practitioners

• Audit cloud identities with trust-changing authority Identify every account, service principal, and certificate that can modify federation, create credentials, or elevate permissions across cloud platforms. Prioritise identities that can alter Azure Active Directory, SAML settings, or OAuth grants.
• Enforce Zero Standing Privilege for admin roles Move privileged cloud access to task-scoped approval with automatic expiry at session end. Reserve standing access only for narrowly defined break-glass use cases and monitor those sessions continuously.
• Separate human login controls from machine trust controls Do not rely on MFA alone for service accounts, application credentials, or signing certificates. Apply distinct governance for non-human identities, including rotation, scope limits, and ownership reviews.
• Monitor trust changes as security events Alert on new certificates, modified federation trusts, added x509 keys, and expanded permissions on service principals. Feed those events into a SIEM so obfuscated privilege changes are visible quickly.
• Review high-risk NHI permissions on a fixed cadence Reconcile account, group, and permission changes against approved baselines and investigate any unplanned privilege expansion. Use the 52 NHI breaches Report to benchmark how often identity abuse precedes larger compromise.

Key takeaways

• Cloud supply chain intrusions become far more dangerous when attackers can turn trust relationships into administrative control.
• Non-human identities such as service accounts, tokens, and certificates need governance separate from human access models.
• Reducing standing privilege and monitoring trust changes are the two controls most likely to shrink attacker dwell time.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity that acts on behalf of software, infrastructure, or automation rather than a person. In practice this includes service accounts, API keys, tokens, certificates, workloads, bots, and AI agents, all of which require ownership, scope control, and lifecycle governance.
• Zero Standing Privilege: Zero Standing Privilege is an access model where elevated permissions are not permanently assigned. Privilege is granted only when needed, for a specific task, and then removed. For cloud and NHI governance, this reduces the time window in which stolen credentials or hijacked identities can be abused.
• Federation Trust: A federation trust is a relationship that allows one identity provider or signing authority to assert identity for another system. In cloud environments, mismanaged trusts can become a high-value attack path because attackers may abuse certificates, tokens, or configuration changes to impersonate legitimate access.
• Identity Blast Radius: Identity blast radius is the amount of access, control, and downstream reach a single identity can affect if it is compromised. It is a practical way to measure NHI risk because it focuses on what the identity can change, not just what it can view or log into.

Deepen your knowledge

Cloud privileged credential governance is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for service accounts, certificates, and federated trust, it is worth exploring.

This post draws on content published by Britive Team: Securing Privileged Cloud Credentials in the SolarWinds cyber attack. Read the original.