Why BLE Unlocks Your Door When Your Phone Has No Signal

Bluetooth phone-as-key unlocking a door without needing cellular or Wi-Fi connectivity

You park in a concrete garage, 3 floors underground. Zero bars. You tap your phone to the car door and it opens anyway. No cloud. No cell tower. No Wi-Fi. Whatever just happened, happened entirely in the 10 centimeters of air between your pocket and the door handle.

If you’re a PM evaluating BLE for a phone-key, smart lock, or digital car key product, this is the question stakeholders keep asking: what happens when the phone is offline? Or the lock? Or both? The short answer: BLE offline authentication works fine, because the cloud was never in the critical path to begin with. The longer answer, which is what you need for a roadmap review, is below.

What “Offline” Actually Means in BLE Access

BLE offline authentication is a local cryptographic handshake between a phone and a lock (or car, or reader) that proves the user holds a valid, signed credential, without either side contacting a server during the unlock.

There are 3 connectivity states worth separating:

Phone online, lock offline (most common; think door locks with no network drop).
Phone offline, lock online (underground garage, connected reader).
Both offline (rare but real: basement storage, remote gates).

All 3 work the same way at the moment of unlock. The radio exchange is local; the cloud sits off to the side.

 [ Cloud ]  <-- enrollment, revocation, audit (async)
    |
    |  (not needed at unlock time)
    v
 [ Phone ] <======BLE======> [ Lock ]
              credential
              challenge
              response
              unlock

A physical house key doesn’t phone home when you turn it. A BLE credential works the same way, with trust established earlier.

The Pre-Provisioning Step: When the Internet Matters

Before any offline unlock can happen, someone has to establish trust. This is enrollment, and it’s the only step that genuinely needs connectivity.

At enrollment, the cloud issues a signed credential to the phone. Think of it as a notarized letter: a certificate or token signed by an issuer whose public key the lock already trusts. That root key was burned into the lock at manufacture, or provisioned once during installation.

Where the private keys live matters a lot:

On the phone: Secure Enclave (iOS) or StrongBox-backed Keystore (Android). The private key is generated on-device and never leaves it.
On the lock: a Secure Element or equivalent hardware root of trust, holding the issuer’s public key and the lock’s own keypair.

+-------------------+        +-------------------+
|   Phone           |        |   Lock            |
|  [Secure Enclave] |        |  [Secure Element] |
|   privkey_user    |        |   root_pubkey     |
+-------------------+        +-------------------+

Once enrollment finishes, the phone is autonomous. It can unlock without ever calling home again, until its credential expires or gets revoked.

The Offline Unlock Handshake, Step by Step

Here’s what happens in the 200 milliseconds between “I walk up” and “the door opens.” No server is contacted. All crypto runs on-device.

Phone                          Lock
  |-------- advertise -------->|
  |<------- connect -----------|
  |-------- credential ------->|
  |                            | verify signature
  |<------- nonce (random) ----|
  |                            |
  | sign(nonce, privkey)       |
  |-------- signed nonce ----->|
  |                            | verify -> UNLOCK

Discovery. The phone advertises, or the lock scans, depending on the design. Some systems flip roles based on battery constraints (locks usually want to sleep). If you want to go deeper on what’s inside those advertising packets, the BLE advertising packet structure is a good reference.
GATT connection. A standard BLE connection is established. This is the pipe for the rest of the exchange.
Credential presentation. The phone sends its signed credential to the lock. This includes the user’s public key and metadata (validity window, permissions, etc.), all signed by the issuer.
Signature verification. The lock checks that signature against the issuer’s public key it already holds. A valid signature on an unexpired credential proves it was legitimately issued, but not that the phone actually holds the matching private key. Someone could have copied the credential blob.
Challenge. The lock generates a random nonce, a one-time number, and sends it to the phone.
Response. The phone signs the nonce with the private key stored in its Secure Enclave. Only the real key-holder can produce this signature.
Verification and unlock. The lock verifies the signed nonce using the public key from the credential. Match? Unlock.

The nonce is the anti-replay mechanism. Record the whole exchange and play it back tomorrow, the nonce is different, the signature is invalid, the door stays shut.

Why the Cloud Still Matters (Just Not Right Now)

“Offline” doesn’t mean “cloudless.” The cloud isn’t in the critical path; it’s in the lifecycle path.

Specifically, the cloud handles:

Enrollment and credential issuance (required online).
Revocation lists, synced opportunistically when either side comes online.
Audit logs, uploaded when the lock or phone regains connectivity.
Time sync, which matters for credential expiration and grace windows.

This is eventual consistency, a pattern most PMs already know from distributed systems. A fired employee’s phone might still unlock the door for 15 minutes after HR revokes access, until the next sync. Whether that’s acceptable depends entirely on your threat model, which is a product decision, not a technical one.

Security Trade-offs PMs Must Understand

Offline auth isn’t weaker than online auth by default, but its failure modes are different. The risks are well-understood and each has a standard mitigation.

Risk	What It Is	Standard Mitigation
Replay	Attacker records an exchange and replays it	Fresh random nonce per session
Relay	Attacker forwards BLE signals over long distance to fool a lock	UWB ranging, RSSI bounds, round-trip timing checks
Revocation lag	Revoked credential still works until sync	Short credential TTLs, opportunistic sync, push channels
Clock drift	Expired creds accepted or valid ones rejected	Hardware-backed time, grace windows, server-signed time updates
Key extraction	Attacker pulls private keys off the phone	Secure Enclave / StrongBox with attestation

The relay attack is the one that keeps getting published. NCC Group’s 2022 work on Tesla’s BLE key is the canonical example: an attacker near the owner’s phone forwards the BLE traffic to an accomplice standing at the car. From both sides’ view, it’s a legitimate handshake, and it succeeds. Defense is about proving physical proximity, which pure BLE can’t do well. That’s why CCC Digital Key Release 3 adds UWB ranging on top of BLE for automotive. For fixed installations, tight RSSI thresholds and timing bounds help but aren’t bulletproof.

Two standards worth knowing when you’re talking to vendors:

Car Connectivity Consortium (CCC) Digital Key for automotive. Apple Wallet Car Key and Google’s digital car key both implement this.
Aliro Alliance for home and commercial access, backed by Apple, Google, Samsung, and major lock vendors. Still emerging, but it’s where the space is heading.

If a vendor can’t tell you which standard they align with, or which primitives they use for relay defense, that’s a signal.

A BLE Access Control Evaluation Checklist

When you sit down with a BLE phone-key or bluetooth digital key vendor, these are the questions that separate serious implementations from homebrew:

Key storage. Where do private keys live on the phone (Secure Enclave / StrongBox) and on the lock (Secure Element)? Is there hardware attestation?
Credential lifecycle. What’s the default TTL? How is revocation propagated? What’s the worst-case window between revocation and enforcement?
Relay defenses. UWB ranging? RSSI thresholds? Round-trip timing? “None” is an answer you should push back on.
Standards alignment. CCC, Aliro, or a proprietary scheme? If proprietary, what’s the threat model doc?
Offline audit. How many unlock events can the lock store while offline? How are logs uploaded and authenticated?
Enrollment UX. What happens if the user is offline during enrollment? Is there a fallback?
Failure modes. What happens when the credential expires and the phone is offline? Is there a grace window, or does the user get locked out?

Most of these have reasonable answers. The red flag is a vendor who hasn’t thought about them.

The Three Questions That Actually Decide Your Vendor

BLE unlocks your door with no signal because trust was established ahead of time and the unlock itself is a local cryptographic conversation. The cloud manages the credential lifecycle; it doesn’t gate the door.

For product evaluation, the question stops being “does it work offline?” (it does) and becomes “how does the vendor handle the offline trade-offs?” Revocation lag, relay attacks, and key storage are the 3 that actually matter. Get answers on those and you’ll know whether you’re looking at a serious product or a demo.

For the next layer down, the relay attack surface is worth its own read, especially if you’re in automotive or high-value commercial access. That’s where BLE alone runs out of room and UWB starts earning its keep.

Hubble Network provides global BLE connectivity for devices in the field, so credential updates and revocations reach locks even when local gateways fail. See how it works →