The $700 billion being spent on U.S. data center construction this year isn't just building compute capacity. It's creating an attack surface that many organizations struggle to secure. When your HVAC contractor, power team, and cooling system installer each build their own network without coordination, you end up with operational technology (OT) sitting dangerously close to the public internet.
This is a real issue. Analysis of 191,000 OT assets in production data centers found that while only 3% were directly internet-accessible, roughly 20% were one hop away through interconnected IT infrastructure. Your building management system needs to connect for firmware updates. Your cooling controllers send telemetry to the manufacturer. Each of these legitimate needs creates a potential entry point for an attacker who's compromised your IT network through phishing or credential theft.
What You Need Before Starting
Network visibility tools for OT asset discovery
You can't secure what you can't see. You need a platform that identifies OT devices without agents, as many controllers and sensors can't run endpoint software. Look for passive network monitoring that builds an asset inventory from traffic analysis.
A current network topology map
Document every contractor-installed network segment. The HVAC team's subnet, the power distribution unit management network, the physical security system VLAN. Different vendors often install systems on different timelines, leading to siloed networks.
Stakeholder buy-in from facilities and IT
OT security crosses organizational boundaries. Your facilities director owns the HVAC contract. Your IT director owns the firewall policy. Without joint ownership of security outcomes, your implementation will fail.
A defined risk tolerance for OT downtime
Segmenting networks means breaking some existing connectivity. Before starting, get executive agreement on acceptable maintenance windows and the business impact of temporarily losing remote monitoring capabilities during the transition.
Step-by-Step Implementation
Week 1-2: Complete Asset Discovery
Deploy your OT visibility platform in monitor-only mode across all data center network segments. Configure it to identify devices by protocol fingerprinting (Modbus, BACnet, SNMP) rather than relying on self-reported device information, which is often incomplete or wrong.
Export a complete asset inventory including device type, firmware version, manufacturer, IP address, and VLAN assignment. Flag any device with a default credential, known CVE, or direct internet route.
Cross-reference this technical inventory against your facilities documentation. You'll find devices nobody knew existed, especially in older sections of the facility where contractors added equipment without updating network diagrams.
Week 3-4: Map Communication Flows
Use your visibility platform to capture two weeks of actual traffic patterns. Document what devices actually communicate with, not just what vendor documentation suggests.
Build a communication matrix showing which OT devices talk to which IT systems, which devices connect to manufacturer clouds, and which systems cross network boundaries without a legitimate reason.
Identify every path from OT to the internet, including indirect paths through IT infrastructure that an attacker could exploit.
Week 5-6: Design Your DMZ Architecture
Create a demilitarized zone (DMZ) between your IT and OT networks using two firewalls facing opposite directions. The upward-facing firewall controls traffic from OT toward IT and the internet. The downward-facing firewall controls traffic from IT toward OT.
Within this DMZ, place jump servers for administrative access, data historians that collect OT telemetry for IT systems, and secure proxies for outbound OT traffic that needs internet connectivity.
Configure firewall rules based on your communication matrix. Start with deny-all and explicitly permit only the flows you documented as necessary. If your HVAC controller needs to reach its manufacturer's update server, route that traffic through the DMZ proxy.
Week 7-8: Implement Network Segmentation
Separate OT systems by function and criticality. Your power distribution units should be on a different subnet than your physical access control system. Your chip-level cooling controllers should be on a different subnet than your building HVAC.
This segmentation contains lateral movement. An attacker who compromises your building management system can't automatically pivot to your power infrastructure.
Deploy these changes during scheduled maintenance windows, one segment at a time. Test each segment's functionality before moving to the next.
Week 9-10: Harden OT Device Configurations
Change every default credential, even on obscure devices like temperature sensors installed years ago.
Disable unnecessary services and protocols on each device. If your uninterruptible power supply supports both HTTP and HTTPS management, disable HTTP. If it supports SNMP v1 and v3, disable v1.
Where possible, disable or strictly control any firmware auto-update features that require internet connectivity. Route these updates through your DMZ proxy with inspection and logging.
Week 11-12: Deploy Continuous Monitoring
Configure your OT visibility platform for active alerting on new devices, configuration changes, unauthorized communication attempts, and known attack patterns.
Integrate OT security alerts into your Security Operations Center workflow. Train your SOC analysts on OT-specific indicators of compromise, which differ from IT threats. A building management system suddenly scanning the network looks different than a compromised workstation doing the same thing.
Establish baseline behavior for each OT segment. Alert on deviations: new protocols, new destinations, traffic volume spikes, or communication during maintenance windows when systems should be idle.
Validation: How to Verify It Works
Test segmentation with controlled scans
From a workstation on your IT network, attempt to reach OT devices directly. These connections should fail. Repeat from the OT side trying to reach arbitrary IT systems or internet destinations. Only explicitly permitted paths through the DMZ should succeed.
Verify your visibility platform detects rogue devices
Connect an unauthorized device to an OT network segment. Your monitoring should alert within minutes, not days.
Conduct a tabletop exercise
Walk through a scenario where an attacker compromises an IT workstation through phishing. Can they pivot to OT? What visibility would you have? What containment options exist? If your answer is "they could probably reach the HVAC system," your segmentation isn't complete.
Review firewall logs for denied connections
You should see regular denied connection attempts from OT devices trying to reach destinations outside their permitted communication matrix. This is normal. If you see zero denied connections, your rules are probably too permissive.
Maintenance and Ongoing Tasks
Monthly firmware review
Check for security updates to OT device firmware. Test updates in a lab environment before deploying to production. Updates that break functionality are common in OT.
Quarterly communication matrix review
Business requirements change. A new monitoring tool might need access to OT telemetry. A contractor might need temporary remote access. Review and update your firewall rules quarterly, removing temporary exceptions that became permanent through neglect.
Annual architecture assessment
As you add data center capacity, ensure new construction follows your segmentation model. Review the architecture with each new contractor before they install equipment. The time to enforce OT security requirements is in the contract, not after the cooling system is already running on a flat network.
Continuous vendor management
When OT vendors need remote access for support, provide it through your DMZ with session logging and time-limited credentials. Never give vendors direct VPN access to OT networks.
The AI boom isn't slowing down. Neither are the contractors building data centers every 90 days. Your OT security implementation needs to match that pace, because the alternative is operational technology that's architected for convenience and exposed for exploitation.
