Buying a Used Smart Lock: What a Factory Reset Doesn’t Clear and How to Verify You Actually Own It

A factory reset on a smart lock is not a title transfer. It usually clears the local keypad codes and may drop the lock from the previous owner’s app, but it does not reliably remove the lock from a vendor cloud account, revoke the previous owner’s remote access, or prove that the lock is no longer bound to someone else’s hub. If you buy a used lock and pair it to your system without checking those layers, you can end up with a device that works for you and still answers to someone else.

This is the procedure I use for used locks that are going into a local-first stack: Home Assistant with Z-Wave JS or ZHA, Zigbee2MQTT, ESPHome, and MQTT. The goal is not paranoia. It is to establish which network and which account the lock actually belongs to before it becomes part of your door.

What a factory reset actually clears

On most consumer smart locks, a factory reset is a local operation. It wipes user codes, schedules, and local settings, and it may put the radio into a state where it can be included in a new network. That is useful, but it is not the same as releasing ownership.

Three things commonly survive a reset or are not addressed by it:

• Cloud account binding. The lock may still be listed in the previous owner’s vendor account. A reset performed at the keypad does not necessarily send a delete command to the vendor’s servers. If the previous owner still has the lock in their app, they may retain remote lock/unlock, code management, or status access depending on the vendor’s design.
• Network credentials. A Z-Wave or Zigbee lock that was paired to a previous hub retains the network key or network parameters until it is properly excluded or reset. A local reset may or may not clear the radio’s network membership. If it does not, the lock will not join your network, and the previous controller may still be able to talk to it.
• Logs and audit history. Some locks store access logs locally or in the vendor cloud. A factory reset may clear local logs, but cloud logs can remain in the previous owner’s account. That is a privacy issue, not an ownership issue, but it matters if the lock was on a rental or a shared door.

The exact behavior depends on the model. I have not seen a universal rule that applies to every lock. Treat the reset as a starting point, not a guarantee.

Why the radio layer is the part most people miss

Z-Wave and Zigbee locks are network devices. They do not just pair to a phone; they join a mesh with a controller that holds the network keys. If the lock is still a member of the previous owner’s network, it will not join yours until it is removed from that network or reset in a way that clears its radio membership.

Home Assistant’s Z-Wave JS documentation is explicit about this: you cannot join a device to a new network if it is still paired with an adapter. It also documents a procedure for removing a device from a foreign Z-Wave network when you no longer have access to the original adapter. That procedure puts the device into exclusion mode and removes it from the previous network. The same principle applies to Zigbee: a Zigbee device can only be connected to a single Zigbee network, and the coordinator holds the network parameters.

For Z-Wave, the network keys are the critical secret. The Home Assistant documentation warns that if your adapter has already been paired with secure devices, you need to enter the previously used network key as the S0 network key, and that you should keep a backup of these keys. A lock that was included with S2 security has its own keys. If the previous owner still has the network key and the lock is still in their network, a factory reset that does not clear the radio leaves that relationship intact.

For Zigbee, the network is defined by the coordinator’s PAN ID, extended PAN ID, and network key. ZHA documentation states that a Zigbee network can have only one coordinator and that a Zigbee device can only be connected to a single Zigbee network. If the lock was paired to a previous coordinator and not properly removed, it will not join your coordinator. Some devices require a factory reset to clear the old network; others can be removed by putting the old coordinator into permit-join or by using the device’s own reset procedure.

Zigbee2MQTT has its own interview and re-pairing behavior, but the primary documentation page for that process was not available when I checked. The general rule still holds: the lock must be removed from the old network before it can join yours. If you cannot remove it from the old network, a factory reset is the fallback, and you should verify that the reset actually cleared the radio by watching for the device to appear as a new join in your coordinator’s logs.

What to ask the seller before you pay

You cannot verify everything remotely, but you can ask questions that separate a clean transfer from a messy one. The answers are not proof, but they tell you what to expect.

• Was the lock ever connected to a hub or a vendor app? If yes, which one?
• Has the lock been removed from that account, or just reset at the keypad?
• Do you still have the original hub or controller? If so, can you exclude the lock from it before shipping?
• Do you have the original network keys or a backup of the controller? If not, the lock may need a full reset to join a new network.
• Is the lock still listed in your vendor app? If yes, can you delete it from the account now?

If the seller cannot answer these questions, assume the lock is still bound to something. That does not make it useless, but it changes the work you have to do.

What to do when the lock arrives

Do not pair it to your production system first. Set up a test controller or a spare coordinator if you have one. The goal is to observe the lock’s behavior before it becomes part of your door.

1. Reset the lock according to the manufacturer’s procedure

Use the exact procedure from the manufacturer’s manual. A generic “hold the button for 10 seconds” may not clear the radio. Some locks require a specific sequence, a programming code, or a button combination. If the manual is not available, search for the model number and the word “factory reset” on the manufacturer’s support site. Do not rely on a forum post if the manual is available.

2. Check for cloud binding

If the lock has a vendor app, install it and try to add the lock. If the app says the lock is already registered to another account, you have a cloud binding problem. Some vendors provide a transfer or ownership release process; others require the previous owner to delete the lock from their account. If the previous owner is unresponsive, the lock may be unusable with that vendor’s cloud features. It may still work as a local Z-Wave or Zigbee device if you can pair it to your own controller, but you lose the vendor app and any cloud-dependent features.

If the app lets you add the lock without complaint, that is a good sign, but it is not proof that the previous owner’s access is gone. Check the app’s device list for any shared users or old accounts. If the vendor provides an audit log, review it for recent activity that you did not initiate.

3. Pair the lock to a test controller

For Z-Wave, use Home Assistant’s Z-Wave JS integration. Put the lock into inclusion mode and add it. If the lock was previously paired and not excluded, the inclusion will fail or the lock will not respond. In that case, use the “Remove foreign device” procedure in Home Assistant: go to Settings > Connectivity > Z-Wave, select Options, and start exclusion. Put the lock into exclusion mode. The UI should confirm that the device was removed. Then try inclusion again.

For Zigbee, use ZHA or Zigbee2MQTT. Put the coordinator into permit-join mode and put the lock into pairing mode. If the lock does not join, it may still be on the old network. Try a factory reset again, or use the old coordinator if you have it to remove the device. ZHA documentation notes that a Zigbee device can only be connected to a single Zigbee network, so a failed join is often a sign of a stale network membership.

Once the lock joins, check the device details in your controller. For Z-Wave, look at the node ID, security class, and whether the device is marked as secure. For Zigbee, look at the IEEE address, network address, and the device’s interview status. If the lock joins but some features are missing, the interview may not have completed. Wake the lock and re-interview it.

4. Verify that the lock is not still reachable by the old controller

This is the part that a factory reset does not prove. If you have the old controller, power it on and see if it can still control the lock. If it can, the lock is still in the old network. You need to exclude it from that network or reset the lock again until the old controller can no longer see it.

If you do not have the old controller, you cannot directly test this. You can look for indirect signs: does the lock respond to commands from your new controller only, or does it also respond to something else? In a Z-Wave network, a device that is still in another network may not respond to your controller at all. In a Zigbee network, the same is true. If the lock joins your network and works, it is likely that the old network membership was cleared. But “likely” is not “verified.” If the lock is on a door that matters, consider a full reset and re-pair, and if the vendor app still shows the lock in another account, treat the cloud access as unresolved.

5. Re-key the lock

A factory reset may not change the physical key cylinder. If the lock has a mechanical key override, the previous owner may still have a key. Re-key the cylinder or replace it. This is a mechanical issue, not a smart-home issue, but it is part of owning the lock. If the lock uses a removable cylinder, you can take it to a locksmith or replace it with a new one. If it is a sealed unit, check whether the manufacturer sells a replacement cylinder.

Graceful degradation: what happens when the network or cloud fails

A used lock that is properly transferred should still work when your network or the vendor cloud is down. The behavior depends on the lock’s design.

Most battery-powered smart locks keep the keypad and the mechanical key working when the network is down. The radio may be offline, but the lock itself still functions. If the lock depends on a cloud service for code management, you may not be able to add or change codes until the cloud is reachable. If the lock stores codes locally, you can manage them through the keypad or a local controller.

For a local-first stack, the goal is to avoid cloud dependence for basic access. If the lock supports local Z-Wave or Zigbee control, you can manage codes through Home Assistant or Zigbee2MQTT without the vendor cloud. If it does not, you are relying on the vendor’s service, and a used lock with an unresolved cloud binding is a liability.

Power failure is a separate case. If the lock is battery-powered, a power failure in the building does not affect it. If the lock is mains-powered or has a hub that is mains-powered, a power failure may take the hub offline. The lock should still work with the keypad and key. If it does not, that is a design flaw worth knowing about before you install it.

A repeatable procedure

Here is the sequence I use. It is not fast, but it is repeatable.

1. Before purchase: Ask the seller whether the lock is still bound to a vendor account or a hub. Ask them to remove it from the account and exclude it from the hub before shipping. If they cannot, plan for a full reset and possible cloud lockout.
2. On arrival: Do not pair to your production system. Set up a test controller or use a spare coordinator.
3. Reset: Follow the manufacturer’s factory reset procedure exactly. Note whether the lock confirms the reset with a sound or light.
4. Check cloud binding: Try to add the lock to the vendor app. If it is already registered, contact the seller or the vendor. If you cannot resolve it, decide whether you can live without the vendor app.
5. Exclude from old network: If you have the old controller, use it to exclude the lock. If not, use the “Remove foreign device” procedure in Home Assistant for Z-Wave, or a factory reset for Zigbee.
6. Pair to test controller: Add the lock to your test controller. Verify that it joins securely and that all expected entities appear.
7. Test control: Lock and unlock from the controller. Check the status updates. If the lock supports codes, add a test code and verify it works.
8. Test degradation: Disconnect the controller from the network and verify that the keypad and key still work. Reconnect and verify that the lock comes back online.
9. Re-key: Replace or re-key the mechanical cylinder.
10. Move to production: Only after the lock passes all checks, pair it to your production controller and add it to your automations.

If the lock fails at step 4 or 5, you have a decision to make. A lock that cannot be cleared from a previous cloud account may still work as a local device, but you should treat the cloud features as unavailable. A lock that cannot be excluded from a previous Z-Wave or Zigbee network is not usable until that is resolved. In some cases, the only fix is to contact the previous owner or the vendor. If neither is possible, the lock may be a paperweight.

When a mechanical lock is the better choice

If the used lock is cheap but the transfer process is uncertain, do the math. A mechanical lock with a keypad or a plain key does not have a cloud account, a network key, or a firmware update that can brick it. It also does not need a hub. For a rental property or a door where reliability matters more than remote access, a mechanical lock is often the smarter choice. I am not against smart locks; I use them. But I would not put a used lock with an unresolved ownership question on a door that I depend on.

FAQ

Does a factory reset remove the lock from the previous owner’s app?

Not necessarily. A factory reset is usually a local operation. It may clear local codes and settings, but it does not always send a delete command to the vendor’s cloud. The previous owner may still see the lock in their app until they remove it or the vendor processes a transfer.

Can I use a used Z-Wave lock if I don’t have the previous network key?

If the lock is still paired to the previous network, you cannot join it to your network until it is excluded or reset. Home Assistant’s Z-Wave JS documentation describes a “Remove foreign device” procedure that can exclude a device from a network you no longer have access to. If that fails, a factory reset may clear the radio, but you should verify that the lock joins your network afterward.

How do I know if a Zigbee lock is still on another network?

If the lock does not join your coordinator after a factory reset, it may still be on the old network. Zigbee devices can only be connected to one network at a time. Try the reset again, or use the old coordinator to remove the device. ZHA documentation notes that a Zigbee network can have only one coordinator, so a failed join is often a sign of stale network membership.

What happens if the vendor cloud goes down?

It depends on the lock. Most battery-powered locks keep the keypad and mechanical key working. If the lock relies on the cloud for code management, you may not be able to change codes until the cloud is back. A local-first setup using Z-Wave JS, ZHA, or Zigbee2MQTT can manage codes locally if the lock supports it.

Should I buy a used smart lock at all?

If you can verify the transfer and the price is low enough to justify the work, yes. If the seller cannot confirm that the lock is removed from their account and network, or if the lock is critical to your security, a new lock or a mechanical lock may be the better choice. The savings are not worth a door that someone else can open.

For a broader look at auditing the small systems that run your home, see How to Audit the Small Systems That Quietly Run Your Week. The same principle applies: know what is connected, know what it depends on, and know what happens when it fails.