Notifications
Clear all
Topic starter
25/06/2026 12:23 am
TL;DR: Static, pre-defined roles in cloud and Kubernetes environments often create privilege sprawl, under-privilege delays, and heavy admin overhead, while context-aware on-demand permissions can generate short-lived least-privilege access from live signals, according to Apono. The core issue is that access models built for stable identities break down when permissions must be assembled and revoked at runtime.
NHIMG editorial — based on content published by Apono: Dynamic Roles, Real Security: Why On-Demand Permissions Beat Pre-Defined Policies
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams implement on-demand permissions in cloud environments?
A: Start by defining the smallest set of request-time signals that can justify elevation, such as ticket state, environment sensitivity, and on-call status.
Q: When do pre-defined roles become a governance risk instead of a convenience?
A: They become a risk when they are widened to avoid access delays and then left in place after the original use case changes.
Q: What breaks when access requests depend on manual role changes?
A: Speed and precision break at the same time.
Practitioner guidance
- Audit standing role bundles for convenience-driven excess Identify roles that include permissions beyond the stated task because they were widened to avoid repeated approvals.
- Define runtime signals for production access Require a documented set of request-time inputs such as ticket state, on-call status, resource sensitivity, and incident context before elevation is issued.
- Separate role governance from role creation Move security review toward policy guardrails, approval conditions, and expiration rules, rather than managing an ever-growing catalogue of predefined permission sets.
What's in the full article
Apono's full analysis covers the operational detail this post intentionally leaves for the source:
- Policy logic examples for generating resource-scoped roles across AWS, Azure, GCP, and Kubernetes
- Practical comparisons between pre-defined permission sets and context-aware role assembly
- Operational guidance on which external signals should gate access, such as tickets and on-call status
- Trade-offs around maintenance overhead, admin workload, and governance workflows
👉 Read Apono's analysis of on-demand permissions and privilege sprawl →
On-demand permissions for cloud access: is your role model keeping up?
Explore further
25/06/2026 9:17 am
Static role catalogues are a scaling assumption, not a governance model. They assume access patterns can be predicted well enough to pre-build permissions for every future task, team, and environment. That breaks down in cloud-native operations where the same identity may need different access depending on incident state, resource type, and workload context. The implication is that IAM teams should stop treating role catalogues as the centre of control and start treating them as one possible output of a policy engine.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Another finding from the same research shows that 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks.
A question worth separating out:
Q: Who should own dynamic access governance in cloud and Kubernetes?
A: Ownership should sit with identity and security governance, not with ad hoc administrators translating business requests into policy edits. The team responsible should define which signals can justify access, which tasks are eligible for automation, and which exceptions require human approval. That keeps operational speed inside a governed access model.
👉 Read our full editorial: On-demand permissions reduce privilege sprawl in cloud access
