Smart locks draw attention from security researchers because a lock on the internet is a more useful target than a deadbolt. Most real incidents, though, trace back to a short list of well-understood failure classes, and each one has a fix somewhere in the hardware, the configuration, or day-to-day operation. The point of reading the list is not to fixate on any single item but to check which ones apply to a door you actually run. No lock is unbreakable; the aim is to close the failures that matter and accept what is left for whatever is behind the door.
Replay and relay attacks
A replay attack records a legitimate unlock signal and sends it again. A relay attack is sneakier: it holds a live radio connection open in real time, so an attacker standing near the lock forwards the signal from a phone that is genuinely somewhere else. Relay attacks against Bluetooth and passive keyless systems have been shown against cars and a few locks.
Decent hardware pushes back on both. Encrypted, challenge-response communication means a captured signal cannot just be replayed — each session uses a fresh nonce, so an old recording is useless. Proximity checks and timeout windows narrow the window for relay, and some platforms add distance bounding or make the phone confirm the action locally. Because authorisation happens on the device, breaking the radio link does not hand anyone control of the door.
Leftover credentials
The most common real breach is not a hack. It is a credential that should not work anymore — a passcode given to a cleaner who left, a card that walked out with a tenant, a phone that was lost and never reported. These linger because in the era of physical keys, nobody bothered to rekey the building either.
The fix has to be structural, because depending on people to remember does not scale. Credentials that are revocable and time-limited expire on a schedule rather than when somebody recalls. Per-person credentials — never a shared code — mean there is always a name against each entry. And loss or departure triggers revocation as a routine step, not an exception. The habits that keep this tidy are written up in our access control security best practices.
Accounts, clouds, and weak codes
If the radio and the credential are sound, the next thing to go after is the account that controls them. A reused password on the admin account, a cloud platform with no rate limiting, or a default master code left in place — any one of these undoes hardware that is otherwise solid.
Strong, unique admin passwords and two-factor authentication close the common account-compromise path. Every lock ships with a default code, and changing it is the first thing to do at setup, not an optional one. User passcodes should be long and random — not 1234, not a birthday. The platform itself should offer audited authentication and transport encryption, meaning TLS end to end, including the hop between gateway and cloud.
Physical attacks
A smart lock is still a lock. A cheap lock body with a short-throw bolt can be beaten the old way — prying, picking, or plain force. Digital sophistication does not make up for a weak bolt.
Pick hardware with a properly thrown, long bolt and a solid body rated for the door type. Fit tamper and forced-entry sensors so a physical attempt is detected and reported instead of staying silent. Adding a door sensor means an opening without a valid credential raises an alarm. On high-security doors, look at an electromagnetic lock driven by an access controller that resists forced entry.
Firmware updates
The vulnerability that gets fixed least often is the one nobody can see. Smart locks run firmware, and firmware has bugs, including security bugs that later releases patch. A lock that has not been updated since install is running every flaw its manufacturer has already fixed.
Apply firmware updates when they arrive, the security ones especially. Keep gateways current, since the gateway is the bridge to the internet and a frequent patch target. Prefer platforms with a credible update record — a lock that never gets patches turns into a long-term liability. Why cloud-connected and offline layouts expose different surfaces is worth understanding; see offline vs cloud access control.
The classes, at a glance
| Failure class | How it happens | What closes it |
|---|---|---|
| Replay attack | Captured signal is resent | Encrypted challenge-response comms with fresh nonces |
| Relay attack | Live radio link extended remotely | Proximity checks, timeouts, on-device authorisation |
| Lost / shared credential | Stale code or card lingers | Revocable, time-limited, per-person credentials |
| Account compromise | Reused password, no 2FA | Strong unique passwords, 2FA, no default codes |
| Short or default code | Guessable user passcode | Long random codes; change defaults at setup |
| Physical attack | Pry, pick or brute force | Long-throw bolt, solid body, tamper sensors |
| Firmware neglect | Old, unpatched software | Prompt updates for locks and gateways |
None of these classes is exotic. They are the same things any door with electronics on it has dealt with for years, and the mitigations are mostly habits you would keep anyway — encrypted traffic, codes that expire, a bolt with proper throw, current firmware. The part that actually gets skipped is the dull one, revoking someone's access when they leave, and that is also where most real breaches happen. Get the boring pieces right and a connected lock holds up well against the deadbolt it replaced. The credential-to-bolt detail is in how smart locks work.