The New Reality Of Federal Building Security

Originally published on Facility Executive.

Integration and expanded policy mean federal building management platforms now require the same heavy security apparatus as sensitive data systems. – by Saruf Alam

There’s a scene playing out across more and more federal facilities. A facilities team stands up a new analytics layer or a fresh building management platform. It works — the dashboards are good, the energy data finally lives in one place, everyone is happy. Then, a few weeks later, someone from the agency’s information security office asks who has remote access to the chiller plant, where the platform sends its data, and whether it is in the system inventory. A decade ago, that question did not get asked. Today, it lands constantly, and the facilities team often has no ready answer.

That question is the visible edge of a much larger shift. In federal buildings, facilities management and information security have stopped being separate conversations. They are merging, and the merger is underway whether or not anyone planned for it.

The Networks Came Together

For years, operational technology lived on an island. The building automation network was its own thing — separate cabling, separate switches, air-gapped from the enterprise network, and comfortably ignored by everyone in IT. That era is over. In a modern facility, OT and IT increasingly ride the same physical medium: the same structured cabling, the same switching infrastructure. The OT traffic is logically segregated into its own VLANs, walled off from enterprise traffic, but that is segregation, not separation. It shares the wire.

For a security team, “shares the wire with the enterprise network” is the phrase that changes everything. The moment building systems stop being a physically isolated island, they become part of the network the CIO is responsible for defending and part of the environment the agency has to account for.

The Devices Are Software

This is not only about the top of the stack. Walk it from the bottom up. The field controller at a Variable Air Volume (VAV) box or a rooftop unit is no longer a dumb device with a couple of relays. It authenticates users. It holds credentials. It runs firmware that gets patched. It extracts and exports data, and it talks to other things on the network. Keep going up to the supervisory controllers and the head-end, and you are looking at full IT software, with user accounts, APIs, and cloud connections.

A building controller today has more in common with a small server than with the pneumatic thermostat it replaced. Once a device authenticates people, stores data, and lives on a network, it is an information system, regardless of what the label on the panel says.

Inside FISMA’s Scope

Here is where the federal context turns this from an IT-hygiene observation into an obligation. The Federal Information Security Modernization Act (FISMA) requires every agency to secure the systems supporting its operations, with authorization decisions grounded in the National Institute of Standards and Technology’s (NIST) Risk Management Framework.

For most of that framework’s life, building automation sat outside it. HVAC, access control, lighting, submetering, and energy management ran on separate networks, procured separately, maintained by contractors, invisible to the agency’s system inventory. They were not information systems in any sense the CIO’s office recognized. Two things ended that arrangement: integration — connecting building systems to enterprise networks and cloud platforms for remote management, analytics, and energy reporting — and policy catching up, as OMB guidance extended the scope of FISMA reporting to cover IoT and operational technology.

The practical consequence is blunt. A building management platform procured today may need an authorization package, an impact-level categorization, and continuous monitoring — the same apparatus applied to systems handling sensitive agency data. For anything delivered as a cloud service, that means the Federal Risk and Authorization Management Program (FedRAMP), and for the systems where a compromise would carry severe consequences, FedRAMP High.

New Rules For The FM

None of this stays in the CIO’s office. The facility manager is the boots on the ground, and every rule the security team sets lands on the FM’s day. A vendor can no longer just VPN in to fix a controller; now it is a ticket and an approval. A firmware update goes through change control. A new sensor cannot simply be dropped on the network. Most of these controls are overdue. But they mean the FM and the CIO’s office can no longer operate as strangers. When they do not talk, the FM gets locked out of their own building by a policy nobody explained, and the security team makes calls with no feel for how the equipment actually runs.

This is seen most clearly in remote access. Most federal facilities run somewhere between eight and fifteen vendor-managed systems, many with standing remote connections for maintenance. Few facilities organizations can produce a current, accurate register of those connections — who holds them, what they reach, how they are revoked. In an authorization context, that register is not housekeeping; it is evidence, and its absence is a finding.

Moving Forward

Three things are worth starting now.

Put information-system requirements into the specification. Not as an afterthought once a platform is chosen, but into the spec itself. Federal buildings never sit still; there is always an uplift, a recommissioning, a new facility coming online, a platform migration. Each one is a chance to get security right or to inherit someone else’s mess. If your specification does not state how a system authenticates, how it segments, how access is granted and revoked, and what it will take to authorize it, you will relitigate all of it on every project — and you will keep discovering at deployment that a platform chosen on operational merit cannot be authorized, which is a wasted cycle measured in quarters.

Use OT standards, not just the IT playbook. This is where well-meaning security teams go wrong: they apply the 800-53 rulebook straight to a chiller and cannot understand why the vendor will not comply or why the equipment starts tripping. OT is not IT. A controller cannot take a surprise reboot on a peak-load afternoon the way a workstation can. NIST published SP 800-82 as an operational-technology overlay of those same controls, along with a quick-start resource aimed squarely at building automation owners working with limited resources. They exist because the general controls map badly onto systems that open doors and start equipment. The CIO you want is the one who brings the discipline of 800-53 but understands that OT plays by different rules and reaches for 800-82 rather than improvising a questionnaire no vendor can answer consistently.

Give the FMs some IT training. This whole dimension has been dropped on facilities team members who were never hired to be security people, and the default is to let them sink. That wastes the most valuable people in the process. A modest amount of cyber and IT training — enough to speak the language, understand what is being asked, and own the parts they should own — turns the FM from a bystander into the person who makes authorization actually work. They are the ones who know the building.

The Bottom Line

The server room and the boiler room spent decades ignoring each other. They cannot anymore, because the boiler room now runs on software the agency has to treat as an information asset. This is not a threat to the facility manager’s job, and it is not a takeover by IT. It is a merger, and mergers go well when both sides show up early and badly when one side finds out at connection.

The disciplines the new scope demands — specification, commissioning verification, contract governance, lifecycle documentation — are ones federal facilities professionals already practice at a high standard. They have simply never been asked to apply them to connected systems on the agency’s enterprise network.

Saruf Alam is Director of Mission Control at KODE Labs, which builds a single-pane-of-glass platform for smart buildings.