Access as a service, from before the cloud was being sold.

Brivo was one of the first firms to sell access control from the cloud, when that was not a sales argument but an oddity that had to be explained. That history shows in one specific thing: it was designed from the start for a portfolio of sites and not for a building. The console does not start at a door, it starts at a list of sites.

The problem it solves is the spread-out organisation that does not want one system per branch. Retail chains, gyms, flexible offices, networks of clinics, companies with industrial units in three provinces. Where today there are six different systems because a local installer fitted each opening, and nobody can answer in a minute who has access to what.

At the door there is a networked controller with its local copy of permissions and schedules, which decides on its own and uploads the events. The administration is entirely web-based. The readers can be from the firm itself or off the shelf, and that matters more than it looks: an installation with decent readers can sometimes be reused, and in a refurbishment that changes the quotation.

The part that sets Brivo apart is not the controller, it is what is around it: an open API and a catalogue of integrations with systems that are not security systems. It sounds like a data sheet and it is not: it means that a worker leaving can come out of the personnel system and reach the door without anybody having to remember. Everything else depends on somebody remembering.

And the small print of that virtue: an identity integration does not build itself. You have to decide which field rules, what happens with temporary leave, what is done with contractors —who are not in the personnel system and are half the people going through a warehouse— and what happens when somebody changes department. The manufacturer calls it a native integration and it is still four meetings.

Outside live the list of people, their permissions, their schedules and the door log. Inside lives the decision: each controller has its copy and opens without asking. With the line down, the doors go on working and the events pile up; what you lose is propagating a change, opening remotely and seeing what is happening now.

So the continuity question is not «what happens if the internet goes down» —which has a good answer— but «how long does it take for the credential of somebody dismissed today to stop opening, if their branch has the line down». That is written into the procedure, and on sensitive doors it is solved with a second connection route.

The data side is the heavy one here, because what is synchronised is personnel information. You ask in writing for the hosting region, the data processor agreement with its sub-processors and the mechanism for the transfers. And you decide which fields are sent: the department and an identifier are enough; sending the DNI (the Spanish national identity number) or the personal phone number because the connector brings them by default is another matter. If the sites belong to different owners, as in a franchise, it has to be made clear beforehand who answers for what.

It fits when there are several sites and the question that hurts most is «who has access to what, right now, at every site?». It fits when there is an IT department that wants this to hang off the directory the way the email does. And in shared buildings and flexible offices, where the work is not the door: it is adding and removing people.

It does not fit in high security with complex logic: chained interlocks, zones with rules that depend on who else is inside, a demanding evacuation roll call, deep integration with an intruder detection platform already installed, guard patrols. That is another type of product and it is said in the first meeting.

And it does not fit —this holds for all seven, but here it shows sooner— if nobody inside is going to take charge of adding and removing people. A platform meant to be run by the client, with nobody to run it, is a subscription paying for a list that ages.

Adding and removing people, schedules, permissions by zone, temporary credentials and looking things up in the log are handled by the client with no need for us. And the usual thing here is for IT to handle it, because the platform is meant to hang off the directory and whoever administers that directory administers this.

Where there is a security department, the healthy thing is to split it: IT holds up the synchronisation and the accounts, security decides permissions and zones. Mixing it ends with nobody reviewing the list because each thinks the other does it. What the client does not touch: adding doors, changing a door's behaviour, the link with fire or intruder detection, or the hierarchy of sites when the company reorganises.

A warning that comes from having seen it: if the synchronisation is changed without thinking it through, credentials can be removed in bulk, and that gets discovered at eight in the morning at the door. So that they can: separate training for whoever manages people and for whoever holds up the integration, the synchronisation scheme documented field by field, the list of roles with the reason for each, and a calendar with the review of the list.

The containment, the power, the door furniture and, once it is checked, sometimes the readers are kept. The controller is replaced. The server disappears, and with it a maintenance line worth noting when costs are compared, because it is almost always forgotten.

The cards, the same as in any change: the old proximity ones can usually be read and this is a good moment to drop them; the ones encrypted with the previous manufacturer's keys usually cannot, and then there is a reissue for the whole workforce.

And there is a case that comes up a lot in spread-out portfolios: coming not from one system but from six. There the migration is not technical, it is about data: merging six lists made to different criteria, deciding which one rules and accepting that active credentials belonging to people who left years ago are going to turn up. That work fixes the problem you called about.