Mobile access systems
Mobile access spans the phone, app or wallet, issuer, reader and access control platform. Include lost devices, replacement and account recovery in the design.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Architecture only; no vendor credential provisioning, radio capture/replay, wallet key, or product security claim.
On this page
Overview#
A mobile credential spans identity service, issuer/cloud, mobile OS/app/wallet, secure key storage, device/account recovery, radio presentation, reader/controller, and PACS authorisation. “Uses BLE/NFC/UWB” describes transport/ranging, not the credential security protocol.
Lifecycle#
identity + sponsor approval -> invitation/enrollment -> device/account binding
-> credential/key provisioning -> reader presentation/ranging
-> controller authorization -> renew/suspend/revoke -> device replacement/exit
Use a scoped opaque mobile credential ID and bind subject, device/application instance, issuer, tenant/site, assurance, validity, and key/version. Avoid exposing stable radio/device identifiers in PACS or analytics.
Presentation modes#
- NFC: intentional close presentation/card emulation; application/card security is separate from radio distance.
- BLE: advertisement/connection/GATT or vendor protocol; pairing isn't necessarily used or sufficient for access authentication.
- UWB: may provide more precise ranging, commonly combined with another discovery/credential channel; complete secure ranging and fallback design matters.
- QR/barcode/link: camera/optical presentation can be convenient but requires freshness, signature, audience/site scope, and screenshot/forwarding controls.
Bluetooth SIG adopted specifications and NFC Forum specifications are the authoritative technology roots. Verify exact core/profile/application/release and product qualification; a phone supporting a core version doesn't prove credential behaviour.
Security model#
- Generate/retain non exportable keys in secure platform storage where supported; bind tokens to app/device/reader/session and prevent bearer reuse.
- Authenticate issuer, reader/controller, and mobile client; protect against replay, relay, downgrade, rogue reader, cloned app, rooted/compromised device, account takeover, and notification link theft.
- Use short lived enrolment/recovery artefacts, out of band approval, and server/PACS reconciliation.
- Define online/offline validation, revocation latency, clock requirements, and stale credential behaviour.
- Avoid unlocking solely from RSSI or “phone nearby.” Separate authenticated credential, measured distance/uncertainty, user intent, and PACS policy.
Privacy and usability#
Radio scanning can track device presence. Rotate identifiers where supported, limit telemetry, don't use access scans for unrelated analytics, and explain permissions/background behaviour. Provide accessible alternatives for dead battery, device loss, OS incompatibility, no smartphone, shared devices, and emergency egress.
Reader and API integration#
ONVIF Profile D includes mobile access peripherals in its public scope, but vendor credential protocols and wallets often remain proprietary. Treat the issuer/cloud as a critical dependency and document data residency, support access, tenant exit, credential export/non portability, and reader firmware lifecycle.
Recovery and decommission#
Lost/replaced phone processes should revoke the old credential/device, invalidate pending invitations, re proof the claimant, issue a new binding, reconcile offline controllers/readers, and alert on later use. At tenant/service exit revoke signing/issuer trust, remove integrations/keys, export required lifecycle audit, and confirm deletion.