Imagine this.
Your company uses RFID cards to open office doors. An employee taps the card, the green light comes on, and the door opens.
Then someone asks:
"If another person can read this card, can they copy it?"
That is usually the real question behind RFID security.
The short answer is:
It depends on what the reader is checking.
If the system only checks a readable card number, copying that number may be enough to fool a poorly designed system.
If the card has to prove that it knows a protected secret before the reader accepts it, copying the visible number alone is no longer enough.
That is what this article will help you understand — without turning RFID security into a cryptography lesson.

If Someone Reads Your RFID Card, Can They Copy It?
Start with a simple office access card.
When an employee taps the card, the reader needs some way to decide:
"Is this an authorized credential?"
In a simple system, that decision may be based mainly on a fixed card identifier such as a UID or card serial number.
You can think of the UID like an employee number printed on an ID badge.
For example:
Employee Card: 12345678
If the system sees 12345678 and immediately opens the door, then the security depends heavily on that number.
The problem is that an identifier is not necessarily a secret.
If someone can read the number and reproduce it on another compatible credential, a system that trusts only the number may have difficulty telling the original card from the copy.
That gives us the first important rule:
A card ID tells the system who the card claims to be. It does not automatically prove that the card is genuine.
This is also why UID is not the same thing as an encryption key.
A UID identifies the card.
A cryptographic key is a secret used to prove that the card is authorized.
Here, UID means a card or tag identifier. It should not be confused with UDI, which is the Unique Device Identification system used for medical devices.
What Changes When the Card Has to Prove It Knows a Secret?
Now imagine a more secure office card.
Instead of asking only:
"What is your card number?"
the reader can effectively ask:
"Can you prove that you know the secret?"
The card performs a cryptographic calculation using a secret key.
The reader checks the result.
If the result is correct, the reader has much stronger evidence that it is communicating with the expected credential rather than a simple copy of the visible card number.
This is where technologies such as AES-128 authentication become useful.
Secure HF/NFC smart-card ICs such as MIFARE DESFire EV3 can support AES-128 and cryptographic authentication.
But you do not need to memorize the algorithm to understand the idea.
Think of it as a secret handshake:
Knowing the employee number is not enough. The card also has to know the secret handshake.
Some systems go one step further.
The reader checks the card, and the card also checks the reader.
That is called mutual authentication.

This can matter in a security-sensitive application because you may want to prevent both:
a fake card pretending to be genuine
and
an unauthorized reader trying to access a genuine card.
Why Can't Someone Just Record the Signal and Use It Again?
This is another common question.
Suppose someone secretly records the communication between a genuine card and reader.
Could they simply replay that recording tomorrow?
A properly designed authentication system makes that much harder by changing part of the authentication process every time.
Think of the reader asking a different question on each transaction.
Today:
"Prove yourself using challenge 4721."
Tomorrow:
"Prove yourself using challenge 8359."
The correct answer changes because the challenge changes.
Yesterday's answer should therefore not automatically work today.
This is the basic idea behind challenge-response authentication.
The exact technical process differs between RFID chips, but the practical idea is easy to understand:
A copied ID stays the same. A secure authentication response changes with the challenge.
That is why recording one valid transaction is very different from actually possessing the secret key.
So If a Card Uses AES, Is It Impossible to Clone?
No.
This is where RFID marketing sometimes becomes misleading.
Seeing AES-128 on a datasheet is a good sign that the chip has modern cryptographic capabilities.
But it does not guarantee that the whole system is secure.
Imagine a company with 5,000 employee cards.
Every card supports AES-128.
That sounds excellent.
Now imagine the installer puts the same secret key on every card and saves the master key in an ordinary configuration file on a service laptop.
If someone steals that file, they do not need to break AES.
They already have the key.
The same problem can happen if a project leaves factory-default keys unchanged, stores secrets insecurely inside reader software, or has weak backend permissions.
So the better question is not:
"Does this card support AES?"
It is:
"How is AES actually being used, and where are the keys protected?"
That small change in the question tells you much more about the real security of the project.
If you see 3DES in an older RFID or smart-card specification, that usually points to legacy compatibility rather than the preferred direction for a new security-sensitive system. NIST withdrew its TDEA recommendation in 2024, although older systems may still need compatibility with existing credentials.
The Key Is Often More Important Than the Word "AES"
Think of AES as a very strong lock.
A strong lock is useful only if the key is protected.
Leaving the key under the doormat defeats the purpose of buying the expensive lock.
RFID systems have the same problem.
The secret keys need to be generated, stored, issued and managed properly.
One common technique is key diversification.
Instead of giving thousands of cards exactly the same working key, a system can derive different credential keys from a protected master secret.
That way, compromising one credential does not automatically mean every other credential uses the same exposed key.
A card UID may sometimes be used as one input when creating a diversified key.
But remember:
The UID is not the secret.
The protected master key is the important part.
A simple analogy is a hotel.
The hotel manages thousands of room keys, but Room 201 does not need to use exactly the same key as Room 502.
The system can manage them centrally while still giving different credentials different working keys.
Where Should Those Important Keys Be Stored?
This is where you may hear the term:
SAM — Secure Access Module.
The name sounds technical, but its purpose is easy to understand.
A SAM is a small security module designed to keep important cryptographic keys in a more protected environment and perform sensitive calculations.
Instead of putting a valuable master key directly into ordinary reader software, the reader can use the SAM when it needs to perform the secure operation.
Think of the SAM as:
a small protected safe for important RFID keys.

NXP's MIFARE SAM AV3 is one example of this type of hardware.
But this does not mean every RFID project needs a SAM.
A warehouse identifying cartons does not have the same security requirements as an office access system protecting restricted rooms.
Some systems may use a SAM. Others may protect keys in a secure backend, secure element, HSM, or another controlled security environment.
The practical rule is simpler:
Important master keys should not be sitting in an easily copied file or ordinary application code.
What Happens When an Employee Leaves the Company?
This is a useful example because it separates two things that are often confused:
authorization
and
encryption keys.
Suppose an employee leaves the company on Friday.
The company normally does not need to change the AES keys on every card in the building.
Instead, the administrator disables that employee's credential in the access-control system.
For example:
Card 12345678 — Deactivated
The card may still physically exist, but the backend no longer authorizes it to open the door.

Changing cryptographic keys is a different issue.
That becomes necessary when the key itself may have been exposed or compromised.
This distinction matters because a good security system should let you disable one employee without rebuilding the security settings of every other employee card.
Do Warehouse UHF RFID Tags Work the Same Way?
Not necessarily.
This is important because people often use the word RFID as if every RFID tag works the same way.
An office access card and a warehouse UHF label may both use RFID, but they solve different problems.
A standard RAIN UHF tag is usually designed to let a reader identify many products, cartons or assets quickly.
During normal inventory, the reader may receive an EPC from the tag.
That is exactly what makes UHF RFID useful for:
warehouse inventory, pallet tracking, asset identification and logistics.
But an EPC should not automatically be treated like a secret password.
For many inventory applications, it does not need to be.
The objective is fast, reliable identification.
If your application needs something different — for example, proving that a high-value product carries a genuine tag rather than a copied identifier — then you may need a UHF chip specifically designed with cryptographic authentication.
Secure UHF RFID does exist.
ISO/IEC 29167-10, for example, defines AES-128 security services for compatible RFID systems.
The important point for a buyer is not the standard number.
It is this:
Do not assume every UHF tag supports secure authentication just because it is an RFID tag. Check the actual IC.
For the basic reader-tag process, see How Do RFID Tags Work?.
How Much RFID Security Do You Actually Need?
There is no single "most secure RFID tag" that makes sense for every project.
The right security level depends on what happens if someone copies, changes or misuses the credential.
| Your situation | What probably matters most |
|---|---|
| Counting cartons in a warehouse | Reliable identification and controlled writing may be enough |
| Tracking reusable factory assets | Stable identity, backend authorization and appropriate write protection |
| Opening office doors | Credential cloning and unauthorized reader access become much more important |
| Controlling access to restricted areas | Strong authentication and protected key management may be justified |
| Authenticating high-value products | The tag may need to prove more than a visible EPC or UID |
| Supporting an old installed system | Compatibility with existing cards and algorithms may affect the hardware choice |
The goal is not to add maximum security to everything.
That usually increases cost and complexity without helping the workflow.
The goal is:
Use enough security for the consequence of failure.
A warehouse box and a restricted laboratory door simply do not have the same risk.
What Should You Ask Before Buying RFID Cards, Tags or Readers?
You do not need to become a cryptography expert.
Before choosing security-sensitive RFID hardware, ask your supplier five practical questions:
-
Which exact RFID IC is inside the card or tag?
Two products operating at the same frequency can have very different security capabilities. -
Does the system trust only the UID or EPC, or does it perform real authentication?
A readable identifier and a cryptographic credential are not the same thing. -
Does the chip support AES or another suitable authentication method, and does the reader support it too?
A secure card is not useful if the reader never uses its security features. -
Where are the secret keys stored and how are they managed?
Good cryptography can still fail if key management is weak. -
What happens when a card or reader is lost?
A real system needs a practical way to revoke credentials and respond to compromised hardware.
Those answers usually tell you more than a large AES-128 logo on a product page.
For reader selection and integration planning, see the RFID Reader Buying Guide.
For a broader comparison between short-range RFID/NFC and other RFID technologies, see RFID vs NFC: Which Technology Is Right for Your Business?.
FAQ
Q: Can someone copy an RFID card just by reading its UID?
A: It depends on what the access-control system trusts. If the system accepts a fixed readable UID as the credential, copying that identifier may create a serious cloning risk. If the card also has to complete cryptographic authentication using a protected secret, copying the UID alone should not be enough.
Q: Is the UID the secret password inside an RFID card?
A: No. A UID is an identifier. It may be readable by a compatible reader. A cryptographic key is a protected secret used for authentication or other security functions. The two should not be treated as the same thing.
Q: Does every RFID card or tag support AES?
A: No. Security depends on the actual RFID IC. Some secure HF/NFC cards support AES-based authentication, and some security-focused UHF chips do as well. Many normal RFID tags are primarily designed for identification rather than cryptographic authentication.
Q: Does AES-128 mean an RFID card cannot be cloned?
A: Not automatically. AES-based authentication can make simple copying of a visible card number ineffective, but the real system still depends on secure key storage, reader configuration, credential provisioning and backend authorization.
Q: What is mutual authentication in simple terms?
A: It means both sides verify each other. The reader checks that the card knows the expected secret, and the card also checks that it is communicating with an authorized reader.
Q: Do I need a SAM in every RFID reader?
A: No. A SAM is useful when important cryptographic keys need stronger hardware protection near the reader, but not every RFID project requires one. The correct design depends on the application and the damage that a key compromise could cause.
Q: Is normal UHF RFID secure enough for warehouse inventory?
A: Often, yes. Many warehouse applications mainly need fast and reliable identification rather than high-security authentication. If the project needs anti-cloning or proof that a tagged product is genuine, then a security-enabled UHF IC may be more appropriate.
Q: Should a new RFID project still use 3DES?
A: Older systems may still require 3DES compatibility, but for a new security-sensitive deployment it is better to evaluate current AES-capable hardware and the complete security architecture rather than choosing 3DES simply because an older system used it.
Conclusion
If you remember only one thing from this article, remember this:
Do not ask only "Does this RFID card support AES?" Ask "What does the system trust?"
If the reader trusts only a readable UID or EPC, the system may have a relatively simple security model.
If the credential has to prove that it knows a protected secret, copying the visible identifier alone is no longer enough.
And even when AES is available, the keys still need to be protected properly.
So when choosing an RFID security solution, think in this order:
What are we protecting?
What happens if the credential is copied?
Does the system need simple identification or real authentication?
Where will the secret keys be protected?
Once those questions are clear, choosing the right card, tag and reader becomes much easier.
For more on the basic operation of RFID tags, see How Do RFID Tags Work?.
For help selecting RFID cards, secure tags, readers or authentication hardware for your application, Contact Fongwah.