One badge across access systems from different manufacturers

The usual reaction to 1 badge across several access control systems is that it can't be done. It's a fair reaction.

Here is exactly what has to be true for it to work.

Start with the identity model

A badge is always issued against something. In a single access control system, that's a cardholder record. It exists inside that system and means nothing outside it.

For 1 badge to work across systems, it has to be issued against an identity that sits above all of them. That means 1 record per person, holding eligibility instead of access rights. Rights look different in each system. Eligibility looks the same everywhere.

This is the part you can't skip. The rest is plumbing.

Then the integrations

Each access control system has to be told the result, and each has its own way of listening. Some offer an application programming interface, some a software development kit, some both.

2 rules matter. First, we only use the manufacturer's own published interface. Undocumented shortcuts break at the next software release, and the customer ends up carrying that risk.

Second, adding a site with a different system should be configuration work. If every site needs its own integration project, you rebuild the fragmentation you set out to remove.

7 systems are integrated today, as working integrations, not certified ones. They include Nedap AEOS, Genetec Synergis, LenelS2 OnGuard and primion GET.

Then the credential specification

This is where projects usually get stuck, and technology isn't the reason.

MIFARE DESFire isn't 1 fixed thing. It is an application identifier, a file structure, a data format and a key. 2 sites can both run DESFire and still be incompatible, because they made different choices at installation and nobody wrote them down.

1 badge means agreeing those 4 choices once, for the whole organisation, and keeping them as a written specification. It is a decision you make. You can't buy it.

Then the keys

The keys that protect the badge have to live somewhere. Our preferred setup is a secure module, hardware or virtual, under the customer's control or escrowed to them. No key ever reaches a reader.

Encoding then happens in an authorised session that carries no key. It can run at a desk encoder, a self-service terminal, an edge controller or the module itself. Each site picks what suits it.

Where some readers still hold keys the classic way, both models run side by side. That is normal, and you don't need to sort it out before you start.

What changes

1 badge, phone credential or wallet pass works at every site in scope, whatever brand of access control each site runs.

Revocation becomes 1 action across all of them. Issuing becomes 1 process. You count your people once.

A site you acquire next year is added by configuration. That is what lets a programme actually finish.

Want the list of systems we integrate with, and how each one connects? Ask us for the software datasheet. Take the scorecard Talk to us