Who Controls the Systems that Protect Your Building

Remote access and operational resilience across buildings and critical infrastructure sites

A building operator may know exactly who holds a master key, yet be unable to identify everyone who can remotely change an access rule or administer the platform used by the security control room. The question is straightforward: who has the technical authority to influence the systems on which the site and its operations depend?

Building automation and physical access control belong within operational technology, or OT: systems that monitor or affect the physical environment. NIST explicitly includes both in its OT security guidance. This places building security within the same broad discipline as industrial control, while leaving the consequences of each deployment to be assessed individually. [1]

For operators, the useful starting point is a particular function and the routes through which it can be influenced. A camera, a door controller and a plant controller have different purposes. Each still requires a defensible answer about who can change its behaviour. For water utilities, energy suppliers, network operators and airports, this concerns the security of operational assets, safe operation and the resilience of essential services.

Remote access has operational consequences

Canadian incidents illustrate why this matters. The Canadian Centre for Cyber Security reported that, in October 2025, an attacker manipulated municipal water pressure controls, causing minor service impacts. Another accessed an airport fuel tank gauging system but could only view information, not manipulate controls. A third changed settings in a grain drying silo, with no evidence of damage. These distinctions matter: access, control and physical harm are different outcomes. The bulletin identifies insecure remote access and weak credentials among the recurring weaknesses. [2]

Operators of buildings and critical infrastructure sites should apply the same distinction when assessing their own systems. Seeing a camera image, changing a recording policy and remotely releasing a door represent different levels of authority. For operational plant, the same assessment extends to changes in process settings and their effects on safe, reliable operation. A risk assessment needs to establish which actions are possible in the actual configuration.

The Cyber Centre's September 2026 warning also describes how vendor connections or cellular modems can leave OT accessible even when it is separated from the corporate network. It reports attackers using AI to develop attack scripts against exposed controllers. AI adds urgency, but the practical exposure remains a reachable system and inadequately controlled access. [3]

A service interface can undermine the main login

Our research at Concepture offers a specific example. In findings published in 2023, we tested a local installation of Advancis WinGuard, a Physical Security Information Management platform. The client login supported protection against repeated password attempts; an enabled service interface did not provide equivalent protection. That interface accepted the same user credentials, allowing password guessing through the less protected route. Credentials obtained there could then provide access to the wider platform according to the account's permissions. [4]

We presented the research at DEF CON's ICS Village. Advancis fixed the reported vulnerabilities and supplied an update following responsible disclosure. These historical findings concerned WinGuard X4 Build 17.5 and earlier with the relevant interfaces enabled, not the current product. [4, 5]

The enduring lesson is architectural. Testing the familiar login screen is insufficient when another interface can validate the same credentials under weaker conditions. Even a service described as monitoring-only deserves examination in the context of the wider system.

Integration concentrates authority

Integrating video, access control and alarm information can help an operator understand an incident and respond promptly. It also warrants a precise examination of the authority granted to the integration platform. If an account can act across several subsystems, its compromise may cross boundaries between areas or operational systems that appear separate in the site design.

The consequences cannot be inferred from a list of connected products. For a fire alarm integration, for example, receiving status messages is different from being permitted to issue commands. Neither establishes, by itself, that an attacker could disable an independent local safety function. The assessment must distinguish what can be observed, what can be changed and which protections remain independent.

I would therefore ask a project team to demonstrate a short set of consequential actions: changing a door's access permissions, altering an alarm workflow, or modifying a camera's recording configuration. For each action, the team should identify the authorised account, the available access routes and the boundary that prevents wider control. These are proposed assessment scenarios, not claims about every installation.

Evidence that the operator retains control

The January 2026 joint guidance on secure OT connectivity, developed by the UK NCSC with partners including Canada's Cyber Centre and Germany's BSI, provides a useful basis. It calls for justified connections, controlled access, monitoring and planned isolation. [6] For site operators, I would turn that guidance into five requests for evidence.

First, produce a verified map of external access. It should identify manufacturers, integrators and support providers, including connections introduced during commissioning. Reconcile the documentation with the installed environment. The Cyber Centre specifically highlights exposure created through third parties and unclear divisions of responsibility. [3]

Second, show how a maintenance session is authorised. Use named identities, limited privileges and time-bound access where appropriate. Require strong authentication at the access boundary, including multi-factor authentication for human remote access. Confirm that alternative service interfaces cannot bypass the intended protections. [6]

Third, demonstrate the limit of each connection. Necessary communications should pass through controlled boundaries; a maintenance route should not confer unrestricted access across the site or its operational plant. Removing direct internet exposure is a priority in the Canadian guidance, with changes to existing OT made under controlled conditions. [2]

Fourth, show who will notice and respond to misuse. The operator needs usable records of relevant access and changes, with responsibility assigned for reviewing and acting on them. A retained log helps little if nobody can interpret it or obtain it during an incident. [6]

Fifth, demonstrate safe withdrawal of access. Practise revoking a supplier's connection and establish which local protection and operational functions remain available. NIST's OT guidance explicitly addresses disconnecting remote access without impairing operations. Isolation and recovery procedures must be tested against the site's actual safety and operational requirements. [1, 6]

Make control part of the handover

These requests can become concrete acceptance criteria. At handover, the operator should receive evidence of access routes and privileges, a documented method for withdrawing access, and an agreed responsibility for keeping both current. Subsequent changes of supplier, remote support arrangements or platform configuration should trigger a review of that evidence.

NIST's August 2026 guidance for building automation owners reinforces the relevance of cybersecurity to building operations, including access control and fire alarms. [7] The organisational consequence, in my view, is that facilities, operations, physical security and cybersecurity teams need one shared account of how these systems can be controlled.

This is also a practical expression of digital sovereignty at site level. An operator depends on specialist suppliers, but should retain the ability to govern their access and continue essential functions when that access must end. Trust in the systems that protect a site and sustain its operations should rest on demonstrable control over that technology. This control supports asset security, safe operation and resilience.

References

Sources consulted on 13 November 2026

[1] NIST. Guide to Operational Technology (OT) Security

SP 800-82 Rev. 3, September 2023. See sections 2.3.5 and 6.2.10, and Appendix F, control AC-17.

[2] Canadian Centre for Cyber Security. Cyber threat bulletin Non-state activity targeting Canadian operational technology

2026. Canadian incidents in October 2025 and recommended mitigations.

[3] Canadian Centre for Cyber Security. Cyber threat actors use artificial intelligence in an active global campaign to disrupt internet-exposed programmable logic controllers

Updated 14 September 2026. See also the sections on third parties and system integrators.

[4] Lukas Sökefeld, Concepture. Insecurity through security

27 April 2023. Research findings, affected versions and responsible disclosure outcome.

[5] Manuel Bohé, Concepture. Hackers Paradise or our presentation at Defcon A look behind the scenes

First-party account confirming the presentation at the ICS Village.

[6] UK NCSC and international partners. Secure connectivity principles for Operational Technology

15 January 2026. Joint guidance reproduced by the Australian Cyber Security Centre; especially principles 5, 7 and 8.

[7] Keith Stouffer and Michael Galler, NIST. NIST Releases Tips and Tactics for Building Automation and Control System Cybersecurity

19 August 2026.