OnGuard does not open the door better. It answers better afterwards.

A large access control system has two halves. On the wall there are boxes with electronics in them, the controllers: they read the reader, look at their copy of the list and decide in tenths of a second whether the lock releases. Above that there is software, and that is where the people, the schedules, the permissions by zone and the record of what has happened really exist. OnGuard is that upper half.

That is why its work is not noticed on commissioning day: any system can open a door. What a platform of this class does is answer «who went into that room on Thursday afternoon» with names and in a minute, withdraw access from forty people on a contract in one afternoon, and make one credential mean the same thing at two different sites.

You find it where a lot of people go through and somebody from outside asks questions: hospitals, pharmaceutical plants, utilities, airports, universities, sites with several buildings. Places where the problem is not the door: it is the list of who can open it and who answers for it.

Underneath there is a Windows server and an SQL database with everything inside: people, credentials, permissions, schedules and history. A separate service talks over the network to the controllers, and out of each controller run buses to the boards that command the readers. That split lets you spread the pieces across different machines as the installation grows, and it also lets a sizing mistake show up years later as reports that take a minute to come out.

The question almost nobody asks is what happens when the network to a building is cut. The controller carries on deciding on its own, with the copy it has downloaded, and stores the events until the line comes back. But that memory is finite: there is a limit to how many people fit and how many events are stored before the oldest are lost. With thousands of people, that forces you to decide which credentials are downloaded to which controller. That is design, not a setting.

On credentials it takes almost everything: old proximity, encrypted card, phone, code and biometric readers hung off it as ordinary readers. And there is a choice that gets forgotten and gets paid for: whether the reader talks to the controller in the old protocol, which cannot be encrypted or supervised —nobody finds out if somebody disconnects the reader and taps the cable—, or in the modern one, which can. Changing it later means opening up the wall again.

The first is whether the system is partitioned. OnGuard can be split so that each site, or each company in a shared building, sees only its own people and its own doors. Deciding that at the start costs one meeting. Deciding it when the database already has five years of people in it is another project, with its shutdown and its review of every permission.

The second is sillier and does more damage: how the permissions are named. On day one there are twelve access levels with clear names. Three years later there are four hundred, because every exception —a supplier coming in on a Saturday, an intern who needs the laboratory for two weeks— was solved by creating a new one. That system can no longer be audited: nobody knows what each level opens without opening it. The rule about who may create levels is worth more than half the configuration.

It fits with many doors spread across several places, people coming and going every week, an HR system worth synchronising the joiners and leavers with, and somebody from outside who occasionally asks for the list of who had access to what. And it fits when the administration has to be spread out: each manager handling the permissions for their own area without being able to touch anything in the system.

It does not fit eight doors, one building and a workforce that barely changes. It would work, but you pay for a server, a database, annual maintenance and a learning curve to use a small part of it, and the daily administration will feel heavy because it is built for an installation ten times the size. There are platforms that do that job with far less apparatus, and saying so is part of the job.

The day-to-day, yes, and they should. Adding a person, withdrawing access, changing a schedule, a supplier coming in on Saturday, printing a card: the client's security team or IT team runs that without calling anyone. OnGuard has delegated administration for it —a floor manager grants permissions over their own zones without seeing or touching the rest of the system— and it is almost always left unused.

The structural work, no. Adding a door, changing the cabling on a bus, touching the video integration, changing what the doors do in a fire, upgrading a version: that belongs to whoever knows the installation, and done halfway it leaves the system working and lying. The borderline case is creating new access levels: let the client do it, but with the naming rule written down, because that is where these installations decay.

And what decides whether they really can is not the platform: it is what is handed to them. The model document, an administrator account of their own with their password and not ours, and training by role instead of one general session —whoever adds people needs a couple of hours and a one-page procedure; whoever pulls reports for an audit needs a different session—. Without that they can use it and they will not: they will call, and in time they will stop calling.

A good part of the wall electronics in the upper range comes from one family of controllers that several platforms share. Depending on what is fitted, a migration can keep controllers, reader boards and all the field cabling, and change only the head end. It has to be checked device by device before it is promised, but when it can be done it turns a project budget into an upgrade budget.

Readers and cables usually survive. Credentials depend on two things: that the new readers read that card technology and that the number the old system stored can be imported as it is. Here is the trap that causes the most delays: the number printed on the card is almost never the one the system stores, and between the two there is a format, a site code and sometimes a conversion nobody documented. It is resolved by reading real cards on the visit, not in a spreadsheet.