There is a sentence that gets said in strata meetings and property management offices across BC, usually with relief, and usually at the end of a project that cost real money:
"We're fine — we upgraded to 13.56."
It is a reasonable thing to believe. Somebody replaced beige fobs that had been in circulation since the building opened, the new cards look modern, and the number 13.56 MHz appeared in the quote next to the words "smart card". The old system was 125 kHz. The new one is a bigger number. Bigger number, newer technology, problem solved.
Except that 13.56 MHz is a radio frequency. It is the band the card and the reader use to talk to each other. It tells you nothing whatsoever about what they say — and inside that one band sit credential technologies separated by more than two decades of cryptographic development, some of them current and some of them thoroughly superseded. A building can spend a great deal of money migrating off legacy proximity and land on a 13.56 MHz credential that its own manufacturer now describes as a legacy product.
That is the trap this article is about. It is a different trap from the one where new cards are issued but the readers still accept the old ones — that article covers 125 kHz proximity and the migration that never gets finished. This one is about what happens inside the 13.56 MHz band, where everything is nominally modern and the differences are invisible from the outside.
The frequency is the road, not the traffic
The cleanest way to think about it: the frequency band is a road. Knowing that two vehicles are on the same road tells you they can travel together. It tells you nothing about what is in either one.
Every credential in this band uses the same slice of radio spectrum, reads at roughly the same short range, and works with the same general class of reader hardware. That shared physical layer is the entire reason the band exists — it is what makes interoperability possible, what lets one reader be sold into many different systems, and what allows a building to change credential technology without necessarily changing every reader on every door.
The security lives one layer up, in the protocol the two ends run once they have found each other. Does the card simply announce a number to anything that asks? Does it require the reader to prove it is entitled to ask, before it answers? Is the data on the card protected, and by cryptography that has been published and examined, or by a scheme the manufacturer kept to itself? Does every card in the building respond to the same secret, or does each card have its own?
Those questions have completely different answers for different credential families, all of them at 13.56 MHz. None of those answers is knowable from the frequency.
The generations inside the band
Without turning this into a product catalogue, there are two families most BC buildings will encounter, and both have an older generation and a current one.
The MIFARE family. MIFARE Classic is the early-generation smart card in this band. It was enormously successful, it is still in circulation in very large numbers, and it belongs to a period before the industry settled on using open, publicly reviewed cryptography in credentials. MIFARE DESFire — in its current EV-series form — is the modern member of the same family: mutual authentication between card and reader, protection built on published cryptographic standards rather than proprietary ones, and a data structure designed so multiple applications can live on one card without sharing each other's secrets.
The iCLASS and Seos family. Legacy iCLASS is the earlier generation. Seos is the current one, built on open standards and structured around a protected data object rather than a raw card number, and designed to be portable — the same credential model works on a card or on a phone. iCLASS SE sits between them as the platform that introduced that data-object approach.
The point of listing these is not that you should memorize them. It is that "13.56 MHz" is an accurate description of every one of them — the early generation and the current generation alike — which is exactly why it is useless as an answer to a security question.
You do not have to take a competitor's word for the generational split, either. HID Global publishes migration guidance about its own catalogue, and in describing how counterfeit credentials get made it groups the older members of both families together as "cards with fewer security features", alongside cards with no electronic security at all. That is a manufacturer sorting its own product line into old and current. When a vendor writes that down about products it still has customers running, it is worth more than any third-party assessment.
We are not going to describe how anything in that older tier is defeated, name a tool, or attach a number to it. You do not need any of that. The owner-level question is not "how is it broken" — it is "which generation are we on, and is it the current one?"
The serial-number shortcut
Here is the one that catches the most buildings, and it is worth understanding properly because it is invisible in every direction.
Almost every card in this band carries a serial number — a plain identifier the card offers up at the start of any conversation, before any security has been negotiated. It exists for housekeeping: it lets a reader tell one card from another when several are presented at once. It was never designed to be a secret, and it is not treated as one.
An access control system can be configured to use that serial number as the credential. Read the serial, look it up in the list of authorized numbers, unlock the door. It works perfectly. It is simple to commission. It requires no key management at all, which is precisely why it happens.
And it discards the entire security layer of the card. A building doing this has bought current-generation credentials and is using them exactly the way it used its 125 kHz fobs — as a number that gets announced to anything within range. The encryption on the card is present, paid for, and completely unused. Nobody can see the difference by looking at the card, the reader, or the door. The only place it shows up is in the reader configuration.
This is the single most valuable question in this article, so here it is as a sentence to use verbatim: "Are the readers authenticating to the secure application on the card, or are they reading the card serial number?" An integrator who works with these systems will answer immediately. One who does not understand the question has just answered it.
Whose keys are they?
The second buried question is key management, and it follows directly from the first.
A credential that uses cryptography needs keys, and somebody has to decide what they are and who holds them. The weak version of this is a system running the manufacturer's default keys, or one where every building that integrator has ever commissioned shares the same key set. The strong version is a key set unique to your site, ideally one your organization controls, so that a credential issued for your building is meaningful only at your building.
Related, and equally worth asking: is each card individually keyed — the industry term is diversified — so that a card's secret is derived per credential, rather than every card in the building holding the same one? A system where all cards share a single secret has concentrated its risk into that one value.
None of this is exotic. It is standard practice on current-generation credentials, and it is one of the main things the current generation exists to make possible. But it is configuration, not hardware, which means it can be skipped without anything looking different afterwards.
Why "we upgraded to 13.56" isn't an answer
Put the pieces together and the sentence collapses.
A building can be at 13.56 MHz on an early-generation credential its own manufacturer now treats as legacy. It can be on a current-generation credential that the readers are using as a plain serial number. It can be properly keyed and cryptographically sound at the card, and still have its readers configured to accept old credentials indefinitely because a migration was never closed out — the failure covered in the upgrade-trap article. And in every one of those cases, the honest answer to "what technology are you on?" is "13.56 MHz", because it is true in all of them.
It is also worth remembering that the credential is only the first link. The reader still has to tell a controller somewhere else in the building what it saw, and in a great many BC installations it does so over a legacy, unencrypted, unsupervised interface — which is its own subject. A strong credential read by a reader that shouts down a weak wire has moved the problem rather than solved it.
What to actually ask
Five questions, in writing, and you can send them to whoever maintains your system today:
- What exact credential technology and generation are our cards? Not the frequency. The family and the generation — and whether that generation is the manufacturer's current one or a superseded one.
- Are the readers authenticating to the secure application on the card, or reading the serial number? If it is the serial number, the security you paid for is switched off.
- Whose keys are in the system, and are the credentials individually keyed? Site-specific and diversified is the answer you want. "The default ones" is an answer you want to know about.
- Are the readers still configured to accept any older credential type? If yes, ask for the date that stops. A migration with no end date is a permanent state.
- What is the upgrade path from here — configuration, credentials, or readers? Often more of the existing hardware is capable than anyone assumes, and the answer is smaller than a rip-out. You will not find out unless someone looks.
An integrator who handles this work routinely will answer all five without hesitation. If the answer to any of them is the frequency, ask again.
The short version
13.56 MHz is a radio band. It describes how your card and reader make contact, not how well the conversation is protected, and it is equally true of credentials separated by two generations of cryptography. Inside that band are early-generation technologies the manufacturers themselves now class as legacy, and current-generation ones built on open, published cryptography — and even the current ones can be commissioned in a way that ignores their security entirely and treats the card as a number to be read aloud.
Which generation are you on, is it the current one, and are your readers actually using it? Those three questions are the whole subject. "We upgraded to 13.56" answers none of them.
