What is admin-time / static authorization?

In large-scale software systems, controlling who can do what is a fundamental security requirement. Admin time authorization, sometimes written as admin-time authorization, is a key concept in access control models that deals with how permissions are assigned and managed.

In simple terms, admin time authorization involves defining users’ access ahead of time, typically by system administrators configuring roles, groups, or permissions for users before those users ever attempt an action.

This approach has long been used to maintain order and security, especially in regulated industries like fintech and healthcare where strict oversight is required. But how does admin time authorization work in practice, and how does it compare to its counterpart, run time authorization, where access decisions are made on the fly?

This article will explain what admin time authorization is, why it matters for software architects and developers, and how it contrasts with dynamic, run-time checks. We’ll also touch on real-world scenarios to illustrate the concept, and briefly discuss how newer solutions tie these models together for better security and compliance.

Understanding admin time authorization

At its core, admin time authorization refers to access permissions that are set up in advance by an administrator. These are typically static assignments of roles or privileges to users or groups during onboarding or configuration, rather than decisions made at the moment of access. In other words, an admin defines “who can access what” ahead of time based on the user’s identity, role, or group membership.

For example, an IT administrator might add a new employee to an HR system and assign them a “Sales Manager” role. That user will then automatically have all the permissions and data access associated with the Sales Manager role in that system​. This initial assignment happens as part of user provisioning, often during hiring or onboarding, and remains in effect until changed by another administrative action.

Key characteristics of admin time authorization include:

• Access is commonly granted via roles (or groups) that represent job functions or responsibility levels. A role defines a set of permissions, and users are assigned to roles by an admin. In our example, “Sales Manager” is a role pre-defined with certain capabilities. The admin time step is assigning that role to the user.
• The permissions are set in advance and do not automatically change unless an admin updates them. The system doesn’t typically factor in dynamic conditions in these permissions - it’s a coarse-grained entitlement given to the user. As a result, this method is considered coarse-grained and static, as it doesn’t usually involve fine-tuned per-resource rules or changing context.
• Because these authorizations are configured by administrators (often via an identity management or admin console), they provide a centralized way to control baseline access across the organization. This central control is valuable for consistency and compliance reporting.

Let’s take a look at how admin-time authorization works in practice. In a traditional enterprise setup, you might have an Identity and Access Management (IAM) or Identity Governance system where administrators maintain user accounts, roles, and group memberships. When a new hire joins, an admin decides what resources they should access based on their job role and assigns the appropriate roles/permissions. These assignments get stored, for example, in an Active Directory group, an IAM database, or a policy store. Later, when the user uses an application, the application checks the user’s roles to determine what they are allowed to do. Importantly, the decision logic at that moment is straightforward because it relies on the already-defined roles - the heavy lifting was done at “admin time”. The system simply says “User X wants to do Y; does User X have the role or group that grants Y?” If yes, access is allowed; if not, it’s denied.

Admin time authorization is essentially the approach behind Role-Based Access Control (RBAC). In RBAC, roles are defined with certain permissions, and users are mapped to roles by administrators. It’s a classic model used in most enterprises because it aligns well with organizational structures - e.g., only users in the “HR Manager” role can approve leave requests, only those in “Doctor” role can view patient records, etc. It’s intuitive and easy to audit, you can list who has which role and thereby infer who has access to what.

This static approach means that if a user’s situation changes (for instance, they move to a different department), an admin has to manually update their roles to change their access rights. Until that happens, the user retains whatever access was initially granted - which leads us to consider both the strengths and weaknesses of admin time authorization in practice.

Admin time authorization in enterprise and regulated industries

In enterprise environments, especially those in regulated sectors like financial services and healthcare, admin time authorization has significant real-world relevance. Organizations in these fields often rely on well-defined job roles and strict hierarchical access rules for compliance reasons.

Here’s why admin time authorization is important and how it shows up in such industries:

• Enterprises are keen on enforcing separation of duties (SoD), ensuring no single individual has excessive power without oversight. Admin time role assignment helps here. For example, in a bank, you might have one role for “Loan Officer” who can initiate a loan application and another role for “Loan Approver” who can approve or reject loans. By assigning employees to these roles at admin time, the bank ensures that an individual cannot self-assign both roles and single-handedly approve their own transactions. This static separation is often required by regulations and internal controls.
• Regulated industries must frequently demonstrate to auditors who had access to what data and when. An admin time model makes this straightforward since access rights are granted via roles or groups that are documented. For instance, a healthcare provider can show that only users with the “Physician” role can view medical records, and a list of all users who have that role is maintained. It’s easy to audit the assignments. The trade-off, however, is that if these assignments aren’t kept up-to-date, they could become a compliance risk - a point we’ll discuss later.
• Many enterprise Software-as-a-Service applications use admin time authorization to delegate control within customer organizations. Consider an enterprise SaaS offering where each customer company has an admin who assigns roles to that company’s users. For example, an “Account Admin” role vs “Regular User” role within the app. This delegated admin model is essentially an admin time authorization at the customer level - the customer’s IT admin pre-defines which of their employees can access which modules of the SaaS. This setup is critical for SaaS providers to satisfy enterprise buyers who want control over their own users’ access.

In these scenarios, admin time authorization provides a predictable and manageable structure. Companies often establish role-based access policies to meet standards like HIPAA in healthcare or PCI-DSS in finance, which mandate least-privilege access. By assigning only the necessary roles to each user, an organization can limit access broadly to what’s needed for someone’s job - and crucially, they can review those assignments periodically. Many large firms run periodic access certification campaigns, often via Identity Governance solutions such as SailPoint or Saviynt, where managers must attest that each report still needs the roles they have. This process is fundamentally about reviewing admin time authorizations to ensure they are still appropriate.

However, as useful as this model is, it’s not without limitations. Enterprises have found that solely relying on static role assignments can lead to stale entitlements and inflexibility, especially as businesses become more dynamic. Now, let’s compare admin time authorization with run-time authorization, which addresses some of these challenges by adding more context to access decisions.

Admin time vs. run-time authorization (static vs. dynamic)

It’s helpful to compare admin time authorization with run-time authorization to fully grasp the concept. While admin time refers to permissions configured in advance, run-time authorization, also known as dynamic authorization, refers to access decisions made at the moment a user attempts an action, using real-time information and policies. The two approaches are complementary - many modern systems use a mix of both. Here’s a concise comparison:

Both models have their place. For example, you might predefine that only users with the “Manager” role can approve expenses (admin time policy), but at run-time you might add that they can only approve expenses under $5,000 or only for their own department - conditions evaluated when an approval action is attempted.

In fact, modern policy-based access control (PBAC) systems often combine admin time and run-time approaches: administrators define roles and high-level policies and developers set up dynamic checks for contextual attributes​. This combination yields a powerful engine that can enforce broad rules via roles, and fine-grained exceptions or conditions (via attributes), together.

Benefits of admin time authorization

Despite the rise of dynamic authorization, admin time authorization remains foundational for several reasons.

Admin time rules are usually easy to understand. If Alice has the “HR Manager” role, she can access the HR system’s manager features. Period. This clarity is useful for communication between IT and business teams - you can discuss access in terms of roles and everyone understands the implications.

Enterprises often have well-defined organizational structures that map nicely to role-based access. It’s straightforward to create roles like Manager, Engineer, Nurse, Patient, Customer, etc., and know roughly what each role should be allowed to do. This predictability helps in designing systems and onboarding new users quickly by just assigning them the standard roles for their job.

Checking a user’s static role at runtime is typically a fast, simple operation (often just a lookup or a list membership check), which has minimal overhead on the application. The complex logic and thinking have been done at admin time. This can be important for performance-sensitive scenarios. It also decouples the application logic from too many conditional checks - the app can assume if a user has role X, then they are allowed to proceed with certain actions, without scattering elaborate conditionals in code.

Because access rights under admin time authorization change only when an admin explicitly makes a change, it’s easier to keep an audit trail of who granted what to whom. Many compliance regimes require demonstrating control over access provisioning. Admin time systems excel here - you can often export a report of all current user-role assignments and when they were last reviewed. This is harder with purely dynamic systems, where access is granted on the fly and might not be explicitly recorded as an assignment.

Access is often linked with the HR lifecycle, with regard to joiners, movers, leavers (JML). Admin time authorization ties in neatly: on hire, grant roles; on role change, update roles; on termination, remove all roles and thus access. This synchronization ensures that when someone leaves the company or changes positions, their access can be adjusted in one go by updating their role assignments.

For these reasons, admin time authorization is not going away. It provides a baseline of security and delegation of control that is understandable and manageable. Especially in large enterprises, you might have thousands of roles and groups defined to cover all business scenarios - a testament to how central admin time authorization is in practice. Tools like Identity Governance and Administration (IGA) software are dedicated to managing this process, allowing organizations to approve and recertify those role assignments regularly to maintain least privilege.

Limitations of admin time authorization, and why we need more

While admin time authorization is effective, it has notable limitations in fast-paced, cloud-based environments.

One big issue is that access rights defined at admin time can become outdated as things change​. Imagine a user who was onboarded with certain roles, but months or years later their job responsibilities shift - unless there’s a robust review process, they might accumulate privileges they no longer need, a phenomenon known as privilege creep. This can lead to unintended exposure of sensitive data, violating the principle of least privilege.

Admin time rules are generally one-size-fits-all for a role. But real-world access decisions often should consider context. For instance, say all doctors in a hospital have access to patient records (role = Doctor). With only admin time control, a doctor can access any patient’s record any time. But maybe the hospital wants to allow doctors to see records only of patients under their care, or only during their shift hours. Such nuances are context-dependent and can’t be encoded purely by static roles - every doctor has the “Doctor” role regardless of current context. Without run-time checks, you can’t easily enforce those finer rules, potentially leading to over-broad access if relying purely on roles.

To try to handle more fine-grained needs with static roles, organizations often create many specialized roles (e.g., “Doctor-OnDuty”, “Doctor-OffDuty”, “Doctor-Cardiology”, “Doctor-EmergencyDept” etc.). This leads to a role explosion problem where the number of roles becomes unmanageable. The admin time model starts to break down in complexity because keeping track of which user should have which combination of 15 different roles becomes a nightmare and each role needs to be added to the application logic to implement it. It’s also error-prone - the more roles and groups, the higher chance someone gets mis-assigned or a role’s definition becomes outdated.

Modern applications often need to integrate new kinds of access rules quickly. For example, a fintech app might roll out a feature that allows external auditors read-only access for a limited time. If your system is purely admin time, you’d need to create new roles or hard-code exceptions for this scenario. In contrast, a dynamic approach could allow an on-the-fly policy like “grant auditor X access to records Y for the next 7 days.” Pure admin time systems aren’t built for such temporary or highly specific permissions - they usually require an admin to step in, create a role or group, assign it, then remember to remove it later. This process can be slow and cumbersome.

Static assignments can’t react to live risk signals. For instance, if a user’s account is behaving suspiciously, maybe their credentials were stolen and they are accessing data at 2 AM from abroad, a run-time policy might catch that and block access due to anomalous context. Admin time roles by themselves won’t account for that - if the user had access, the system will continue to grant it until an admin manually intervenes, or an anomaly detection system triggers an account disable. In essence, admin time authorization alone has no feedback loop for changing risk context.

These limitations are driving organizations to augment their access control with more dynamic, context-aware solutions. Instead of users having broad standing access just in case (the result of static roles), the trend is toward giving just-in-time access based on current need and context, thereby reducing constant exposure. This doesn’t mean admin time authorization is obsolete - far from it. It means that to enforce the principle of least privilege and Zero Trust security models, companies are layering runtime checks on top of the solid foundation that admin time roles provide. Next, we’ll look at what run-time authorization entails and how combining it with admin time can yield a robust access control strategy.

The rise of run-time (dynamic) authorization

Illustration of a run-time authorization flow. When a user attempts to access a resource, the application’s Policy Enforcement Point (PEP) checks with an external Policy Decision Point (PDP) to ask, “Is this action allowed right now?” The PDP evaluates the request against current policies and context (e.g. the user’s role, attributes of the resource, time of day, location, etc.) and returns a Permit or Deny decision. The PEP then enforces that decision, allowing or blocking the action​. This decision happens in real time for each access request, enabling dynamic checks beyond what was configured at admin time.

Run-time authorization is all about making authorization decisions on the fly, considering real-time information. Instead of relying solely on a user’s pre-assigned role, the system evaluates policies and attributes at the moment of access. A policy might say, for example, “Only a manager can delete a record, and even then, only if the record’s ownerId matches the manager’s department ID, or if the manager has a higher clearance level.” When a user tries to delete a record, the system will check: does this user have the manager role (admin time check) and do the dynamic conditions hold true (run-time check)? If yes, allow; if not, deny.

Run-time authorization is often implemented via Attribute-Based Access Control (ABAC) or similar models like Policy-Based Access Control (PBAC). In ABAC, you define rules based on attributes of the principal (user), resource (object), action, and environment. For instance, consider a healthcare scenario:

• Principal attributes: role = Doctor, specialty = Cardiology, department = Pediatrics
• Resource attributes: resource type = Patient Record, patient’s department = Pediatrics
• Environment attributes: time = 14:30, location = Hospital network, clearance = normal

A dynamic policy could be: “Permit access to patient record if principal.roles includes Doctor AND principal.attr.department == resource.attr.department” In this case, a pediatric department doctor can see pediatric patient records, but not cardiology patients if they’re not in that department. This check happens at run-time by comparing the user’s department attribute with the record’s department attribute. If the user moves departments, as long as the attributes are updated, the policy automatically adapts – no admin needed to toggle roles in that specific instance. Thus, run-time authorization complements admin time authorization by injecting current context. In the above, being a Doctor is likely a role from admin time, but matching departments is a dynamic condition at run-time.

Benefits of run-time authorization in modern systems include:

• You can enforce very specific conditions. For example, “user must have MFA enabled and be on corporate device to download data classified as sensitive”. This is crucial in high-security and regulated environments where just being in the right role isn’t enough - you also need situational safeguards.
• Access can adapt immediately to changes. If a user’s attribute changes, say their clearance level drops, or they switch teams, or their session risk score spikes, a dynamic system can start denying requests that were allowed just minutes before, reflecting the new reality. There’s no need to wait for an admin to intervene; the policies react to attribute changes or contextual input.
• Instead of giving users broad access “just in case” they need it, run-time authorization encourages a “prove you need it now” approach, or the principle of Least Privilege. For example, a developer might not have access to production servers by default, unlike old models where being in the IT group might give standing access. But if they need to fix an emergency issue, a dynamic policy could allow them to request access which is granted if certain conditions are met (e.g., ticket ID provided, within business hours, approval obtained) and automatically revoke it after a short window. This ephemeral access reduces standing privileges dramatically, aligning with Zero Standing Privilege (ZSP) principles​ - employees get access only when needed, only for as long as needed.

Of course, implementing run-time authorization requires robust architecture. As depicted in the diagram above, many systems use a Policy Decision Point (PDP), a service running along the application, and the application as a Policy Enforcement Point (PEP) which delegates the decision to the PDP. For example, Cerbos PDP serves as PDPs that evaluate policies in real time. The application (PEP) asks “Can user X do action Y on resource Z?” and the PDP replies yes/no based on policies that may include both admin time aspects (like roles) and dynamic context. This pattern ensures decisions are consistent and centrally managed through a Policy Administration Point (PAP) like Cerbos Hub, even though they happen during each access attempt.

For developers and architects, the rise of run-time authorization means designing systems that are policy-driven rather than purely role-driven. Instead of baking all access rules into code or assuming roles alone suffice, one defines policies that the authorization engine uses. This approach, often called policy-as-code, allows security teams to update access rules without modifying application code – a big plus in agile environments. An admin or policy author can tweak a policy (say, require MFA for a certain action) and it takes effect immediately on all new access requests, without redeploying the app. This agility is highly valuable in enterprises where security requirements change due to new regulations or emerging threats.

However, it’s worth noting that run-time and admin time are not either/or choices. They work best in tandem. Let’s explore how a combination of both can be achieved, and how organizations today blend these models.

Combining admin time and run-time authorization for best results

In practice, the strongest access control implementations use a hybrid approach: admin time authorization sets the stage with broad entitlements, and run-time authorization refines and verifies access with context. Rather than replacing one with the other, organizations layer them to leverage the advantages of each. Here’s how they complement each other.

Think of admin time roles as giving a baseline eligibility to do something, and run-time policies as the conditions under which that eligibility actually translates into allowed access. For example, an employee might be given a role “Trader” in a stock trading system (admin time assignment, meaning they are generally allowed to execute trades). But the run-time policies might say “If the trade value is above $1M, then require approval” or “Only allow trading on weekdays between 9am-5pm.” So the role is necessary but not always sufficient; the dynamic rules impose additional controls when needed. This way, you don’t have to create separate roles like “TraderAbove1M” - you handle it with a policy.

Admin time is great for everyday access provisioning - it’s straightforward for an IT team or automated onboarding workflow to assign roles. Run-time is great for making decisions about sensitive or exceptional situations that you can’t just codify with static roles. By combining them, you let the admin time system handle the routine access, making sure everyone has what they basically need to do their job, and let run-time system handle the edge cases and high-risk decisions in real time.

Using both approaches can actually improve compliance. Admin time roles provide a clear structure and are easy to audit, as we have discussed, while run-time policies provide real-time enforcement of security policies that might be required by regulations. For instance, a regulation might say “customer data should only be accessed from approved locations.” You could enforce that by a run-time geo-location check. If an auditor asks “How do you ensure rule X?”, you can show them the dynamic policy in the PDP as well as logs of it being enforced. Meanwhile, the admin time layer ensures only certain job roles even have the ability to initiate those data access requests in the first place. This multi-layer approach aligns with Zero Trust Architecture principles - never trust, always verify, even if the user is an “insider” with a role.

Managing a combination of static roles and dynamic policies might sound complex, but modern authorization platforms, such as Cerbos, are emerging to make it easier. These systems often allow defining policies that include role checks (role being an attribute of the user) alongside other conditions. For example, you could write a policy that says: permit action if role = “Manager” and record.ownerId = user.id. Here “role = Manager” is basically an admin time piece of information, and the second part is a dynamic check. Tools can then let admins or security engineers update these policies without having to create or manage dozens of separate roles for each rule.

Conclusion

Admin time authorization is a fundamental concept in access control, centered on assigning roles and groups to users ahead of time by an administrator. It provides the backbone of security in many enterprise systems, offering clarity, consistency, and ease of audit. Especially in industries like finance and healthcare, where knowing exactly who has access to what is critical, admin time authorization, through mechanisms like RBAC, has proven indispensable. However, as businesses face more dynamic scenarios and sophisticated security requirements, admin time controls alone are often not enough. This is where run-time authorization comes into play, adding a layer of context-aware, real-time decision making that ensures access is appropriate in the moment and adheres to the principle of least privilege.

In modern large-scale software systems, the trend is to blend static and dynamic approaches. By doing so, organizations can enjoy the best of both worlds: the governance and simplicity of predefined roles, and the security and flexibility of on-the-fly policy enforcement. For developers and architects, this means designing systems with both an identity governance component, to handle roles/entitlements, and a robust policy engine, to handle contextual rules. With the availability of advanced, developer-friendly, and operator-friendly authorization solutions, implementing this hybrid model is becoming more straightforward. These tools help offload the complexity of evaluating who can do what, when, and under what conditions - so your application logic can remain clean while your security remains rock-solid.

In summary, admin time authorization is about setting the stage for access control, and runtime authorization is about making the moment-to-moment judgments. Understanding both is crucial for anyone building or securing today’s applications. By leveraging admin time authorization for broad strokes and run-time authorization for finer details, enterprises can meet compliance requirements and security goals without sacrificing agility. As you design your next system or review your current access controls, consider where you might tighten things with dynamic policies or simplify with well-chosen roles. The combination of the two might just be the key to a safer and more manageable authorization model for your organization’s needs.

If you’re interested in implementing admin time and run-time authorization - try out Cerbos Hub or book a call with a Cerbos engineer to see how our solution can help streamline access control and secure your applications.