How Elevator Access Control Works: Reader to Floor Relay

System boundaries: from entrance to floor authorisation

An elevator access control deployment should be treated as a building workflow, not as a standalone device installation. The user journey starts before the cabin: credentials are issued, floor permissions and validity dates are assigned, and rules are defined by role, time window and operational state (normal, maintenance, lockdown). By the time a resident or employee reaches the elevator, the system must already know which floors are permitted and which interactions should be blocked. This is what prevents "security drift" and removes ambiguity for the people operating the building.

The most stable architecture separates responsibilities into three layers:

• Readers capture and authenticate the credential. They never decide.
• Controllers hold the permission table, take the access decision and drive outputs.
• Management software handles credential lifecycle, policy changes, monitoring and audit.

This separation makes troubleshooting easier because a field fault (a reader with a broken bus link), a network fault (uplink down) and a policy fault (wrong floor mask on a card) show up in different layers instead of being mixed together. It also improves resilience: the local decision path keeps working when cloud or WAN latency changes.

For deployments in Kosovo, where integrators routinely handle mixed infrastructure — legacy button wiring, newer elevator controllers and site-specific constraints — a correct design avoids "button simulation only" approaches where possible and prefers a validated, logged command path into the elevator. Where the cabin cannot be rewired, a retrofit bridge such as the AXON PBC-Bridge taps the existing button lines instead of replacing them.

Credential-to-command flow, step by step

The core flow is short but must be deterministic. Using the shipping AXON cabin subsystem — AXON URX-Secure reader plus AXON CCU-32 cabin controller — a single tap runs like this:

1. Card tap at the cabin reader. The reader energises the 13.56 MHz field, reads the card's real 7-byte UID and runs a MIFARE DESFire EV3 mutual authentication (AES-128). A copied UID, a MIFARE Classic clone or a foreign DESFire card fails here and, by default, produces no reaction at all. See MIFARE DESFire EV3 vs Classic for why this step matters.
2. Event to the controller. The reader sends a CARD_EVENT frame with the UID and an AUTH_OK flag to the CCU-32 over half-duplex RS-485 at 115200 bps. The frame is AES-CTR encrypted, tagged with a CMAC and carries an anti-replay counter; the controller verifies counter and MAC before it parses anything.
3. Local decision. The CCU-32 looks the card up in its on-board permission table — known, not blocked, floor mask, validity date — and answers ACCESS_RESULT to the reader within its one-second window. The reader shows green or red for three seconds.
4. Relays pulse, event logged. For each granted floor the matching relay pulses for three seconds so the passenger can press that button on the original panel. The event (timestamp, UID, floors, outcome) is logged locally and published over MQTT/TLS when an uplink is available.

Any failure state returns a clear outcome — deny, timeout, link down, maintenance mode — never undefined behaviour. If no verdict reaches the reader within one second of a tap, the tap is treated as a deny; if the controller is silent for more than three seconds the reader signals link-down and stops accepting cards. The system fails closed.

Determinism matters because operators need explainability. When a user reports denied access, the log must show whether the cause was an expired credential, a floor permission mismatch, a schedule restriction or a communication fault. That level of observability reduces friction and lets security teams enforce policy consistently. People searching for "akses per ashensor" or "akses per lifta" usually want exactly this behaviour: predictable floor-level control, not generic entry logging.

Cabin subsystem vs landing subsystem

Real buildings gate access at two places: inside the cabin and at the landings or entrances. AXON splits these into two subsystems that share the same reader firmware but use different backbones.

In subsystem B the Node never decides: it terminates the reader's RS-485 session, re-wraps the event for the CAN bus and waits for the master's verdict (decision, relay mask, pulse length). If nothing arrives within 800 ms the tap expires as a deny. The end-to-end reader → node → master → node path is budgeted under 100 ms and measured under 10 ms, so it fits comfortably inside the reader's one-second window.

Retrofits that keep existing Wiegand 26/34 readers use the AXON AMS converter behind each reader to bring the credential onto the same RS-485 bus, so a mixed fleet of old and new readers appears to the controller as one set of addressed endpoints.

Local vs central validation — and why both matter

Purely centralised systems create operational risk when network quality fluctuates. Purely local systems become hard to govern across many buildings. The practical answer is a hybrid: local enforcement for time-critical decisions, centralised synchronisation for policy consistency, monitoring and audit.

• With local validation, the elevator keeps working through an outage. The CCU-32 and ICM-GE both keep deciding from their last synchronised permission table and queue events until a route returns. The cloud is never asked for an access decision.
• With central oversight, security teams update permissions, block or rotate credentials and review event history from one management plane. This is what multi-site operators and service companies need.

The hybrid model also supports phased modernisation. A site can start with the cabin subsystem only, add landing nodes later, and progressively adopt stronger controls — encrypted readers, anti-cloning credentials, segmented CAN ports — without replacing the whole stack in one step. For a broader view of the modernisation path see Elevator Access Control.

Communication layer choices and integration discipline

The communication layer should be selected by environment and role, not by habit:

• RS-485 is the reader bus. It tolerates noisy field conditions, supports multi-drop with individual addressing and, in AXON, carries the encrypt-then-MAC secure layer on top of a CRC16 frame layer. Daisy-chain, shielded twisted pair, 120 Ω termination at the two physical ends only, no star wiring.
• CAN is the building backbone between floor nodes and the ICM-GE master. Non-destructive arbitration means sixty nodes tapping at once do not collide, and hardware acceptance filters mean a node never sees another node's traffic. Termination rules are the same: 120 Ω at both ends, short stubs.
• Ethernet is the primary uplink to the cloud (MQTT over TLS, OTA firmware, bulk log sync). Give the controller a dedicated switch port or a managed VLAN.
• Cellular (LTE-M / NB-IoT or LTE Cat-1) is the fallback uplink when no cable reaches the cabin or the wired link is down. Fit an external antenna — a steel cabin attenuates signal.

A fuller comparison is in RS-485 vs CAN vs Ethernet for Access Control.

Integration discipline is usually the real success factor: consistent addressing, clean wiring, documented floor-to-relay mappings, controlled firmware updates and clear rollback procedures. Most production failures are not caused by hardware quality; they come from undocumented field changes and inconsistent commissioning. Communication diagnostics — command latency, event integrity, fail-safe behaviour on a cut bus — should be part of acceptance testing and measured before handover.

Operational governance after go-live

Going live is not the finish line. Access systems need governance: a credential issuance policy, a deactivation workflow for tenants and staff who leave, periodic permission review, incident response and a maintenance cadence. Without it, even technically strong installations degrade over time.

Operators should track a small set of metrics:

• Distribution of denied events by reason (unknown card, blocked, floor mismatch, expired, timeout)
• Reader and bus link uptime, and re-authentication counts
• Command success ratio and uplink availability
• Frequency of policy changes and who made them

These reveal whether a problem is security-related, configuration-related or infrastructure-related.

Finally, user communication matters. Residents, employees and facility teams should understand what the system does and why. Clear guidance reduces misuse and improves acceptance, especially when moving from unrestricted elevator behaviour to controlled floor authorisation.

Key takeaways

• A sound architecture combines an authenticating reader, a controller that decides locally, and a traceable event log.
• The credential-to-relay path must be deterministic and fail closed: no verdict means deny.
• Deployment quality depends on communication design (RS-485 to readers, CAN in the riser, Ethernet/cellular up), credential lifecycle and commissioning discipline.
• Practical integration balances security objectives with the realities of the building — including cabins that cannot be rewired.

Frequently asked questions

Is elevator access control only for high-rise towers? No. Mid-size residential and office buildings benefit just as much from floor-level authorisation and auditability. A 32-relay cabin controller covers most buildings in Kosovo with headroom.

Can existing elevator infrastructure be reused? In most cases yes. The CCU-32 pulses relays into the existing call-button matrix without redesigning the elevator's wiring; the PBC-Bridge taps existing button lines in cabins that cannot be rewired; the AMS converter keeps existing Wiegand readers in service. Staged migration preserves operational continuity.

Does the elevator stop working if the internet goes down? No. The access decision is taken on the cabin controller from its local permission table. The uplink is used only for synchronising cards, collecting logs and delivering firmware; events queue until the connection returns.

What is the main implementation risk? Inconsistent integration practice — undocumented mappings, poor termination, unmanaged firmware. Strong commissioning, measured acceptance tests and documentation reduce deployment risk significantly.

Related: Elevator Access Control, RFID Access Control System, Anti-Cloning RFID, AXON Technical Documentation.