How Access Control Systems Really Work: From Credential Tap to Door Hardware
A credential can be accepted while the opening still fails. Understanding why means following the complete path from reader communication and authorization to lock power, physical hardware, and door-state feedback.
A credential is presented. The reader flashes green. The event log says Access Granted. But the lock never releases.
Nothing in that sequence is necessarily contradictory. The credential path may have worked exactly as designed while the door path failed somewhere else.
That is one of the most useful ways to understand an access-controlled opening: the reader is only the visible part of a larger system. Behind every credential tap is a sequence of communication, authorization, electrical outputs, locking hardware, and physical-state monitoring.
The 30-second answer
Four connected events. Four different things to verify.
One tap starts two different system paths
A practical way to understand the opening is to separate it into a credential and decision path and a door and hardware path.
Where authorization occurs varies by architecture. It may happen at a dedicated controller, at an intelligent edge device, or through another platform design. The exact sequence should be verified for the system being specified.
One decision path. One physical-response path.
Both must work before the opening can be considered reliable.
A valid authorization does not prove that the lock released. A door opening does not, by itself, prove that the opening was authorized.
The reader-to-controller link is a separate security decision
Credential technology and reader communication are often treated as if they were the same layer. They are not.
A credential may use proximity, smart-card, mobile, biometric, or another technology. Separately, the reader needs a method to communicate with the controller or access-control system.
Wiegand
Wiegand remains widely installed and can be important for legacy compatibility. For credential data, however, it is a one-way signaling method and does not provide inherent encryption of that reader-to-controller data path.1
Design implication: a more secure credential does not automatically create a more secure reader-to-controller connection.
OSDP
OSDP provides bidirectional communication, device supervision, and additional management capabilities between access-control units and peripheral devices. The current SIA specification is version 2.2.2, and OSDP is also published as IEC 60839-11-5.2
Verify the exact implementation: supported features and interoperability still depend on the devices, firmware, and configuration being combined.
OSDP-capable does not automatically mean Secure Channel is established. OSDP supports Secure Channel using AES-128, but support, provisioning, configuration, and successful negotiation must be verified during implementation and commissioning.3
RS-485 is not a synonym for OSDP. RS-485 describes an electrical communications layer. Manufacturer documentation must still confirm the application protocol and supported OSDP capabilities.
The controller can grant access and the lock can still fail
After authorization, troubleshooting moves from the logical path into the electrical and mechanical path. A controller may change its output exactly as expected while the opening remains locked.
Depending on the architecture, the opening may use a dry relay contact, a powered lock output, or a separate access-control power supply. Product selection may also depend on:
The controller saying "unlock" does not prove that the locking hardware received the electrical and mechanical conditions required to release.
What happens when power is lost?
Fail-safe and fail-secure behavior is a system-level decision, not a label to choose in isolation. Egress requirements, fire-alarm interfaces, life-safety requirements, approved door hardware, adopted codes, and the Authority Having Jurisdiction may affect the correct design.
Verify the approved project documents, exact manufacturer instructions, applicable codes, and AHJ requirements. Access-control guidance does not replace qualified door-hardware, fire-alarm, electrical, or life-safety design.
DPS and REX tell the system what happened next
Authorization tells the system what should happen. Inputs at the opening help it determine what did happen.
DPS: door position is not lock status
A Door Position Sensor or door contact typically tells the controller whether the monitored door is open or closed. That input enables conditions such as Door Forced Open and Door Open Too Long.4
CLOSED does not necessarily mean SECURED.
A closed contact does not independently prove latch engagement, strike operation, or locking force.
REX: more than an unlock button
REX behavior depends on the architecture and configuration. A valid REX may command an unlock, reset a timer, or primarily tell the system that the next opening is expected.5
REX is an input into door logic.
It can affect event processing and prevent a legitimate exit from appearing as a forced opening.
Four events that should not be confused
Exact event names, timers, and logic vary by manufacturer and configuration. The useful question is: what information caused the event, and what does that event still not prove?
One opening can generate four very different events.
Trace the event back to the information that created it.
| Event | What it typically tells you | Primary information involved |
|---|---|---|
| Access Granted | Authorization logic approved the request. | Credential plus authorization logic |
| Door Opened | The monitored door changed to an open state. | DPS or door contact |
| Door Forced Open | The door opened without the expected authorized condition according to configured logic. | DPS plus controller state and event logic |
| Door Held / Open Too Long | The door remained open beyond the configured interval. | DPS plus configured timer |
Why the green light proves less than you think
Reader LEDs and buzzers provide useful feedback, but their exact meaning depends on the system and configuration. A green indication may represent a successful credential or access condition.
Troubleshoot the failed layer, not the visible device
Reader turns green. Door stays locked.
Move downstream. The reader may have completed its part while the output, power, wiring, lock, or physical opening failed.
Door unlocks, but the system reports Forced Open.
The credential and lock may both be functioning. The controller may be receiving the wrong state or may not recognize the opening as expected.
Door Held Open alarms appear during normal use.
Increasing the timer may hide the symptom without correcting the opening. Check the physical closing behavior first.
Commission the opening as a system
A good commissioning test goes beyond presenting one valid credential. Deliberately create the conditions the opening is expected to recognize.
Verify authorization, unlock, DPS transition, closing, and relocking.
Observe how the system handles a grant with no physical transition.
Confirm denied behavior and that the opening remains secured.
Verify the intended forced-open logic and notification path.
Confirm open-too-long timing, escalation, and restoration.
Confirm REX, expected door state, and event processing.
Where the project requires it, also verify power-loss, network-loss, backup-power, and recovery behavior. Commissioning should prove more than the fact that every device powers on. It should prove that the opening behaves correctly as a system.
Before selecting parts, verify the chain
Reliable access control requires more than matching a reader with a credential. Work through the complete signal, decision, power, and feedback path.
Then verify the exact manufacturer documentation for the devices being combined. This is the same system-first principle used when reviewing fire alarm part compatibility: brand, connector type, or physical fit does not establish the complete operating relationship.
Planning an access-control opening?
Send EhubAmerica the controller model, reader interface, credential type, lock hardware, available power, and the behavior the opening must support. Our team can help narrow compatible options and identify what should be verified before equipment is ordered.
Common questions
Does OSDP automatically mean encrypted communication?
Can a reader work even if the door does not unlock?
What is the difference between DPS and REX?
Does a green reader light prove the lock released?
Primary technical references
- Security Industry Association: Access and Credentials - Simplicity on the Surface
- Security Industry Association: Open Supervised Device Protocol; IEC 60839-11-5:2020
- Security Industry Association: OSDP implementation checklist and Secure Channel guidance
- Johnson Controls / Kantech: Door contact and monitored-door conditions
- Johnson Controls / Kantech: Request-to-Exit configuration and event behavior
- Axis Communications: Network Door Controller documentation
A working reader proves only part of the path.
A reliable opening requires the full chain to work: credential processing, reader communication, authorization, output, power, lock hardware, physical movement, and door-state feedback.
EhubAmerica supports integrators and technical buyers with product selection, system compatibility, and project planning across access control, networking, video surveillance, and life-safety systems.