Not necessarily. Static roles can still work in stable environments with limited change and small user populations. The better test is whether the environment changes faster than the role catalogue can be maintained without over-permissioning or delays. Where cloud, Kubernetes and SaaS are moving quickly, on-demand permissions usually fit the operating model better.
When on-demand permissions make more sense than fixed roles
On-demand permissions are strongest when access needs are variable, high-impact, or short-lived. If a user or system only needs elevated access for a task, granting it just in time can reduce standing privilege, limit blast radius, and avoid the drift that builds up in large role catalogues. That is especially true when cloud platforms, Kubernetes, and SaaS change faster than humans can safely maintain role definitions.
The key decision is not whether roles are “old” and on-demand access is “new”. It is whether the environment is stable enough that pre-defined roles stay accurate without becoming broader than intended. In a slow-changing environment, roles can still be the cleanest control because they are easier to audit and easier to explain. In a fast-changing one, role sprawl and exception creep are often the real failure modes.
On-demand permissions also work better when the access request itself is part of the control. If the business can tolerate an approval step, a time limit, and a narrow scope, the access decision becomes more precise than a static role that must cover many possible situations. That is why practitioners often pair this model with Just-in-Time Access and Zero Standing Privilege Guide and with the Privileged Access Management Guide when the access is elevated or sensitive.
Where pre-defined roles still hold up
Pre-defined roles are still useful when duties are repetitive, the environment changes slowly, and the population is small enough that a well-maintained role model stays understandable. They provide consistency, make reviews easier, and reduce operational friction when the same access pattern is needed every day. In those conditions, the risk is usually not the existence of roles, but oversized roles that were never cleaned up after the original need changed.
Roles also remain practical when the control objective is baseline access, not exception handling. A stable job function with limited systems, limited data exposure, and predictable approvals may be better served by roles than by per-request elevation. The more the environment resembles a fixed operating model, the more roles retain their value. The more it resembles a dynamic platform, the more likely roles lag behind reality.
That is why access models should reflect the operating rhythm of the environment. A general-purpose role catalogue that tries to cover every edge case often becomes harder to govern than a narrower role set plus Authorisation Models Guide for finer-grained decisions. When the question is “who should have what by default”, roles are still useful. When the question is “should this action be allowed right now”, on-demand permissioning is usually the better fit.
How to decide without creating permission sprawl
The most reliable test is operational change rate versus maintenance capacity. If teams cannot keep the role catalogue aligned with reality, the model will either over-permission users or slow them down with constant exceptions. On-demand permissions reduce that tension, but only if the request, approval, and expiry mechanics are disciplined enough to stay consistent.
For cloud-heavy environments, the same judgement applies to effective permissions and privilege paths, not just the nominal role name. A role that looks modest on paper can still hide broad escalation paths, which is why teams often need Cloud PAM and CIEM Guide style analysis to see what access is actually available. If the real issue is privilege growth and not just role structure, the answer is usually to right-size access first and then decide where elevation is truly necessary.
For teams evaluating the model at scale, the practical decision is whether the access pattern is stable enough to codify or dynamic enough to orchestrate. A small, predictable team may do well with roles plus periodic review. A platform team operating across cloud, Kubernetes, and SaaS often needs a hybrid, default roles for everyday work and on-demand access for anything privileged, temporary, or environment-specific.
Risk and Threat Considerations
Access model mistakes usually show up as either excessive standing privilege or repeated exceptions that no one can review properly. Both create exposure, but the threat profile is different: broad roles increase blast radius, while brittle role catalogues encourage workarounds, shadow access, and uncontrolled elevation. OWASP Non-Human Identity Top 10 is useful here because the same patterns that affect machines and service access, secret leakage, overprivilege, and long-lived credentials, also describe what goes wrong when access is not tightly bounded.
Failure mechanism: Static roles lag behind a changing environment, so people accumulate excess permissions “just to keep work moving”, or they bypass the role model entirely with ad hoc grants that never get removed. In fast-moving cloud and SaaS environments, that creates persistent privilege, poor auditability, and a larger attack surface for account takeover or privilege abuse.
Impact: The result is not just cleaner or messier administration, it is materially different exposure. Over-permissioned access increases the damage from compromised accounts, while unmanaged exceptions make it harder to prove who could do what at any given time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Directly supports limiting access to only what each task needs. |
| IA-5 — Authenticator Management | Access on demand depends on controlled credential issuance, rotation and expiry. | |
| AC-2 — Account Management | Role and on-demand access both rely on provisioning, review and revocation discipline. | |
| Recommendation — Enforce least privilege and remove broad standing access where time-bound access will do. Manage credentials so temporary access expires and long-lived secrets do not accumulate. Review and revoke accounts and entitlements on a defined lifecycle, not ad hoc. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question is fundamentally about choosing access control patterns that fit operating change. |
| GV.RM-01 — Risk Management Strategy | Choosing roles versus on-demand access is a governance decision about acceptable privilege risk. | |
| Recommendation — Align access control design to task need and operational cadence. Set a risk-based rule for when standing roles are acceptable versus when elevation is required. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | CIS access control guidance maps directly to deciding between role-based and just-in-time access. |
| CIS-5 — Account Management | The access model depends on disciplined account provisioning, review and deprovisioning. | |
| Recommendation — Maintain and right-size access so permissions match current business need. Track account lifecycle tightly enough to remove unused or excessive access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is an access control design choice within an ISMS. |
| Recommendation — Define access rules that fit operational change without creating excess privilege. | ||
Practitioner Guidance
What to prioritise: Start by classifying which access patterns are stable, which are exception-driven, and which are genuinely ephemeral. Stable baseline work can stay role-based; privileged, time-bound, or environment-specific actions are the best candidates for on-demand permissioning.
What to verify: Check whether every elevated access path has an expiry, an owner, and an auditable reason. If the model cannot answer “why was this access granted, for how long, and for which task”, it is too loose for high-risk use.
Common mistake: Teams often try to replace every role with just-in-time access. That usually trades one form of sprawl for another, because the control then depends on approvals being fast, consistent, and actually reviewed.
Practitioner takeaway: Use roles where the work is stable and on-demand permissions where the access need is temporary or fast-changing, but do not let either model become a hidden excuse for broad standing privilege.
Related resources from NHI Mgmt Group
- How should security teams use IAST and RASP in NHI governance?
- How can security teams decide when to use provisioned capacity instead of on-demand AI access?
- How should security teams govern effective permissions instead of just assigned roles?
- How should security teams prioritise NHI remediation in cloud environments?