Types of Physical Access Control: Credentials, System Architectures, and Policy Models

A physical access control system (PACS) combines readers, controllers, credentials, and software to govern who enters a facility and when. Three choices shape every deployment: how identity is presented at the door (credentials), where the system lives (architecture), and how decisions are made (policy).

This article covers the credential types most commonly used at the door, four deployment architectures, the placement of access decisions inside those architectures, and the four policy models applied to physical entry.

Four Deployment Architectures

PACS deployments are commonly described in terms of four architectural patterns: standalone, on-premises networked, cloud-managed, and hybrid.

Standalone Systems

A standalone PACS controls access at a single facility or specific areas within it. Credential validation happens locally at the reader or controller with no network dependency. Every access decision is self-contained.

The operational advantage is resilience. A standalone system has no WAN dependency, no server to fail, and no connectivity requirement for door decisions. Common deployments include single-tenant offices, remote utility cabinets, equipment rooms, and storage areas where a small, stable population of credential holders makes manual updates practical.

The limitation is administration. An administrator may need to visit each door in person to change access rights. That constraint makes standalone systems difficult to scale beyond a handful of doors, particularly when organizations need to revoke a credential quickly. Audit trails are also local, which complicates investigations that span more than one door.

Networked On-Premises Systems

A networked PACS connects readers and controllers to a central on-premises server over a local area network. The architecture depends on fast communication among readers, controllers, panels, and head-end components, along with services for credential status and validation.

The critical design principle is distributed intelligence. Controllers download and cache the credential database and access rule set from the central server, then execute access decisions locally. The central server functions as the management point and audit repository rather than the real-time decision engine.

Because controllers cache credential and access rule data locally, they continue granting or denying access when the server goes offline. Policy updates, credential provisioning, and audit log aggregation require the server, but door-level decisions do not. Networked on-premises systems remain common in environments with strict data residency requirements, dedicated physical security networks, or limited tolerance for third-party hosting.

Cloud-Managed Systems

Cloud-managed PACS, often sold as Access Control as a Service (ACaaS), move the management plane to a third-party provider's infrastructure. Administrators manage permissions and review logs through a web interface from any location. The on-premises hardware remains at the facility, with firmware, software, and policy updates rolling out from the provider.

One architectural variable has a major effect on resilience. Cloud-managed systems with local controller caching behave like networked PACS during an internet outage: controllers retain cached credentials and continue operating. Thin-client configurations require continuous connectivity, and an outage in that model can create a single point of failure for physical access across connected doors.

For federal deployments covered by the GSA guidance, FedRAMP authorization and FIPS 201 alignment may be required.

Hybrid Architectures

Hybrid deployments combine on-premises controllers with cloud-based management, or integrate standalone and networked components across a multi-site campus. A common migration pattern keeps controller topology on-premises while moving the management plane to a cloud-hosted subscription service. Access decisions remain local, while centralized management, policy updates, and cross-site analytics occur in the cloud.

Multi-site organizations often adopt hybrid designs to preserve existing controller investments while unifying administration across geographies that previously ran as independent deployments.

How Controllers Place Access Decisions

Every PACS must make an access decision at the door. Where that decision happens determines the system's failure characteristics.

In a centralized architecture, access-control decisions are managed by central servers and controllers rather than by individual door readers. Policy changes and revocations take effect immediately. But a WAN outage between a remote site and the central controller can disrupt management and, depending on system design, may affect door operation or cause doors to revert to their configured fail-open or fail-secure states. Fail-open behavior preserves life safety and egress; fail-secure behavior preserves asset protection. The choice is set per door based on risk and code requirements.

In a distributed architecture, local controllers make decisions using a cached copy of the credential database. The trade-off is that revocations must propagate to every edge controller. Organizations must account for that propagation window in their security policy, particularly for terminated employee scenarios where same-day badge collection and physical escort procedures may be required.

Credential Types at the Door

Architecture determines where decisions happen. Credentials determine what each user presents to be evaluated. Six categories cover most deployments, and each carries distinct operational tradeoffs.

Physical cards and fobs (proximity, MIFARE, iCLASS) remain the default for general employee access. Costs are low, the technology is well understood, and replacement is straightforward. Legacy 125 kHz proximity formats are cloneable with inexpensive equipment, which matters for any door protecting more than a public lobby.

PIN entry requires no carry credential and works as a low-cost option for back doors, gates, and shared spaces. The weaknesses are shoulder surfing, code sharing, and the absence of an individual audit trail when one PIN serves a group.

Mobile credentials issued to a smartphone over Bluetooth Low Energy or NFC can be revoked instantly, carry no replacement cost, and avoid the logistics of issuing physical cards. Adoption requires compatible readers and a policy decision on personal device use, particularly where employees decline to install an employer-managed app.

Biometrics such as fingerprint, face, and iris provide higher assurance because the credential cannot be lent or lost. Templates must be stored, transmitted, and protected, which raises privacy and regulatory questions in jurisdictions with biometric-specific statutes.

Smart cards including PIV and CAC use cryptographic authentication rather than a static identifier. Federal facilities and other regulated environments rely on smart cards under FIPS 201 because the credential is validated against a trust chain rather than simply read.

Multi-factor combinations pair a card with a PIN, or a card with a biometric. The added friction at the reader is the point: the second factor closes the gap a lost card or stolen PIN would otherwise create. Multi-factor reads are usually reserved for higher-assurance doors such as data centers, evidence rooms, or executive areas.

Four Policy Models for Physical Access

Architecture determines where decisions happen, and credentials determine what is presented. Policy models determine how those decisions are made. The four models below originated in computer security literature but have been adopted across PACS administration to describe how badge access maps to doors and zones. They often appear layered within the same facility.

Discretionary Access Control

Under DAC, the owner of a space grants or revokes badge access at their discretion. A department head adds an employee's badge to the reader list for their office suite. A principal investigator grants lab access to a graduate student. A host employee sponsors a visitor's temporary badge at the lobby turnstile.

The operational risk is privilege accumulation. Badges retain access when the original granter forgets to remove them, departments do not coordinate revocations, or a sponsor leaves without closing out visitor badges. Former employees, contractors, or visitors may retain entry capability at specific doors long after the business reason ended. DAC works best for small populations and contained spaces where the granting owner has direct visibility into who still belongs.

Mandatory Access Control

MAC removes discretionary authority entirely. A central security authority sets badge access rules, and individual department heads or area managers cannot change them at the local door.

A classified facility applies MAC by tying badge access to centrally defined security classifications and clearance rules. A badge tied to a Secret clearance will not open a door into a Top Secret area, regardless of any local sponsor's preference. MAC is most common in government, defense, and other regulated environments where access to specific rooms or floors is governed by external authority rather than local management.

Role-Based Access Control

RBAC assigns badge permissions to job roles rather than to named individuals. At a corporate headquarters, an employee badge opens the lobby turnstile and general office floors; a Facilities badge adds mechanical rooms and the rooftop; an IT badge adds the server room and network closets on every floor; a Security badge adds the SOC, the loading dock, and after-hours access to the perimeter.

When an employee transfers from Facilities to IT, the badge does not need to be reprogrammed door by door. Removing the Facilities role drops the mechanical rooms and rooftop, and adding the IT role enables the server rooms. The administrative work happens once in the role definition, not at every reader. New hires inherit the correct doors on day one because their badge is assigned to a role that already exists.

The tradeoff is granularity. When one person needs access slightly outside their role, the cleanest fix is a new role rather than a one-off badge exception, which administrators often resist because it expands the role catalog. Role assignments capture this administrative logic in federal control language.

Attribute-Based Access Control

ABAC evaluates multiple attributes simultaneously against a policy rule before unlocking the door. The attributes describe the person presenting the badge, the door being approached, and the conditions surrounding the request.

Environment conditions include time of day, location, and current threat level. An engineer with a Building B location attribute can badge into an R&D lab during weekday business hours. Outside those hours, the same badge is denied at the same door even though the engineer's role has not changed. That condition-based enforcement is difficult to express in pure RBAC.

ABAC also addresses multi-condition scenarios. A contractor's badge opens a secure workspace only when role, project assignment, clearance level, and active sponsorship all satisfy the policy rule. If any attribute lapses, including a sponsorship that expired the previous day, the badge stops working at that door without any administrator touching the system. The administrative cost is higher, because attribute sources must be reliable, current, and integrated with the PACS policy engine.

Where Credentials, Architecture, and Policy Intersect

The three axes layer at the door. A perimeter entry may use a proximity card on a cloud-managed system with RBAC tied to broad employee roles. A secure lab in the same facility may require a smart card or biometric on a distributed controller, with ABAC checking role, sponsorship, time, and threat level before the lock releases. The same PACS can run all three patterns at once, with the strictest combination reserved for the few openings that protect the highest-value assets.

Frequently Asked Questions about Physical Access Control

How should teams test PACS behavior during an outage?

Teams should simulate server, network, and internet loss before rollout. The goal is to confirm whether controllers keep making local decisions, how long cached data remains usable, and which management functions pause until connectivity returns.

Which credential type fits a higher-risk space?

Higher-risk spaces usually pair a cryptographic credential such as a smart card or mobile credential with a second factor like a PIN or biometric. The combination resists cloning, raises the cost of a lost or shared credential, and produces a cleaner audit trail.

How often should access roles and attributes be reviewed?

Review cycles should match the risk of the protected area and the pace of personnel change. High-risk spaces usually need more frequent checks to catch stale permissions, expired sponsorships, and role changes before they create exposure.

‍