Replication: copying one specific card

Card replication (often called cloning) means reading the exact identifier off one specific, real credential — someone's actual badge — and programming a second physical token, or a device, to reproduce that exact same identifier indefinitely. The tools used for this (commercial cloners, devices like the Proxmark, or even some consumer NFC apps against unencrypted card formats) capture a static value and play it back forever, unless that one card number is revoked.

Replication is, by design, tied to a single pre-existing credential. It doesn't create new access — it copies access that already exists, onto a second token. This is precisely why unencrypted legacy formats like 26-bit HID Prox are considered a security weakness: their static, unencrypted identifier is trivial to capture and replicate with inexpensive hardware.

Emulation: generating a signal, not copying one

Card emulation, as used in RoboID and in legitimate access control products generally, doesn't start from an existing physical card at all. There's no card to read or clone. Instead, the device is capable of generating a properly-formatted credential signal in the format a reader expects — and it decides whether and when to actually transmit that signal based on a separate, real-time authorization check.

Critically, the credential value an emulator transmits is provisioned and governed through your identity platform — it isn't lifted from somebody else's badge. It exists because it was issued, not because it was captured.

Property Replication Emulation
Credential origin Copied from an existing card Provisioned through IAM
Tied to a real-time auth check No — static replay Yes — checked every time
Revocable independently Only by revoking the original card Yes — per identity, instantly
Typical use Unauthorized duplication, pentesting Authorized robot / device access
Audit trail None — looks identical to the original card Full — logged per device identity
A useful shorthand: replication answers "how do I make a copy of this one badge?" Emulation answers "how do I let an authorized but badge-less device speak the reader's language, only when it's been granted access right now?" The output format on the wire can look similar. The intent, governance, and risk are not.

Why the distinction matters in practice

Security teams are right to be wary of anything described as "cloning" or "replication" near their access control system — that's a known attack technique, and treating it casually would be a mistake. When evaluating a robot access solution, the questions to ask are: does this device copy an existing person's credential, or does it hold its own provisioned identity? Is every signal transmission gated by a live policy check, or does it just replay a fixed value? Is the event logged to an identity-attributable audit trail?

A solution built around real emulation should answer all three in the direction of governance: no, every time, and yes. If a vendor can't answer that clearly, it's worth assuming you're looking at replication with better marketing.

Want a technical walkthrough of how RoboID's emulation is gated by your IAM policy?

Request Early Access →