A building can have current antivirus coverage, a well-run help desk, and a documented incident-response plan - then still be one vendor connection away from losing visibility into critical building systems. An OT security assessment examines that gap: the systems that run the physical environment, the pathways into them, and the people accountable for keeping them available.
For property and operations leaders, this is not an abstract cyber exercise. A compromised or unstable operational technology environment can interrupt access control, surveillance, environmental controls, power monitoring, life-safety interfaces, tenant operations, and the ability to respond when something goes wrong. The immediate question is not whether every device can meet a traditional IT security standard. It is whether the organization knows what it operates, how it is connected, who can change it, and what happens when it fails.
What an OT security assessment should answer
Operational technology includes the control systems, field devices, gateways, supervisory platforms, and remote connections used to monitor or operate the built environment. In a commercial property, that can include building automation, lighting control, power and energy monitoring, elevator interfaces, video systems, access control, industrial controls, and associated management networks.
An assessment should produce decisions, not just a long list of findings. It should answer four practical questions: What is connected? Who owns it? Who can access it? What could cause an outage or unsafe operating condition?
That requires more than a vulnerability scan. In many live environments, active scanning can disrupt fragile or undocumented devices. A disciplined assessment starts with passive discovery, existing documentation, configuration review, and structured interviews with facilities, IT, security, and service providers. Testing must be planned around operational windows and change-control requirements.
The goal is a defensible picture of the environment: assets, data flows, remote access, dependencies, support status, and recovery capability. Without that picture, every vendor assurance is partial and every incident becomes a scavenger hunt.
Start with the operating reality, not the network diagram
Most building diagrams show intended design. They rarely show the environment as it operates after tenant improvements, emergency repairs, controller replacements, vendor troubleshooting, and years of small changes. The assessment needs to reconcile drawings, asset records, switch configurations, firewall rules, cloud management portals, and what technicians find in telecom rooms and control panels.
This is where hidden risk often appears. A controller may be connected to a flat network shared with workstations. A remote-support account may remain active after a service contract ends. A cellular gateway may bypass the organization’s normal monitoring. A replacement device may have been installed with a default password because the original credentials were unavailable.
None of these conditions necessarily means a system is already compromised. They do mean the organization has limited control over a system that affects operations. That distinction matters. The purpose of the assessment is to prioritize exposure and operational consequence, not to label every legacy component as an emergency.
Inventory the assets that matter
A usable OT inventory goes beyond make, model, and serial number. It records the asset’s purpose, physical location, network address, software or firmware version, system owner, support provider, replacement status, and operational dependency. If a device cannot be patched without disrupting occupied space, that constraint belongs in the record.
The inventory should also identify the assets that support the assets: network switches, uninterruptible power systems, virtual hosts, management workstations, remote-access appliances, backup storage, and monitoring platforms. A building-management server may be well secured, but its availability still depends on power, network paths, and the account used to administer it.
Ownership must be explicit. “Facilities owns it” is not enough when facilities operates the system, IT manages the network, a security team reviews alerts, and a contractor retains administrator access. One accountable owner should be named for each risk decision, even when several teams perform the work.
Map access paths and trust boundaries
Remote access deserves particular scrutiny because it is frequently necessary and frequently poorly governed. Controls technicians, integrators, equipment providers, and managed service teams all need a practical way to support systems. The question is whether access is approved, limited, logged, and removable.
An assessment should identify every path into the OT environment, including virtual private networks, remote desktop services, web portals, vendor cloud connections, jump hosts, wireless bridges, and cellular devices. It should verify whether multi-factor authentication is used, whether shared accounts exist, and whether access is restricted to the systems each person needs.
Network segmentation is equally important, but it is not a checkbox. Separating business IT from building operations can reduce the chance that a common endpoint incident spreads into control systems. Further segmentation between critical systems can limit the blast radius of a failure. Yet segmentation that breaks legitimate communications or prevents emergency support creates a different operational problem. The design must reflect real workflows, then be documented and tested.
Evaluate resilience, not only exposure
An OT security assessment that ends with passwords and firewall rules is incomplete. Building operations depend on availability. The review should examine what happens if a server fails, a switch loses power, a vendor connection is disabled, or a ransomware event affects the management network.
Ask whether configurations are backed up and whether those backups can be restored. Ask whether there is a current list of emergency contacts, administrator credentials held in a controlled process, and a runbook for operating in a degraded state. Ask whether failover has been tested or merely assumed.
Recovery requirements differ by system. A reporting dashboard can tolerate a longer outage than access control at a multi-tenant site. Environmental monitoring may be restored differently from a system that issues physical commands. This is why business impact should drive remediation order. A high-severity technical finding with no practical path to a critical system may rank below a modest configuration issue on a system that can shut down daily operations.
Turn findings into accountable work
The most common failure is not discovering risks. It is producing a report that no one converts into operating controls. Findings should be organized by operational impact, likelihood, required owner, and realistic remediation path.
Some actions can be completed quickly: disable unused accounts, remove default credentials, document vendor access, back up configurations, and correct exposed services. Others require capital planning or coordinated downtime, such as replacing unsupported controllers, redesigning network segmentation, or moving an aging management platform to supported infrastructure.
A useful remediation plan separates immediate safeguards from lifecycle work. It also records accepted risks. If a legacy device cannot be upgraded before a planned renovation, leadership should formally decide what compensating controls apply: isolation, restricted access, enhanced monitoring, spare parts, or a manual operating procedure. Silent acceptance is not governance.
Make assessment evidence part of turnover
New construction and major renovations offer the best opportunity to avoid inherited OT risk. Final acceptance should require more than a system demonstration. The owner should receive current network diagrams, device inventories, configuration backups, administrator handoff procedures, support contacts, warranty details, remote-access approval records, and proof that required tests were completed.
This is a shared responsibility across the project team, but it needs one standard and one acceptance process. When documentation is scattered across installers, consultants, and equipment providers, the owner inherits a building that works on opening day but cannot be governed on day 300.
When to repeat an OT security assessment
A full assessment is not required every time a technician changes a setpoint. It should, however, be repeated on a defined cycle and after meaningful changes: an acquisition, a major tenant build-out, a platform migration, a serious incident, a change in remote-support arrangements, or the discovery of unsupported equipment.
Between formal reviews, maintain the inventory, review access, validate backups, and test selected recovery procedures. These recurring controls are less dramatic than a major assessment, but they are what keep the assessment from becoming outdated the moment it is delivered.
The practical value of an OT security assessment is not a cleaner report. It is the ability to make a clear call during an outage: what failed, what depends on it, who has authority to act, and how operations return to a controlled state.