Locks and Security News: your weekly locks and security industry newsletter
16th September 2026 Issue no. 819

Your industry news - first

We strongly recommend viewing Locks and Security News full size in your web browser. Click our masthead above to visit our website version.

What smart locks inherit from software

By Evgenii Arsentev, PhD, AI transformation executive, ARSENTEV.AI

A mechanical lock fails in a way the trade has understood for a century. It fails locally, it fails visibly, and it fails one site at a time. Somebody notices a door that will not close, a key that turns badly, a cylinder that has been attacked. The failure is in front of you and it belongs to that one door.

A connected lock does not do any of that. It inherits the failure modes of the software industry, and those are shaped differently: they are remote, they are quiet, and they tend to arrive everywhere at once. That is not an argument against connected hardware. I run automated systems for a living and I would not go back. It is an argument for specifying them with your eyes open, because the questions that protect a mechanical installation are not the questions that protect a connected one.

The trust boundary moved and nobody announced it

When a lock joins a network, the thing you are installing stops being the thing on the door. You are also installing a piece of firmware that will need maintaining for as long as the building stands, a set of accounts that can open that door from anywhere, an app, and a relationship with a company whose continued existence is now part of your security posture.

Most specification conversations still only cover the first item. The rest arrives by default, and the person who ends up owning it is usually the installer, who inherited it without being asked.

Four things worth knowing before you recommend a product

The vendor's availability becomes your availability. Ask what the lock does when the internet is down, when the vendor's service is down, and when the vendor is gone entirely. A good answer is specific: which functions continue locally, how long cached credentials remain valid, what the mechanical override is. A bad answer is reassurance. This is the single most useful question in the whole conversation, because it separates products designed by people who have run a service from products designed by people who have only shipped one.

Firmware is a fleet problem, not a site problem. Mechanical hardware is maintained per site, when someone visits. Software has to be maintained per fleet, including the units you installed five years ago for a client who has since changed facilities manager twice. Ask how updates reach a device, whether they can be staged rather than pushed to everything at once, how long the manufacturer commits to issuing them, and what happens to a device that has been offline for a year. Then ask yourself, honestly, whose job it will be to notice.

Credentials spread quietly. In the software world we have spent a decade learning to scope credentials to a single task and to issue them per person, because a login that can do everything, everywhere, is the thing attackers actually want. Field practice has not caught up. One engineer account that opens every site is normal, because it is convenient, and it survives the engineer leaving. Before you specify, ask whether the platform supports per-person accounts, per-site scoping, and immediate revocation, and whether there is an audit record that the account holder cannot edit.

Failure becomes correlated. This is the one that is genuinely new. A mechanical vulnerability affects the doors that have that cylinder, discovered one at a time by people who have to be physically present. A compromised update, or a compromised vendor, reaches every installation simultaneously, at the speed of a software deployment. The convenience of managing a thousand doors from one screen is exactly the same mechanism as the risk, and you cannot have one without the other.

The part that is arriving now

There is a further turn that specifiers should see coming, because it is already ordinary in my world. Increasingly, the account that opens a door is not held by a person at all. Building systems are being wired to automated tools and integrations, and those act with the credentials they were given.

In my own operation I measured this directly: just over half of the calls my systems make to AI models come from automated sub-processes rather than from anything a person typed, and each of those runs with its own context and its own permissions. That is an org chart nobody has drawn. Two practical consequences follow. First, when something goes wrong, "who opened that door" may not have a human answer, and your audit trail needs to survive that question. Second, automated systems that read incoming text can be instructed by that text. If a process reads emails, tickets or supplier documents, then the contents of those documents are, in effect, instructions from strangers.

And automation fails with total confidence, which is the property people underestimate. In my own systems, an automated publishing process once put content out through the wrong channel because two files collided under the same name. A person would have caught it in a second. The automation did it perfectly, immediately and without hesitation. Roughly one in five tasks I hand to an automated agent comes back wrong or incomplete, and nothing in the output tells you which one. That figure is an operational estimate from daily use rather than a laboratory measurement, and I would rather label it honestly than dress it up, but it is the number that shapes how I design controls.

The rule I would give the trade is simple: let the system act alone where a mistake can be undone, and put a named human on anything that cannot be. A door that unlocks is, for those few minutes, an irreversible act.

Which trade-offs are worth making

None of this means recommending mechanical hardware by default. Connected locks solve real problems: credentials that can be revoked the hour someone leaves, access that can be granted to a contractor for a Tuesday morning, an audit trail that actually exists. Compared with a key that has been copied an unknown number of times, that is a large gain.

The trade-off is acceptable when three conditions hold. The lock degrades safely, meaning loss of connectivity reduces convenience rather than security. The credential model is per-person and revocable, so leavers actually leave. And somebody has been named as responsible for updates for the life of the installation, in writing, at the point of sale rather than after the first incident.

Where those three are in place, connected hardware is the better specification. Where they are absent, you have not bought a better lock. You have bought a lock plus a software dependency, and handed the maintenance bill to whoever picks up the phone in five years.

What to take away

The trade already knows how to think about physical attack. The gap is in thinking about maintenance and accounts, which is where software failures actually live. If you take one question into your next specification meeting, make it this one: when this product fails, does it fail at this door, or at every door we have ever installed?

Evgenii Arsentev, PhD, is an AI transformation executive at ARSENTEV.AI. He runs automated systems in production and publishes measurement work on how they behave. ORCID 0000-0002-9120-7298. [email protected]

16th September 2026