The doors, inside the program you already watch the cameras with.

In a great many places the video is well sorted and the doors go their own way: another manufacturer, another program, another server and another person who knows how to run it. When there is an odd access attempt, somebody looks at the log on one screen and hunts for the image on another, by hand and by the time on the clock.

Secure Entry is Axis's answer to that, and it is a modest answer on purpose: the doors are managed inside the same software the cameras are watched with. The electronics are networked door controllers, powered by the network cable itself, with no big panel in a cabinet.

It turns up where there are four to a few dozen doors and the cameras are already from this firm: an industrial unit, a school, a clinic, a mid-sized office, a sports centre. And it turns up a lot in extensions: there are already cameras and recording, and now six controlled doors are needed without building a whole system.

Each controller is a network device hanging off a network point, powered through it and running one door or two. It keeps its configuration, its permissions and its schedules inside and decides for itself. There is no central panel they all depend on, and that changes the building work: less cabinet and less data cable back to a rack, more dependence on the network.

Managing people, credentials and schedules lives in the video software, in the same client the operator already works in. That has an advantage you do not appreciate until you see it: a denied attempt appears with the image of that door beside it, with no integration project in between, because there are not two systems to integrate.

And the limit is right there. It grows by adding controllers, but what does not grow is the features: it is not the place for deep zone hierarchies, chained interlocks, visitor management at scale or fine synchronisation with the personnel system. It is meant to do the ordinary things well, not to meet a high-security specification.

Each controller is one more device on the network, with its address and its configuration. The good part: there is no separate access server, there is no new database to back up and all the data stays on site, which makes the data protection conversation a good deal simpler. The load on the video server and its backups is still the client's.

What has to be done properly: putting those devices on a network separate from the network the company works on, with its own rules; and backing up the network electronics, because if the switch loses power, the doors hanging off it lose power. That is sized, not assumed.

And what happens if the video server goes down: the doors go on working, because each controller decides with its own copy. What you lose is the management, the joint view and the central log while it is down. It is a reasonable degradation, but it has to be said beforehand.

It fits when the cameras are already from this firm, the doors are a handful and the requirements are the ordinary ones: who goes in, when, with what credential and that a record with the image is kept. It also fits in extensions, where building a whole platform for six doors is out of proportion.

It does not fit in high security, nor in a large multi-site with administration hierarchies, nor where deep integration with personnel, visitors at scale or a demanding evacuation roll call is needed. That is not a defect of the product: it is simply not that product.

And there is a trap worth naming, because it is the one you pay for three years later: from here you do not grow into an enterprise platform. If the installation is going to ask for that in three years —because the company is growing, because there is going to be a specification, because audits are coming in—, you choose something else now, even if it costs more today. We have that conversation at the start and with numbers.

Whoever is going to administer the doors already uses that program to watch the cameras. There is no new tool to learn, and no second place to register the same person. Adding and removing people, credentials, schedules, permissions per door and looking things up in the log are handled by the client from day one, and usually it is IT or whoever already ran the video.

What stays ours: adding a controller or a door, changing what a door does when the power goes, touching the link with the fire detection, changing the network or upgrading firmware. And there is a wrinkle particular to this architecture: because each controller is an independent device, configuration changes have to be made in the right place and not in two places at once, or you end up with a door that behaves differently from what the screen says.

What is handed over: short training —which here really is short, because the program is already known—, the door map with its behaviour written down, the controller inventory with its address and its firmware, what was licensed and one sheet with the five likely problems and their answer.

Coming from a small standalone access system, the containment, the locks, the door furniture and often the readers stay. The controller is replaced and its program disappears: that part of the migration is cheap and quick, and it is exactly the case where this option is at its best.

What has to be looked at first is the network point at each door and its power. If the network does not reach the door, a new cable does, and there goes the advantage: better to see it on the site visit and not in the offer.

The cards, the usual: if the current ones read, nobody notices the change; if they are encrypted with another manufacturer's keys, there is a reissue. And the history is exported and archived before the old system is switched off, because it is not going to travel.