RFID System Security and Encryption: What the Tag Can Protect, and What Only Your Backend Can

Most RFID security conversations start with the tag and end with the tag. That is the wrong place to begin, because the tag is simultaneously the weakest element in the system and the least valuable thing to defend. A passive inlay has no battery, a few hundred gates, and a radio link that anyone within ten metres can listen to.

The realistic question is not how to make the tag unhackable. It is where to put the defensive effort so that the cost of an attack exceeds its value — and which layer of the system must carry that effort.

What is actually at risk in an RFID deployment

Name the assets before choosing the controls, because security spending without a threat model buys comfort rather than protection.

• Inventory integrity: forged reads that inflate stock, or cloned tags that create phantom shipments.
• Physical security: an attacker who knows which items are in which location, or which ones are in transit.
• Customer privacy: movement patterns inferred from item-level tags, especially apparel and retail.
• Anti-counterfeiting: the tag is the product identity, so a clone is a counterfeit.
• Safety and compliance: pharmaceutical and medical traceability where a wrong identity is a regulatory event, not a stock error.

Air-interface threats: skimming, cloning, eavesdropping and relay

Four attacks account for almost everything demonstrated in the wild, and they have different economics.

• Skimming: reading tags without the operator's knowledge. Trivial with a handheld or a modified reader at a few metres; the cost is a few hundred dollars.
• Eavesdropping: passively listening to the reader-to-tag exchange. Needs proximity, not permission.
• Cloning: copying an EPC into a new tag. Cheap tags make this nearly free, and a clone is indistinguishable at the air interface unless the system checks something beyond the EPC.
• Relay: forwarding a challenge to a distant genuine tag. Rare in logistics, meaningful in access control and payment-adjacent scenarios.

Note what is not on the list: breaking cryptography. Attackers rarely need to. They clone, they skim, or they attack the backend.

What EPC Gen2 passwords actually stop

Gen2 provides two 32-bit passwords and a set of lock bits. They are useful, and their limits need stating plainly.

• Access password: required before writing to memory. It stops casual re-encoding of your tags, nothing more.
• Kill password: permanently disables the tag, used at end of life for privacy. A wrong attempt decrements a counter, and after four failures the tag locks itself.
• Lock bits: per-memory-bank, some permanent. They prevent writes, not reads.
• There is no read protection in Gen2. Any compliant reader can read the EPC and TID in the clear. Anything you would not publish must not be stored in tag memory.

Tag authentication and anti-clone strategies

If cloning matters, verify something the attacker cannot copy cheaply.

• TID uniqueness: the TID is factory-programmed and cannot be rewritten; check it against your own registry of issued TIDs. This stops the lazy clone, not the determined one.
• Cryptographic tags: AES-based authentication (for example NXP UCODE DNA or EM Microelectronic alternatives) with a per-tag key. Cost moves from cents to roughly a dollar per tag, which is only justified when the item value or the regulatory exposure is high.
• Challenge-response at the reader: the reader sends a nonce and verifies a signed response. Requires a key-management service; losing the keys is worse than having no scheme.
• Digital signature in user memory: signed payload verified against a public key, useful for anti-counterfeiting where the verifier may be a phone.

Do not invent a scheme. Vendor-specific proprietary authentication exists precisely because home-grown protocols leak.

Backend security: the layer attackers actually target

The most common real-world incident is not a cloned tag. It is a reader with a default password on a flat network.

• TLS everywhere between reader, edge and ERP; mutual TLS where the reader supports it, so a rogue device cannot impersonate a genuine one.
• Network segmentation: a dedicated VLAN per reader group, no route to the corporate LAN, no internet egress.
• Signed firmware and a controlled update path; readers are embedded computers and are patched as rarely as they are audited.
• Least privilege on the middleware: a service account that can post receipts but cannot delete them.
• Secrets management: no passwords in configuration files or in the ERP database in clear text.
• Immutable audit log of every configuration change, with the operator identity.
• LLRP and vendor APIs over TLS, with the management interface reachable only from an administrative subnet.

Privacy and compliance: minimisation beats encryption

Regulation cares less about radio than about what you can infer from data you retain.

• GDPR Article 5: collect what the process needs. A garment tag does not need a customer identifier to be a garment tag.
• Right to erasure: for item-level retail tags, either kill the tag at the point of sale or rotate the EPC so it can no longer be linked to a purchase.
• PIPL and similar regimes impose the same discipline: purpose limitation, retention limits and a lawful basis for any personal data.
• Retail disclosure: signage at the entrance, a published retention period and a contact for questions. Cheap, and it prevents most complaints.
• Keep the linkage between EPC and customer in the ERP, never on the tag.

A practical hardening sequence

Do these in order; each one removes a class of attack before the next becomes relevant.

1. Segment the reader network and remove default credentials. This alone prevents the majority of real incidents. 2. Enable TLS, then mutual TLS, on every reader-to-edge connection. 3. Set access passwords and lock bits on tags you control, and record the passwords in a managed store. 4. Check TIDs against a registry at the edge; quarantine unknown TIDs instead of silently accepting them. 5. Add cryptographic tags only where the asset value justifies the cost, and start with the highest-value SKUs. 6. Kill or rotate tags at end of life, and test that procedure with a real reader rather than in documentation.

Bottom line

RFID security is a system property, not a tag feature. The tag is a radio-visible identifier with weak write protection and no read protection; treat it as public data that happens to be attached to your item.

• Put the identifier on the tag, put the meaning in the backend.
• Assume every EPC can be read and copied, and design detection rather than denial.
• Spend the first budget on network segmentation and credentials, not on exotic tags.
• Use cryptographic tags where the item value or regulation demands it, and nowhere else.
• Keep personal data out of tag memory, and make erasure a tested procedure.

That posture costs far less than a breach, and it survives the next tag generation.