We build the boards that decide who rides
AXON Access is a hardware and firmware company in Prishtinë, Kosovo. We design every board in the AXON system ourselves, write the firmware that runs on it, and document what it does on the wire. Our mission is simple: make access management easier and more secure for the buildings we serve in Kosovo, Albania, North Macedonia and across Europe.
One access system, two independent subsystems
Inside the elevator cabin the AXON CCU-32 cabin master holds the permission table and drives per-floor relays into the elevator's call-button matrix. URX-Secure readers hang off it on an encrypted RS-485 bus. When a resident taps a card, the reader authenticates it, the cabin master looks the card up in its local database and releases only the floors that card is allowed to reach.
Outside the cabin — landings, entrances, garages, internal doors — the AXON ICM-GE external master talks to one AXON Node per floor or door over encrypted CAN, and readers sit behind each node on RS-485. The master decides; the nodes report and execute. Both subsystems talk directly to the AXON cloud and neither depends on the other.
The cloud, reached over MQTT with TLS, only synchronises the card database, collects event logs and delivers OTA firmware. It is never asked for an access decision. Building managers work in the AXON web dashboard and mobile app: issue and block cards, set floor permissions and validity dates, and read the event history.
Around the two masters sits a family of expansion boards — dual-relay modules, a 32-channel solid-state relay panel, a Wiegand-to-RS-485 converter, a LoRa long-range link, a push-button retrofit bridge and a touch-plus-biometric cabin panel. Some ship today; some are on the bench. Each product page says which.
- Subsystem A: CCU-32 cabin master + URX-Secure readers, encrypted RS-485
- Subsystem B: ICM-GE master ↔ per-floor AXON Node over encrypted CAN, readers on RS-485
- Cards: MIFARE DESFire EV3, AES mutual authentication, no UID-only trust
- Cloud: MQTT/TLS for database sync, logs and OTA — decisions stay local
Four rules every AXON board follows
These are not slogans. They are constraints we apply at the schematic, in the firmware and in the documentation, and you can check each one against the product pages.
Offline first
Every master keeps the full card database in local flash and decides on the board. If the fibre is cut or the LTE modem loses signal, cards still work, doors still open and the elevator serves the right floors. The cloud gets the events when the link returns. An outage should degrade visibility, not operations.
Encryption by default
The reader bus is encrypted RS-485, the floor backbone is encrypted CAN with per-node keys and anti-replay counters, and cards are MIFARE DESFire EV3 with AES mutual authentication. A copied UID does not authenticate, so it does not open anything — no reader in the system grants on a UID alone.
Honest documentation
We write the firmware, so our documentation comes from the source, not from a sales sheet. Where the shipping code differs from the long-term design, we say so on the page. Integrators planning a rollout deserve to know what ships today and what is roadmap.
Built in Kosovo
Schematics, layouts, firmware and bench tests are done by our own team in Prishtinë. Boards ship from local stock in Kosovo, and support during installation comes from the people who designed the hardware. If a question reaches us, it reaches an engineer who has had the board on the bench.
From schematic to shipped board
Every AXON module goes through the same four stages. A product page tells you which stage the board is in today, in the status label under its name.
Design
We choose the MCU, transceivers and secure element, draw the schematic and lay out the board in-house. Bus topology, key storage and failure behaviour are decided here, against the AXON system specification that every device shares.
Firmware
We write the firmware line by line: the reader-side RS-485 protocol reused on cabin master and node, the encrypted CAN link, the local database lookup and the MQTT/TLS uplink. What the code does is what the documentation says.
Bench validation
Prototypes go on the bench with real cards, real bus lengths and real relays. Encryption is verified against a host implementation, timing is measured and protections are tested. Only measured values reach the spec table; unknown values are left out.
Field pilots
Boards that pass the bench go into pilot installations before general availability. Pilot units are available on request for modules in final test, and the product page states this openly rather than calling the board finished.
Planning an elevator or building access project?
Tell us the floor count, entrances and readers you need. We size the cabin or CAN subsystem, quote hardware from local stock in Kosovo and answer technical questions directly. Mon–Fri 09:00–17:00, +383 48 296 722.