Topic starter
09/12/2025 3:00 pm
TL;DR: A cloud insider with standing admin access can move laterally, clone repositories, and exfiltrate data even when least privilege is in place, according to the Britive Team’s analysis of the Ubiquiti breach. Zero standing privilege changes the control objective from limiting entitlements to eliminating persistent access windows.
Editorial analysis by NHI Mgmt Group, based on content published by Britive: “Ubiquiti Security Breach: How Zero Standing Privileges Stop Rogue Developers”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 10 months ago 2 times by Abdelrahman
This topic was modified 6 days ago by NHI Mgmt Group
06/10/2026 9:25 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Zero standing privilege is the missing control in rogue developer risk