RFID Security and EPC Passwords: What Gen2 Actually Protects

RFID security discussions usually start with a question about encryption, and that is the wrong first question. Gen2 tags are small passive devices with a few hundred bits of memory and no battery; what they can protect is narrow, specific and worth understanding before anyone writes a security requirement.

Security starts with the threat model

Different threats need different mechanisms, and most are not cryptographic.

• Rewriting an EPC: someone changes a tag so a pallet claims to be a different item.
• Killing a tag: a stolen item arrives at a portal and is invisible.
• Cloning: a copied EPC appears on a counterfeit or a duplicate asset.
• Eavesdropping: an unauthorised reader harvests identifiers in a public area.
• Denial of service: deliberate jamming or deliberate over-reading disrupts operations.

The EPC is not a secret

It is a broadcast identifier, and it should be designed as one.

• Gen2 tags answer any compliant reader that asks; there is no authentication in the base inventory commands.
• An EPC can be read from several metres away by anyone with a suitable reader and antenna.
• Treat the EPC as a licence plate, not as a password or a cryptographic token.
• Never encode personal data, pricing or contract terms into the EPC field.
• Design downstream processes so that knowing an EPC grants no authority on its own.

Access and kill passwords in Gen2

Two 32-bit passwords cover two different risks.

• The access password gates memory writes, so an unauthorised party cannot rewrite the EPC or user data.
• The kill password gates the permanent disable command, so a tag cannot be silently switched off.
• Both are transmitted over the air and need cover-coding to avoid trivial interception.
• A tag left with the default password of zero is effectively unprotected, which is common in pilots.
• Write both passwords at commissioning, or accept that neither protection exists.

Lock bits and permalock

Locking is the strongest control Gen2 offers, and it is irreversible.

• Lock commands protect the EPC, TID, user memory, access password and kill password at different granularities.
• A locked EPC cannot be corrected, so lock only after the data is verified and the process is stable.
• Permalock makes the lock itself permanent, removing any future ability to unlock.
• Read-only TID is useful evidence for identity; it is not, by itself, proof against cloning.
• Decide the lock policy per asset class, because a wrongly locked tag becomes electronic waste.

Cover-coding and what it protects

It hides passwords from casual interception, not from a determined attacker.

• Cover-coding XORs the password with a random number the reader requests from the tag first.
• It prevents a passive listener from lifting a plaintext password out of the air.
• It does not stop an attacker who can interact with the tag directly.
• It does nothing for the EPC read itself, which remains in the clear by design.
• Enable it on readers where the option exists, and do not market it as encryption.

Cloning, TID and Gen2v2 authentication

The realistic defences are identity checks and physical evidence.

• A cloner copies the EPC bank; a TID value is harder to copy but has been demonstrated.
• Gen2v2 adds an Authenticate command with cryptographic suites, which requires tags that support it.
• Cryptographic authentication costs more per tag and narrows the supplier field considerably.
• For many operations, a lookup against a server-side record is stronger than any on-tag check.
• Use authentication where the item value justifies it, and process controls everywhere else.

Key management across a tag estate

Passwords that live in spreadsheets are not controls.

• Store access and kill passwords in a managed secret store, per site and per tag class.
• Never hard-code them in middleware, mobile apps or printer templates.
• Rotate access passwords where the tag generation permits rewriting, and track which tags still hold old values.
• Restrict which readers and which operators can issue lock or kill commands.
• Log every lock and kill event with the operator, time and tag, and review the log.

Tamper evidence and physical security

Most real-world attacks are physical, not radio.

• A tag can be peeled off and moved to another item; use destructible or tamper-evident labels.
• Tamper loops and case seals detect opening but add cost and failure modes.
• Inspect tags during inbound receiving; a damaged tag is more likely than a cloned one.
• Attach tags where removal damages the label, not where it is convenient.
• Pair RFID with a visual mark or a serial number for high-value goods.

The reader infrastructure is an attack surface

The weakest point is rarely the tag.

• Readers run firmware and network services, and they are often left on default credentials.
• Segment the reader network and deny outbound access to the internet.
• Keep firmware updated, and test updates in a lab before rolling them across a site.
• Treat the middleware that writes EPCs as a privileged system, because it can corrupt identities at scale.
• Audit who can change tag data, and keep an immutable log of those changes.

Audit, monitoring and incident response

A security control that nobody watches is a control that has already failed.

• Log reads, writes, locks and kill commands centrally, with reader identity and operator.
• Alert on any kill command issued outside the documented commissioning or disposal workflow.
• Alert on abnormal write volume from a single reader, which is the signature of bulk rewriting.
• Keep the tag register able to answer when a given EPC was last seen and by which reader.
• Rehearse a cloning or tampering response before it happens; the first real incident is a bad time to design one.

A realistic security posture

State what you have achieved, and state what you have not.

• For most warehouses, a locked EPC plus a server-side validation is proportionate and sufficient.
• For high-value or regulated goods, add Gen2v2 authentication and physical tamper evidence.
• For public-facing environments, assume identifiers are harvested and design accordingly.
• Document the threat model, because an undocumented control is a control nobody maintains.
• Review annually: tag suppliers, reader firmware and the threat model all change.