Digital Identity in The Building

The identity graph 

Physical access control systems are increasingly becoming a key source of occupancy data. Visitor management, elevator control, parking and building automation are consolidating around them, while security manufacturers and enterprise platforms compete for control over the emerging identity model. This raises a central question: Will access control remain interchangeable infrastructure, or will it become the intelligence layer that captures the value of identity and presence?

For the individual building owner, this question is not decided in the global competition between platform providers. It is decided during design phases 3 to 5, in a specification written by someone who, at that moment, may not realise that they are making an architectural decision for the next twenty years.

What the term actually describes

The term “identity graph” sounds like a product. It describes none. What is meant is the sum of the answers to a mundane question: who may go where, and when — and how does the building know?

In practice it is a chain. At the start sits a leading system that knows which people belong to the organisation; usually the HR system. It feeds a directory service. Above that sits an authorisation management layer that maps roles to access rights. That in turn supplies the access control system, and only then come the downstream trades, from elevator dispatch to room booking.

This chain can be planned in new-build projects. In existing properties it is almost never continuous, and it breaks with remarkable regularity at the same point: with everyone who has no HR record. Maintenance staff, cleaning, site management, temporary workers, suppliers. For them there is no triggering event that ends an authorisation — and therefore no lifecycle. 

For planners this yields a first sober finding: the quality of an identity architecture is not measured by the capability of the access control system, but by the weakest point in this chain.

Convergence on paper, package boundaries on site

The consolidation described is real. From a designer’s point of view, however, it has a property that stays invisible in architecture diagrams: each of the converging systems is its own procurement package.

Visitor management, elevator control, parking, room booking, building automation and video — behind each sit different contractors, different project stages, different warranty periods and often different specialist designers. What appears on the diagram as a shared identity layer is, on site, a series of separate awards with interfaces in between.

And interfaces sit between packages. Which means that, in case of doubt, they sit with no one.

The typical example is the elevator interface. It rarely fails on technical grounds — the methods have been established for years. It can fail because the connection appeared in no specification, neither in the elevator package nor in the security package, and surfaces during commissioning as a variation for which no one holds a budget. 

Anyone who wants convergence has to procure it. As a distinct deliverable, with named responsibility, an interface schedule and acceptance criteria. Not as a secondary obligation of the largest package.

The four decisions

Four questions determine a building’s identity architecture. They are answered in every project — deliberately, or by the first trade on site setting the facts.

• Which system is authoritative? Where is the person record created, and in which direction do changes flow? As long as this question stays open, parallel data stores emerge and drift apart. The answer does not have to be the HR system — but there has to be an answer.
• Who owns the data? Access events become the basis for occupancy analysis, space decisions and sustainability reporting. That makes it relevant in which format they can be exported, whether the history comes with them, and whether export is part of the standard contract or a chargeable module.
• Which interfaces are guaranteed? “Offers an open interface” is not a requirement, it is a hope. What matters is the specific functional scope, its documentation, availability without an additional licence tier, and whether third parties may use it without the vendor’s consent.
• What does the exit look like? What happens to credentials, authorisation structures and event history when the vendor changes? Anyone who does not hold the cryptographic keys of the credentials cannot realistically change service.

Four layers, lifespans that differ tenfold

The real reason these decisions reach so far is an asymmetry that has no place in market analysis: the components of an identity architecture age at completely different rates.

Door hardware, cabling and structural provision outlast two to three decades. Readers and controllers sit in the middle. Software is replaced every few years. Contracts under subscription models can be terminated, in some cases annually. 

From this follows a procurement rule worth saying out loud: the shorter-lived the layer, the more important its replaceability. With cabling you may commit. With software you should not.

This is also where the observation that subscription-based operating models are spreading deserves a planner’s reading. They shift cost from investment to operations, bundle updates and remote maintenance into a predictable rate, and take work off operators who often have no staff for it. But they tie a twenty-year hardware investment to a contract with a far shorter horizon. That is not an argument against them. It is an argument for costing out the end of the contract during procurement, rather than deferring it to the future.

The downside that rarely gets discussed

The more trades depend on the presence signal from access control, the less its failure is a security incident. It becomes an operational outage.

As long as the access system opens doors, a failure is unpleasant and organisationally manageable. Once lighting, space conditioning, elevator dispatch and desk booking depend on it, it leaves the security domain. It becomes a business-critical system — with corresponding requirements for availability, redundancy, maintenance windows and fallback operation.

This consequence barely features in the convergence narrative, and that is striking, because for operators it is the most consequential one. Coupling systems increases not only the benefit but also the dependency on a single component.

The practical conclusion is unspectacular and still rarely drawn: define fallback operation before you tender the integration. How long do the door controllers keep running autonomously? What happens to the coupled trades? And who notices the failure first — the security organisation or the user sitting in a dark open-plan office? 

At the drawing board, not in the market

Whether access control remains infrastructure or becomes intelligence is an open question for the industry as a whole. For the individual building it is not. There it is answered when someone determines which system holds the person record, who owns the data, which interfaces are contractually guaranteed and what an exit looks like.

These decisions are made early, they are made quietly, and they are made even when no one makes them. The difference between a building with an identity architecture and one with an access control system that simply grew is not the product selection. It is whether someone asked the four questions while they were still open.

Where this becomes a legal deadline: Employee consultation belongs in the schedule

The moment access data is used for occupancy analysis, space decisions or attendance patterns, it becomes data capable of monitoring conduct and performance — whether or not monitoring was ever intended. Most jurisdictions attach obligations to that: works council consultation across much of continental Europe, employee notice and consent requirements in parts of North America and Asia-Pacific, and a data protection impact assessment wherever the GDPR applies. Germany sets the strictest common benchmark: under section 87 (1) no. 6 of the Works Constitution Act, the mere capability to monitor is enough to require a works council agreement before the system may be introduced.

For project planning the consequence is the same everywhere: the consultation belongs in the schedule, with a realistic duration and ahead of commissioning. Projects that defer this step to the acceptance phase routinely lose months there — and in unfavourable cases lose functions that were paid for long ago.