Topic starter
30/09/2026 7:12 pm
TL;DR: P0 Security shows that AWS environments keep accumulating standing access through over-provisioned roles, dormant credentials, and unused policies that teams struggle to safely remove, even when they believe least privilege is in place. The governance gap is not visibility alone but the inability to prove what is safe to remove without breaking production.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “How to fix standing access in AWS”.
By the numbers:
- permissions haven’t been used in over 90 days, but still carry high-risk actions like data exfiltration or policy modification.
Key questions
Q: What breaks when unused AWS access is not identified and removed?
A: Unused access becomes latent attack surface.
Q: Why does standing AWS access create incident risk even when least privilege is the policy?
A: Least privilege fails when it is treated as a one-time approval rather than a living control.
Q: How do security teams know whether an AWS permission is actually safe to delete?
A: They need evidence of usage, dependency, and reachability before removal.
Practitioner guidance
- Audit standing AWS privileges by usage evidence Compare IAM roles, policies, and credentials against actual usage before deciding what to remove.
- Prioritise dormant privileges with high-risk actions Target permissions that have been unused for long periods but still allow policy modification, data access, or other high-impact operations.
- Map identity-to-resource paths before remediation Build a current graph of which identities can reach which resources and through what chain of permissions.
Bottom line: Standing AWS access persists because teams cannot confidently remove permissions once they are no longer needed.
What's in the full article
P0 Security's full video covers the operational detail this post intentionally leaves for the source:
- The live AWS access graph workflow for tracing who can reach a specific resource and through which permission chain
- The command generation and remediation steps used to strip unused privileges without disrupting production
- The walkthrough of how Access DNA and the Identity Graph surface overexposed or dormant access paths
- The practical sequence for moving from detection to safe least-privilege enforcement in AWS
👉 Read P0 Security's walkthrough on fixing standing AWS access in production →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/09/2026 7:12 pm
Standing AWS access is a lifecycle failure, not a visibility problem. The hard part is not finding that permissions exist, but proving when they are still justified and safely removable. AWS gives teams the primitives, but not the governance answerability needed to enforce least privilege without operational fear. That is why standing access persists even in mature environments: the access lifecycle is not being governed as a lifecycle.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should IAM and PAM teams work together on AWS standing access?
A: IAM teams should identify and right-size roles, while PAM teams should focus on high-risk actions and revocation discipline. The handoff matters because standing access often behaves like privileged access even when it sits inside ordinary cloud roles. Shared governance prevents cleanup from becoming a one-team blind spot.
👉 Read our full editorial: Standing AWS access creates the governance gap least privilege misses