Bare Metal Cyber

Picture yourself standing in the lobby of your flagship office tower. On the surface, it’s concrete, glass, and steel. But just beneath that polished finish is something that looks a lot more like a distributed system than a piece of real estate. Access badges are talking to a cloud portal. Air conditioning is tuned by a building management system someone can reach through a vendor tunnel. Cameras, lighting, occupancy sensors, and elevators are all quietly exchanging data with services you do not fully control. That is the world we are walking into today.

You are listening to a Wednesday “Headline” feature from Bare Metal Cyber Magazine, developed by Bare Metal Cyber. In this episode, we are exploring smart buildings as a quiet new attack surface: how the technology that runs the places where your people work has become tightly coupled with your core digital risk, and what that means for you as a security or technology leader over the next few years.

For a long time, buildings were treated as a backdrop. They were a fixed cost on the balance sheet, a set of mechanical systems buried in a basement, and some contracts with landlords and facilities vendors. Cyber risk lived somewhere else, in data centers, in cloud platforms, in laptops and phones. That mental model no longer fits. As buildings have become more “smart,” the things that make them efficient and pleasant to occupy have quietly turned them into platforms: stacks of software, devices, and cloud services that behave like any other complex system an attacker can explore, abuse, or hold to ransom.

The important point is that this shift did not happen because security leaders asked for it. It happened because real estate teams wanted better space utilization numbers, executives wanted modern amenities, and facilities leaders wanted to hit energy and sustainability targets. Along the way, the building picked up a building management system, mobile badge apps, cloud dashboards, and third-party analytics. Each decision was rational within its own lane. Taken together, they turned the building into a live digital environment that now sits right next to your core business systems.

If you roll the clock back twenty years, most offices and campuses were still mostly “dumb.” You had physical keys, standalone badge systems, analog cameras, and mechanical controls that required a person on-site to change anything meaningful. Today, look at that same footprint and you will find control systems and services everywhere. Heating and cooling are managed by a building management system, often abbreviated as B M S, with a web interface and remote access. Doors are run by networked controllers. Cameras stream into cloud video platforms. Lighting, parking, visitor management, and room booking all have their own apps and portals. The building is no longer a single system. It is a cluster of loosely coupled microservices.

Those capabilities did not arrive as a cohesive architecture. They arrived as projects. A landlord chose a mobile access vendor to differentiate the property. A contractor installed networked thermostats for energy reporting. An integrator wired up occupancy sensors to feed a space planning dashboard. None of that is inherently bad. The problem is that security architecture was rarely part of the first conversation. As a result, the attack surface grew in pieces: here a vendor remote access path, there a set of shared credentials, somewhere else a “temporary” connection into the corporate network that never quite went away.

What makes this hard for leaders is the time horizon. When you approve a cloud app, you can replace it in a few years if it no longer fits your risk tolerance. When you embed a particular class of controllers in walls and ceilings, or standardize on a vendor stack for a campus, you are making a bet that will live for decades. Buildings are long-lived capital assets. Code is not. That mismatch creates an asymmetry where early decisions about smart building technology silently shape your cyber-physical risk posture for a very long time.

To make sense of the risk, it helps to mentally cut away the walls and look at the smart building as a stack. At the bottom, you have field devices: sensors that measure temperature and motion, actuators that open dampers and doors, badge readers, cameras, and elevator controllers. Above them sit control devices running specialized firmware: the small computers that speak building protocols and coordinate the physical behavior of systems. On top of that, you have the building management layer, which pulls data together and lets operators see and adjust the environment. Layered above that are cloud portals, mobile apps, analytics platforms, and integration services owned by landlords and vendors.

From there, you can draw in the networks that connect it all. Often there is an operational technology network, usually shortened to O T, that links control systems and field devices. Sometimes it is logically separate from the main corporate network. Sometimes it is physically mixed in, using shared switches and shared cabling. Remote access for integrators and vendors is usually provided through some combination of virtual private networks, often called V P Ns, proprietary cloud relay services, and remote desktop gateways. On paper, all of this looks neat and segmented. On the ground, the reality is frequently messy and driven by convenience.

The most important insight for a leader is this: most of the trust boundaries in that stack were drawn for operational ease, not for security. Facility teams want to be able to connect quickly when something breaks. Vendors want to support many customers with minimal friction. Landlords want to onboard and offboard tenants without re-architecting the building each time. As a result, identity for building operators often lives in a parallel universe of local accounts and vendor directories. Logging is incomplete or hard to get out of proprietary systems. The same service that presents a nice dashboard on a tablet may also be able to push configuration changes down to devices that control life-safety functions.

When you look at it this way, it becomes easier to see how a smart building can become a leverage point for attackers. Most discussions of ransomware focus on data: file shares, mail systems, customer records. But in a smart building, the attacker does not have to touch your data at all to create a crisis. If someone can credibly threaten your ability to keep the building safe, accessible, and compliant, they have bargaining power. Locking badge readers on key floors, disrupting cooling in areas with critical systems, or causing repeated false alarms can create immediate, very visible pain for the business.

The attack paths that lead to that leverage are rarely exotic. They may start with a compromised integrator password into the building management system. They may begin with a cloud portal that was never put behind strong multi-factor authentication. They may involve a misconfigured remote access gateway into the O T network or a set of reused credentials on a camera management system. Once an attacker is in a position to talk to the systems that operators rely on, they do not need to control everything. They just need to influence enough of the environment that you have to take them seriously.

A more subtle risk is when the building becomes a staging ground instead of the final target. If the O T network and the main corporate network are loosely separated, or joined through ad hoc devices, then compromising a “low-value” device in a mechanical room can become the first step in a deeper intrusion. From that foothold, an attacker can look for pathways into identity systems, file shares, or line-of-business applications. In that scenario, the building is both a potential ransom asset and a quiet way into more traditional targets. The fact that it sits outside many core security processes makes it an appealing option.

When something goes wrong in that environment, it also becomes very clear how little shared ownership there is. Smart buildings live at the intersection of real estate, facilities, information technology, security, general contractors, and specialist vendors. Real estate leaders are measured on occupancy and cost per square foot. Facilities leaders are judged on comfort, uptime, and how quickly they can resolve issues. Technology and security leaders focus on data and systems that clearly belong to the business. General contractors and integrators are rewarded for delivering projects on time and on budget. Each group makes decisions that make sense locally, but no one is naturally assigned to own end-to-end cyber-physical risk for the building as a whole.

You can see that gap reflected in contracts and funding models. Capital projects that add “smart” features are often scoped and negotiated long before the current security leadership team is involved. Security requirements, when they appear, are written as vague language about “following best practices” rather than clear expectations about network design, identity integration, logging, and vulnerability management. Service agreements may grant vendors broad remote access rights with little detail on how authentication is handled or how changes are tracked. When an incident happens, everyone points at the contract, and no one points at a shared architecture.

Even when technology and security teams are invited into the conversation, it is often too late. They are brought in after vendor choices have been made and systems have been designed. The discussion then becomes one of bolting on monitoring and segmentation around fixed decisions, instead of designing a defensible smart building from the beginning. Meanwhile executives and boards hear about modern amenities, energy savings, and employee experience improvements. They do not hear about how vendor tunnels connect into life-safety systems, or how cloud portals may bypass your normal identity and access patterns entirely.

For senior leaders, this governance vacuum is the most dangerous part of the story. You do not need to become an expert in every building protocol to move the risk in a meaningful way. You do need to make sure smart building decisions are pulled into the same governance arenas that handle large cloud migrations, core network changes, and major software adoptions. Until that happens, you are effectively delegating a significant part of your cyber-physical exposure to contracts and relationships that were never designed to carry that weight.

So what does it look like to design and operate defensible smart buildings instead of just convenient ones? It starts with a mental upgrade. You treat the building stack like a first-class critical system, alongside your data center, your cloud backbone, and your identity platform. That means insisting on an explicit reference architecture for campuses and major sites. At minimum, you want well-defined O T networks with controlled gateways, a very small number of hardened jump points or proxies for remote access, and a clear pattern for how cloud services and mobile apps talk to the devices that actually move doors, fans, and elevators.

From there, you can define a few non-negotiables that apply regardless of which vendors or technologies are involved. Smart building systems should authenticate through strong, centralized identity wherever it is practical, with named accounts for operators and vendors and with multi-factor authentication where risk justifies it. Remote access for integrators should be brokered, logged, and time-bound, not an always-on virtual private network that lives outside your normal change processes. Separation between O T networks and corporate networks should be implemented in reality, not just on diagrams, with monitoring that can show when unusual commands or configuration changes are being pushed into critical systems.

Procurement and lifecycle management are the levers where leaders often have the most influence. For new construction and major retrofit projects, you can embed security expectations in the design brief, the selection process, and the contracts. That might include required network topologies, expectations for how systems integrate with your identity provider, requirements for exporting logs and telemetry into your monitoring stack, commitments for patch support, and clear language about how the vendor will cooperate with incident response. For existing buildings, the path is more incremental: you start by identifying the most critical systems, you prioritize cleaning up access and segmentation around them, and you use contract renewals as opportunities to close gaps.

In both new and old environments, incident preparation matters. Building systems should be visible in your incident response plans and should be exercised in joint tabletop sessions that bring facilities, vendors, and security together. The goal is not to scare anyone. It is to make sure that when something goes wrong, the people with their hands on the systems and the people responsible for risk and communication already know how they will work together, and which levers they can safely pull without creating secondary crises.

Defensibility here does not mean you can prevent every attack or every failure. It means you can explain, in a straightforward way, how someone would have to work to weaponize your building, what stands in their way, how you would detect and contain them, and who is accountable at each step. If you can tell that story for your cloud environment and your data center but not for the buildings that house your people and your critical systems, then your smart building strategy is unfinished.

At its core, this topic is about changing how you see the physical spaces your organization relies on. They are no longer neutral backdrops where technology happens. They are technology platforms themselves, with their own stacks, their own vendors, their own attack paths, and their own failure modes. Once you internalize that, it becomes much harder to dismiss smart building risk as “just facilities,” or to accept that major capital projects can move forward without serious security review.

Bringing smart buildings into your mainline security and technology conversations changes the questions you ask. You start weighing decades-long capital decisions against the three-to-five-year cycles of software and services. You look at vendor tunnels into building systems through the same lens as identity federation and cloud connectivity. You shift the conversation with executives from amenities and aesthetics to cyber-physical resilience and the continuity of operations in the places where your people actually sit.

The practical next step is not a sweeping retrofit of every system in every building. It is to ask better questions and to pull the right people into the room. Ask your teams whether they can sketch the architecture of your most critical sites. Ask who controls remote access paths into building systems, and how those paths are authenticated and monitored. Ask whether incident playbooks cover scenarios where the building itself is degraded or misused as part of an attack. And ask who outside the security organization has effective veto power over smart building decisions today.

Once those questions are on the table, you can start moving. You can prioritize a small set of buildings or campuses where the business impact would be highest. You can establish design patterns for upcoming projects so that each new “smart” feature lands in a known, defensible way. You can use renewals and renovations as opportunities to bring older sites closer to that standard. Over time, you shift smart buildings from a blind spot at the edge of your risk map to a set of platforms you understand, can explain, and can reasonably defend.