Article Archives
Article Categories
Articles
Building Automation Doesn't Need a New Standard - It Needs an Owner...

As connected building systems multiply faster than the governance structures meant to secure them, the answer is not another framework. It is clear accountability for the ones that already exist.
A 332 percent jump in internet-exposed building automation devices and a widening pattern of critical vendor vulnerabilities are not, on their own, the story. The story is that most facilities management and commercial real estate organizations still cannot say who inside their walls is accountable for closing that gap.
The Numbers Are Not the Point
Two data points from 2026 describe the same industry from two directions. Joint research from Palo Alto Networks, Siemens, and the Idaho National Laboratory found that internet-exposed operational technology (OT) devices, the sensors and controls behind heating, cooling, lighting, and access systems, grew 332 percent between 2023 and 2024, reaching more than 19.6 million fingerprinted devices and services worldwide. In the same year, building automation products from at least five independently corroborated vendors, spanning access control, energy management, HVAC, and core automation software, disclosed critical or high-severity vulnerabilities, including a maximum-severity flaw in a widely deployed access control platform that left roughly 100,000 endpoints reachable from the open internet.
Read separately, these look like two more entries in an already crowded cybersecurity news cycle. Read together, they describe something more specific: building automation is being connected, networked, and opened to remote access faster than the organizations that own it are building the capacity to govern it.
That is a solvable problem, and it does not require anyone to invent a new standard to solve it.
The Frameworks Already Exist
The National Institute of Standards and Technology's Special Publication 800-82 has offered a risk management framework for industrial control systems, the category that includes building automation, for years. The International Electrotechnical Commission's IEC 62443 series remains the primary international standard for segmenting and securing automation networks. In January 2026, the Cybersecurity and Infrastructure Security Agency (CISA) published eight principles for managing connectivity into operational technology environments, and in April 2026, CISA joined the Department of Defense, the Department of Energy, the Federal Bureau of Investigation, and the Department of State in the first joint federal zero trust guidance written specifically for OT.
The core issue is organizational, not technical: None of this is new. What is missing is not guidance. It is the internal decision, inside individual facilities management (FM) and commercial real estate (CRE) organizations, to formalize who owns operational technology (OT) security when it falls between two departments that were never designed to share it: information technology (IT), which owns network security policy but rarely understands building-system operations, and FM, which understands the buildings but has not traditionally been asked to own cybersecurity.
A 2026 industry survey from OPSWAT and the SANS Institute found that 23 percent of organizations have visibility into only half or less of their own operational technology environment. That is not a patching problem. An organization cannot govern what it cannot see, regardless of how many frameworks it has adopted on paper.
One more caution belongs in this conversation. Security researchers increasingly warn that raw vulnerability counts are a weak stand-in for actual risk: a platform disclosing many low-consequence flaws is not automatically less secure than one disclosing few, if exploitation activity tells a different story. The building automation vulnerability pattern documented in 2026 matters not because six or more vendors were involved, but because the disclosures spanned access control, energy management, and core automation simultaneously, at the same moment the exposed surface grew by a third. Governance decisions should weigh exploitability and exposure alongside severity scores and counts, not counts alone.
What Ownership Looks Like in Practice
For an FM or CRE leader, closing this gap starts with a small number of concrete moves, in a specific order.
- Formalize shared ownership. First, assign accountability before the next disclosure, not after it. A documented Responsible, Accountable, Consulted, and Informed (RACI) structure between IT and FM, anchored in NIST SP 800-82, turns an implicit assumption into an explicit commitment.
- See the portfolio before prioritizing it. Second, inventory. A portfolio-wide count of internet-facing building automation endpoints is the prerequisite for every governance decision that follows it, not a parallel workstream to get to eventually.
- Harden before expanding. Third, apply IEC 62443 zone-and-conduit segmentation to the platforms with the broadest footprint, and extend the 2026 federal zero trust framework to every remote and vendor connection into building systems, starting with the connections already known to be internet-facing.
- Gate what comes next. Fourth, before extending any artificial intelligence (AI) driven analytics or maintenance platform's access into building automation systems, confirm the first three moves are already in place. The same connectivity that expanded internet exposure by 332 percent applies directly to any AI integration layered on top of it.
The Choice Ahead
The building lifecycle management community does not need to wait for a new framework, a new regulation, or a worse headline to act. Every tool required to close this gap, NIST SP 800-82, IEC 62443, and the 2026 federal zero trust guidance for operational technology, is already available and already free to adopt. What remains is a decision inside individual organizations: formalize ownership deliberately, or keep assigning it informally, one disclosure at a time.
What a Building Model Actually Does: The Hidden Layers of BIM Data

What a Building Model Actually Does: The Hidden Layers of BIM Data
For commercial real estate professionals who have never opened a model themselves, Building Information Modeling looks like an architecture and engineering tool. Underneath, it is a data structure doing work most CRE stakeholders never see.
Ask a facility management professional, an asset manager, or a portfolio director what Building Information Modeling (BIM) is, and the answer usually stops at “the 3D model the design team uses.” That is not wrong. It is just the top layer of a much deeper structure, and most of the value sits below the surface most stakeholders ever look at. Peel back that surface, and BIM reveals itself as a highly structured, interoperable data architecture that enables uses no unstructured drawing set, PDF binder, or spreadsheet ever could.
This matters to commercial real estate (CRE) professionals precisely because so few of them touch the model directly. The design and construction team builds it. Everyone downstream, facilities, operations, sustainability, portfolio management, lives with its consequences for decades. Understanding what that structure actually enables is the first step toward demanding better data at handover, rather than accepting whatever survives the transition from construction to operations.
The Data Backbone Nobody Sees
Before a BIM model does anything sophisticated, it depends on a foundation that looks almost mundane: disciplined document management. Consistent file naming, version control, and a clear record of who created, modified, or approved a given piece of information sound like administrative housekeeping. They are the precondition for everything that follows. Industry practice organizes this discipline through a Common Data Environment (CDE), an agreed single source of truth for a project’s information, a concept formalized in the international ISO 19650 standard. Without a CDE, evidence suggests that model data fragments across incompatible tools and email threads exactly the way traditional drawings and specifications always have. Structure without governance is just a different kind of clutter.

On top of that foundation sits a layer even less visible to CRE audiences: authorship accountability. In a large BIM project, dozens of contributors, architects, structural engineers, mechanical designers, subcontractors, touch the same federated model. Someone has to be accountable for each piece of it. Industry contract documents define a role called the Model Element Author, responsible for developing a specific part of the model to an agreed level of detail at each project milestone. That accountability does not disappear when construction ends. It transfers, at handover, to whoever inherits responsibility for the building’s data in operations. This is the moment where lifecycle continuity either holds or breaks. A model authored rigorously during design and construction, then handed over without a clear ownership transfer, is a Ferrari with no one holding the keys. The data exists. Nobody is accountable for keeping it current.
Coordination: Catching Problems Before They Cost Money
The layer most CRE professionals have at least heard of is coordination, commonly shorthanded as “clash detection.” What is less understood is that this is not one check but three distinct ones. A hard clash is a physical collision, a pipe routed directly through a structural beam. A soft clash is a clearance problem, two elements that do not touch but sit too close for maintenance access or code compliance. A workflow clash is a scheduling conflict, two trades needing the same physical space at the same time. Detecting all three before construction begins, rather than discovering them on site, is only possible because the model’s elements carry structured, machine-readable geometry and metadata rather than static lines on a drawing. An open, vendor-neutral exchange format maintained by the international buildingSMART standards organization allows teams using different software to share these coordination issues without exchanging entire models, evidence that this practice has matured into genuine industry infrastructure rather than a single vendor’s feature.

The same structured data enables two more uses with direct portfolio implications. Linking schedule activities to specific model objects produces a visual simulation of construction sequencing, letting a team spot a dangerous overlap of trades before it becomes a safety incident. Linking model quantities directly to cost data means a design change updates the cost estimate automatically, rather than waiting for someone to manually recalculate a spreadsheet. Neither use case is possible with a drawing set. Both depend on the same underlying structure that makes coordination checking possible in the first place.
Operations: Where the Data Should Be Paying Off
For a facility management professional, the most consequential layer is the one that arrives last: the as-built record model, enriched with equipment data, warranties, and maintenance schedules, functioning as an operational digital twin. Increasingly, this record model is paired with real-time sensor data to support predictive maintenance, flagging a component likely to fail before it does, rather than waiting for a reactive service call. Asset management, space tracking, and building systems analysis all draw from this same connected record rather than a static as-built binder handed over in a banker’s box.

Whether an owner actually receives a model this useful depends entirely on the authorship and CDE discipline described above. A building’s operational data is only as good as the handover discipline that preceded it. This is where BLMI’s building lifecycle management position has practical teeth: the industry’s persistent data silos between design, construction, and operations are not a minor inconvenience. They are the specific mechanism by which a rich, structured model degrades into an unreliable one by the time a facility management team actually needs it.
Beyond the Building: The Same Structure at City Scale
The most striking illustration of what structured BIM data enables is not a single building at all. Rome’s Department of Urban Planning, working with GIS technology partners and BIM software providers, has developed a geospatial digital twin federating dozens of individual building models with roughly a hundred layers of geographic and infrastructure data, presented at MIPIM, one of the industry’s major international real estate events. The result lets planners, investors, and citizens query an entire city’s regeneration program, buildings, transit, utilities, and services, through a single interactive model. That capability exists only because each underlying building model was built to an open, structured standard that could be federated with territorial data in the first place. An unstructured drawing set could never scale this way. A structured one can extend from a single mechanical room to an entire city without changing its fundamental architecture.

Why This Should Matter to You
None of these use cases are exotic vendor claims. The taxonomy underlying much of this catalog traces to an academic research program, not a marketing department, and every claim in this article has been checked against independent standards bodies before publication. What connects them is a single, unglamorous idea: structure is what makes data reusable across disciplines, phases, and even geographic scale. A CRE professional who has never opened a BIM authoring tool still has a direct stake in whether that structure survives from design through decades of operation, because every use case described here, from clash avoidance to predictive maintenance to citywide digital twins, depends on the same foundation holding together at every handoff.

The practical takeaway is not “go learn to model.” It is “start asking what happens to the model after it stops being someone else’s problem.” Building Lifecycle Management exists because that question rarely has a good answer yet, and closing that gap benefits everyone who inherits a building after the design and construction team moves on to the next project.
Building Lifecycle Management Initiative (BLMI) | 2026
This article draws on a validated research brief produced by BLMI, cataloging BIM data use cases described in a series of technical articles published by ACCA Software, cross-checked against Penn State University’s BIM Project Execution Planning Guide, the American Institute of Architects’ contract documents, BIMForum, buildingSMART International, ISO 19650, and independent reporting on "Digital Twin Roma Capitale" initiative.