How can access control integrate with other building systems?

Access control can share identity, events and door states with a long list of other systems: HR and identity directories for joiners and leavers, visitor management, lifts, video surveillance, intruder detection, the building management system for occupancy-based operation, hotel property management for guest keys, and the fire alarm system for door release. The benefit is less manual administration and better-informed operation. The risk is that a weakness in any connected system becomes a way to open doors. Every integration therefore needs three things written down: what data flows, in which direction, and, above all, which system has the authority to unlock a door or change someone's access.

Doors are operational technology too

NIST's guide to OT security (SP 800-82) classes physical access control systems as operational technology, alongside building automation. NIST describes the basic chain: a reader captures a credential, a door controller validates it, the access control server decides, the controller releases the lock and every attempt is logged. Each integration attaches to some part of that chain, and precision about which part matters, because reading an event log carries a very different risk from being able to issue a credential or command a door.

The usual integrations

Who decides?

The central design question is authority, and in a well-designed arrangement it is divided cleanly. The access control system decides who may open a door; other systems may request or supply information, but they should not bypass its rules. The identity source decides who exists: if HR is authoritative, access rights follow HR records, and manual changes in the access system become controlled exceptions. And the fire strategy decides how doors behave in an emergency. The fire alarm interface, and how doors on escape routes respond to an alarm or a loss of power, are life-safety matters determined by the appointed fire engineer and the applicable regulations. The integration designer implements them, and the smart building brief must not override them.

Write commands are where integrations most often go wrong. A building management system that can "unlock all doors" for a convenience scenario, or a visitor app that can create permanent credentials, has become part of the security system by the back door, without ever being designed or protected as one.

Standards that help, and what they do not do

Between readers and controllers, the Open Supervised Device Protocol (OSDP), published internationally as IEC 60839-11-5:2020, specifies communication between access control units and peripheral devices such as readers. The Security Industry Association, which maintains OSDP, describes it as an alternative to the legacy Wiegand interface, with supervision of the reader connection and, from Version 2, Secure Channel encryption. For new installations we generally recommend specifying OSDP with Secure Channel enabled, confirming that each proposed reader and controller supports it, and checking at commissioning that it is actually switched on, not left at a default.

For interoperability between suppliers, ONVIF Profile C covers door control, site information and event management for electronic access control, and Profile A covers the configuration of credentials, schedules and access rules. Conformance can make integration between different suppliers' products more predictable. As with any profile, check which features are mandatory and which are conditional, and test the functions your project needs.

Hotels have their own reference point. HTNG (Hospitality Technology Next Generation), the industry's technology association, has been part of the American Hotel & Lodging Association since 2021 and develops open specifications for hotel system integration, including categories for door lock and property management systems. Where your suppliers support them, cite them in the specification.

None of these standards replaces a project test of the actual integration under normal, abnormal and failure conditions.

Personal data and proportion

Access events record where identifiable people went and when. In the EU, the principles in Article 5 of the GDPR apply, including purpose limitation, data minimisation and storage limitation. Before access events are used for a new purpose, such as occupancy analytics, ask whether aggregated or anonymised counts would be enough, and agree retention periods with your data protection adviser. Biometric data processed to identify people uniquely falls into the special categories of Article 9, which may be processed only under specific conditions, so whether to use biometric readers is a decision for your data protection specialists.

Eight lines for the specification

• An integration schedule listing each connected system, data exchanged, direction, method and responsible supplier.
• A statement of authority for each integration, including any permitted write commands and their conditions.
• Failure behaviour for each integration, consistent with the fire strategy and security requirements.
• Network placement in a security zone, with only the required flows permitted.
• Account management for integration services, including how credentials are rotated and revoked.
• Logging and review responsibilities for access-related events.
• Data protection requirements: purpose, minimisation, retention and access to logs.
• Acceptance tests covering normal use, revocation, conflicting signals and outages.