UPS, Rack PDU and DCIM Security Guide: Securing the Networked Power Chain in Data Centres and Comms Rooms

The devices that keep servers powered, uninterruptible power supplies, switched rack PDUs and the DCIM software that watches them, are networked computers that can switch off a data hall with one authenticated command. They usually sit on the facilities side of the house, are installed by electrical contractors, keep factory credentials for years and are patched rarely because a firmware update can mean a maintenance window on live power. This guide covers the networked power chain from UPS network management cards through metered and switched PDUs, environmental sensors, shutdown agents and DCIM platforms. It is for infrastructure, network and security teams who own data centres, colocation cages, server rooms or branch comms rooms. Physical site security, cooling design and redundancy tiers are covered in the Data Centre Security Guide and are not repeated here.

Key takeaways

• Treat power management as a privileged control plane: anyone who can log in to a switched PDU or UPS card can cut power to the servers behind it, so these logins deserve the same care as hypervisor admin.
• Never expose a UPS or PDU to the internet: CISA and the US Department of Energy warned in March 2022 that attackers were reaching internet-connected UPS devices through unchanged default credentials.
• Kill the default account and the cleartext protocols: change factory credentials, turn off Telnet, HTTP, FTP and SNMPv1/v2c, and use SSH, HTTPS and SNMPv3 with authentication and privacy.
• Firmware is the long-lived risk: research disclosed in 2022 showed UPS firmware updates could be abused to persist on the device and even damage it, so verify firmware sources and plan update windows like any other critical patch.
• DCIM concentrates credentials: a DCIM server stores SNMP secrets and device logins for every rack, so protect it, its service accounts and its integrations as a tier 0 style asset for the facility.

What is in the networked power chain

Each layer has a management interface, and each interface is a way to change what power reaches IT equipment.

Two features make this estate different from ordinary servers. First, impact is physical and immediate: a power-off is an outage, not a data breach, and it can damage storage arrays that lose power mid-write. Second, ownership is split. Facilities teams buy and install the hardware, electrical contractors commission it, IT teams consume the alerts, and security often does not know it exists.

Threats and how they show up

Firmware case study: in March 2022 researchers at Armis disclosed TLStorm, three vulnerabilities in a widely used line of smart UPS devices: a TLS authentication bypass, a TLS buffer overflow reachable by unauthenticated packets, and a design flaw in firmware update signing. According to the disclosure coverage, an attacker able to impersonate the vendor cloud connection could push malicious firmware, gain long-term persistence on the UPS and, in the worst case, overheat the power circuitry. The vendor published fixes and mitigations and, because some models need downtime to update, left the update decision to customers. The lesson for every vendor's estate is the customer-side control: inventory which devices have a cloud connector enabled, keep firmware current, and only enable cloud features you actually use.

Hardening the device management plane

Most UPS cards and rack PDUs share a similar feature set. Use these as a baseline and check the exact names in your vendor's documentation.

• Accounts: remove or rename the factory administrator, set unique long passwords per device or, better, central authentication through RADIUS, TACACS+ or LDAP where the device supports it, with a local break-glass account stored in a vault. CISA and DOE recommend strong password length requirements plus login timeout and lockout.
• Roles: separate read-only monitoring, outlet control and device administration. Most monitoring needs read-only; very few people should be able to switch outlets.
• Protocols: enable HTTPS and SSH, disable HTTP, Telnet and FTP. Replace the self-signed certificate with one from your internal CA. See the SNMP Security Guide for SNMP detail.
• SNMP: SNMPv3 with the User-based Security Model (RFC 3414) gives authentication, privacy and replay protection; prefer SHA-2 and AES options where the firmware offers them. Disable SNMPv1 and v2c, or if a legacy poller forces v2c, use read-only communities, never public/private, and restrict by source address. Disable SNMP write unless DCIM genuinely needs it.
• Industrial protocols: Modbus TCP (port 502) and BACnet/IP (UDP 47808) have no built-in authentication in common deployments. Turn them off unless the building management system uses them, and allow only the BMS host to reach them.
• Cloud and remote connectors: vendor cloud monitoring, email relay and remote service features are off unless there is a named owner and need. Record each one.
• Access lists: use the device's own allowed-host list in addition to firewall rules, so a mistake in one layer is not fatal.
• Logging and time: configure NTP and send syslog and SNMP traps to the central collector. Device event logs are small and roll over quickly.
• Physical ports: serial and USB console ports allow password reset on many models. Restrict physical access to racks and note which models permit console reset.

Network placement and remote access

Power devices belong on an isolated management network, not on user or server VLANs. The same network usually carries BMC and switch management traffic; see the Out-of-Band Management Network Design Guide and the Server BMC Security guide.

• Remote vendor access: CISA and DOE accept internet access only as a rare exception with a VPN, multi-factor authentication and strong passwords. Ireland's NCSC adds that third parties managing these systems must apply the same measures. Use time-bound access through a bastion with session recording rather than a standing VPN account per contractor.
• Plan for the outage itself: the NCSC Ireland alert also asks organisations to plan how they will monitor devices during a power disruption. Put the management switch, firewall and jump host on protected power, or you lose visibility exactly when you need it.
• Branch and comms rooms: small UPS units with network cards in branch offices are often on the user LAN. Move them to a management VLAN or disable the network card and rely on USB shutdown signalling to a local host.

DCIM and shutdown agents

DCIM platforms poll every device for power and environmental data and some can issue outlet commands. That makes them both a monitoring asset and a concentration of risk.

• Stored secrets: DCIM holds SNMPv3 users and keys, device admin logins and sometimes BMS credentials. Store them in the product's encrypted store or an external vault, give the DCIM polling account read-only rights on devices, and use a separate, tightly held account for any control function.
• Control functions: if DCIM can switch outlets, require a named user, a reason and, for bulk actions, a second approver. Log every command with the device and outlet.
• Integrations: DCIM often connects to the CMDB, ticketing, virtualisation managers and the BMS through API keys and service accounts. Inventory them and scope each to the minimum. The Building Management System Security Guide covers the BMS side.
• Platform hardening: patch the DCIM application, its database and its OS on the normal server cycle, put the web interface behind SSO with MFA, and restrict who can export inventory, since rack-level power maps are useful reconnaissance.
• Shutdown agents: agents on hypervisors and servers trigger graceful shutdown on battery events. Authenticate the agent to the UPS card (shared secret or certificate as the product supports), limit which hosts accept shutdown commands, and test that a single spoofed event cannot shut down a whole cluster. Agents that log in to hypervisors over SSH or APIs hold privileged credentials: vault and rotate them.

Where identity fits

Every power device is a set of identities: the local administrator, monitoring users, SNMPv3 users, RADIUS or LDAP bind accounts, DCIM polling accounts, shutdown agent secrets and vendor portal accounts. These are non-human identities with power-off rights, and they are usually missing from IAM reviews. Bring them into the joiner, mover and leaver process for staff and contractors, record an owner for each service account, and rotate shared secrets after any contractor engagement ends. See the Non-Human Identity (NHI) Guide and the Device and IoT Identity Guide.

Firmware and lifecycle

1. Inventory: record model, network card model, firmware version, serial, location, IP address and which features (cloud, Modbus, SNMP versions) are enabled. CISA's first recommended action is to enumerate all UPSs and similar systems.
2. Source: download firmware only from the vendor's official site, verify the published hash or signature, and keep a local copy of the approved image.
3. Schedule: subscribe to vendor security notifications. Plan updates for network cards (often hitless to the load) separately from UPS core firmware (which may need bypass or downtime).
4. Test: update one unit per model in a pilot rack, confirm alarms, SNMP polling, shutdown agent signalling and outlet state persistence, then roll out by row.
5. Rollback: keep the previous image and a configuration export. Know whether the model allows downgrade before you start.
6. End of life: network cards often reach end of support years before the UPS itself. Plan card replacement, and sanitise configuration (credentials, certificates, SNMP keys) before disposal. See the Media Sanitisation Guide.

Implementation: a phased approach

1. Weeks 1 to 2, discover: scan management ranges and external attack surface for UPS, PDU and sensor interfaces, check DCIM inventory against what you find, and confirm none is reachable from the internet.
2. Weeks 2 to 4, contain: move devices to the management network, apply firewall and device allow lists, change every default credential and disable cleartext protocols. Do one row first and confirm DCIM polling and shutdown agents still work.
3. Month 2, centralise: enable central authentication and roles, move device secrets into a vault, forward logs and traps to the SIEM, and define alerts.
4. Month 3, firmware and DCIM: bring firmware to current supported versions, harden the DCIM platform and its integrations, and add approval steps for outlet control.
5. Ongoing: quarterly configuration drift checks against a baseline, annual shutdown and failover tests with security monitoring on, and contractor access reviews after each project.

Roll back safely: export each device configuration before change, keep a console path, and never change shutdown agent settings on all hosts at once.

Decision guidance by size

• Small server room or branch: one or two UPS units and a handful of PDUs. Priority is no internet exposure, changed defaults, SNMPv3 or no SNMP, and USB or network shutdown to the local host tested twice a year.
• Enterprise data centre: hundreds of devices. Central authentication, role separation, DCIM with vaulted credentials, an out-of-band network and change control for outlet actions.
• Colocation customer: the provider owns upstream power. You control portal accounts, API keys, any customer-switched PDUs in your cage, and contract terms for logs and notification. Ask whether provider staff can switch your outlets and how that is logged.

Detection and measurement

Metrics:

• Percentage of power devices with default credentials removed (target 100%).
• Number of power devices reachable from the internet (target zero, checked monthly from an external scan).
• Percentage of devices on supported firmware within the agreed window.
• Percentage of devices using central authentication or vaulted unique credentials.
• Outlet control actions without a matching change ticket per quarter.
• Shutdown agent test pass rate in the annual power test.

Common failure patterns

• Remote monitoring by port forward: a contractor sets up a port forward so they can check battery health, and it stays for years. This is the pattern CISA and DOE warned about.
• One password for every PDU: shared across hundreds of devices and known to every contractor who has ever worked on the site.
• Facilities devices outside vulnerability management: scanners exclude the facilities range to avoid "upsetting" devices, so firmware is never assessed.
• DCIM as the soft centre: SNMP keys and device admin passwords stored in a DCIM database with a default application admin login.
• Management network on unprotected power: during an outage the network that carries UPS telemetry goes down first, so the team flies blind.
• Untested shutdown chain: agents installed once, never tested after hypervisor upgrades, so a real battery event either does nothing or shuts down too much.

Framework mapping

Treat the estate as operational technology for governance purposes: NIST SP 800-82 Rev. 3 covers building automation and similar systems that control physical processes.

Practitioner checklist

• Every UPS, PDU, ATS, sensor and DCIM instance is in the asset inventory with firmware version and owner.
• No power device is reachable from the internet; checked by an external scan at least monthly.
• Factory credentials changed on every device; central authentication or vaulted unique passwords in place.
• Telnet, HTTP, FTP and SNMPv1/v2c disabled; SNMPv3 with authentication and privacy where SNMP is needed.
• Outlet control limited to named roles with change tickets; bulk actions need a second approver.
• Devices sit on an isolated management network that itself runs on protected power.
• Firmware from official sources, verified, on a supported version; update process tested per model.
• DCIM secrets vaulted, polling accounts read-only, integrations inventoried with owners.
• Syslog and traps reach the SIEM with alerts for outlet changes, UPS output changes and firmware changes.
• Shutdown agents authenticated and tested in an annual power test.

Standards and references

• CISA and US Department of Energy: Mitigating Attacks Against Uninterruptible Power Supply Devices
• National Cyber Security Centre Ireland: Targeting of Uninterruptible Power Supply Devices
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5
• IETF: RFC 3414, User-based Security Model for SNMPv3
• MITRE ATT&CK: System Shutdown/Reboot
• Help Net Security: Widely used UPS devices can be hijacked and destroyed remotely

Related NHI Mgmt Group resources: Data Centre Security Guide · Out-of-Band Management Network Design Guide · Building Management System Security Guide · SNMP Security Guide