Admin time authorization is still the baseline for enterprise access

At a glance

What this is: This is an analysis of admin time authorization, showing how pre-assigned roles, groups, and permissions establish baseline access and where static authorization falls short.

Why it matters: It matters because IAM teams still rely on admin time assignments for provisioning, certification, and separation of duties, but those controls must now coexist with runtime policy checks and stronger lifecycle governance.

👉 Read Cerbos's analysis of admin time authorization and runtime checks

Context

Admin time authorization is the practice of assigning access before a user acts, usually through roles, groups, or direct permissions configured by administrators. In identity programmes, that makes it a core governance mechanism for baseline access, not a substitute for contextual decision-making.

The gap is that static entitlements do not change with the moment of access. For IAM, IGA, and PAM teams, the question is not whether admin time authorization remains useful, but where it stops being sufficient for least privilege, separation of duties, and lifecycle control.

This topic sits squarely inside human IAM and lifecycle governance, with clear implications for provisioning, recertification, and access review design. For a broader lifecycle view, see the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide.

Key questions

Q: How should organisations combine admin time authorization with runtime policy?

A: Use admin time authorization for baseline roles and groups, then apply runtime policy for context-sensitive decisions such as device trust, location, and sensitive resources. That hybrid model keeps access understandable for auditors while preventing static roles from over-granting access in high-risk moments. It is the practical way to preserve governance without turning every exception into a new role.

Q: When does admin time authorization create more risk than it reduces?

A: It becomes risky when roles are used to encode exceptions, temporary access, or fine-grained conditions that should be evaluated at request time. At that point, role sprawl, stale entitlements, and privilege creep can outpace review and make the model harder to govern than a policy-driven alternative.

Q: What do security teams get wrong about static access assignments?

A: Teams often assume that a role assignment proves least privilege, when it really only proves that access was approved at a point in time. If the user’s job, risk posture, or project scope changes, the entitlement can remain valid long after it should have been removed.

Q: Who should own role reviews and entitlement cleanup?

A: IAM or IGA teams should own the control design, but managers and application owners should validate whether the entitlement still matches business need. That shared model is what makes access certification useful, because governance only works when technical ownership and business accountability both exist.

Technical breakdown

How admin time authorization implements RBAC

Admin time authorization is the pre-decision layer in which an administrator assigns roles or groups before any access request occurs. In role-based access control, the role carries permissions, and the application later checks membership rather than calculating entitlement from scratch. That makes the model simple to audit and efficient to evaluate, but it also means the access decision is only as current as the last administrative change. The model works best when job functions are stable and the resource boundary is clear, such as standard employee access or regulated approval flows. Practical implication: treat admin time authorization as baseline entitlement management, not as the final security decision for sensitive actions.

Practical implication: treat admin time authorization as baseline entitlement management, not as the final security decision for sensitive actions.

Why runtime authorization changes the decision surface

Runtime authorization evaluates access at the moment of request using live context, such as device state, location, resource attributes, and risk signals. That is a different control surface from admin time assignment because the policy can deny access even when the user already holds a role. This is the main reason hybrid models have emerged: the static layer gives structure, while the dynamic layer handles exceptions and sensitive conditions. In practice, runtime checks reduce the need to create special-purpose roles for every edge case. Practical implication: use runtime policy for high-risk, temporary, or context-sensitive access, especially where static roles would otherwise multiply.

Practical implication: use runtime policy for high-risk, temporary, or context-sensitive access, especially where static roles would otherwise multiply.

Role explosion, stale entitlements, and privilege creep

Static authorization becomes fragile when organisations try to encode too much nuance into roles. The result is role explosion, where dozens of narrowly defined roles appear to solve precision but actually make administration harder and reviews less reliable. Stale entitlements follow when job changes, temporary assignments, or exceptions are not removed on time. That is where privilege creep emerges, not as a theoretical flaw, but as an operational by-product of delayed governance. Admin time controls still matter, yet they need lifecycle discipline to stay aligned with the current business state. Practical implication: simplify role design, then use periodic access review to remove entitlements that no longer match the user’s current function.

Practical implication: simplify role design, then use periodic access review to remove entitlements that no longer match the user’s current function.

NHI Mgmt Group analysis

Admin time authorization remains the governance anchor for baseline access, but it is not a complete authorisation model. The article is right to distinguish pre-assigned entitlements from dynamic decision-making, because that split maps to a real operational boundary in IAM. Static roles give auditors a clear record of who was granted what, but they do not answer whether the access is still appropriate at the moment of use. For practitioners, the implication is that admin time authorization should define the floor, not the ceiling, of access control.

Role-based access control breaks down when organisations try to use roles as a substitute for policy. The article’s discussion of role explosion shows the real failure mode: static grouping starts encoding exceptions that should have been handled as conditions. That shifts complexity from policy logic into entitlement sprawl, which then weakens review quality and change control. For IAM teams, the practical conclusion is to keep roles coarse and let runtime policy carry the contextual burden.

Privilege creep is not just an access review problem. It is the predictable outcome of static authorisation without disciplined lifecycle governance. The article correctly links provisioning, movers, and leavers to admin-time assignments because access that is granted once but rarely reassessed will drift away from job reality. That matters across human IAM programmes, where certification campaigns often look complete on paper but miss stale access in practice. The implication is that lifecycle governance has to be built into entitlement administration, not bolted on afterward.

Least privilege at admin time is a design assumption, not a guarantee. Admin time authorization was designed for access that can be determined in advance from job function and organisational hierarchy. That assumption fails when access needs depend on live context, temporary risk, or narrowly scoped exceptions that are only knowable at request time. The implication is that practitioners must stop treating static assignment as proof of least privilege and reframe it as one input to a broader control model.

Hybrid authorisation is where modern enterprise access control is heading. The article’s comparison between admin time and runtime checks reflects the direction most identity programmes are already taking: static entitlements for governance, dynamic policy for contextual enforcement. That does not eliminate the value of roles, but it changes their job. IAM, IGA, and application teams should expect role design, access reviews, and policy engines to become more tightly coupled. The implication is that access architecture should be planned as a two-layer model, not a binary choice.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why static authorization without governance discipline leaves hidden access paths in place.
• For the lifecycle angle, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding need to be managed as one control plane.

What this signals

Admin-time roles will remain necessary, but they are increasingly just the starting point for access control. IAM programmes that stop at pre-assigned entitlements will keep inheriting stale access, so the operating model has to shift toward a layered design with runtime checks on top of the static baseline. The control question is no longer whether roles exist, but whether they are continuously validated against the business state.

With 97% of NHIs carrying excessive privileges, static thinking is already failing the machine-identity side of the house. That figure points to the same structural problem seen in human IAM: once access is granted in advance and rarely re-evaluated, entitlement drift becomes the norm. Teams should treat entitlement simplification and lifecycle review as a shared discipline across human, machine, and application access.

For practitioners

• Keep roles coarse and purpose-built Limit each role to a stable business function and avoid encoding exceptions, location rules, or time-based conditions into role names. That reduces role explosion and makes access review campaigns easier to interpret.
• Move contextual decisions into runtime policy Apply dynamic checks for sensitive access, temporary entitlements, and requests that depend on device posture, location, or resource attributes. Use the runtime layer where a static role would otherwise grant access too broadly.
• Tie joiner-mover-leaver events to entitlement removal Make role updates and deprovisioning part of the identity lifecycle, not a separate cleanup exercise. When a user changes job function or leaves, remove obsolete access immediately rather than waiting for the next certification round.
• Review for privilege creep on a fixed cadence Compare current assignments to actual job needs and remove roles that no longer match the person’s current function. Use access certification to validate the baseline, then use policy checks to handle exceptional requests.

Key takeaways

• Admin time authorization is the baseline entitlement model, but it cannot by itself enforce context-aware least privilege.
• Static role design becomes fragile when it turns into role explosion, stale access, and privilege creep.
• The practical answer is a hybrid model: coarse roles for governance and runtime policy for sensitive decisions.

Key terms

• Admin Time Authorization: Access is assigned in advance by an administrator rather than decided when a user makes a request. The model usually relies on roles or groups and works best when job functions are stable, entitlement changes are controlled, and the organisation can review those assignments regularly.
• Runtime Authorization: Access is decided at the moment of use based on live policy and context. It can consider attributes such as device posture, location, resource sensitivity, and risk signals, which makes it better suited to exceptional or high-risk access decisions than static role assignment alone.
• Privilege Creep: Privilege creep is the gradual accumulation of access that no longer matches a person’s current job or need. It usually appears when entitlements are granted once, then left in place through role changes, exceptions, or missed offboarding, creating avoidable exposure over time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or IAM programme maturity, it is worth exploring.

This post draws on content published by Cerbos: admin time authorization and runtime access control. Read the original.