A facilities team can secure every exterior door and still leave the building exposed through a forgotten remote connection to an air-handling controller. An IT team can require multifactor authentication and still lose control when an installer plugs an unmanaged laptop into a telecom room switch. Zero trust addresses these gaps, but only when it is treated as an operating model, not a software purchase.
For commercial properties and enterprise environments, the issue is larger than user logins. Connected buildings rely on networks, controllers, cameras, access systems, tenant services, cloud applications, maintenance providers, and temporary project access. Each connection creates a decision: who is allowed in, what can they reach, how long should access last, and who owns the answer when something goes wrong?
What Zero Trust Means in a Connected Building
Zero trust is often reduced to a simple slogan: never trust, always verify. That is directionally correct, but it does not tell an operations leader what to govern.
In practice, zero trust requires every request for access to be evaluated using evidence. The user or service must be known. The device must meet the organization’s requirements. The requested resource must be appropriate for that role. Access must be limited to what is needed, and activity must be visible enough to investigate when conditions change.
That applies to more than employees opening email. It applies to a building engineer accessing a supervisory workstation, a security contractor reviewing camera systems, a third party supporting a controller, and an automated device sending data to a management platform. A badge reader, a wireless access point, a laptop in a mechanical room, and a remote support account should not receive trust simply because they are inside the property or connected to the network.
The principle is straightforward: location is not identity, and a network connection is not authorization.
Why Traditional Building Networks Create Blind Spots
Many properties were built around a perimeter assumption. If a device was connected to the internal network, it was often treated as safe enough to communicate broadly. That model may have been convenient when systems were isolated and vendor support required occasional onsite visits. It breaks down when operational technology, physical security, corporate IT, and remote service access share infrastructure.
The trouble is rarely one bad configuration. It is accumulated fragmentation. The cabling contractor hands off to the network team. The network team hands off to a security integrator. A facilities vendor receives remote access through a temporary exception that becomes permanent. A property changes management firms, but old accounts remain. Documentation is incomplete, so no one can confidently identify what is connected, why it is connected, or who approved it.
An attacker does not need access to every system. One poorly governed connection can provide a path to systems that should have been separated. The same is true for ordinary operational mistakes. A vendor can accidentally modify the wrong controller, a compromised device can scan across segments, or a former employee can retain access longer than intended.
Zero trust reduces the blast radius of these failures. It does not eliminate the need for secure cabling, segmented networks, managed switching, physical protection of telecom rooms, or reliable backups. It makes those controls work as a coordinated system instead of a collection of isolated projects.
Start With Ownership Before Technology
The first zero trust question is not which tool to deploy. It is who owns access decisions across the lifecycle of the building and its systems.
That ownership must be clear at design, construction, turnover, daily operations, and incident response. If one party provisions identities, another manages network ports, a third controls building applications, and no one owns the combined process, exceptions will become the real policy.
A practical governance model identifies a single accountable owner for each asset class and access path. That does not mean one person performs every task. It means there is no ambiguity about who approves access, reviews it, maintains records, and closes it when a project, contract, tenancy, or employee relationship ends.
For example, a remote maintenance connection should have a documented business owner, a technical owner, an approved access method, a defined expiration process, and a record of the systems it can reach. If any one of those elements is missing, the connection is not fully governed.
This is where property and enterprise leaders can make immediate progress. Require a common access standard from every contractor, integrator, managed service provider, and internal department. One standard does not mean every system must operate identically. It means exceptions are visible, justified, time-bound, and approved by someone accountable for the risk.
Build an Access Inventory That Operations Can Use
Zero trust depends on knowing what exists. A spreadsheet created during commissioning and never updated is not an inventory. A usable inventory supports decisions during normal operations and during an outage.
At minimum, it should connect people, devices, systems, and access methods. For each asset, record its location, owner, purpose, network segment, support relationship, software or firmware status, and whether it can be accessed remotely. For each external party, record the named individuals or approved support process, the systems in scope, the method of connection, and the expiration or review date.
The inventory should include systems that are easy to overlook: UPS monitoring cards, environmental sensors, wireless bridges, digital signage players, audiovisual control systems, printer interfaces, door controllers, and temporary construction networks. These often sit outside the normal IT purchasing process but still connect to valuable infrastructure.
The goal is not paperwork for its own sake. During an incident, teams need answers quickly. Which devices are on this segment? Who supports this controller? Can this remote account be disabled without affecting life safety, tenant operations, or critical maintenance? Without current records, every response becomes a search across email chains and vendor phone calls.
Apply Least Privilege to People, Devices, and Vendors
Least privilege means granting only the access required for a specific function. It is a familiar security concept, but connected facilities need to apply it more consistently.
A vendor supporting camera storage should not automatically reach access control systems. A technician troubleshooting a controller should not receive broad administrative access to the corporate network. A property manager who needs reporting may not need configuration rights. A temporary project account should not remain active after final acceptance.
Network segmentation is a central control here. Separate operational technology, physical security, tenant services, corporate systems, guest networks, and management interfaces according to risk and operational need. Segmentation is not a substitute for identity controls, but it limits how far an error or compromise can travel.
Device posture matters as well. A known, managed engineering workstation is different from an unknown laptop connected during an emergency service call. The response should reflect that difference. Where legacy equipment cannot support modern authentication or endpoint controls, compensate with restricted network paths, tightly controlled jump access, monitoring, and documented support procedures.
This is one of the areas where the answer depends on the environment. Older building systems may not tolerate aggressive scanning, frequent patch cycles, or unsupported security agents. Treating every device like a modern office laptop can create outages. The right approach is risk-based: understand the limitation, isolate the system appropriately, and assign an owner to review the exception.
Make Remote Access Temporary, Traceable, and Tested
Remote vendor access is one of the most common ownership gaps in commercial environments. It is also often necessary. A specialist may need to diagnose a fault after hours, support a critical repair, or provide updates without traveling onsite. The objective is not to ban remote access. It is to make it controlled.
Access should be tied to a named person or a documented approval process, not a shared account that outlives the people using it. It should be limited to the required systems, protected by strong authentication, logged, and removed when the work is complete. For recurring support, establish scheduled reviews rather than assuming a standing connection is harmless.
Test the offboarding process, too. Ask a simple operational question: if a contractor’s engagement ended today, could the organization identify and remove every account, credential, remote session method, and physical access privilege by the end of the day? If the answer is uncertain, the access program is not ready.
Zero Trust Needs an Incident Runbook
Controls matter most when something fails. A zero trust program should therefore produce usable runbooks, not just policy statements.
The runbook should identify who can isolate a network segment, revoke a vendor connection, disable an account, contact system owners, preserve logs, and authorize restoration. It should account for the operational consequence of isolation. Taking a system offline may protect the network but affect access control, camera visibility, environmental monitoring, or tenant operations.
Exercise realistic scenarios with the people who would actually respond. A lost engineering laptop, an unauthorized device in a telecom room, a suspicious remote login, or a controller behaving unexpectedly will expose whether responsibilities are clear. These exercises also reveal where documentation, access rights, and escalation paths have drifted.
The most effective zero trust programs are not built around distrust of people. They are built around disciplined verification and clear responsibility. When every connection has an owner, every exception has a reason, and every response path is practiced, a building becomes easier to operate under pressure. That is the standard worth carrying from project design through final acceptance and every day after.