Mobile Access Credentials: Securing Phone Badges

When the employee badge moves into a phone wallet, opening a door depends on a corporate account, a consumer device and a provisioning service, so physical access inherits every weakness in that identity chain. Mobile access credentials remove the cloning problem of legacy cards when they are built on cryptographic credentials, but they add new questions: who can provision a badge, what happens when a phone is lost or an account is taken over, whether a locked phone should open a door, and how Bluetooth proximity can be relayed. This guide covers wallet employee badges, app-based NFC and Bluetooth Low Energy (BLE) credentials, the identity risks they create and the controls that close them. It is for physical security managers, identity and access management teams and mobile device administrators. Card replacement planning is covered in the Legacy Access Card Migration Guide and is not repeated here. Platforms are listed alphabetically; the order is not a ranking.

Key takeaways

The provisioning account is the new badge office. Whoever can sign in to the employer app that adds the badge can obtain a working credential, so that account needs phishing-resistant MFA and a hardened recovery process.
Convenience settings are security decisions. Express Mode and wake-to-use behaviour let a badge work without unlocking the phone; decide door by door whether that is acceptable.
Revocation must reach the phone and the panel. Lost Mode or a remote wipe protects the device, but the access control system must also suspend the credential and record the event.
BLE proximity can be relayed. Encryption does not stop a relay of a Bluetooth connection; require a user action or secure ranging for doors where passive unlock is a risk.
Join physical and logical identity. Feed badge issuance and revocation from the same joiner-mover-leaver process as directory accounts, and send PACS events to the SIEM alongside sign-in logs.

Mobile credential types

Mobile access credentials fall into three groups. The reader infrastructure and the provider ecosystem decide which ones a site can use.

Type	How it is presented	Where the credential lives	Identity dependency	Main risk to manage
Wallet employee badge (NFC)	Tap phone or watch on an NFC reader; may work without unlocking	Phone wallet, provisioned by the access control provider through the platform's wallet service	Employer app account plus the user's platform account	Provisioning account takeover; badge working on a locked device
Provider app credential (NFC)	Tap with the provider's app, often in the background	Provider app storage on the phone	Provider app account	App account recovery; app integrity on rooted or jailbroken devices
Provider app credential (BLE)	Phone near the reader, often with a gesture or automatically within range	Provider app storage on the phone	Provider app account	Relay of the Bluetooth connection; unintended unlock at range

Whichever type is used, the reader to panel link still matters. A mobile credential read correctly and then sent in plaintext over Wiegand leaves the wire as the weak point; pair mobile rollouts with OSDP Secure Channel. See the Physical Access Control Systems Security Guide.

Wallet employee badges by platform

Both major phone platforms support employee badges in their wallets through participating access control providers. The settings below come from each vendor's documentation as of November 2026. They are customer-side choices that the organisation and its users control.

Apple Wallet employee badge

Provisioning: the employee signs in to the employer's app with employee credentials and taps "Add to Apple Wallet". Apple's Platform Security Guide states that multifactor authentication must be enabled on the account the employee uses to add a badge. Adding the badge to an iPhone also adds it to the paired Apple Watch.
Express Mode: Apple's support article describes Express Mode as on by default; the badge works by holding the iPhone or Apple Watch near the reader. With Express Mode off, the user opens the badge in Wallet and authenticates with Face ID or Touch ID first.
Lost or stolen device: marking the device as lost disables Apple Wallet and temporarily removes cards and passes, including the badge; the device can also be erased at iCloud.com. After Lost Mode is turned off, the user re-enables the badge in Settings with the Apple Account password.
Availability: Apple lists iPhone 6s or later or Apple Watch Series 3 or later on the latest iOS or watchOS, a signed-in Apple Account and a participating employer and app.

Google Wallet corporate badge

Provisioning: the employee opens the employer's app or website, finds the badge and taps "Add to Google Wallet", confirming identity with the device screen lock or password. Google's developer documentation describes an Account Hub that manages the card lifecycle and the authentication keys used with readers. A badge can be on one phone and one watch at a time.
Unlock behaviour: Google's help article says the device only needs to be awake, not unlocked, to use a badge, and that users can require the device to be unlocked before an NFC transaction completes for extra security.
Lost or stolen device: the user locates, locks or erases the device with Android's device-finding tools, notifies the employer and re-enables the badge after recovery or on a new device. Removing a badge from a phone does not remove it from a paired watch.
Availability: Google lists Android 9 or later with NFC turned on, optionally Wear OS 2 or later, the Google Wallet app, the latest provider app and NFC readers that support the provider's protocol. Google notes that rooted devices, custom ROMs and modified factory software can prevent Wallet from adding a badge.

Settings to decide for either platform

Decision	Apple Wallet setting	Google Wallet setting	Recommended default
Use without unlocking	Express Mode on the badge	Wake-to-use, with the option to require unlock for NFC	Allow for general office doors; require unlock or add a PIN at restricted doors
Watch credential	Added with the paired Apple Watch	Added to a Wear OS watch from the phone	Permit only where watches are covered by the device policy
Lost device	Mark as lost or erase at iCloud.com	Lock or erase with Android device-finding tools	User action plus PACS suspension of the credential
Re-enable after recovery	Badge re-enabled with the Apple Account password	Badge re-enabled by the user, employer notified	Require a fresh check by the badge office for restricted-area holders

Identity risks and how to close them

A mobile badge turns a door credential into something issued over the internet to an account. The risks below are where physical and logical identity meet.

Risk	How it happens	Control	Framework reference
Provisioning account takeover	Phished or reused password on the employer app account lets an attacker add the badge to their own phone	Federate the provider app with corporate SSO and require phishing-resistant MFA; alert on new badge provisioning	NIST SP 800-53 IA-2; CSF 2.0 PR.AA-03
Help desk re-provisioning fraud	Caller claims a new phone and asks for the badge to be moved	Verified identity proofing for badge transfer, call-back to a known number, notification to the old device	NIST SP 800-53 IA-2
Lost or stolen phone	Badge works while the device is awake or locked, depending on settings	Require unlock at restricted doors; revoke in the PACS on report; measure revocation latency	NIST SP 800-53 AC-19, PE-2
Leaver keeps a working badge	Directory account disabled but PACS credential still valid	Drive badge revocation from the same HR leaver event as directory deprovisioning	NIST SP 800-53 PE-2; CSF 2.0 PR.AA-01
Compromised or modified device	Rooted or jailbroken phone, outdated OS	Device compliance checks in MDM for corporate devices; platform integrity checks block some modified devices	NIST SP 800-53 AC-19, IA-3
BLE relay	An attacker forwards the Bluetooth connection between the phone and a distant reader	Require a user action on the phone, disable passive unlock at sensitive doors, prefer secure ranging where readers support it	NIST SP 800-53 PE-3
Shared or generic credentials	Badges issued to role accounts or shared phones	Issue only to named people; treat shared kiosk or vehicle credentials as non-human identities with an owner	NIST SP 800-53 PE-2

The help desk is often the weakest point because moving a badge to a new phone looks like a routine request. See the Vishing and Help Desk Social Engineering Awareness Guide. For tying badge lifecycles to HR events see the Joiner-Mover-Leaver Guide.

Bluetooth readers and relay risk

BLE credentials allow touchless and longer-range entry, which is convenient for car parks and accessibility, but they rely on a Bluetooth connection as a proxy for presence. NCC Group's technical advisory of 15 May 2022 showed a link-layer relay attack against BLE proximity authentication systems, including commercial building access control, that adds only about 8 ms of latency and continues through encrypted connection parameter changes. The advisory states that neither link-layer encryption nor normal response-timing expectations defend against relay attacks.

Require user intent: NCC Group recommends user confirmation on the mobile device before unlocking. In practice that means a tap, a gesture in the app, or unlocking the phone, not walking into range.
Use secure ranging where available: the advisory recommends time-of-flight distance bounding such as Ultra-Wideband for proximity decisions.
Limit passive range by door: keep hands-free BLE for low-risk entrances and car park barriers; require NFC tap or a PIN at restricted areas.
Monitor: unlocks without a matching door open, or entries while the holder's other activity places them elsewhere, are relay indicators worth alerting on.

Background on Bluetooth and NFC as radio technologies is in the Bluetooth, RFID and NFC Security Guide.

Choosing a model for your organisation

Small office: a cloud access control service with wallet badges removes card printing. Turn on SSO and MFA for the provider app and decide the unlock rule for the server or comms room.
Corporate estate with bring-your-own devices: keep physical cards as a fallback for staff without suitable phones and for privacy objections; you cannot enforce MDM on personal phones, so lean on unlock requirements at sensitive doors and fast revocation.
Corporate-owned phones: enforce OS currency, passcode and compliance through MDM before allowing badge provisioning. See the Mobile Device Management Security Guide.
High-security and regulated sites: keep a second factor at restricted doors, and where PIV is required, assess derived credential options against federal guidance before treating a phone as equivalent to a card. See the Smart Card and PIV/CAC Authentication Guide.

How to implement

Confirm infrastructure: check that readers support the mobile protocol and wallet badges, firmware is current and reader links run OSDP Secure Channel.
Secure the provisioning path: federate the provider app with corporate SSO, require phishing-resistant MFA, and define who may issue, transfer and revoke badges.
Set door policy: classify doors and decide where unlock-free use (Express Mode or wake-to-use) is allowed and where an unlock, PIN or tap is required.
Connect lifecycle: drive badge issuance and revocation from HR events, and give the help desk a verified process for device changes.
Pilot: start with one site and a volunteer group with both card and phone, measure read reliability, low-battery behaviour and help desk volume.
Test negative cases: a revoked badge must be refused, a badge on a device in Lost Mode must stop working, and a leaver's badge must fail on the day they leave.
Roll back safely: keep physical cards active for pilot users until acceptance, and keep staffed entry for critical doors during cutover.
Expand and retire: roll out by site, then disable legacy card reading where mobile and secure cards have replaced it.

Detection and metrics

Send provisioning events from the access control provider and door events from the PACS to the SIEM, and correlate them with directory sign-ins.

Provisioning alerts: new badge provisioned, badge moved to a new device, or provisioning from an unusual location shortly after an MFA reset.
Revocation latency: median time from HR leaver event or lost-device report to credential suspension in the PACS (target same day, ideally minutes).
Orphaned credentials: active mobile badges with no matching active directory account (target zero). See the Orphaned and Dormant Accounts guide.
Restricted-door coverage: percentage of restricted doors requiring an unlock, PIN or tap rather than passive entry.
Provider account MFA coverage: percentage of badge holders whose provisioning account uses phishing-resistant MFA.
Help desk transfers: badge transfer requests per month and the share verified through the defined proofing process.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	PE-2 Physical Access Authorizations; PE-3 Physical Access Control	Who may hold a mobile badge and how doors enforce it
NIST SP 800-53 Rev. 5	AC-19 Access Control for Mobile Devices; IA-3 Device Identification and Authentication	Device requirements for phones carrying credentials
NIST SP 800-53 Rev. 5	IA-2 Identification and Authentication (Organizational Users)	MFA on the provisioning account
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.AA-06	Identity management, authentication and physical access managed commensurate with risk
ISO/IEC 27001:2022	A.7.2 Physical entry; A.8.1 User endpoint devices	Entry controls and protection of the phones that carry badges

Common failure patterns

Provider app on its own password: the account that issues badges is not federated with SSO and has weaker authentication than email.
One unlock rule for every door: unlock-free use is allowed at the data centre because it was the default at reception.
Device wiped, credential live: the user marks the phone lost but nobody suspends the credential in the PACS or records the event.
Badge transfer by phone call: the help desk moves a badge to a "new phone" without verified identity proofing.
Hands-free BLE on sensitive doors: passive range-based unlock at doors where a relay would be valuable.
Mobile over Wiegand: a cryptographic phone credential sent to the panel over an unencrypted reader link. See the Access Card Cloning guide for how legacy weaknesses persist alongside new credentials.

Practitioner checklist

Federate the provisioning app with corporate SSO and require phishing-resistant MFA.
Classify doors and set where unlock-free use is allowed and where unlock, PIN or tap is required.
Connect badge issuance and revocation to HR joiner and leaver events.
Define a verified help desk process for badge transfers to new devices.
Make lost-device reports trigger PACS suspension, not only device lock or wipe.
Require user action rather than passive BLE unlock at restricted doors.
Confirm readers run current firmware and OSDP Secure Channel to the panel.
Feed provisioning and door events to the SIEM and track revocation latency.
Keep a physical card option for staff without suitable phones.

Mobile Access Credentials: Securing Phone Badges and Their Identity Links