Zero standing privilege is the missing control in rogue developer risk

At a glance

What this is: This is a breach analysis of the Ubiquiti incident showing that standing developer access in cloud environments can enable repository cloning, lateral movement, and extortion.

Why it matters: It matters because IAM, PAM, and cloud security teams cannot rely on least privilege alone when persistent access remains available outside task boundaries.

Context

Rogue developer risk is a cloud governance problem, not just an insider-threat headline. When a user account keeps elevated access all the time, the organisation has already lost control of when that access exists, who can use it, and whether the access window matches the work being done.

The Ubiquiti case illustrates why zero standing privilege changes the control objective for developers and cloud workloads. Temporary access reduces the time available for misuse, while standing access leaves a constant path into repositories, cloud accounts, and data stores.

Key questions

Q: What breaks when developers keep standing cloud access?

A: Standing cloud access breaks the assumption that privileged use is tied to a specific task. It gives insiders a reusable path into data and control planes, so the organisation is exposed whenever the account is online. The result is a larger abuse window, weaker containment, and a slower response when misuse begins.

Q: What is the difference between least privilege and zero standing privilege?

A: Least privilege minimizes what an identity can do, while zero standing privilege also removes the access until it is actually needed. Least privilege can still leave dormant but active access paths in place. Zero standing privilege is stronger for NHI governance because it turns permissions into temporary, auditable events instead of permanent conditions.

Q: How should federal teams measure whether privileged access is actually controlled?

A: They should measure whether every privileged identity has a named owner, a clear purpose, session monitoring, and a revocation path that works during active use. If the team cannot explain an agent’s privileged action after the fact, control is incomplete.

Q: Should cloud teams treat developers and service accounts differently for access governance?

A: They should govern both through the same lifecycle lens, but not with the same access pattern. Developers may need interactive just-in-time access, while service accounts need tightly scoped machine credentials and clear ownership. In both cases, the key is to avoid always-on privilege that outlives the business need.

Technical breakdown

Standing developer access in cloud environments

Standing access means privileges remain available continuously rather than being issued for a specific task and then withdrawn. In cloud environments, that often appears as long-lived IAM roles, highly privileged user accounts, or service credentials that are rarely reviewed because they are assumed to be operationally necessary. The control problem is not only excessive permission scope. It is the fact that the account can be used at any time, including outside change windows, without a fresh access decision. That creates a wide abuse window for insiders and makes revocation the only effective containment once misuse begins.

Practical implication: inventory every developer and cloud admin account that still has always-on elevated access.

Why least privilege did not stop the damage

Least privilege reduces the number of actions an account can perform, but it does not change whether the account exists with reusable access in the first place. In the Ubiquiti breach, the issue was not a one-off overreach in a single workflow. It was a privileged account that could be used repeatedly to reach AWS and GitHub resources. That means the blast radius was constrained only after the user had already authenticated. For insiders, that distinction matters because the attack path begins with legitimate access, not credential theft.

Practical implication: treat least privilege as a scope control, not a substitute for task-scoped credential issuance.

Zero standing privilege as a governance control

Zero standing privilege shifts the question from what the identity can do to when the identity is allowed to do it. The model assumes access should be brokered only when needed and revoked when the task ends, which is why it is especially relevant for developers, applications, and cloud operators. In practice, ZSP aligns IAM with PAM by removing the default state of persistent privilege and forcing access to be time-bound. That changes the security posture from permanent exposure with review later to no reusable access until a controlled request is approved.

Practical implication: move high-risk cloud access from persistent entitlement to just-in-time issuance.

Threat narrative

Attacker objective: The objective was to extract company data and pressure Ubiquiti into paying an extortion demand while amplifying reputational damage.

1. Entry occurred through a privileged employee account with access to AWS and GitHub resources, giving the attacker legitimate starting access rather than a stolen credential path.
2. Escalation followed as the account was used to move across the cloud environment and clone data repositories, expanding reach beyond the original access context.
3. Impact came from data exposure, attempted extortion, and reputational harm, showing how standing access can turn an insider into a broad-damage event.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

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 cloud privilege is the real insider-risk multiplier: The Ubiquiti case shows that the decisive failure was not merely excessive permission scope but persistent access that remained usable without a fresh business need. That model leaves the organisation exposed 24/7, which is exactly why zero standing privilege should be treated as a governance baseline for cloud developers and operators. The practitioner conclusion is simple: if access never goes away, neither does the abuse window.

Least privilege is necessary but insufficient when access is reusable: Reducing what an account can do does not solve the core insider problem if the account still exists with always-on privilege. Ubiquiti’s loss shows that an account can be narrowly scoped and still be dangerous when it remains continuously available for misuse. The practitioner conclusion is to separate entitlement minimisation from access lifetime control.

Zero standing privilege reframes developer governance around issuance, not entitlement: The better control question is when a developer or workload should have access, not whether it should have a broad role forever. That is why ZSP aligns so closely with modern cloud PAM and just-in-time access patterns. The practitioner conclusion is to make time-bound access the default for high-risk cloud activity.

Operational visibility is the companion control to access removal: A standing account that is not actively monitored becomes a blind spot, especially in multi-cloud environments where activity can span AWS, GitHub, and other platforms. The article’s cloud breach pattern shows that environment-wide visibility and access expiry are inseparable. The practitioner conclusion is to govern cloud identity as a lifecycle problem, not a static permissions problem.

Zero standing privilege breaks the assumption that trusted users can be left alone between reviews: Access review processes were designed for accounts whose privileges persist long enough to be certified. That assumption fails when a developer account can be abused, copied, or repurposed before the next review cycle. The implication is that certification alone is too slow a control for standing cloud access, so practitioners must rethink how access is issued and removed.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
• Read next: Just-in-Time Access and Zero Standing Privilege Guide

What this signals

Zero standing privilege is a lifecycle control, not a narrower permission model: Once access becomes task-scoped, the governance target shifts from reducing entitlements to eliminating persistent access windows. That is the practical difference between a cloud account that can be reviewed later and one that cannot be misused outside a defined task window. For IAM and PAM teams, the control objective is issuance and expiry, not just role design.

The breach pattern also shows why cloud identity needs to be managed across human and non-human actors together. Developers, service identities, and application access all create the same governance risk when privileges persist without a reason to exist, so the lifecycle model has to be consistent across the estate. For practitioners, that means zero standing privilege should be part of the cloud access baseline, not a niche exception.

For practitioners

• Inventory standing privileged developer access Identify every human and non-human cloud identity with always-on elevated access across AWS, GitHub, and related operational systems, then rank them by blast radius.
• Convert privileged access to just-in-time issuance Replace open-ended admin access with temporary access that expires after the task, especially for developers who can reach code repositories and cloud control planes.
• Separate entitlement scope from access lifetime Keep least privilege as the permission design baseline, but add expiry and revocation controls so an account cannot be reused indefinitely once granted.
• Monitor cross-cloud privilege activity Correlate cloud and repository events so unusual cloning, movement between platforms, or reuse of privileged sessions is visible as one access pattern.

Key takeaways

• Ubiquiti shows that a privileged cloud account can enable repository cloning, lateral movement, and extortion even when the broader permission model is not obviously broken.
• The critical risk is persistent access, because always-on privilege gives insiders a reusable path that survives outside the task that justified it.
• Zero standing privilege changes the control objective from limiting what an account can do to removing the chance to do it outside a time-bound need.

Key terms

• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.

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.