Data Center Penetration Testing: Test the Management Plane Before Someone Else Does

What data center penetration testing covers, and what it honestly cannot

Ask ten people what data center penetration testing means and eight will describe a physical intrusion: a tester with a fake badge, a cloned access card, a propped fire door. That work exists and it matters. It is also a small part of how data centers actually get compromised.

Here’s the thing: almost everything that keeps a modern facility running is reachable over a network. Servers carry a second computer inside them — the baseboard management controller — that can power them on, reflash their firmware and open a console, regardless of what the operating system thinks.

Hypervisors have management interfaces. Switches have management planes. Cooling, power distribution, access control and cameras sit on IP networks. Customers of a colocation provider log in to portals and raise remote-hands tickets through APIs.

Data center penetration testing, done remotely, is the discipline of testing all of that: starting from a realistic position — the internet, a tenant’s cross-connect, a compromised workstation on the corporate side, a leaked credential — and proving how far it reaches into the layers that matter.

What it cannot do is physical. A remote test will not tailgate, will not pick a lock, will not test whether your guards challenge a stranger. If a vendor sells you a “data center pentest” delivered entirely over the network and implies it covers physical security, they are selling you a story.

The honest framing is that a remote test covers the networked side of physical security — the access-control server, the camera network, the badge database — which is where a surprising share of “physical” incidents actually start.

The truth is, you need both. This page is about the half that is usually under-tested, because it is the half that an attacker on the other side of the world can reach.

The management plane is the real front door

Every server in your halls has a management controller: HPE calls it iLO, Dell calls it iDRAC, Supermicro and many others ship AMI’s MegaRAC. It has its own processor, its own network interface and its own credentials, and it works when the server is off. For an operator it is indispensable. For an attacker it is the best possible foothold: control of the controller is control of the machine beneath the operating system.

Two pieces of public evidence from 2025 and 2026 show how exposed that layer is, and why data center penetration testing has to start there.

In July 2026, researchers at Lava reported that 36,872 server management controllers answered from the public internet on the IPMI port. Of those, 24,650 — roughly two-thirds — disclosed password-derived authentication material before any login, because of CVE-2013-4786, a weakness in the IPMI 2.0 specification itself. There is no patch, because the flaw is in the protocol.

Roughly one in six exposed hosts answered for an empty username. On 2,340 endpoints a named account matched a wordlist password. Lava reported that factory passwords for some vendors could be recovered in seconds to an hour on consumer graphics hardware, and documented a ransom note sitting in the login page of an exposed controller.

A year earlier, on 25 June 2025, CISA added CVE-2024-54085 to its Known Exploited Vulnerabilities catalog: an authentication bypass in the Redfish interface of AMI MegaRAC firmware, disclosed by Eclypsium in March 2025, which grants administrative control of the controller without credentials.

Eclypsium’s description of the consequences is worth repeating in plain terms: remote control of the server, malware below the operating system, modified firmware, over-voltage commands that damage hardware, and reboot loops that need a person at the rack to stop. It was the first BMC flaw on the catalog, and it reached an ecosystem of OEMs that ship the same firmware.

Neither finding is exotic. One is a twelve-year-old specification weakness; the other is a header-handling bug in widely shipped firmware. What makes them dangerous is where they sit: on the layer that most organisations have never had tested, because the annual engagement was scoped to the web application and the corporate network.

That is the first job of data center penetration testing: find every management controller you own, establish what can reach it, and prove whether the credentials and firmware on it hold.

Six layers a data center penetration testing engagement should walk

A good data center penetration testing engagement is organised by layer, because each layer has its own systems, its own entry points and its own definition of impact. Here is the walk we use.

1. The tenant edge. Customer portals, remote-hands ticketing, cross-connect ordering, billing APIs, status pages. These are ordinary web and API targets — authorisation between tenants, business logic, exposed administrative functions — except that the prize behind them is a ticket that asks an engineer to plug a cable into someone else’s cage.

2. The management plane. BMCs and their IPMI and Redfish interfaces, jump hosts, the out-of-band network, DCIM platforms that know where every asset lives and what it is connected to. The questions are reachability, credentials, firmware currency and segmentation: can a position on the corporate network, a tenant VLAN or the internet see this plane at all?

3. Virtualisation and orchestration. Hypervisor managers, cluster consoles, container platforms and the identities that bind them to cloud accounts. This is the layer with the longest public record of exploited flaws, and the one where one credential turns into every workload. Our Kubernetes penetration testing guide covers the container half in depth.

4. The network fabric. Switch and router management interfaces, the automation that configures them, route reflectors and the edge appliances that terminate remote access. Segmentation claims live here, and segmentation claims are exactly what a test exists to check rather than to believe.

5. Storage and backup. Array management interfaces, backup servers, replication links, file-transfer gateways. Ransomware operators learned years ago that the backup console is the most valuable machine in the building, and the exploited-vulnerability record agrees.

6. Facility operational technology. Building management, cooling and power monitoring, UPS and PDU management, access-control controllers, camera networks. These systems were never designed to meet an attacker, and they are tested with different rules: passive first, read-only where possible, no actuation without explicit agreement, in line with NIST’s guidance for operational technology.

The sixth layer is where the physical boundary becomes visible. A remote data center penetration testing engagement can prove that the access-control server accepts a default password, that the camera VLAN is reachable from the guest Wi-Fi, or that the building management system is exposed to a tenant network. It cannot prove that the door closes behind a stranger. State that boundary in the scope, and the report will be trusted on both sides of it.

What the exploited-vulnerability record says

To check that the six layers are the right ones, we went to the most conservative public source of what attackers actually use: CISA’s Known Exploited Vulnerabilities catalog, which lists only flaws with confirmed exploitation in the wild. We took the catalog version of 23 October 2026 — 1,756 entries — and matched entries by vendor and product family against the layers above. The matching is by keyword and approximate, so read the counts as a shape, not a census.

The shape is clear. Network edge and remote-access appliances dominate with 186 entries and a rate that is still rising: 36 in 2025 and 36 so far in 2026. Network switching and routing management accounts for 80, with a sharp spike in 2026.

Physical-security devices — cameras, recorders, access-control products — account for 51. Hypervisor and virtualisation management, 38. Storage, backup and file-transfer products, 35. Facility OT and power, 6. Server BMCs, exactly 1.

Two readings follow for anyone scoping data center penetration testing. First, the layers with the long records — edge appliances, hypervisors, backup — are precisely the layers an annual, web-focused engagement tends to skip. Second, the single BMC entry sits next to 36,872 exposed controllers. The catalog counts what is caught being exploited; a management plane that is rarely monitored and rarely tested produces few catches. Treat the gap as a warning about visibility, not as reassurance.

Colocation changes the authorisation model

In an owned facility the operator can authorise a test of everything. In a colocation or multi-tenant site, data center penetration testing has to respect a shared-responsibility line that most contracts describe only loosely.

The provider owns the building, the facility OT, the shared network fabric, the portals and the management plane of its own equipment. Each tenant owns what is inside its cage or rack, from the BMC on its servers upward. A test commissioned by one party may not touch the other party’s systems without written authorisation, and a serious vendor will refuse to proceed until that line is drawn on paper.

Two data center penetration testing scopes therefore exist. The provider scope asks whether one tenant can reach another through the fabric, the portals or the facility systems, and whether the provider’s own management plane is exposed. The tenant scope asks whether a tenant’s own equipment is reachable from the provider’s shared networks or from the internet, and whether its remote-hands and portal access could be abused.

The frameworks that govern facilities — the physical and environmental controls in ISO/IEC 27001 Annex A, the availability and security criteria of SOC 2, the segmentation testing that PCI DSS requires wherever cardholder data is hosted — all assume these scopes are tested, not asserted. Our guides to ISO 27001 penetration testing and PCI DSS penetration testing map the clauses; the compliance penetration testing hub ties them together.

Outages, not only breaches

Security teams scope data center penetration testing around confidentiality. Facility teams should read the same report for availability, because the systems a test touches are the systems whose failure costs the most.

Uptime Institute’s 2026 Annual Outage Analysis, published in May 2026, reports that 57% of respondents said their most recent major outage cost more than $100,000, and one in five put it above $1 million — the second consecutive year at that level.

Power remains the leading cause, with UPS systems, transfer switches and generators the dominant failure points. Over nine years of tracking publicly reported outages, third-party IT and data center providers accounted for about two-thirds of them.

Now look at the sixth layer again. UPS and PDU management, power monitoring and building management are networked, and an attacker who reaches them does not need to steal data to cause the most expensive kind of incident a facility can have. Uptime’s finding that failing to follow established procedures remains the leading driver of human-error outages has a security echo: a management interface left on a default password is a procedure not followed.

This is also the strongest argument for OT-safe rules in data center penetration testing itself. A tester who trips a transfer switch has caused the outage the test was meant to prevent. The right engagement proves reachability and weak credentials on power and cooling systems without ever issuing a command that changes their state.

How to scope data center penetration testing

Start data center penetration testing with an inventory of management interfaces. Every BMC, hypervisor console, switch management address, storage controller, backup server, DCIM and BMS endpoint, with the network each sits on. If the inventory does not exist, building it is the first deliverable.

Define footholds, not just targets. The internet, a tenant network, the corporate LAN, a contractor’s VPN account, a leaked portal credential. The interesting question is how far each position reaches, and that only emerges when the test starts from the position rather than from a list of hosts.

Write the OT rules before anything runs. Passive discovery first; read-only interaction where possible; no actuation, configuration change or firmware operation on power, cooling or access-control systems without a named person’s explicit approval; change windows; a kill switch. NIST SP 800-82 is the reference, and a vendor who has not read it should not be near your BMS.

Draw the tenant line in writing. Which cages, racks and VLANs are in scope, whose authorisation covers them, and what happens if a path leads into a system that belongs to someone else: stop and report, never continue.

Ask for proof and a retest. Each finding demonstrated, the chain shown, severity judged by what the path reaches, and a retest after the fix. A list of open ports with a model’s prose on top is a scan.

Keep physical testing separate from data center penetration testing, and say so. If you want doors, guards and mantraps tested, commission a physical red team and say so. Do not let a remote test imply coverage it does not have, and do not let a physical test imply the management plane was checked.

For the externally reachable part of this scope — what a facility leaks to the internet before anyone logs in — our external pentest guide covers the method, and our enterprise penetration testing piece makes the case for cadence.

How SelfHack AI runs data center penetration testing

SelfHack AI is an autonomous penetration testing platform, and data centers are one of the environments it was built for: internal and external networks, web and API, cloud including Google Cloud, Kubernetes, IoT and OT, through to satellite and drone links and the AI features in your own systems.

We test what a network can reach, and we say so. Six layers, from the tenant portal to the building management system. We do not do physical intrusion, and we will tell you which partner should.

Agents, not scripts. In data center penetration testing our agents start from the footholds you define, plan, act, observe and chain, and demonstrate every step. Severity follows the path: a default password on a camera recorder is a finding; the same recorder on a VLAN that reaches the access-control server is an incident waiting for a date. The approach is described in our agentic penetration testing guide.

OT-safe by design. Passive-first discovery, read-only verification and hard limits on actuation for facility systems, with full action logs so your engineers can audit every packet the agents sent.

Multi-tenant authorisation built in. Scope is enforced as a boundary the agents cannot cross, and a path that leads into another party’s systems is reported, not followed.

Continuous. Data center penetration testing cannot be annual: firmware changes, new racks arrive, VLANs are re-cut, a vendor publishes the next MegaRAC advisory. The management plane is retested as it changes, not at next year’s audit.

Evidence auditors accept, in 16+ languages. Scope, proven findings, remediation and retest, mapped to ISO 27001, SOC 2, PCI DSS and the frameworks your tenants ask about.

If you have never had your management plane tested from the positions an attacker actually holds, talk to us about a pilot on a facility you own.

FAQ

What does data center penetration testing cover?

The networked layers of a facility: the tenant edge (portals, APIs, remote hands), the management plane (BMCs, out-of-band networks, DCIM), virtualisation and orchestration, the network fabric, storage and backup, and facility operational technology such as building management, power monitoring, access control and cameras. Physical intrusion testing is a separate, on-site discipline.

Can data center penetration testing be done remotely?

Yes, for everything reachable over a network, which is most of what an attacker would target. A remote test cannot evaluate doors, guards or mantraps; pair it with a physical red team if those are in question, and make sure each report states its boundary.

Is it safe to test building management and power systems?

Only with OT-safe rules: passive discovery first, read-only verification, no actuation or configuration change without explicit named approval, change windows and a kill switch. NIST SP 800-82 is the reference. A test that trips a transfer switch has caused the outage it was meant to prevent.

Who authorises a test in a colocation facility?

The provider authorises its own building, fabric, portals and management plane; each tenant authorises what is in its own cage or rack. Neither party’s test may touch the other’s systems without written authorisation, and a path that leads across the line should be reported and not followed.

How often should data center penetration testing be repeated?

Continuously, in practice. Firmware advisories such as the 2025 MegaRAC bypass arrive between annual engagements, equipment and VLANs change constantly, and research in 2026 found tens of thousands of controllers exposed to the internet. A once-a-year snapshot describes a facility that has already changed.

The verdict

The data center’s most dangerous surface is not its doors. It is the second computer inside every server, the console that controls every hypervisor, the network that configures every switch, and the building systems that keep the lights on — all reachable, all rarely tested, all now documented as exposed at scale.

Data center penetration testing, done honestly, walks those six layers from the positions an attacker holds, proves what reaches what, respects the tenant line and the OT rules, and states plainly that the physical half needs its own test. Do that continuously and the management plane stops being the layer nobody looked at.

If you would rather have data center penetration testing find your exposed controllers than read about them in someone else’s research, talk to us.

Sources & methodology: Lava’s July 2026 BMC exposure research as reported by Help Net Security; Eclypsium on CVE-2024-54085 and its KEV listing; CISA Known Exploited Vulnerabilities catalog, version 2026.10.23, grouped by SelfHack AI using approximate vendor and product keyword matching; Uptime Institute, Annual Outage Analysis 2026 (press release, 13 May 2026); operational-technology testing rules follow NIST SP 800-82 Rev. 3; general method follows NIST SP 800-115 and the OWASP Web Security Testing Guide for the portal and API layer. This page describes scope and method at a buyer’s level and intentionally contains no attack commands. Only test facilities and systems you own or are authorised to test.