Access Control Systems for Secure Building Entry

A card reader is only one visible part of a physical access control system. The system has to accept a credential, interpret the request, determine whether entry is permitted, operate the controlled opening, observe what happens at the door, and make relevant status or event information available for administration and review.

That end-to-end view prevents a common mistake: treating access control as a collection of badges and readers. Implementations may combine functions in one device or distribute them across controllers, servers, networked peripherals, and management software, but the task remains the same: turn an entry request into a controlled physical outcome.

What a Physical Access Control System Controls

A physical access control system regulates passage into a protected area through an access point such as a controlled door. NIST describes physical access control in terms of authentication and authorization: the system needs enough confidence in the presented identity or authenticator to process the request, and it then needs to determine whether that person or credential is permitted to enter the protected area.

The protected object is therefore not a software account. It is a physical passage. The system may use digital identities, networked devices, databases, and software services, but its final enforcement point is a real opening that remains secured, releases for entry, or reports a condition.

This distinction also explains why access control should be understood as a system rather than a reader feature. The reader captures input; a controller, access-control unit, or other decision point evaluates or obtains the authorization result; locking hardware enforces the physical result; and door-side inputs report conditions that the credential alone cannot describe.

The Components Behind a Controlled Door

The exact products and topology vary, but several functions appear repeatedly in physical access control systems.

Credentials and Cardholders

A credential is the evidence or data presented as part of an access request. It can take different physical or digital forms, and the detailed security properties of those technologies are a separate design topic. For the foundation model, the important point is that the system receives credential information associated with a credential holder and uses that information as part of the entry decision.

The term cardholder is common in systems built around cards, but credential holder is more technology-neutral. Neither term means that possession of a credential automatically grants entry. The credential identifies or helps authenticate the requester; authorization is a separate question.

Readers

A reader is the device or peripheral that accepts or captures credential input at the access point. Depending on the technology, that may mean reading data from a physical credential, receiving a digital identifier, or capturing another supported authentication input.

A reader does not necessarily own the authorization logic. Some devices combine multiple functions, but many architectures pass credential information onward to a controller, access-control unit, or other decision point.

Controllers and Access-Control Units

A controller or access-control unit coordinates access-control processing and door-side I/O. In a common architecture, it receives information from the reader, evaluates or obtains the relevant authorization result, and then commands the controlled opening when access is granted.

NIST's documented PACS example shows controllers reading badge information, checking authorization, and unlocking a door when access is allowed. ONVIF access-control specifications also model systems in which authorization may be handled locally or through an external decision process. These are useful examples of the same principle: the controller participates in turning credential input into a physical door action, while the exact location of the decision depends on the implementation.

Locking Hardware

Locking hardware is the physical enforcement layer. It secures or releases the controlled opening according to the system's command and the mechanical/electrical design of the door.

Access-control logic and locking hardware solve different parts of the problem. The controller can issue a grant decision, but the physical result depends on the installed locking arrangement. Likewise, the state of a lock is not automatically the same thing as the state of the door itself.

Door Position and Request-to-Exit Inputs

A door position input can report whether the opening is physically open or closed. Some systems may also monitor lock state separately, so "door closed" should not be treated as universal proof that the lock is secured.

A request-to-exit, or REX, device/input is associated with a person leaving through the controlled opening. It can tell the access-control system that exit is being requested or initiated. What happens next depends on the hardware, system logic, and any applicable egress or life-safety requirements; REX should not be presented as one universal wiring or release method.

How an Access Decision Becomes a Door Action

Consider an authorized person presenting a credential at a controlled door. A useful conceptual transaction looks like this:

1. Credential presentation: the credential holder presents supported credential information to the reader.
2. Reader input: the reader captures the relevant identifier or authentication data and passes it into the access-control process.
3. Decision processing: a controller, access-control unit, or other configured decision point receives the request.
4. Authentication or validation where applicable: the system establishes the required confidence in the presented identity, authenticator, or credential information.
5. Authorization check: the system evaluates whether that identified or authenticated requester is permitted through that access point under the applicable configured conditions.
6. Grant or deny: the access request produces a decision.
7. Door action: if granted, the applicable controller or access-control component commands the locking hardware according to the system design. If denied, the access request itself does not produce an unlock command; the actual door state still depends on the locking, egress, and other active system conditions.
8. Door state: door position and other available inputs can show what happens after the decision.
9. Event reporting: the system may record or report the access decision, door state, or other supported conditions to management software.

This sequence is a system model, not a fixed wiring diagram. A standalone device may combine reader, controller, and decision functions; a distributed system may keep authorization data at local controllers; another architecture may obtain authorization from a central or external service. The constant is the relationship between input, decision, physical action, state, and event visibility.

Authentication and Authorization Are Different Questions

Authentication and authorization answer different questions in a physical access-control transaction.

Authentication establishes confidence in the identity, authenticator, or presented authentication information. In a physical access system, that can include validating the credential or other supported identity evidence.

Authorization decides whether the requester is permitted to perform the requested action. At a controlled door, the action is entry through that access point under the conditions the system is configured to evaluate.

A valid credential therefore does not necessarily mean the door should unlock. The credential can be recognized while authorization is not granted for that opening or for the applicable conditions. The detailed design of access levels, door groups, cardholder groups, schedules, and permission structures belongs to access-control administration and is outside this foundation article.

Where the Decision Happens Depends on the Architecture

Physical access control does not require one universal decision topology. The authorization data and decision logic may be located at a local controller, synchronized from a management system, provided by another PACS service, or handled through an external authorization process supported by the implementation.

That distinction matters operationally. A system designed to make decisions locally may continue handling some access requests without continuous communication to a central server, while an architecture that depends on an external decision service has different dependencies. Neither behavior should be assumed from the words "networked access control" alone.

Decision placement also determines system dependencies. Some controllers may store the information needed for local decisions; other designs may rely more heavily on central services. The architecture determines what can continue during server, network, or service interruptions.

Door Status, Request-to-Exit, and Access Events

The credential transaction tells the system that an access request occurred. Door-side inputs tell it what happened at the physical opening.

Door position monitoring can report an open or closed state. REX can indicate that an exit request or exit-related action occurred. Depending on the implementation, additional events may represent granted access, denied access, door conditions, device conditions, or configuration/status changes.

These signals create operational context, but they are not universal audit fields. ONVIF profiles and its access-control service define access-control event capabilities for conformant systems, while actual products and deployments may expose different event sets, data fields, and retention behavior.

Some environments can also correlate access events with video for investigation or operational context. That does not make video part of the access-decision chain itself; the video path remains a separate system. Insitect's Video Surveillance Systems and How They Work explains that architecture separately.

There is also no universal retention period that follows from the fact that a system is an access-control system. Retention depends on implementation, organizational policy, operational needs, and applicable legal requirements.

Management Software Coordinates the System

Management software provides an administrative and operational layer over the access-control system. Depending on the implementation, it can administer credential holders and credentials, configure or distribute authorization rules and conditions, and present access points, device status, events, and records for review. Exact functions and data models vary.

Its role should not be confused with the real-time decision point. A management server may configure or distribute authorization information without participating in every door transaction. In another design, central or external services may take a more direct role in authorization. The system architecture determines that relationship.

The practical design of access levels, door groups, cardholder groups, schedules, and permission models is deliberately separate from this foundation. Here, those concepts matter only because configured authorization conditions are inputs to the access decision.

Networked Access Control and Interoperability

Networked access-control systems can include IP-connected controllers, software services, management clients, and networked peripherals. Connectivity allows components to exchange configuration, credential-related information, status, events, and commands according to the system's architecture.

Standardized interfaces can help different components communicate, but interoperability depends on the specific functions and supported profiles involved. ONVIF Profile D addresses access-control peripherals, while Profiles A and C cover access-control configuration and door/event functions for conformant devices and clients. Support for one profile or feature should not be interpreted as universal cross-vendor feature parity.

At the reader/controller boundary, SIA's Open Supervised Device Protocol (OSDP) is one standardized communications approach used between control panels and peripherals such as readers. SIA describes bidirectional communication, device supervision, and Secure Channel support as part of the OSDP standard family. That makes OSDP relevant to interoperability and security discussions, but it is not the only possible reader interface and does not define the entire PACS architecture.

Fail-Safe, Fail-Secure, and the Life-Safety Boundary

The terms fail-safe and fail-secure describe power-loss behavior of locking arrangements at a high level. UL explains fail-safe behavior as releasing on loss of power and fail-secure behavior as maintaining the locked position on loss of power.

Those labels do not answer the larger life-safety question by themselves. A locking arrangement can include additional hardware, release logic, fire-alarm interaction, mechanical egress functions, and code-driven requirements. The appropriate arrangement depends on the opening, the occupancy/application, the applicable codes and standards, and the authority having jurisdiction.

Egress requirements can therefore constrain the security behavior of a controlled opening. For example, in U.S. workplaces covered by OSHA 29 CFR 1910.36, exit-route doors must be openable from the inside without keys, tools, or special knowledge, and a device or alarm failure must not prevent emergency use of the exit route. That is a U.S. workplace requirement, not a universal global rule or a complete access-control design procedure.

The foundation principle is narrower: access-control security objectives do not replace life-safety and egress requirements, and "fail-safe" or "fail-secure" should not be used as shorthand for code compliance.

Cybersecurity and Privacy Are Part of the System Context

When access-control devices and management systems communicate over networks, they become part of the organization's computing environment. That introduces cybersecurity concerns around device configuration, protection of stored or transmitted data, logical access to interfaces, authorized software updates, and visibility into device security state. NIST's IoT cybersecurity baseline identifies those capabilities as general considerations for connected devices.

The appropriate controls depend on the architecture and risk. This foundation article does not prescribe network segmentation, firewall policy, cryptographic configuration, credential lifecycle procedures, or other detailed hardening measures. The key point is that a network-connected controller or management server should not be treated only as part of the door hardware layer; it is also a computing component that handles security-relevant data and interfaces.

Privacy is related but distinct. Access-control records can associate people or credentials with entry attempts, granted access, denied access, times, locations, or other supported events. The exact data collected depends on the implementation, and legal requirements depend on jurisdiction and use.

Biometric data can carry distinct legal implications because some legal frameworks distinguish it from ordinary credential data. Under the EU GDPR, biometric data processed for the purpose of uniquely identifying a natural person is treated as a special category of personal data, subject to Article 9 and its exceptions. That EU rule should not be generalized into a global requirement, and it does not mean that every access-control credential is biometric or that one universal consent rule applies.

Follow the Transaction, Not Just the Reader

The most durable way to understand physical access control is to follow the transaction from the person to the door and back into system records:

credential holder → credential → reader → controller or decision point → authentication/validation as applicable → authorization → grant or deny → locking hardware and door action → door/exit status → event and management visibility

Products can place those functions in different devices and services, but the relationships remain useful. The reader captures the request; decision logic determines whether entry is permitted; locking hardware enforces the physical result; door-side inputs describe the opening; and management software administers the system and exposes supported events and records.

That boundary matters because later design work—access levels and groups, credential selection, locking calculations, code compliance, network architecture, and cybersecurity implementation—depends on this system model rather than replacing it.