Axis Communications’ Steven Kenny argues that data centre operators need clear ownership of cybersecurity risk across physical security systems. 

Imagine a vulnerability is discovered in a camera protecting a data centre. Responsibility immediately crosses several functions: the security team relies on its images, an integrator maintains the installation, and IT controls the network to which it connects. Who decides whether that device can safely remain connected, and who ensures the decision is carried out?

Operators should be able to answer that question without first untangling a maintenance contract. Yet unclear responsibility can leave a known vulnerability unresolved while each team waits for another to act.

The EU’s Critical Entities Resilience (CER) Directive reflects a wider focus on strengthening the ability of essential service providers to withstand disruption. For data centre operators, that raises a further question: whether the systems installed to protect the facility could become a source of disruption themselves – a question that should be considered throughout the commissioning and deployment process.

Ownership must start at design

Connected physical security belongs within normal cyber governance, with an accountable owner throughout its operational life. The process of defining responsibility begins early because physical security projects involve several groups with different duties. A designer specifies the system, an integrator configures it and the operator takes it into service. Each may complete their work correctly without establishing who will manage the device’s cybersecurity months and years later.

A maintenance agreement can leave that question unanswered if its scope centres only on keeping the equipment functional. Restoring a lost video image and assessing a newly disclosed software vulnerability are very different tasks. Operators need to establish explicitly who monitors security advisories and who has the authority to approve remedial work.

There should also be a named person within the operating organisation who remains accountable when work is contracted out. Suppliers and service partners can carry out maintenance, but the operator still needs to understand which risks remain and whether the response is adequate.

This is particularly important when a fix cannot be applied immediately. Operational constraints may justify a delay, but someone must accept that exposure knowingly, record the reason and set a review date. Without those steps, a temporary exception can persist long after the circumstances that justified it have changed.

Assess what compromise would expose

The cybersecurity of physical security equipment deserves attention because of both its network connections and its purpose. A camera is a computer: it runs software, handles data and communicates across the network. Its position on a wall does not make it any less important than equipment in the rack. In some respects, its compromise may be more consequential because of what it can see and what it can reach.

It could, for example, reveal the layout of sensitive areas or patterns of activity within the facility. An attacker may gain useful intelligence without interrupting the video service or causing an obvious operational fault. Depending on the network design and permissions, a vulnerable device could also provide a foothold from which to investigate other systems. The risk attached to a device is therefore determined less by its purchase price than by what it can observe, access and reach.

For operators, determining this means checking the actual deployment rather than relying on a specification sheet. Security equipment should have only the access needed for its role, within an appropriately segmented network. The review should establish who can administer it and whether its configuration and firmware remain under control. A diagram approved during design cannot establish whether those conditions are in place in practice.

Make support part of the buying decision

Procurement of a connected device is also a commitment to maintaining its security for as long as it remains in service. The team that will manage a device’s security should have a say in whether the organisation buys it, because the purchase creates a maintenance obligation that can last for years.

A specification establishes whether equipment performs the required function. It does not, by itself, prove how securely the manufacturer develops and maintains its software. Operators also need evidence of vulnerability management, secure update processes and long-term support commitments.

Provenance deserves the same attention. Weaknesses introduced during manufacture or through compromised firmware can undermine a device before local configuration has been considered. Procurement teams should ask what evidence supports the supplier’s security assurances and how concerns will be investigated.

Support duration must also be weighed against the intended service life. Equipment can continue producing a usable image long after its software support has ended. If replacement decisions are based only on physical reliability, the data centre can inherit a functioning device that has become a cybersecurity liability.

Before approval, the operator should understand how that situation will be handled and who will fund replacement. A lower acquisition cost is difficult to defend if the organisation has made no provision for keeping the equipment secure.

Test the decision before an incident

An installation audit only records the state of the system at a particular point in time. Over time, software changes and maintenance arrangements evolve. Operators need evidence that the responsibilities agreed at procurement still work under those changing conditions.

A practical starting point is to select a connected security device and walk through a hypothetical vulnerability affecting it. Can the team identify whether the device is affected? Who assesses the exposure, and who authorises a change? If an update requires an interruption to coverage, how will the security team manage that period?

This exercise tests whether documented responsibilities translate into an operational response – before that response is needed. It can reveal, for example, that the organisation knows who installs updates but has never assigned responsibility for deciding how urgently they are needed. That kind of omission is far easier to correct during planning than under the pressure of a live incident.

The wider focus on essential service continuity gives data centre leaders a reason to examine where unclear ownership could delay a response. They should use these exercises to assign responsibility and deadlines for unresolved risks. Where equipment can no longer be maintained securely, the decision must reach someone authorised to fund replacement or accept continued exposure. A maintenance team without that authority cannot settle the question on the operator’s behalf.