Mobile Access Control: Using Your Phone as a Key

How phone credentials actually work

The platform issues a cryptographic credential to the user's app after an invitation; the phone and reader mutually authenticate over Bluetooth Low Energy (tap or proximity) or NFC. Credentials sit behind the phone's own security — screen lock, biometrics, hardware keystores — and die instantly when revoked centrally or when the user wipes the phone. Readers installed in recent years frequently support BLE already; older installations may need reader swaps only, keeping controllers, wiring and locks.

Where mobile beats fobs — and where it doesn't

• Remote issue: a new starter or visitor gets a key by email before they arrive — transformative for multi-site and hybrid teams
• Revocation discipline: leavers' keys actually get cancelled because it's one click, not a returns chase
• No credential logistics: no fob stock, postage or replacement queue
• Costs: per-user licence fees on some platforms vs pennies-per-fob — model it at your headcount
• Phones die: flat batteries and forgotten phones argue for keeping a fob/PIN fallback path
• Not everyone has (or will use) a suitable phone: contractors, visitors, some staff — mixed-credential design is the realistic end state

Security and privacy questions, answered straight

A stolen unlocked phone is the real risk surface — mitigated by the app requiring device lock/biometric and by instant remote revocation, which together beat a lost fob's window of exposure. Cloning is not practical against properly implemented mobile credentials, unlike legacy fobs. Privacy: the access system logs the same door events it always did; reputable platforms don't track phone location — worth stating plainly to staff during rollout, alongside the genuine alternative (fob) for anyone declining to use a personal device.