Employee badge in Apple Wallet: what your building needs to support it

Somebody on your staff has seen it — a friend at another company holds a phone to a reader and walks through — and they arrive at your desk with a reasonable question: why does our building not do that?

The answer that usually comes back is not reasonable. It is either a vague "we're looking into it" or a flat "our system doesn't support that", and neither tells anyone anything they can act on.

Here is the honest version. A badge living in the phone's own wallet, rather than in a separate app you have to open, is not a feature anybody switches on. It is the end of a chain. The access control platform has to support it. The credential technology has to support it. The readers on the wall have to support it — and that link is the expensive one. Behind all of it sits a commercial arrangement between your credential vendor and the phone maker that your building neither controls nor can shortcut.

If any single link in that chain is missing, the answer is no. Not "no, but we can configure it" — no.

The most useful thing here is not the explanation. It is the short list of things to put in writing the next time your readers are replaced, so that you do not pay to replace them twice.

The distinction that causes most of the confusion

There are two different things people call "opening the door with your phone", and they are not the same product.

The first is a vendor app. You install the access control company's own application, log in, and it holds your credential — usually talking to the reader over Bluetooth. You may have to open the app, or wake the phone, or press something.

The second is a wallet credential — the badge sits in the phone's built-in wallet alongside payment cards and transit passes, in the operating system rather than in a third-party app. This is the one your staff have seen, and its appeal is entirely the moment of use: you hold the phone near the reader and it works, without unlocking, without opening anything.

What makes the second desirable is also what makes it hard. Being inside the wallet means being inside a part of the phone the phone maker controls tightly, on terms the phone maker sets. A vendor app is software your integrator can ship. A wallet credential is not.

So when a vendor says the system "supports mobile credentials", you have learned nothing. Ask which of the two they mean — a great many systems support the first and not the second, and the sentence covers both.

The chain, one link at a time

Link one: the access control platform

The platform is the head end — the software and controllers holding the list of who may go through which door at what hour, and issuing and revoking credentials.

For a wallet badge to work, the platform has to issue a credential into a phone wallet and revoke it again, and handle the surrounding administration: enrolment, a lost phone, a departure at four in the afternoon. That is a real feature with machinery behind it, not a checkbox.

Some platforms have this. Some are working on it. Some never will, because the product is at the end of its life and the manufacturer is investing elsewhere.

We are not going to tell you which is which, and you should treat any article that does with mild suspicion — that list changes with every release, and the version running in your building may be several releases behind whatever a marketing page describes. Get it from your platform vendor in writing, naming your installed version. "Our platform supports it" and "the version you are running supports it" are different sentences, and only the second is about your building.

Link two: the credential technology

Underneath the wallet is a credential — a piece of secured data identifying a person. Wallet-based employee badges are built on the modern encrypted credential technologies, not on the legacy proximity credentials a great many BC buildings still run.

Which means the wallet question is often not a wallet question at all. If your building is still on legacy proximity cards, you are not one step away from phones in wallets — you are one whole credential migration away from being in the conversation, and that migration has its own trap. We covered it in the access-card upgrade step most buildings skip.

So the honest sequencing for most older buildings is: credentials first, wallet later. And the credential migration delivers a real security improvement on its own, whether or not the phone thing ever happens.

Link three: the readers — this is the expensive one

Here is where the conversation usually ends, and where the money is.

The reader on your wall is a sensor. It reads a credential and passes the result down a wire to a controller elsewhere in the building, which is the thing that decides. For a wallet credential, that sensor must carry out the specific secured exchange the phone expects — a hardware and firmware capability, designed into a product line at manufacture.

Which leads to the sentence most owners are not told: for most existing readers, supporting a phone wallet badge means replacing the reader, not updating it. Some product families offer a field-upgradable module or a firmware path. Many do not, and no amount of goodwill from your integrator changes a reader that does not have the necessary hardware inside it.

Replacing readers is not a software project. It is a per-door physical job: a technician, a ladder or a lift, the existing back box and mounting, possibly different power requirements, re-termination, and commissioning. Multiply by every door where someone might reasonably expect to use a phone — lobby, parkade, elevator, floor entries, amenity rooms — and you have a capital project with a cable schedule, not a change request.

We are not going to attach a number to that, because it depends on your door count and your building. But the shape of it is: this is the link that turns a nice idea into a budget line.

Link four: the commercial arrangement

The last link is the one nobody mentions in a quote, and it is why this cannot simply be engineered around.

Putting a credential inside a phone's built-in wallet requires a commercial and technical arrangement between the credential or platform vendor and the phone maker. It is a programme with participation requirements, entered into by the vendor, not by your building. Your integrator cannot join it on your behalf and neither can you.

Three consequences follow. Your options are limited to vendors actually in the programme. There may be ongoing per-user licensing on mobile credentials, separate from what you paid for hardware. And the arrangement can change on a timetable that has nothing to do with your building.

We are not going to state the terms, the fees, or the requirements, because we cannot source them and they are not ours to describe. Ask your platform vendor to state in writing what the ongoing per-user cost is, what happens to those credentials if you change platforms, and whether anything about the arrangement is time-limited. A vendor who will put that in an email is a vendor worth dealing with.

Why new readers can still mean years away

This surprises people most, and it is worth saying plainly, because it is nobody's fault.

A building that replaced its readers three years ago bought readers meeting the specification written at the time — which was almost certainly about credential technology and wiring, because that is what a competent specifier cared about then. The readers do exactly what they were bought to do. Nothing is broken.

But readers are a long-lived asset, and nobody replaces working ones across an entire building because a phone feature exists. So the practical timeline is not "when the vendor ships it" — it is "at the next reader replacement cycle", which may be a decade out, or whenever a renovation opens the walls a floor at a time. That is also why buildings end up with a partial answer: the new tower on the campus has it, the two older buildings do not, and everyone gets a different explanation.

Note too that the links move independently. Your platform vendor may ship support next year while your readers stay incapable for eight more, and the reverse happens too. Both halves have to land, and nothing coordinates them for you.

What to specify today so you do not buy twice

You do not need to decide today whether you want phones in wallets. You need to make sure that the next time you spend money on readers, you do not foreclose it — because reader replacement is the expensive link, and doing it twice is the avoidable failure.

Whenever readers are quoted, replaced, or specified for a new build, ask for these in writing:

1. The exact model numbers being installed, and a written statement of what each supports. Not "mobile ready" — that phrase means nothing and is used to mean everything. Ask specifically: does this model support a credential held in the phone's built-in wallet, a vendor-app credential over Bluetooth, or neither? Get it per model, on paper, from the party quoting it.

2. Whether the wallet capability is in the hardware or requires a future module. If it needs a module, ask what it costs, whether it is available now, and whether fitting it means taking the reader off the wall. A capability requiring a truck roll to every door is not much better than a replacement.

3. Modern encrypted credential technology, with legacy support disabled at the end of migration. Worth doing on its own merits, and a precondition for everything discussed here.

4. The reader-to-controller protocol specified properly. If you are opening the walls anyway, specify the supervised, encrypted, two-way protocol on that wire rather than the legacy default, so that a future reader change is a reader change and not a rewiring job. We covered why that wire matters in the wire between your card reader and the door.

5. Written confirmation from the platform vendor about your installed version. Whether wallet issuance is supported today, and if not, what the position is — understanding that a roadmap is not a commitment and should not be paid for as one.

6. What happens to mobile credentials if you leave. Per-user licensing, term, and what your staff hold if you change vendors.

An integrator who works with this regularly will answer all six without difficulty. One who becomes vague on the first two is telling you something useful.

The short version

When your staff ask why the building does not put their badge in their phone, the true answer is not "our system doesn't do that". It is: this needs four separate things to be true at once — the platform, the credential, the readers and a commercial arrangement none of us control — and in this building, these are the ones that are not.

That is a better answer, because it is checkable, and because it points at the moment when it becomes decidable. Which is the next time somebody is standing in front of your doors with a drill.

For the wider question of whether mobile credentials are right for your site at all, including the reasons to decide against them, see the tradeoffs of mobile credentials.