By an invitation - usually an email or a code - that the user redeems in the credential application, which then provisions the credential over the network.

The administrator creates the person in the access system and assigns a mobile credential. The invitation goes to the address on their record.

The user installs the application, redeems the invitation, and the credential is bound to that device.

Binding matters: a well-designed system ties the credential to one device so it cannot simply be copied to a second phone.

Bulk invitation is essential on any population of size, and directory integration makes it automatic for joiners.

Plan for the tail: people who do not redeem, whose email is wrong, or whose device will not run the application. Someone has to chase these, and a card is the fallback.

The old credential is revoked and a new one is issued to the new device - which is one entry in the management platform rather than a trip to reception.

Device changes are frequent, so this needs to be a self-service or helpdesk routine rather than a project.

Because the credential is bound to a device, moving to a new phone requires reissuing rather than restoring from a backup.

A lost phone should be treated like a lost card: revoke first, replace second. The handset's own passcode or biometric provides a useful additional barrier meanwhile.

A user without their phone for a day needs a temporary card, which is another reason to keep a managed pool.

Check whether the licence allows reissuing to a new device without consuming another seat. Vendors differ.

A recurring per-user subscription instead of a unit price - and on high-turnover populations it usually costs less in total once labour is counted.

The card comparison is not the price of a card. It is the card, the printing consumables, the printer, the replacement rate and the administrative time each issuance and replacement takes.

Mobile removes almost all of that and replaces it with a predictable annual fee.

On a stable population with low turnover and a long card life, cards can still be cheaper over five years.

Multi-year licence terms usually reduce the annual rate materially, so ask.

Model both over the expected system life including labour, and confirm what happens to issued credentials if the subscription lapses.

That is a policy and, in several jurisdictions, a legal question - so settle it before the project is announced rather than after.

Installing an employer's application on a personal device raises reasonable objections about privacy, storage, battery and data.

In some territories this requires consultation with employee representatives, and in others it cannot be made a condition of employment at all.

Be able to answer plainly what the application can see, what it sends, and what happens to it when the person leaves.

Always offer a genuine alternative. A card for anyone who declines removes the objection entirely and costs very little.

Corporate-owned devices avoid the issue and simplify version management, which is one reason mobile credentials are adopted fastest where the organisation already supplies phones.

Generally not - and that is the practical failure mode a card fallback exists for.

The credential needs the handset powered to present itself. A phone with no charge opens no doors.

Some handsets retain a reserve mode for contactless transactions for a period after shutdown, but this is platform-dependent and should not be relied on as a design feature.

The everyday answer is a card in the wallet for the small number of people who need guaranteed access.

It also argues for not putting mobile-only doors on critical routes - a plant room or a server room reached only by phone is a bad day waiting to happen.

Where a site is going mobile-first, keep a small pool of pre-enrolled temporary cards at reception and log their issue.

Centrally, in the management platform, and the change should reach both the vendor's service and the controllers.

Revocation is the strongest argument for mobile credentials: no recovery, no waiting, no chasing.

Ask exactly where enforcement happens. Removing the credential from the handset relies on the phone connecting; disabling the identity at the controller does not.

The robust arrangement does both, so an offline handset presenting an old credential is still refused at the door.

Directory integration makes revocation automatic on the day someone leaves, which is the highest-value integration on the whole system.

Test it: revoke a credential, put the phone in flight mode, and try the door.

Existing credentials keep working at the door; what stops is issuing and, in some products, revoking.

The credential is held on the handset and the decision is taken by the controller, so neither needs the vendor's service at the moment somebody enters.

Provisioning a new credential does need it, so an outage during onboarding is disruptive rather than dangerous.

Where revocation depends on reaching the handset, an outage delays it - which is another reason to prefer enforcement at the controller.

Ask for the service's availability commitment and its status history rather than accepting a general assurance.

Keep the card fallback path working. It is the answer to every question of this shape.