For most of the last two decades, a large share of connected consumer devices shipped with the same administrative password across every unit produced. The manufacturer printed it in the manual, the manual went online, and the credential was effectively public from the day the product launched. It was not a secret that leaked. It was never a secret.
A connected lock inherits this history from the broader device industry, and it inherits a second layer that pure software products do not have: mechanical and keypad programming codes that persist through a factory reset and are often documented in the same public manual.
Governments legislated against it
The default credential problem became severe enough that lawmakers acted, which is a useful signal about how structural it was. California’s connected device security law requires that a device sold in the state be equipped with reasonable security features, and specifies two ways of satisfying that requirement where a preprogrammed password is used. The text of California SB-327 states the device complies if the preprogrammed password is unique to each device manufactured, or if the device contains a security feature that requires a user to generate a new means of authentication before access is granted for the first time.
The United Kingdom took a broader approach in primary legislation. Section 1 of the Product Security and Telecommunications Infrastructure Act 2022 creates the power to specify security requirements for connectable products made available to consumers, with the detailed requirements set by regulations and enforcement obligations placed on manufacturers, importers, and distributors.
Read together, the direction of travel is clear. Unique or user generated credentials at first use are becoming a baseline expectation rather than a premium feature, and a product still shipping a shared default in 2026 is telling you something about its engineering culture.
The capability baseline
NIST approaches the same problem from the engineering side rather than the legal side. NIST IR 8259A defines the core baseline of device cybersecurity capabilities that devices should provide through their own hardware and software to support common security controls, intended as a starting point for identifying what capabilities a new device needs.
Translated into questions you can ask before buying a lock: can the device be uniquely identified, can its configuration be changed only by authorized parties and restored to a known good state, can its software be updated, does it protect data at rest and in transit, and can it record and report on security relevant events. A vendor that can answer those crisply has thought about the problem. A vendor that responds with the phrase bank grade encryption has not.
The account layer is usually the weaker half
For most households, the realistic exposure is not a radio attack on the lock. It is the account that controls the lock:
- Password reuse. If the lock account shares a password with an email address that has appeared in a breach, the lock is protected by that breach, not by its own security.
- Missing multi-factor authentication. If the vendor offers it, enable it. If the vendor does not offer it on an account that can unlock a door, that is a meaningful mark against the product.
- Shared logins. One household account passed around means no attribution, no per person revocation, and no way to remove access when a relationship or a service arrangement ends. Use per person guest access with its own credential instead.
- Stale access. Codes issued to contractors, sitters, and former occupants tend to outlive their purpose indefinitely because nothing prompts anyone to remove them.
Installer codes and factory reset
Keypad and connected locks generally have at least three tiers of credential: user codes, a master or programming code, and an installer or manufacturer default used during setup. The failure pattern is that the master code is left at the documented default while the user carefully sets a strong personal code, which produces the appearance of security with none of the substance.
Factory reset deserves specific attention. Understand what reset restores, because if reset returns the lock to a published default and reset is reachable from the accessible side of the door, then the effective security of the device is the security of that default. If you acquire a home or a device secondhand, assume prior codes exist until you have deliberately cleared and re-enrolled everything.
A ten minute hardening routine
- Change the master or programming code away from the documented default, first, before anything else.
- Set a unique account password stored in a password manager, and turn on multi-factor authentication.
- Delete every code you did not personally issue, then re-enroll the ones you actually need.
- Give each person their own credential rather than sharing one.
- Check for and apply firmware updates, and find out how long the vendor commits to providing them.
- Confirm what the device does when the network is down and when the battery dies, and make sure you have a mechanical fallback you can actually reach.
