There is a question you can ask an integrator that will tell you more about the state of your access control than any product datasheet, and it takes eleven words:
"Are the credentials for this building on a diversified site key?"
Most owners have never heard the phrase. That is not a failure of the owner. It is a subject that lives inside the trade, gets settled during commissioning by someone holding a laptop, and never appears on a quote, in a contract or in a strata council package. The decision gets made either way. It is simply made without you.
This article is about what that decision is, why the convenient answer is the wrong one for a building owner, and the second question — the one about ownership — that nobody thinks to ask until it becomes expensive.
First: what the key actually is
Start with what changed when buildings moved off legacy proximity cards.
An old proximity credential holds a number and broadcasts it to anything that asks. No secret is involved, which is why that number behaves like a password written on the outside of the card — see the upgrade step buildings skip. It is the reason buildings move to encrypted smart card credentials in the first place.
A modern encrypted credential works differently. Instead of announcing a number, the card and the reader perform a short exchange in which each proves to the other that it holds a shared secret, and only if that exchange succeeds does the card release the data the system cares about. The credential is not shouting a password across the room; it is having a private conversation an eavesdropper cannot usefully join.
That shared secret is the key. In the access control trade it is usually called a site key — the key associated with a particular installation.
Worth saying early: the generation of credential technology in your building and the key management behind it are two separate questions, and a good answer to the first does not imply a good answer to the second. We take the first apart in a companion article on 13.56 MHz credentials. This one is about the second.
Everything the encryption buys you rests on one property of that key: it must be a secret belonging to your building and to nothing else. The mathematics is not the fragile part — in a current-generation credential it is genuinely strong. The fragile part is administrative. A strong lock fitted to every door on the street is not a strong lock. It is a strong key blank.
What "diversified" means
Diversified is the trade's word for a key that is unique to your site, rather than one shared across a manufacturer's or an installer's install base.
There are, broadly, three states a building can be in.
Default keys. The credential is issued on the key the product shipped with — the value that comes out of the box before anyone changes it. Every unit of that product line starts life this way. If nobody changed it, the "secret" your door depends on is shared with every other unmodified installation of the same product anywhere in the world.
A shared key. The credential is issued on a key unique to somebody — usually the integrator — but used across all of their customers. Your building, the office park down the highway and every other site that company has commissioned are operating on the same secret. Better than the default, and still not yours.
A diversified site key. The credential is issued on a key generated for your building and used nowhere else. Better implementations go a step further and derive a distinct key for each individual card from that site key, so that no two credentials in the building carry the same secret either. That is the state you want, and it is the state you have to ask for.
The distinction sounds academic until you translate it out of cryptography and into building management, where it is not academic at all.
Why this is the whole ball game
Here is the consequence, stated as plainly as we can.
If your building's credentials are issued on a shared or default key, then the trust relationship your access control system enforces is not "this card belongs to this building." It is "this card belongs to the population of buildings using this key." A credential issued for another site on the same key is not a foreign object to your reader. It is, as far as the cryptography is concerned, a legitimate member of the family.
The direction runs both ways, and the second is the one that should worry a property manager more. Cards issued for your building are also credentials in that wider population. Every card handed to a resident, a cleaner, a contractor or a temporary staff member is a piece of your building's security posture that has walked out the front door — and on a shared key, it is not only your building's posture it carries.
Note carefully what has and has not gone wrong here. Nothing is broken and no defect has been exploited. The credential is doing precisely what it was designed to do, the encryption is intact, and every component is working to specification. The system is answering the question it was configured to answer. It was configured to answer the wrong question.
That is why this belongs under governance rather than technology. There is no vulnerability to patch — only a decision, made on your behalf, that determines what your locks actually mean.
Why the convenient answer is the default
It is worth being fair to installers about how this happens, because understanding the incentive is what lets you counter it in a procurement conversation.
A shared key is genuinely easier to work with. Card stock is ordered in bulk and drawn from one pool for any customer. A technician arriving to add three readers does not need to retrieve site-specific material first, and a replacement for a lost fob can be encoded from whatever is in the van. Nothing has to be tracked, stored, escrowed or handed over.
Diversified keys impose real work in exchange. Each site needs its key generated, recorded, protected and made available to whoever encodes a card five years from now. Card orders become site-specific. Somebody has to own a process, and processes cost money that does not show up as a visible feature on a quote.
So the incentives point one way for the party doing the work and the other way for the party who owns the building. That is not a conspiracy — it is an ordinary misalignment, and it resolves in favour of whoever is paying attention. Historically that has not been the owner, because the owner did not know the decision existed.
It is the same pattern as the wire behind your reader, where a legacy protocol persists on new installations out of habit rather than merit. Defaults do not lose because something better exists. They lose when a buyer specifies against them.
The second question: who holds your key?
Now the part that almost nobody asks, and the reason this article exists.
Suppose you do everything right. You ask the question, your integrator confirms your building is on a diversified site key generated exclusively for you, and the answer is honest. Good. There is one question left:
Who holds it?
Because a key unique to your building that only your integrator possesses is not, in any practical sense, yours. It is a key to your property held by a company you have a commercial relationship with, and the security of that arrangement depends entirely on the relationship staying good.
Play the tape forward on the ordinary events in a building's life.
You want a second quote. A competing integrator can install readers, run cable and commission a panel. What they cannot do is issue a credential your existing readers will accept, because they do not hold the secret those readers check against. Your incumbent's pricing is now protected by cryptography rather than by being competitive. That is not a market. It is a moat, and you paid for the water.
Your integrator is acquired, folds, or the one technician who knew where the keys were kept retires. Key material living in one person's head, one laptop or one unbacked-up file does not survive corporate events, and what a building discovers when it goes missing is that reissuing credentials means re-keying the whole estate.
You have a dispute. Consider what your position looks like in a disagreement over an invoice with a counterparty who controls whether you can issue a fob to a new resident on Monday.
You sell the building, or the management contract changes hands. Whatever you cannot hand over is not part of what you sold. If nobody can produce the key material at closing, the buyer inherits a system nobody can administer — a diligence finding you would rather discover before the other side does.
None of these requires bad faith from anybody. They are what happens when custody of something essential was never written down. The uncomfortable summary: if you cannot say where your site key is held, who can access it, and how you would obtain it if your integrator stopped answering the phone, then a third party holds a controlling interest in your locks.
What to ask for, in writing
Five items. Put them in the specification, not in a conversation.
1. "Diversified site keys, unique to this site." Written into the scope of work. It needs to appear before commissioning, because changing it afterwards means reissuing credentials.
2. Confirmation as commissioned fact, not capability. "The system supports key diversification" and "this building runs on a site-specific key" are different statements, and the first is true of a great deal of hardware configured so the second is false. Ask for the state of the installed system, per site, attested in the handover documentation.
3. Escrow of the key material, with you as the owner. The key belongs to the building. Specify where it is held, in what form, who can access it, and what your route to it is. Deposit with the owner's records, a management company's controlled store or a formal escrow arrangement are all workable. "Our office keeps it" without a named process is not.
4. A defined handover on termination. Whatever the contract says about ending the relationship should say what happens to the key material when it ends. An integrator with no objection to that clause is telling you something useful. So is one who objects.
5. Card ordering that does not create a hostage. Establish whether credentials for your building can be obtained from more than one source, and by what process. If only one company on earth can sell you a working fob, that is a commercial fact about your building worth knowing before you need a fob.
An integrator who does this properly will find all five unremarkable — they will have a process already. Vagueness on item three is the tell.
What we can actually support
We are not going to tell you how any of this is defeated, quantify how common shared keys are in BC, or attach a number to anything. We cannot source those claims, and a security company producing statistics it cannot support is doing the same thing as one producing threats it cannot support.
Here is what we can support. The strength of an encrypted credential rests on a secret shared between the card and the reader, and whether that secret is unique to your building is a configuration decision rather than a property of the product. The industry's own documentation is direct about the underlying principle — HID Global, writing about legacy technology in its own catalogue, describes credential numbers as serving the same purpose as a password: secret values that identify a user to a system. Everything above is that idea taken one step forward. Passwords are only meaningful when they are not shared, and a key shared across an install base is a shared password with better mathematics behind it.
If your building has moved to modern credentials, the money is already spent and the hard part is already done. Two questions finish the job. Is the key ours alone, and where is it kept?
Ask them before you need the answer.
