The door that cannot be cabled. And nothing else.

Aperio is wireless lock technology from the ASSA ABLOY group. It is two parts: the lock —door furniture, a cylinder, a cabinet or rack lock— and a hub fitted nearby that talks to the controller of the system already in place. From the same software as always, that door appears as one more: with its permission, its schedule and its line in the log.

What it is not: a system. It has no screen, no users, no log of its own. It replaces nothing and it is not bought «instead of»: it is bought to extend what you already have to the doors you never reached. Put like that it sounds like little; in a real installation it is exactly what is missing.

You see the problem straight away in any building with access control. The street door has a reader, and inside there are thirty doors with a key: offices, meeting rooms, the archive, the comms room, the racks in the data centre. None of them was cabled because ceilings would have had to be opened. And there they are, with a key that has been going round for four years and nobody knows how many copies there are.

The lock talks over short-range radio to a hub, and the hub is cabled to the controller just like a reader. It serves one lock or several depending on the model, and it has to be close: a few metres, and less with a metal door, a thick wall or a cabinet in the way. That is why an Aperio design is not a list of doors, it is a radio survey. Where these go wrong, it is almost always here.

It works online: every read goes up and every permission change comes down at that moment. That is the reason to choose it instead of a lock that keeps the permissions on the card itself, where removing access depends on the person passing an update point. Here a removal is a removal, and the record of who went into the archive on Thursday exists.

It runs on batteries, and that has to be managed. How long they last depends on how many times the door is opened a day. The system gives an alert when one runs low, and that alert has to reach a person with a box of batteries and not a mailbox nobody reads. A lock with a flat battery is a mechanical key and a phone call on a Monday.

For the credential it uses the same card as the rest of the system, and that is half the project: the lock has to read the same technology with the same keys. If that is not sorted out properly, you end up with a second card for the internal doors, which is the opposite of what you came to buy.

Aperio is the one that hangs off a third-party platform: you choose it when you already have a system and you want to extend it without adding another. Next to it is the group's own small-system line, which brings its own software and runs itself, meant for anyone with nothing in place. And there is the group's own platform layer, which is something else again.

They are not interchangeable and they look alike enough in the brochure to be confused. One question settles it: are you going to administer these doors from the system you already have, or are they going to have their own administration? If it is the first, Aperio. If it is the second, you would be paying for a hub and an integration for nothing.

The same group also brings electronic cylinders for doors that will not take door furniture, and key management cabinets for the mechanical keys that are going to go on existing. In a real project there is some of all three, and you have to ask somebody to draw where each one stops.

Adding and removing people, the schedules and the permissions by zone for these doors are handled from the platform already in place, with the same screens and the same people. Whoever administers the access control today —the security team, the IT team or whoever runs personnel— administers thirty more doors tomorrow without learning anything new. That is exactly the reason to choose this technology and not a separate system.

What does change is one maintenance routine. The batteries and the alerts for a lock that is not communicating are new tasks, and it has to be decided whose they are: the client's or ours. Nobody's is not an option, because then the first dead lock is found by the user.

What is not the client's: pairing a lock with its hub, the firmware and the configuration of the lock itself. That is done with a manufacturer's tool and not from the access screen, and it is worth knowing so that a new lock not adding itself does not come as a surprise.

What we leave: the drawing of which lock goes with which hub —the document that saves the next engineer—, the inventory with the model and the date of every battery, the low battery procedure with who receives the alert, and the training, which here really is short.

The typical migration is from mechanical keys, and it is done in phases without touching the whole master key suite. You start with the doors where not knowing who goes in hurts most, you take those keys out of circulation and you carry on the following year with the next group. It is one of the few security migrations that can be done in pieces without the halfway result being a problem.

The other is from locks that keep the permissions on the card. There you gain what matters: the removal is immediate and the record exists. In exchange the hubs have to be cabled, which is minor building work but it is building work.

And a warning so as not to repeat the usual mistake: fitting new locks with the old insecure card is swapping a key that gets copied for a card that gets cloned. If the credential has to be replaced, it is replaced first or replaced at the same time. Not afterwards.