Operational technology · Reviewed 27 September 2026

Procure a controllable system—not a remote-access exception.

A neutral, US-first evidence framework for data-centre building, power, cooling, environmental and access-control technology: define critical functions, system boundaries, connectivity, supplier access, acceptance and recovery before comparing offers.

Browse US operations suppliers

System basis

Define the function before the connection

NIST includes building automation, physical-access control and environmental monitoring within the broad OT family because these systems observe or affect the physical environment. In a data centre, the exact boundary is project-specific. Freeze the required functions and consequences first, then make every product, service and connection justify its place.

Input 1

Critical function and consequence

List the power, cooling, environmental, access and safety functions in scope; the operating states they support; the consequence of loss, false data or unintended command; and the safe or recoverable state. Do not start with a security-tool list.
Input 2

System and responsibility boundary

Map controllers, sensors, workstations, servers, gateways, panels, cloud services, licences and data stores. Name the owner, integrator, maintainer and security authority for every boundary and shared responsibility.
Input 3

Connectivity and data flows

Record every required protocol, source, destination, direction, purpose and trust boundary across OT, IT, vendor and cloud environments. Treat wireless, temporary commissioning links and data export as designed connections, not exceptions.
Input 4

Identity and supplier access

Define named and service accounts, role permissions, privileged workflows, multi-factor authentication, local or break-glass access, approval windows, session records, account expiry and the exact route used by each supplier.
Input 5

Product and support evidence

Request the secure-configuration guide, supported versions, software and component inventory, default-service list, vulnerability-disclosure route, advisory process, update and rollback method, support dates, dependencies and replacement path.
Input 6

Acceptance and operational evidence

Turn requirements into factory, site and operational tests for hardening, segmentation, access, logging, backup, restore, isolation, failover and supplier response. Define witnesses, pass criteria, defects and the evidence handed to operations.
Input 7

Incident, change and exit route

Set notification and coordination duties, forensic and log availability, emergency access, recovery priorities, configuration control, subcontractor changes, obsolescence, access removal, data return or deletion and transition support.

Evidence matrix

Join every control to an asset, test and owner

Evidence set

Architecture record

Comparison record

Current asset and software inventory, ownership, critical function, network zone, dependencies, data flows, external connections and approved deviations

Accountable input

OT owner, integrator and security architect

Evidence set

Access record

Comparison record

Account types, privilege model, authentication, supplier route, approvals, session logging, dormant-account removal, emergency access and periodic review

Accountable input

Operations, identity and supplier leads

Evidence set

Product record

Comparison record

Secure defaults, hardening guide, services and protocols, component provenance, vulnerability route, advisories, updates, rollback, support term and end-of-life notice

Accountable input

Manufacturer and technical authority

Evidence set

Protection record

Comparison record

Segmentation, boundary controls, allowlisted flows, time source, logging, monitoring, configuration backup, malware approach and physical access assumptions

Accountable input

OT engineering and cyber-security teams

Evidence set

Acceptance record

Comparison record

Test environment and version, procedure, expected result, witness, result, defect, retest, residual risk, approved baseline and handover evidence

Accountable input

Commissioning authority and asset owner

Evidence set

Lifecycle record

Comparison record

Patch and change decisions, remote sessions, incidents, exercises, restored backups, supplier changes, unsupported assets, compensating controls and exit actions

Accountable input

Service owner and contract manager

Secure by demand

Make product and service evidence part of selection

United States · Primary focus

Ask manufacturers how security works in the product

CISA's joint OT procurement guidance asks owners to evaluate secure configuration, authentication, logging, updates, vulnerability handling, data protection and resilience before selection. NIST adds supply-chain due diligence and supplier requirements based on criticality. These are risk frameworks, not a product certification or a substitute for applicable law and owner standards.
United Kingdom

Keep architecture and connectivity evidence current

The NCSC asks owners to maintain a definitive view of OT assets, connections and third parties, then justify and constrain connectivity, harden boundaries, monitor activity and prepare an isolation plan. Apply the relevant UK legal, regulatory, contractual and sector requirements to the actual facility and service.

Supplier connectivity

Remote support is an operating path

Justify

Start with the service need

Record why a connection is needed, which assets and commands it can reach, who authorises it, when it is active, which data leaves the facility and how the owner can disable or isolate it.
Constrain

Limit identity, route and time

CISA prioritizes removing OT assets from public exposure, controlled private access, strong authentication including phishing-resistant multi-factor authentication, least privilege and removal of dormant accounts. Translate those outcomes into the project architecture and access schedule.
Evidence

Retain the session record

Define approvals, named users, start and end time, commands or changes, monitored logs, files transferred, resulting configuration, exceptions and access closure. A supplier policy alone does not prove how a facility session was controlled.

Acceptance and recovery

Test control before granting operational authority

Plan tests at the safest representative layer available and coordinate them with the operating and safety case. Record the exact hardware, firmware, software, configuration and network state so the accepted baseline can be reproduced, monitored and restored.

Prove the intended controls

Test account roles, denied access, approved data flows, segmentation, hardening, time and log delivery, remote-session controls, configuration backup, alert routing and isolation. State any tests that cannot be run safely and the compensating evidence used.

Prove the recovery route

Restore configurations and required data, exercise loss of external services, revoke supplier access, recover from an update or failed change, verify manual or degraded operation where designed, and close defects before operational handover.

Offer comparison

Compare boundaries, proof and lifecycle on one basis

01

Compare the same boundary

Issue one architecture and access schedule to every bidder. A product-only offer is not comparable with an integrated service that includes gateways, cloud analytics, remote support and lifecycle ownership.
02

Score verifiable capability

Ask for product documentation, support commitments, test methods and representative evidence. Treat certifications, policies and feature claims as inputs whose scope and applicability still need checking.
03

Price the operating lifetime

Compare licences, secure configuration, integration, testing, monitoring, updates, incident support, recovery, skills, spares, obsolescence and transition—not only the initial hardware or software price.

Build the research set

Connect control-system scope to the directory

Use the directory to identify organisations for further research across the physical systems and lifecycle services in scope, then issue the same boundary, access and evidence schedule to every candidate. Directory inclusion is not proof of secure design, integration authority, product support, cyber competence, available capacity or successful delivery.

Primary references

Sources used for this guide

NIST SP 800-82 Rev. 3 defines OT to include building automation, physical-access control and environmental monitoring, and connects security controls to the performance, reliability and safety needs of systems that affect the physical environment.
The joint US-led guide puts security into OT product selection and gives owners questions for authentication, configuration, logging, updates, vulnerability handling, data protection and resilience.
The May 2025 fact sheet prioritizes controlled remote access, phishing-resistant multi-factor authentication, least privilege, removal of dormant access and segmentation between IT and OT networks.
NIST SP 1305 shows how to set supplier requirements by criticality, carry them into agreements, assess suppliers before acquisition and include third parties in incident and recovery planning.
The NCSC guidance treats current asset, connectivity and third-party records as the basis for risk decisions and asks owners to maintain an accountable view rather than rely on a one-time survey.
Eight principles cover justified connectivity, limited exposure, standardised connections and protocols, hardened boundaries, constrained impact, monitoring and an isolation plan.
The assurance questions cover supplier access, remote connections, incidents, recovery, subcontractors, data handling, testing and contract exit without treating a certificate as complete evidence.

Sources checked 27 September 2026. Cyber-security, privacy, safety, operational, sector and legal requirements vary by facility, system, service, data, jurisdiction and contract; confirm the current obligations and safe test method with the responsible specialists and authorities.