Access Control for Multi-Entrance Buildings: Design Guide

Why one policy, not many panels

Buildings with multiple entrances, ramps, garages and elevator points need the same rules enforced on every path in. Without a central policy each door becomes its own configuration domain: a card revoked at the front entrance still works at the garage, and nobody can answer "where can this card get in?" without walking the building. An effective architecture maps identities to permissions across zones from one authoritative table, so access at one entry point never implies access elsewhere. This matters most in mixed-use properties, where residential, office and service traffic share entrances and elevators.

Zone modeling: every access point is an addressed node

Zone modeling is the foundation. Every access point — entrances, garage gate, ramp barrier, each elevator landing, plant rooms — is a named policy object. In AXON this is physical: each point is an AXON Node with a hardware address. Six DIP switches set the node id (0–62; 63 is broadcast) and two set the device type — floor, door, garage or ramp. The type is reported to the master in the node's status frame so the matching policy is applied; the id feeds the CAN hardware filters and the node's key derivation. Replacing a board is a wiring-and-DIP job, no laptop.

Plan the address scheme to follow the floor plan (entrances 1–9, garage and ramps 10–19, landings 20 upward). The requests Kosovo installers bring us — akses për dyer, akses për garazh, akses për rampë — all reduce to the same object: an addressed node with a type and a policy. Roles should include temporary ones for contractors: on the ICM-GE each credential record carries a valid-from date and a 32-bit floor/zone mask, so a contractor card is valid for one zone and one period and rejected everywhere else, with the reason logged.

One master, two CAN segments

The AXON ICM-GE is the external master for landings, entrances and doors: two independent Classic CAN 2.0B ports at 250 kbit/s, up to 63 addressed nodes per port, and a 4 MB on-board database of sorted 64-byte records (credential, per-port and per-relay permission masks, valid-from and valid-to dates, flags, CRC-8) holding up to 32,704 cards. The offline decision target is under 2 ms; the measured reader → node → master → node path is under 10 ms against a 100 ms budget.

For a multi-entrance site the two ports are the natural fault domains:

• CAN 1 — perimeter: entrances, garage gate, ramps, external doors.
• CAN 2 — vertical: elevator landings and internal doors on the riser.

Each segment is one shielded twisted pair, 120 Ω terminated at the two physical ends only, node stubs of 30 cm or less, no star wiring. Bus power to each port is switched separately on the master, so a shorted segment in the garage can be cut at runtime while the landings keep working.

Worked example: three entrances, an underground garage, a service ramp and twelve landings — sixteen nodes, five on CAN 1 and twelve on CAN 2. One master in the basement service room decides for all of them, and the manager can open the garage gate remotely with a relay command to that node. Where a point needs two outputs — barrier plus warning lamp — an RBN-2 dual-relay module switches next to the load. See RS-485 vs CAN vs Ethernet for why the riser is CAN and the reader leg is RS-485.

One credential for every entrance

Every reader in the building is the same URX-Secure: a 13.56 MHz DESFire EV3 reader that runs AES-128 mutual authentication with the card before reporting anything, then sends the event to its node over an encrypted, MAC-protected RS-485 link at 115200 bps. The card UID never crosses the reader bus or the CAN backbone in the clear, so a passive tap at the garage cannot track a resident floor by floor. Each node holds its own AES-128 key derived from the master's root key; compromising one board exposes that node only.

The master's decision order is identical at every point: known card, not blocked, zone bit set for this node, validity date current — GRANT or DENY with a reason code. See Anti-Cloning RFID.

The elevator is a separate subsystem — on the same cards

In AXON the cabin is deliberately its own subsystem. The CCU-32 cabin master reads the in-cabin URX-Secure over RS-485, decides locally which floors a card may reach and pulses one relay per allowed floor button; the ICM-GE covers landings, entrances and doors over CAN. Both talk to the AXON platform independently and both use the same DESFire EV3 cards, so a resident's card that opens the garage and lobby also enables their home floor, while a visitor granted the lobby cannot ride to another tenant's floor. Enforcement is on two boards; management is in one place. See Elevator Access.

Retrofit and distributed sites

• Some entrances keep old readers. An AXON AMS (W2R-N) behind an existing Wiegand 26/34 reader forwards each credential as an addressed RS-485 message and can pass Wiegand through to the legacy panel during a phased cutover.
• Legacy MIFARE Classic cards still in circulation. With READ_ALL the URX-Secure reports them UID-only, flagged not authenticated, for logging while DESFire EV3 cards are issued. The reader never grants on a UID alone.
• Entrances hundreds of metres apart. For gated complexes or campuses, an ICM-LR master links remote points over LoRa (868 MHz, roughly 1 km line-of-sight, encrypted end to end) with a short local RS-485 bus at each point.

Resilience and serviceability

• Cloud unreachable: the ICM-GE keeps deciding from its last synchronised database; events are recorded locally and reported when the link returns. An outage degrades visibility, not operations.
• Master unreachable from a node: the pending tap expires after 800 ms as a deny. In the production build a node never pulses a relay on its own judgement — a lost master means a closed door, not an open one.
• Bus faults: five consecutive CAN errors trigger a 30 s pause and re-initialisation; a watchdog resets a hung node after about 4 s; a 5-second status frame lets the master re-authenticate a rebooted node at once.
• Serviceability: DIP addressing, documented wiring, verified two-slot OTA on the master, status LEDs for triage.

Governance after commissioning

Review roles, watch DENY patterns by reason code (unknown, blocked, no zone permission, expired), validate zone policies and refine exception workflows — monthly or quarterly depending on complexity. Because every event carries its reason and originating node, stale credentials and policy conflicts surface in the dashboard before they become incidents. For the local context see Access Control in Kosovo.

Key takeaways

• Model every entrance, gate, ramp and landing as an addressed node with a device type; the policy lives on one master.
• Split perimeter and vertical circulation across the ICM-GE's two CAN ports; terminate each segment at both ends only.
• Use one DESFire EV3 card population and one reader SKU; keep legacy readers via AMS during migration.
• Treat the cabin as its own subsystem on the same cards, managed from the same place.
• Nodes fail closed, the master decides offline, every event carries a reason code.

Frequently Asked Questions

Q: How many entrances can one centralized system manage? A: One ICM-GE serves up to 120 access points per CAN port across two independent ports — 240 per master — one node per entrance, gate, ramp, landing or internal door. Larger or distributed properties add further masters or an ICM-LR for remote points, with the card database synchronised from the AXON platform, so there is no system-level cap on how far a site can grow.

Q: Should elevator control be separate from door access? A: In AXON it is a separate subsystem — CCU-32 in the cabin, ICM-GE for entrances and landings — but both use the same DESFire EV3 cards and are managed from one place, so there is no policy gap between perimeter and floors.

Q: What is the first step for upgrading a fragmented site? A: Zone modeling and role definitions: list every access point, assign a device type and node id, and decide which CAN segment it joins. Then migrate in phases — AMS converters keep existing readers live while the backbone and master are commissioned.

Q: What happens at the garage gate if the internet is down? A: Nothing changes. The master decides from its local database, the node pulses the gate relay on GRANT, and the event waits in the local log until Ethernet or LTE returns.