When the whole building is already from the same house.

SiPass Integrated is Siemens' access control platform for large buildings: hospitals, airports, pharmaceutical plants, universities, data centres, sites with thousands of people. It does what you ask of a platform that size —zones, interlocks, anti-passback, visitors, lifts, headcount— and it does it from a server on site.

But the reason it turns up in a specification is almost never the access control data sheet. It turns up because the building already belongs to that house: the fire control panel, the building management, the climate control. In that kind of building, access is not a separate system, it is a part of the building, and treating it as an add-on is what produces installations that do not talk to each other.

Whoever chooses it usually has what cloud clients do not: a maintenance department and a fifteen-year horizon. And what that drags with it: phased building work and a system that has to carry on working through the phases.

A server with its database and its operator positions, and field controllers that keep their own copy of people, permissions and schedules. That last part is what matters on the bad day: if the server goes down or loses the network, the doors carry on applying the logic they have loaded and store up events. There is no degrading to «open everything» or «close everything».

It grows by module and by segment, and in installations that cannot stop it is built with a redundant server. There is a classic budget trap there: the redundancy, the integrations and the operator positions are licensed, and if they are not sized at the start they turn up halfway through the works as a variation.

Its distinctive value is the integration with the rest of the building from the same house: the fire system releasing the doors it should release and no others, a technical alarm and a denied access showing on the same screen. With third-party video you have to look at how far each integration goes: seeing the camera is not having the image attached to the event.

The good part: the people data and the door log stay on the client's server. The data protection conversation gets much simpler —no international transfers to justify and no list of sub-processors to review— and the system depends on no line either to work or to be administered.

What the client takes on in exchange: backups that have to be made and tested, patches that have to be applied, a server that has to be watched and a life cycle that has to be followed. That is not free and it has names and hours attached. When there is nobody to do it, this architecture is the worse of the two, not the better.

And the decision you pay for three years later: an installation that does not upgrade stays anchored to an operating system and a database that go out of support. Upgrading then is no longer maintenance, it is a project with a shutdown, with testing and with a budget. It is planned from the first year or it never happens.

It fits large buildings with real requirements and somebody to sustain them: zones, interlocks, evacuation headcount, audit, dozens of positions. And it fits very well when the fire detection and the building management already come from the same house, because there the integration stops being a risky project.

It does not fit five doors. Nor thirty small branches: it can be done, and the result is an oversized system nobody governs and that costs more to maintain than to buy. That is what the cloud platforms are for, and we say so even though the big project bills better.

And it does not fit where there is nobody to maintain a security server. That is not a minor snag: it is the main reason why very good installations end up, six years later, being the most out-of-date equipment in the building.

The day-to-day is run by the client and run without us: adding and removing people, issuing and cancelling cards, moving somebody into another group, assigning schedules, handling visitors, pulling a list of who went in where. The platform has fine-grained operator roles, and the normal arrangement is that security runs people and permissions while IT sustains the server, the backups and the directory.

What is not touched without the integrator is the configuration of the installation: adding controllers or doors, changing a door's mode, touching interlocks, anti-passback or the evacuation logic, altering the integration with the fire system or with the building, and upgrading versions. It is not a question of permissions, it is that those changes have to be tested, and testing them on a live installation has to be organised.

Documentation and training, which on a platform this size are part of the deliverable: training by role with a short manual of our own —not the manufacturer's, which runs to six hundred pages—, the door and mode matrix signed off, the tree of zones and schedules exactly as it ended up, the licence inventory and the version status, and the administrator keys in the client's name.

Coming from another enterprise platform, you keep the containment, the power supply, the door furniture and often the locks; the readers, depending which they are; and the field electronics get changed, because they are proprietary. That means work in the cabinets and a phased migration, with the old system and the new one living side by side for a few days.

What always has to be decided beforehand: what is done with the history —it is exported and archived— and what is done with the cards. If the workforce carries credentials encrypted with another manufacturer's keys, there will probably be a reissue, and in a hospital or a factory on shifts that is a logistics plan of its own.

And the case nobody talks about: extending a SiPass that has been installed for years. There the project does not start with the new doors, it starts with an audit of what version it is on, what it runs on and whether what you want to add is compatible with that. Skipping that audit is the most common way of turning a small extension into a full upgrade halfway through the works.