hysical security platforms now depend on cloud services, identities, APIs and remote access, requiring security teams to understand the cyber risks behind connected systems today.


P


Ask a security manager to describe an access control system and the answer will usually begin with doors, readers and cards. Ask the IT department about the same system and the answer sounds different: a server, a database, hundreds of user accounts, several open network ports and a maintenance contract with a supplier that connects remotely to keep everything running.


Both answers are accurate. Only one of them tends to appear on the security risk register.


That gap matters because the physical security estate has quietly become an IT estate. Access control platforms run in the cloud. Credentials live on phones. Cameras stream to video management systems on corporate networks and require patching like any other server. Visitor management systems collect personal data and display it at reception. Guard workforce platforms track patrols through mobile devices.


Control rooms increasingly depend on APIs that exchange information between systems bought years apart from different suppliers.


This does not make physical security professionals responsible for every aspect of cyber security. It does make them responsible for systems that carry cyber risk. That is a different job from the one many physical security teams were originally trained to perform.


Convergence on site


The convergence is rarely dramatic. It appears through small, ordinary decisions.


An installer requests a remote access account to support the system outside working hours, and the account is granted permanently rather than for the duration of the work. A camera firmware update is deferred because the site cannot accept an outage during trading hours, then deferred again and eventually forgotten. An HR platform is integrated with access control so new starters receive badges automatically, but nobody establishes what will happen to the connection when the HR platform is replaced. A contractor returns a card within an hour of leaving, while the contractor's login to the


25


management console remains active two years later.


Each example represents a decision that a physical security team makes, influences or fails to question. Addressing these risks does not require deep technical knowledge. It requires somebody in the room who recognises that the question exists and knows who must answer it.


Cyber skills that matter


There is a reasonable concern that developing


cyber skills means learning to write code or configure firewalls. For most physical security roles, it does not. The useful capability is narrower: holding an informed conversation with IT, a supplier and a client about how a security system is connected, administered and recovered.


Some of the related areas are:


Identity and access. Every system has accounts, and those accounts need the same lifecycle discipline that badges have always required. Who can create an operator? Who approves access? What happens on the day somebody leaves? A leaver process that reclaims a card but not a console login is only half a process.


Privileged and shared accounts. Administrative accounts can change permissions, disable alarms, alter schedules and delete audit records. When engineers share an account, or retain the default password used during commissioning, there is no reliable way to attribute an action to an individual. That matters most when attribution is the purpose of the system.


Patching and lifecycle. Controllers, cameras and intercoms are computers with operating systems and support horizons. Record when each device stops receiving security updates in the same asset schedule used for planned replacement. Equipment can remain mechanically sound while falling out of software support. That should be a conscious risk decision, not an accidental one.


Vendor remote access. Many organisations rely on suppliers to connect remotely and diagnose faults. Ask whether that access is time-limited, individually attributable, logged and disabled when the contract ends. This remains one of the controls most frequently handled poorly.


© CITY SECURITY MAGAZINE – AUTUMN 2026


Integrations and APIs. When two systems communicate, something is normally holding a credential that permits the exchange. Somebody should know what that credential is, what it can do, where it is stored and who is responsible for rotating it. 'The integrator set it up' is not an answer that survives an incident review.


Logging and escalation. Access control systems produce rich audit trails that may remain unread until an incident occurs, by which time the retention period may have expired. Decide what is retained and for how long. More importantly, decide whom to call at 2 a.m. when the system becomes unreachable and nobody yet knows whether the cause is a network failure, a supplier issue or a cyber incident.


Ownership cannot be shared


Connected security systems often sit between organisational boundaries. The security manager owns the operational requirement. IT controls the network and identity services. An installer commissions the equipment. A software provider operates the cloud platform. A facilities team may hold the budget. Everyone owns a portion of the system, which can mean nobody owns the complete risk.


The answer is not to make one team responsible for everything. It is to name a business owner for each system and document the supporting responsibilities. The owner should know where the system is hosted, which supplier can access it, who approves privileged accounts, who schedules patches, how backups are tested and who leads recovery. IT should define the technical controls and escalation route. Suppliers should provide support dates, access records and clear notification procedures. Physical security should confirm that the controls still support operational needs, including emergency access and continuity during an outage.


www.citysecuritymagazine.com


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36