The floor plan says “office tower,” but the reality looks more like a distributed system diagram. Access control badges feed a cloud portal. HVAC is tuned by a building management system (BMS) someone can reach over a vendor VPN. Lighting, cameras, occupancy sensors, and elevators are all quietly talking to each other and to services you don’t directly control. The building still feels like concrete and steel, but almost every critical function is now software that can be probed, abused, or held to ransom.
In this Wednesday “Headline” feature from Bare Metal Cyber Magazine, we’re looking at smart buildings as a cyber-physical domain that has slipped past most security programs. Operational technology (OT) networks, Internet of Things (IoT) devices, and cloud dashboards have converged into a new attack surface that doesn’t show up cleanly in a CMDB, an identity directory, or a traditional vulnerability scan. Over the next 12–24 months, the organizations that live and work in these environments will be judged not just on how they protect data, but on how resilient their physical environments are to digital failure.
For security and technology leaders, this isn’t just another “shadow IT” problem. Smart buildings are long-lived capital assets, designed and contracted years before your current risk model, and they will silently constrain your security posture for decades if you don’t engage. The question is no longer whether building systems are in scope, but who owns them, how they’re architected, and what failure might look like when the attack target is the environment where your people sit and your critical systems run.
From Bricks to Microservices
Twenty years ago, a building was mostly a passive backdrop: concrete, glass, mechanical systems, and a few standalone control panels buried in a basement room. Today, that same footprint is more like a cluster of loosely coupled microservices. Access control, HVAC, lighting, parking, conference room booking, visitor management, elevators, and video analytics are each running on their own hardware, firmware, and cloud portals. Every “amenity” that makes the building feel modern is another component in a distributed system, with its own update cycle, password habits, and failure modes.
This shift didn’t happen because CISOs wanted it. It arrived through real estate optimization, energy efficiency targets, and tenant experience programs. Facilities teams bought building management systems with web front-ends so operators could work from tablets. Landlords deployed mobile badge apps to differentiate their properties. Integrators stitched together occupancy sensors, cameras, and room booking to help executives brag about “smart workplaces.” Security architecture was rarely part of the earliest conversations, and yet these systems now sit adjacent to, or directly on top of, corporate networks and identity infrastructure.
For leaders, the important point is that smart building risk is baked into the capital plan, not treated as a transient technology choice. Once you embed a particular class of controllers into walls and ceilings, or commit to a vendor ecosystem across a campus, you’ve effectively locked in a cyber-physical attack surface for the life of the asset. You can harden, segment, and monitor, but you are not swapping out the entire stack every three years like laptops. That asymmetry between long-lived concrete and fast-moving code is what makes smart buildings quietly dangerous if you’re not at the table early.
Inside the Smart Building Stack
If you peel back the drywall on a modern smart building, you don’t find a single “building system” so much as a layered, mismatched stack. At the bottom sit field devices: sensors, actuators, badge readers, thermostats, cameras, elevator controllers. Above them, programmable logic controllers and gateway devices run vendor-specific firmware and protocols. On top of that, a building management system (BMS) coordinates HVAC, power, and alarms, usually with a web interface. Then, cloud portals, mobile apps, and analytics services broker data and remote access for landlords, integrators, and tenants. It’s a full-stack application, but with physical consequences.
From a leader’s perspective, the real insight is that most of the trust boundaries in this stack were drawn for convenience, not security. OT networks are often logically segmented on paper but physically bridged by unmanaged switches, repurposed firewalls, or “temporary” jump hosts that became permanent. Vendor remote access is commonly a mix of VPNs, proprietary cloud relay services, and shared integrator accounts. Identity for building operators and technicians may live in a parallel universe of local users and vendor directories, only loosely connected to your corporate identity provider, if at all. The result is an attack surface where authentication is inconsistent and accountability is blurred.
You can also assume that telemetry and control paths are intertwined in ways your IT team would never accept for core business systems. The same cloud service that surfaces energy dashboards to an iPad may also push configuration changes to controllers in a mechanical room. A mobile badge app might talk to both corporate identity providers and landlord-owned access control servers through a chain of APIs you’ve never seen. When something goes wrong—whether malicious or accidental—it’s hard to tell which layer misbehaved, who touched what, or where to pull the plug without taking the building offline.
For CISOs and technology leaders, the first step is to mentally promote this stack to the same level of architectural importance as your data center or cloud backbone. If you can’t sketch the major layers, name the top five vendors with hands in the building, or explain where OT networks intersect corporate networks, you’re not actually managing the risk. You’re renting it.
When the Building Becomes a Ransom Asset
Most leaders instinctively think about ransomware in terms of data: encrypted file shares, locked email, stolen customer records. Smart buildings introduce a different kind of leverage. Here, the asset is environmental control. Attackers don’t need to exfiltrate terabytes or post anything on a leak site. They can threaten to lock badge readers on a trading floor, disable cooling in a data room, or randomly trigger fire alarms in a hospital. The business impact is immediate, visible, and hard to work around with laptops and cloud failover plans.
The attack paths are rarely exotic. A compromised integrator account into the building management system (BMS), a cloud portal with weak MFA, an unpatched remote access gateway into the OT network, or reused credentials on a camera management system can all give an attacker enough control to cause disruption. Once inside, they don’t need to own every device; they just need to reach the handful of systems that operators rely on to keep the building habitable and compliant. Even “noisy” actions—changing setpoints, disabling elevators, turning off lighting on critical floors—can be enough to force a rapid business decision under pressure.
The more subtle risk is when building systems become a staging ground rather than the final target. If OT networks are poorly segmented from corporate networks, an attacker can quietly pivot from a “low-value” device in a mechanical room into systems with access to identity providers, file shares, or line-of-business applications. In that scenario, the building is both a ransom asset and a stealth foothold. Leaders who underestimate the building because “it’s just facilities” may only discover the connection when they’re dealing with both a physical disruption and an IT incident response.
For security and technology leadership, the takeaway is simple but uncomfortable: if someone can credibly threaten your ability to keep a building safe, accessible, and compliant, they have negotiating power, whether or not they ever touch your data. That reality changes how you think about tabletop exercises, incident communications, and what “critical infrastructure” means inside your own walls.
The Governance Vacuum Around Concrete
Smart buildings sit at the intersection of groups that rarely share a security model. Real estate focuses on occupancy, cost per square foot, and lease terms. Facilities cares about uptime, comfort, and vendor responsiveness. IT and security worry about networks, identity, and data. General contractors and integrators just want the project delivered on time. Each function makes rational decisions in its own lane, but no one is tasked with owning the end-to-end cyber-physical risk of the building as a system. The result is a governance vacuum where long-lived exposures can hide in plain sight.
You can see this in how decisions are funded and contracted. Capital projects often bundle “smart” features into construction scopes negotiated years before the current CISO arrived. Security requirements show up, if at all, as vague clauses in a statement of work rather than concrete obligations around network design, identity integration, logging, and vulnerability management. Service contracts give vendors broad remote access rights and control over critical systems, with little clarity on how authentication is handled, how changes are logged, or who is accountable when something goes wrong. When an issue surfaces, everyone points to the contract language and no one owns the architecture.
Even when IT and security are invited, they’re often brought in too late, after major vendor and design choices are locked. At that point, the conversation becomes “how do we bolt on monitoring and segmentation” instead of “how do we design a defensible smart building from the start.” Boards and executives hear about energy savings and modern amenities, not about vendor VPNs into life-safety systems or cloud portals that bypass corporate identity. Without a clear governance structure, leaders can’t answer simple questions: who approves new remote access paths, who reviews building system changes for security impact, and how incidents will be coordinated across facilities, vendors, and security during a real disruption.
For senior leaders, this is the real problem to solve. You don’t need to become an expert in building protocols. You do need to ensure that smart building decisions are pulled into the same governance arenas that handle cloud migrations, core network changes, and major SaaS adoptions. Until that happens, your organization is effectively betting its physical environment on contracts and relationships that were never designed to carry cyber risk.
Designing Defensible Smart Buildings
Designing defensible smart buildings starts with a simple shift: treat the building stack as a first-class critical system, not a side project under facilities. That means insisting on an explicit reference architecture, just as you would for cloud or identity. At minimum, you want a clearly defined operational technology (OT) network with controlled gateways, a small number of hardened jump points or proxies for remote access, and a single, well-understood pattern for how cloud portals and mobile apps talk to controllers. If you can’t draw that on a whiteboard in ten minutes, you don’t have an architecture, you have a collection of conveniences.
From there, leaders can push for a small set of non-negotiables that apply across both new construction and inherited buildings. Smart building systems should authenticate through strong, centralized identity wherever possible, with named accounts and multi-factor authentication for operators and vendors. Remote access from integrators should be brokered, logged, and time-bound, not a permanent VPN that nobody quite owns. OT networks should be segmented from corporate networks in practice, not just in diagrams, with monitoring that can at least tell you when unusual commands or configuration changes are being pushed to critical controllers. None of this is exotic; it is applying your existing security patterns to a different set of assets.
Procurement and lifecycle management are where leaders have disproportionate leverage. For new builds and major retrofits, security requirements belong in the design brief, the RFP, and the contracts: network topology expectations, identity integration, logging and data export capabilities, patch and support commitments, incident cooperation clauses. For existing buildings, the play is more incremental: inventory the most critical systems, prioritize segmentation and access cleanup, and negotiate with vendors to close the worst gaps as contracts renew. In both cases, mandate that building systems are included in incident response playbooks and exercised in joint tabletop scenarios with facilities and vendors, so nobody is trying to learn the building under stress.
Ultimately, “defensible” does not mean perfectly secure. It means you can explain, with a straight face, how an attacker would have to work to weaponize your building, what controls stand in their way, how you would detect and contain them, and who is accountable at each step. If you can answer those questions for your cloud and data center but not for your flagship office or primary data hall, your smart building strategy isn’t finished—it’s just unacknowledged.
At its heart, this topic is about recognizing that your buildings are no longer neutral backdrops for technology, but technology platforms in their own right. The cutaway view of a smart building reveals something that looks far more like a layered application than a stack of concrete and steel: sensors, controllers, networks, cloud services, and vendors all stitched together with assumptions about trust. Once you see it that way, it becomes obvious that leaving smart buildings outside your core security architecture and governance is not a gap at the margins, but a structural blind spot.
Bringing smart buildings into the fold changes how leaders think about risk and time. You start to weigh decades-long capital decisions against three-year technology lifecycles, and ask whether procurement and design are locking in exposures your successors will inherit. You begin to treat vendor remote access and OT network segmentation with the same seriousness as identity federation and cloud connectivity. The conversation with boards and executives shifts from “facilities upgrades” to “cyber-physical resilience,” and from amenities to the continuity of the environments where people and critical systems actually live.
When leaders internalize this argument, they stop tolerating ambiguity about who owns building risk and how it is managed. They insist on reference architectures for campuses, on contracts that reflect security expectations, and on incident playbooks that cover both physical and digital consequences. The next practical step is not a massive retrofit, but a better set of questions. Ask your team: if we treated this building like another critical platform, what would we change about its design, funding, and governance? And who, outside the security org, needs to be in the room before the next “smart” decision is made?