Why Traditional Patch Management Fails in Smart Buildings

Part 5 of the series 

The Building Is Now Part of the Attack Surface

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

One of the first questions security teams ask after discovering an unsupported building controller is remarkably predictable.

“Why hasn’t it been patched?”

It is also the wrong question.

Not because patching is unimportant.

But because modern building infrastructure does not operate under the same assumptions as enterprise IT.

The expectation that every vulnerability should be addressed through rapid patch deployment reflects decades of experience with laptops, servers and cloud workloads.

Buildings follow a different reality.

Understanding that difference is essential.

Ignoring it creates security programmes that look mature on paper while becoming impossible to implement in practice.

The Patching Mindset

Enterprise IT has built its security philosophy around continuous change.

New vulnerabilities appear daily.

Operating systems evolve monthly.

Browsers update automatically.

Cloud services deploy changes continuously.

Endpoint management assumes that systems can be restarted, rebuilt or replaced with relatively limited operational impact.

Success is measured by:

• patch compliance,
• deployment speed,
• vulnerability reduction,
• exposure windows,
• automation rates.

These metrics work well in conventional IT.

They become problematic when transferred directly into operational building environments.

Buildings Operate on Different Time Scales

Most office computers remain in service for four or five years.

Many building systems remain operational for twenty years or more.

Some critical installations exceed thirty years.

During that lifetime:

• manufacturers merge,
• software platforms disappear,
• operating systems become obsolete,
• suppliers change,
• documentation is lost,
• spare parts become scarce,
• technical knowledge retires with experienced engineers.

The building continues functioning.

The cybersecurity assumptions under which it was designed do not.

Availability Comes First

A failed software update on a laptop is inconvenient.

A failed software update on a building automation controller may interrupt:

• heating,
• cooling,
• ventilation,
• pressure regulation,
• access control,
• energy distribution,
• environmental monitoring,
• critical facilities.

Facility managers therefore ask different questions.

Not:

“Can we install the patch?”

Instead:

“What happens if the patch fails?”

That distinction changes everything.

Unsupported Does Not Mean Replace Immediately

Security teams often identify unsupported operating systems as critical findings.

Technically, they are correct.

Operationally, replacement may not be realistic.

Why?

Because replacing one controller may require:

• shutting down entire building sections,
• recertifying installations,
• replacing dependent hardware,
• upgrading proprietary software,
• redesigning interfaces,
• retraining operators,
• obtaining regulatory approvals,
• coordinating specialist contractors.

The vulnerability may be discovered in minutes.

Replacing the affected infrastructure may require years.

Vendor Dependency

Enterprise IT usually controls software deployment.

Building technology often does not.

Updates frequently depend on:

• manufacturer approval,
• certified firmware,
• system integrators,
• contractual maintenance windows,
• compatibility testing,
• operational acceptance.

The organisation cannot simply download the latest software.

It must wait until the vendor confirms that the update will not compromise operational safety or system stability.

Cybersecurity often sees delay.

Facility management sees responsibility.

Both perspectives are legitimate.

When Security Creates Operational Risk

An uncomfortable truth exists.

Sometimes a security update increases operational risk.

Imagine updating a building management platform controlling multiple sites.

Unexpected consequences could include:

• communication failures,
• incompatible field controllers,
• unavailable monitoring,
• incorrect sensor readings,
• access-control disruption,
• unstable automation logic.

No responsible facility manager ignores those possibilities.

The objective is not simply to reduce cyber risk.

It is to reduce enterprise risk.

The Legacy Dilemma

Every organisation eventually reaches the same conclusion.

Some critical systems cannot be patched immediately.

That reality does not represent failure.

Ignoring it does.

A mature ISMS accepts operational constraints without accepting unmanaged risk.

The response changes from:

“Patch immediately.”

to

“How do we safely operate until replacement becomes possible?”

That question leads to better governance.

Compensating Controls Matter

Cybersecurity has always recognised compensating controls.

Building infrastructure depends on them.

Examples include:

• network segmentation,
• application allow-listing,
• restricted remote access,
• privileged identity governance,
• configuration management,
• engineering workstation protection,
• enhanced monitoring,
• strict maintenance procedures,
• physical access restrictions,
• supplier supervision.

The objective is not perfection.

The objective is controlled exposure.

Vulnerability Management Is Not Patch Management

Many organisations use both terms interchangeably.

They should not.

Patch management is one possible response.

Vulnerability management is a governance process.

Possible responses include:

• applying a patch,
• replacing equipment,
• disabling functionality,
• isolating networks,
• reducing privileges,
• increasing monitoring,
• implementing temporary controls,
• accepting documented residual risk.

Thinking beyond patches is particularly important in operational environments.

Procurement Determines Tomorrow’s Problems

Most legacy systems begin as new systems.

The security decisions made during procurement determine whether future patch management becomes manageable—or impossible.

Questions that belong in procurement include:

• How long is security support guaranteed?
• How are vulnerabilities reported?
• Can firmware be updated securely?
• Does the platform support modern authentication?
• Can logging be integrated into enterprise monitoring?
• How are cryptographic functions maintained?
• Is vendor lock-in unavoidable?
• Can unsupported components be replaced independently?

Every unanswered procurement question eventually becomes an operational security problem.

The Executive Perspective

Boards often request vulnerability metrics.

Those metrics rarely explain reality.

Imagine two organisations.

Organisation A patches ninety-eight percent of systems within fourteen days.

Organisation B patches only seventy percent.

Which organisation is more secure?

The answer depends entirely on context.

If Organisation B has systematically isolated unsupported operational systems, implemented strong supplier governance, introduced continuous monitoring and funded replacement programmes, its actual enterprise risk may be lower.

Metrics without operational understanding create dangerous conclusions.

Bridging the Gap

The relationship between cybersecurity and facility management changes once both sides recognise a simple truth.

Neither is arguing against security.

They are managing different consequences.

Cybersecurity fears compromise.

Facility management fears operational disruption.

Enterprise resilience requires balancing both.

That balance is impossible if patch management remains an IT-only discussion.

What Mature Organisations Do Differently

Organisations with mature cyber-physical governance:

• distinguish vulnerability management from patch deployment,
• classify systems according to operational criticality,
• establish risk-based maintenance windows,
• integrate facility managers into vulnerability governance,
• define compensating controls,
• monitor unsupported systems more closely,
• fund lifecycle replacement programmes,
• include security requirements in procurement,
• report residual risk transparently to executive management.

Most importantly, they stop measuring security maturity by patch speed alone.

They measure how effectively cyber risk is managed throughout the entire system lifecycle.

Conclusion

Patch management is one of cybersecurity’s greatest success stories.

It is also one of its most misunderstood concepts when applied to smart buildings.

Buildings do not fail because facility managers dislike security.

They fail when organisations apply enterprise IT assumptions to operational environments without understanding their constraints.

The challenge is therefore not choosing between cybersecurity and operational continuity.

The challenge is governing both.

Because the most resilient building is not necessarily the one that installs patches the fastest.

It is the one that understands its risks, documents its constraints, applies appropriate compensating controls and plans continuously for secure lifecycle replacement.

Security maturity is not measured by how quickly systems change.

It is measured by how responsibly organisations manage the systems that cannot.

Publication Note & Disclaimer
This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.