Episode 75 — Choose Authorization Models for Physical, Logical, and Administrative Access Control
When you move past the idea of simply letting someone in and start thinking about what they can do once they are in, you arrive at authorization models. An authorization model is the underlying logic a system uses to decide whether an identity can perform an action on a resource, and it matters because different environments need different kinds of control. A door lock, a building badge reader, a file server, and an administrator console all answer the same basic question, yet they operate under very different constraints and risks. Physical access decisions often happen at the edge of a facility and must be fast, reliable, and safe under pressure. Logical access decisions happen in software and can be extremely fine-grained, but they must remain consistent and understandable as systems grow. Administrative access decisions are the most sensitive because they can change the system itself, and a single mistake can create long-term exposure. Choosing authorization models is therefore not a “pick your favorite” exercise; it is an architectural decision about how trust, accountability, and safety are enforced in different domains. By the end of this lesson, you should be able to explain why certain models fit doors and badges well, why others fit applications and data better, and why administrative authorization needs extra structure beyond ordinary user access.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
A strong way to begin is to separate the idea of an authorization mechanism from an authorization model, because beginners often mix them together. A mechanism might be a badge reader, a keypad, a gate, a file permission check, or a policy engine, and it is the thing that performs enforcement. A model is the rule system that determines what the mechanism should do, such as granting access based on roles, labels, ownership, or attributes. This distinction matters because you can have a modern mechanism enforcing a weak model, or a simple mechanism enforcing a well-chosen model. It also matters because the same model can appear in different forms, like being enforced at a door controller or inside an application. Architects choose models based on how decisions should be made and then select mechanisms that can enforce those decisions reliably. When you keep the model separate, you can evaluate tradeoffs more clearly, such as whether a model will be too complex to govern or too rigid to support real workflows. You also avoid the trap of believing that a system is secure because it has “access control,” when the real question is what kind of access control logic is being used and whether that logic matches the risk. This mental separation sets you up to compare physical, logical, and administrative access control without confusion.
Physical authorization is easiest to visualize because it often maps to places and boundaries, such as buildings, floors, labs, data centers, and secure rooms. The resources in physical access control are spaces, and the actions are usually simple, like enter, exit, or pass through a checkpoint. Because physical systems must respond quickly and predictably, the authorization model typically needs to be stable and easy to enforce even when networks are slow or partially unavailable. Many physical access designs lean toward role-like groupings, where membership in a group grants access to certain doors or zones, because this is easy to administer and easy to audit. However, physical access also involves safety and emergency requirements, such as allowing people to exit during a fire alarm, which means the model must account for conditions where authorization is overridden for life safety. A beginner misunderstanding is thinking physical access is “simpler” and therefore less important, but physical access is often the first layer that protects critical systems and sensitive assets. If the model is too permissive, an attacker can bypass many logical controls by gaining proximity to devices or by reaching restricted areas. The architectural challenge is choosing a model that supports operational needs while still minimizing access to sensitive zones.
A common physical access pattern is to use zones and clearance levels, which resembles role-based thinking even if the organization does not call it that explicitly. People are assigned to groups based on their job function, location, and duty requirements, and those groups map to zones they can access. This is effective because it reduces the number of door-by-door exceptions and allows administrators to reason about access at a higher level. Yet zones can become too broad if they are defined for convenience rather than risk, and broad zones lead to over-access that is hard to notice because physical movement does not always leave the same kind of detailed trace as digital access. Physical models must also account for special cases like visitors, contractors, and maintenance personnel, where access should be time-bounded and accompanied, but reality often pressures organizations into giving broad temporary badges. When choosing a physical authorization model, an architect looks for two qualities: it should be manageable for facilities and security teams, and it should support least privilege by limiting who can reach the most sensitive areas. You also want the model to align with monitoring, such as logs of door events, so investigations can reconstruct who accessed which zones and when. A physical model that is easy to grant but hard to review is an invitation for long-term drift.
Logical authorization covers the systems and data people interact with digitally, and it is where models become more varied because software can make much more nuanced decisions. Resources can include files, database records, services, and application features, while actions can include read, write, delete, approve, administer, and many more. Logical authorization models must deal with complexity and scale, because a modern environment may include thousands of resources and many types of identities, including services and automated processes. One model that appears frequently is Discretionary Access Control (D A C), which is based on the idea that the owner of a resource can decide who else gets access. This model is intuitive in personal computing because it matches how people think about owning files and sharing them. The limitation is that it can be hard to govern centrally, because access decisions spread across many resource owners with different judgments and habits. D A C can also lead to access sprawl when permissions are shared broadly and never cleaned up. When an architect chooses D A C-like behavior, it is usually in places where ownership is meaningful and where centralized governance can still enforce boundaries, such as restricting what owners can share externally or requiring reviews for sensitive resources. Understanding D A C helps you see why some systems drift into over-sharing if there is no governance around the owner’s discretion.
Another logical model that is often contrasted with D A C is Mandatory Access Control (M A C), where access decisions are enforced based on system-wide rules rather than user discretion. In M A C designs, resources and users may have labels, and the system enforces which labels can interact based on policy, regardless of what a user wants. This model is useful when confidentiality requirements are strict and must be enforced consistently, such as in environments where data classification drives access and where policy must not be bypassed by convenient sharing. The advantage of M A C is strong, predictable enforcement that aligns with high-assurance security goals. The cost is reduced flexibility, because M A C can be harder to fit to everyday collaboration and can require careful planning of labels and workflows. Beginners sometimes assume M A C is always better because it sounds stricter, but strictness that breaks workflows can cause shadow systems and unsafe workarounds. Architects choose M A C-like approaches when the risk requires it and when the organization can support the governance needed to keep labels accurate and processes workable. In practice, many environments use M A C concepts for certain high-risk data sets while using more flexible models for general business operations.
Role-Based Access Control (R B A C) is one of the most widely used logical authorization models because it fits how organizations think about job functions. In R B A C, you assign permissions to roles, and you assign users to roles, which makes it easier to manage access as people join, move, and leave. The strength of R B A C is that it supports governance and review because you can ask whether a role is appropriate for a person rather than reviewing thousands of individual permissions. It also supports consistency because two people in the same role should receive the same access, reducing one-off exceptions. The weakness is role explosion, where organizations create too many roles to match every nuance, or role bloating, where roles accumulate permissions over time. Both problems can break least privilege and make audits difficult because roles stop meaning what their names suggest. When architects choose R B A C, they focus on designing a role hierarchy that maps to stable job functions and on defining a process for role change control so roles remain clean. They also plan for temporary access needs, because temporary needs can otherwise lead to permanent role modifications. R B A C fits well for many logical systems, but it must be governed to remain a model rather than a tangle of exceptions.
Attribute-Based Access Control (A B A C) extends the idea of authorization beyond roles by using attributes about the user, the resource, the action, and the context. Instead of saying this role can access that system, an A B A C policy might evaluate conditions like department, clearance, resource sensitivity, time of day, or whether a device meets certain requirements. The benefit is flexibility and precision, because you can express nuanced rules that adapt as attributes change. The risk is complexity, because policies can become hard to understand and hard to debug, especially when many attributes are involved and when different systems interpret attributes differently. Beginners sometimes assume A B A C is too advanced to be practical, but it can be extremely useful when roles are too coarse and when access decisions need context. The architectural challenge is ensuring attribute quality, because A B A C decisions are only as good as the attributes they consume. If attributes are stale or inconsistent, the policy becomes unpredictable, leading to either unintended denials or unintended grants. Architects choose A B A C when they need fine-grained control and can invest in attribute governance, policy testing, and clear documentation so policies remain reviewable. A B A C often works best when combined with a stable role foundation, using roles for broad baselines and attributes for sensitive refinements.
Access Control List (A C L) is a concept that appears in many systems and is best understood as a way of representing permissions on a specific resource. An A C L typically lists which identities or groups can perform which actions on that resource. This representation can support different models, including D A C and R B A C, depending on how identities are granted and governed. A beginner mistake is to treat A C Ls as a model by themselves, when they are often a mechanism for implementing a model. A system can have A C Ls that are managed by resource owners, which leans toward D A C, or A C Ls that are managed centrally through roles and groups, which leans toward R B A C. The architectural concern is scale and manageability, because A C Ls can proliferate across millions of resources, and reviewing them individually is unrealistic. This is why A C L-heavy environments often rely on groups as a layer of indirection, so you manage group membership rather than editing every A C L. Even then, group sprawl can create the same governance challenges as role sprawl. Choosing to rely heavily on A C L representations is therefore a decision about how permissions will be expressed, reviewed, and kept consistent over time, not just about how a system stores access rules.
Now we can shift to administrative access control, which deserves special handling because administrative actions can change authorization itself. Administrative access includes the ability to create identities, assign roles, modify policies, change logging settings, and alter system configurations that affect security boundaries. A beginner misunderstanding is to treat administrators as simply “more trusted users,” but administrative authority is qualitatively different because it can reshape the system’s rules. That means authorization models for administrative access often incorporate stronger separation of duties, stronger approval workflows, and stronger audit requirements. In administrative contexts, it is common to design for tiered privileges, where different admin roles have different scopes rather than one global administrator role that can do everything. This is an application of least privilege at the highest stakes, because a single fully privileged account is a tempting target and a single mistake can have widespread impact. Administrative authorization models also need to handle emergency access, but emergency access must be carefully governed so it does not become a routine shortcut. Architects often design administrative controls to require explicit elevation for high-impact actions, ensuring that elevated privileges are time-bounded and that actions are strongly attributable. In short, administrative authorization models must anticipate abuse and error more aggressively than ordinary user authorization models because the impact is so much greater.
Choosing between these models across physical, logical, and administrative domains often comes down to matching the model to the nature of the resource and the governance capability of the organization. Physical access tends to favor simpler, more stable models because decisions must be fast and operationally robust, and because the action set is limited. Logical access can support more complex models because software can evaluate richer context, but complexity must be justified by risk and supported by good data and processes. Administrative access demands extra controls because it can change the system’s own enforcement, so models must emphasize containment, oversight, and auditability. A beginner pitfall is trying to apply the same model everywhere because it feels consistent, yet consistency that ignores context can create gaps. For example, a pure D A C approach that works for personal file sharing can become chaotic for enterprise data with compliance requirements. A pure M A C approach that works for high-classification data can become unworkable for fast-moving business collaboration if the organization is not ready for it. A pure R B A C approach can become brittle if roles cannot capture necessary nuance, while a pure A B A C approach can become unmanageable if attributes are unreliable. Architects choose intentionally and often combine models in layered ways, using each where its strengths match the domain’s needs.
Another essential consideration is how authorization models interact with auditing and investigations, because authorization is not only about prevention but also about accountability. If you cannot explain why access was granted, you will struggle to prove compliance and to understand incidents. R B A C tends to be more explainable because role membership is a clear story, while A B A C can become harder to explain if policies are complex and rely on many attributes and conditions. M A C can be explainable if labels and rules are well-defined, but it can also be confusing if users do not understand labeling. Physical models can be difficult to audit if badge access is broad and if logs are not reviewed, because a door event log does not always reveal what a person did once inside. Administrative authorization requires especially strong logging because administrative actions can hide traces by disabling logs or altering policies. When choosing models, architects consider how decisions will be recorded, how reviews will be performed, and how quickly anomalies can be detected. A model that is theoretically secure but practically unreviewable can drift quietly until it fails. For beginners, the key is to see auditability as part of model choice, not a separate task. A good model supports not only correct decisions today but also clear evidence and reasoning tomorrow.
You also need to consider lifecycle and change, because authorization models must survive joiners, movers, leavers, system upgrades, and organizational restructuring. R B A C aligns naturally with job role changes if role assignments are driven by authoritative processes, but it can also be disrupted by reorganizations that redefine roles. A B A C can adapt to changes if attributes are updated reliably, but it can also fail if attribute sources drift or if policies are not updated alongside organizational changes. D A C can create long-lived access sprawl when people share resources and then move on, leaving permissions behind. M A C requires careful governance of labels as data moves and is reclassified, which is a real operational burden that must be planned. Physical access models must handle badge deprovisioning promptly when people leave, or else physical access becomes a lingering vulnerability that undermines logical controls. Administrative models must handle privilege assignments and removals with precision, because orphan admin access is one of the most dangerous forms of drift. Architects evaluate models partly by asking how well they support change without creating hidden leftovers. The model that is easiest to keep aligned with lifecycle reality is often safer in practice than a stricter model that cannot be maintained properly.
As you gain confidence, a mature way to think about model selection is to start from the resource and the risk, then work backward to the simplest model that can enforce the needed boundaries with good governance. For physical access, that often means zone-based group membership with careful exceptions and time-bounded visitor access, because it is understandable and enforceable. For logical access, that might mean using R B A C for baseline permissions, complemented by A B A C conditions for sensitive resources where context matters, and using D A C only where ownership is meaningful and bounded by policy. For high-assurance environments, M A C concepts may be necessary for certain data classes, but you plan governance and workflow to avoid forcing unsafe bypasses. For administrative access, you often use scoped admin roles, strong separation of duties, explicit elevation for high-impact actions, and strict auditing, because administrative authority must be contained and reviewable. The point is not to build the most complex model; it is to build a model that can be understood, enforced, audited, and maintained. When a model is too complex, people stop trusting it and start working around it, which defeats the purpose. When a model is too simple for the risk, it leaves obvious pathways open. Architecture is choosing the middle path where safety and operability meet.
Choosing authorization models for physical, logical, and administrative access control is about matching decision logic to the environment’s resources, risks, and ability to govern change. Physical access tends to favor stable, zone-oriented models that support reliable enforcement and safety requirements, while still limiting who can reach the most sensitive spaces. Logical access supports richer models such as D A C, M A C, R B A C, and A B A C, and the right choice depends on whether you need owner discretion, system-wide mandatory rules, role-driven governance, or attribute-driven nuance. Administrative access requires extra containment because it can reshape the system’s controls, so models must emphasize scoped privileges, oversight, and strong auditing. Across all domains, the best model is one that remains explainable, reviewable, and maintainable as identities and systems change. When you can explain not only what each model is but why it fits a particular kind of access and how it affects governance and investigations, you are doing the kind of reasoning that architecture demands. The deeper lesson is that authorization models are the grammar of trust, and selecting the right grammar for each domain is how you keep access decisions both safe and sustainable.
