Security

Preventing RFID Cloning in Access Systems: Practical Controls

RFID cloning is stopped in layers, not by a single product. The credential must prove a secret key (DESFire EV3 mutual authentication instead of a bare UID), the reader-to-controller link must be encrypted and replay-protected, the access decision must live on a local master that fails closed, and the card population must be governed over its whole lifecycle — issuance, blocking, expiry and audit. This guide walks through each layer with the concrete controls used in the AXON system, and shows how retrofits can move from cloneable cards to authenticated ones without a hard cutover.

11 min read Updated 2026-08-17 Written from firmware and schematics by the AXON team
Preventing RFID Cloning in Access Systems: Practical Controls

Where cloning risk actually comes from

RFID cloning is not theoretical. It shows up wherever a reader grants access on the strength of a serial number alone. Three legacy patterns account for almost all of it:

  • 125 kHz proximity cards broadcast a fixed ID with no cryptography. A handheld cloner copies one in seconds.
  • MIFARE Classic has broken encryption; its UID and sector contents can be read and written to a blank card with hobbyist tools.
  • Wiegand-26 wiring carries the credential in cleartext along the whole cable between reader and panel. Anyone with access to the riser can record and replay it — the card itself does not need to be touched.

The operational consequences are what matter to a building: unauthorised entry, an audit trail that shows a legitimate resident where an intruder actually was, and slow incident response because nobody can tell a clone from the original. Risk also varies by site. A residential building with one lobby door has a different exposure than a mixed-use tower with per-floor elevator restrictions, a garage ramp and service windows for contractors. Match the controls to the actual threat model rather than to a marketing tier.

For the cryptographic background — why DESFire EV3 resists what MIFARE Classic cannot — see the DESFire EV3 vs Classic deep-dive and the companion article on anti-cloning RFID.

Layer 1: make the card prove a key, not a number

The single most effective control is a credential that cannot be copied by reading it. With MIFARE DESFire EV3 the reader selects an application on the card and runs an AES-128 challenge-response (AuthenticateAES). The card must answer with a key that never leaves the chip. A tag that only carries a copied UID has no key, fails authentication and is treated as if it were never presented.

The AXON URX-Secure reader implements this with a few design rules worth borrowing regardless of vendor:

  • Never grant on UID alone. The 7-byte manufacturer UID is the card's identity, but it is trusted only after the AES exchange succeeds. A cloned UID produces no LED, no beep and no bus frame.
  • Per-card diversified keys. Keys are derived from a root through a READ sub-master and then AES-CMAC over the card UID (the AN10922 pattern). Every card holds a different key, so recovering one card's key does not open the estate.
  • The reader holds the minimum secret. URX-Secure carries only the READ sub-master — enough to authenticate any AXON card, not enough to format, rewrite or re-key one. A stolen reader is bounded in what it can do.
  • Ignore foreign cards by default. MIFARE Classic, NTAG or third-party DESFire cards produce no reaction unless the master explicitly enables UID-only reporting for a migration window (see below).

Authenticating the card is pointless if the reader then sends "card 0x04A2… authenticated" in cleartext down a cable someone can tap. In the AXON architecture the reader talks to its master over RS-485 at 115200 bps, 8N1, and the link runs a secure layer modelled on DESFire itself:

  • A 3-pass mutual authentication between reader and master (AES-128-CBC over a shared link key) yields a per-session key.
  • Every access frame — CARD_EVENT, ACCESS_RESULT, SET_CONFIG — is AES-CTR encrypted, then tagged with an 8-byte CMAC over a 4-byte counter (encrypt-then-MAC).
  • Counters are per direction, so a recorded frame cannot be replayed or reflected. Frames with a bad MAC or stale counter are dropped; eight bad frames in a row lock the link for 5 seconds.
  • The master re-keys every 5 minutes and the reader caps a session at 15 minutes.

The practical result is that the card UID never crosses the wire in the clear, and a captured grant cannot be played back. The same reader firmware and the same wire protocol serve both positions in a building — inside the cabin to the AXON CCU-32 cabin master, and at each landing to the AXON Node.

Layer 3: encrypt the backbone, key each endpoint separately

On the landings the Node forwards each authenticated card event to the external master, AXON ICM-GE, over a Classic CAN bus at 250 kbps — up to 120 access points per port, two ports per master. Because dozens of nodes sit in publicly accessible corridors, the backbone follows two rules:

  1. Per-node diversified keys. Each Node holds its own AES-128 key derived by AES-CMAC from the CAN root key and its DIP-set node id. A cracked-open board exposes that node only; a failed MAC or replayed counter drops that node's session and forces a fresh mutual authentication, and nothing else changes.
  2. Encrypt-then-MAC with the CAN ID bound into the tag. Traffic is AES-CTR encrypted, CMAC-tagged with 4-byte counters per direction, and the 11-bit arbitration ID is covered by the MAC — a frame cannot be replayed to a different node. Hardware acceptance filters mean a node never even sees other nodes' frames.

Read the RS-485 vs CAN vs Ethernet comparison for why the cabin uses RS-485 while the riser uses CAN.

Layer 4: decide at a local master, and fail closed

Reader-side checks tell you the card is genuine. They do not tell you whether that card should open this door at this hour. That decision belongs to a controller holding the permission table, not to the reader:

  • Inside the elevator, the CCU-32 verifies the frame, checks its local permissions and answers within the reader's 1-second window; granted floor relays pulse for 3 seconds so the passenger can press only the buttons they are entitled to.
  • Outside the cabin, ICM-GE holds the full card database on board — per-port and per-relay permission masks, valid-from and valid-to dates and flags per credential — and looks a card up by binary search with a design target under 2 ms. Existence, blocked flag, permission mask and validity are checked in that order.
  • No cloud in the decision path. The server synchronises the database, collects logs and delivers firmware; an internet outage changes nothing at the tap.
  • Fail closed. If a Node gets no verdict within 800 ms the tap expires as a deny. A frame that fails its counter or MAC check produces no verdict, so the reader shows deny. A Node never pulses a relay on its own judgement.

Controller-side policy is also where you add the rules that catch a valid-looking credential used wrongly: schedule windows, floor permission matrices, per-door rules for garage and ramp entrances. Behaviour analytics on the event log — abnormal-hour usage, unusual floor sequences, repeated denies — improve investigation speed, but they are a supplement to hard policy, not a replacement. Tune thresholds so alerts stay actionable; raw alert floods create fatigue.

Attack surface versus control

AttackWhere it landsControl that closes it
Copy UID to blank tagCardDESFire EV3 AuthenticateAES; never grant on UID alone
Sniff credential on reader cableReader ↔ masterAES-CTR + CMAC secure layer on RS-485; UID never in the clear
Replay a recorded grant frameReader ↔ masterPer-direction counters, 8-byte CMAC, session re-key
Tap the riser and inject a "pulse relay" commandNode ↔ masterPer-node AES-128 key, CAN ID bound into MAC, verified master command only
Steal a reader and extract keysReaderReader holds READ sub-master only — cannot re-key or format cards
Compromise one landing boardNodePer-node diversified key; session dropped and re-authentication forced
Use a card after the holder leftLifecycleBlocked flag, valid-from date, master database sync

Retrofits: reducing exposure without a hard cutover

Most buildings do not start from a blank slate. Two paths keep an existing estate running while cloning exposure shrinks:

  • Keep the readers, replace the panel and bus. The AXON AMS converter sits in the back box behind an existing Wiegand 26/34 reader and republishes each read on the AXON RS-485 bus with its own address. The cleartext Wiegand path shrinks from tens of metres of riser cable to a few centimetres, and every door becomes individually auditable. The card layer is unchanged, so this bounds the wiring risk but does not fix a MIFARE Classic population — pair it with a card migration for the highest-risk doors.
  • Migrate the cards under a controlled window. With the master's READ_ALL flag, URX-Secure reports legacy cards UID-only, flagged as not authenticated, so the master can log them while DESFire EV3 cards are issued as replacements. The reader itself never grants a UID-only card; the master's policy defines what the transition window means, and when it closes.
  • Legacy Wiegand into the cabin. The CCU-32 also accepts a Wiegand-26 reader directly on its D0/D1 inputs, so a cabin retrofit can run on the existing reader while the encrypted reader is planned as the long-term option. Treat that credential as cleartext until it is replaced.

Credential lifecycle and governance

Hardware buys you the ability to resist cloning; process is what keeps it working. A strong reader behind a weak issuance workflow still leaks:

  • Issuance. Provision DESFire cards under a defined key hierarchy; keep root and admin keys off the readers and off the site.
  • Revocation. Set the blocked flag the day a resident moves out or a contractor finishes; push it in the next database sync rather than waiting for the card to be handed back.
  • Expiry. Use per-card validity dates for contractors and short-term tenants so unreturned cards die on their own.
  • Audit. Every GRANT and DENY, with its reason — unknown card, blocked, no floor permission, expired — is logged locally and synchronised later. Review denies periodically; a burst of "unknown card" at one landing is the earliest signal of a cloning attempt.
  • Firmware and keys. Keep firmware current (CCU-32 uses two-slot, CRC-verified OTA over HTTPS) and track open items honestly: on today's AXON boards the link keys sit in software AES with an ATECC608 secure element planned, which is exactly the kind of gap a governance review should record.
  • Baseline and change control. Document the configuration, version it, and require authenticated maintenance flow for replacements. Without a baseline, troubleshooting in a multi-entrance property becomes guesswork.

Field integration: do not undo the crypto with the wiring

Integration quality is a security control. Exposed junctions, undocumented bypass switches, shared unmanaged power and ad-hoc protocol bridges create attack paths that no card format can close. Recommended practice:

  • Terminate RS-485 and CAN segments with 120 Ω at both physical ends and daisy-chain — no star wiring — so link errors are not mistaken for attacks and vice versa.
  • Keep the Wiegand stub, where one still exists, inside the reader back box.
  • Use protected enclosures for masters and Nodes; a Node in a public corridor is a per-node-keyed device precisely because physical access is assumed.
  • Record every replacement: a swapped Node re-keys automatically from its DIP address, but the master should still know which id changed and when.

In Kosovo, where installers work across building ages from prefabricated blocks to new towers, this discipline is what makes legacy constraints manageable. See Access Control for Multi-Entrance Buildings for topology guidance.

Key takeaways

  • Cloning resistance starts at the card: DESFire EV3 mutual authentication, per-card diversified keys, and no UID-only grants.
  • The reader link and the riser must be encrypted and replay-protected, or the card layer is wasted.
  • The decision belongs to a local master that fails closed and never waits on the cloud.
  • Retrofits can shrink exposure in stages — bus first, cards second — without a hard cutover.
  • Governance (issuance, blocking, expiry, audit, change control) is what keeps the architecture effective over years.

Frequently Asked Questions

Can anti-cloning measures fully eliminate cloning? No. The correct goal is measurable risk reduction: authenticated credentials, encrypted links, master-side policy and controlled operations. Each layer removes a class of attack; together they leave no cheap path.

Should every building use the same RFID security setup? No. Configuration should match the risk profile, usage model and operational constraints of the property. A single-lobby residential building and a multi-tenant office with per-floor elevator restrictions warrant different policy, even on the same hardware.

What is the fastest improvement for weak legacy deployments? Move the decision to a controller with a governed credential lifecycle — blocking, expiry, audit — and bound the cleartext Wiegand path with a converter, before investing in analytics. Then migrate the cards on the highest-risk doors to DESFire EV3.

Does encrypting the bus help if the cards are still MIFARE Classic? It closes the wiring attacks — sniffing and replay on the cable — but a Classic UID can still be read at the card. Bus encryption is a necessary step, not a sufficient one; the card layer has to follow.

What happens if the master or the internet is down? The internet is never in the decision path; the master decides from its local database and syncs later. If the master itself is unreachable, the Node denies after 800 ms and the reader shows deny — the system fails closed rather than open.

Related: Anti-Cloning RFID, Access Control Kosovo, AXON URX-Secure, AXON CCU-32, AXON ICM-GE.

Published 2026-02-22 · Updated 2026-08-17Ask an engineer
Size it for your building

Need this applied to a real building?

Tell us the floors, entrances and readers. We size the AXON system, supply the boards from local stock in Kosovo and support commissioning.