When revoking smart lock access doesn't actually revoke it

Every estate I've looked at has the same quiet problem, and it isn't the perimeter. It's the guest list. A big property runs on a rotating cast of people who need to get in once, or weekly, or for a season: staff, trades, property managers, house sitters. Physical keys made that painful enough that people paid attention to it. Smart locks made it frictionless, and frictionless things stop getting audited. So the interesting question isn't whether the lock is hard to pick. It's whether the access you took away is actually gone.

In August 2025, six researchers from UC San Diego, Chengsong Diao, Danielle Dang, Sierra Lira, Angela Tsai, Miro Haller, and Nadia Heninger, presented a paper at the USENIX WOOT Conference on Offensive Technologies that answers that question for one specific product, and the answer is uncomfortable. They reverse-engineered the Master Lock Bluetooth Deadbolt D1000 and its companion app, reconstructed the proprietary Bluetooth protocol, and found five distinct vulnerabilities. The one that matters most for a household isn't the flashiest. It's the boring one about revocation.

The revoke button and the door disagreed

Here is the mechanism, in plain terms. When you give someone temporary access, the system issues their phone an access profile, a credential with an expiration date baked into it. The lock trusts that credential. When you later revoke that person's access, the revocation happens on the app and server side: their copy of the official Master Lock app stops letting them open the door.

The lock never hears about it. In the researchers' words, "Revocations only happen at the application layer," and "on the underlying protocol layer, the access profile remains valid until its original expiration date." A guest who extracted their own credential while they legitimately had it, and who could talk to the lock directly instead of through the app, could keep opening the door. The paper states the consequence flatly: "in practice, it takes up to nine months for a revocation to take effect."

Nine months, because that was the validity period stamped into those profiles. Not a hacking feat at the moment of entry. A credential that outlived the relationship, and an owner who had every reason to believe otherwise because the interface told them so.

The other four, briefly

The rest of the findings sketch the same shape. Sessions could be replayed: because the lock reused the same key and starting nonce, a recorded Bluetooth exchange could be played back to unlock the door without any valid account at all. The lock's clock turned out to be security-critical and writable: a guest could send the time-sync command directly and set the clock backward to outlive their own expiration, or forward to expire everyone else's. Audit events could be forged, and genuine ones blocked from reaching the telemetry server, by an adversary who knew only the lock's Bluetooth identifier. And malformed Bluetooth messages could leak or corrupt memory and leave the lock unresponsive until a reboot, a flaw Master Lock later confirmed as a buffer overflow.

Read those together and notice what they have in common. Not one of them is a lockpick. Every one is a protocol problem: the lock trusting something it shouldn't, or failing to be told something it needed to know.

Encryption is not access control

This is the part I'd underline for anyone specifying a system. Master Lock's own marketing described the product as using "military-grade authentication and encryption mechanisms built upon proven, NIST recommended and FIPS approved algorithms to deter sniffing, replay and manipulation attempts." That claim is not a lie about the algorithms. AES is AES. The researchers still replayed a session and opened the door, because the flaw was in how the algorithm was used, not in the algorithm. The paper's conclusion is the sentence worth taping to a wall: "The presence of encryption in the BLE communication does not suffice to create a secure protocol."

I spent my Army career as an electronic-warfare and counter-IED officer, and this is the most familiar failure mode in the business. A radio that is encrypted is not a radio that is secure. Encryption protects the contents of a message. It says nothing about whether the right person sent it, whether you've heard it before, or whether the thing acting on it has any idea what's happened since. We lost more ground to replay, to bad key handling, and to systems that trusted a stale credential than we ever lost to anyone breaking the math. Nobody breaks the math. They walk around it.

A revoked guest replaying a valid credential is the residential version of exactly that, and it's why "military-grade encryption" on a spec sheet should read to you as a non-answer. The questions that determine whether a lock is safe are duller: how quickly does a revocation reach the hardware, what happens when the lock is offline, can the device tell a fresh message from a recorded one, and can it lie to you about its own logs.

To Master Lock's credit

The disclosure went the way disclosure is supposed to go, and the report is incomplete without this. The researchers reported their findings on March 10, 2025. The security team at Fortune Brands Connected Products, the company that owns Master Lock along with Yale and August, responded on March 14 and met with them in depth, acknowledged the findings, and explained the origin of the issues.

That explanation is genuinely interesting. The nine-month window was not the normal design. Master Lock profiles usually last a week. The D1000 was an exception because of an earlier firmware bug that made the lock's real-time clock jump forward, which was locking legitimate users out; stretching the validity period was the workaround. The clock bug was already fixed in the firmware the researchers tested. The company planned to push firmware updates more aggressively and then bring the validity period back down to seven days, with remediation expected to complete by June 2025.

So the specific hole is closed, and I'm not writing this to tell you to throw out a deadbolt. The researchers are careful here too: they note the attack still applies, the window is just much shorter. That's the honest state of it.

Why the pattern outlives the patch

What doesn't get patched is the design pressure that created the bug. Look at the chain. A clock drifts. Users get locked out. The fix that ships is a longer credential lifetime, because a lockout is a support call and a stale credential is invisible. Nobody chose to weaken revocation. Revocation got weakened as a side effect of making the product less annoying, and it stayed that way because nothing in the interface ever showed the gap.

That trade shows up everywhere in connected access control, and it will show up again in the next product, because the underlying tension is real: a lock that must work when the internet is down cannot verify everything in real time. Offline capability and instant revocation genuinely pull against each other. The researchers' proposed fix reflects that, and it's the right instinct, authenticate the time updates themselves with the lock's own key so the clock can't be tampered with while still allowing offline operation.

Two facts of scale are worth holding alongside this. The global smart lock market was estimated at $2.8 billion in 2024. And a prior study found that smart locks were the second most common smart device in Airbnb rentals, an environment built entirely on granting and revoking access to strangers. The failure mode described here is aimed squarely at the way these products are actually used.

What to do with this

The practical takeaway is not a product recommendation, it's a change in what you ask. Treat every credential as something with a lifetime you should know, and ask your integrator to tell you what it is: when access is revoked, how long until the lock itself stops honoring the old credential, and does that answer change when the lock is offline. If nobody can answer that, that number is your real exposure window, and you're carrying it whether or not anyone has measured it.

Then stop asking the lock to be the whole system. A door that opens is an event, and an event can be corroborated. If the deadbolt reports an entry at 2 a.m. and nothing else in the house saw a car, a gate, a phone, or a person, that disagreement is the alarm, and it fires whether the credential was cryptographically perfect or nine months stale. That's the same layered logic underneath my reports on why integration beats gear and how crews case a house before entry. Note too that this attack leaves a clean log by design, since forged audit entries were one of the five findings. A lock that can rewrite its own history is not a witness, and you should not treat its logs as evidence without something independent agreeing.

This layered, cross-checking approach is the work I actually do: I help design the AI security systems for a veteran-owned (SDVOSB) luxury home-security company run by fellow veterans. (Disclosure: I don't own that company and earn nothing from this link; I flag it because it's a field I build in, not just write about. Nothing here is sponsored. Full policy here.)

The signal

The most valuable thing in this paper isn't a vulnerability in one deadbolt, which is patched. It's the demonstration that a security control can be entirely real in the interface and entirely absent in the hardware, with nothing on screen to tell you which one you're looking at. You pressed revoke. The app agreed. The door didn't. Ask what your locks do at the protocol layer, not what the app says they did, because the app is not the thing standing between your house and the person you fired.