Every server has a small computer inside it that almost no security programme watches: the baseboard management controller. The BMC - iDRAC on Dell, iLO on HPE, XCC on Lenovo - runs before the operating system, stays powered when the host is off, and has total control over the hardware. That makes it one of the most powerful and most overlooked footholds in the data centre. As regulation such as NIS2 raises the bar and a steady stream of BMC and firmware vulnerabilities surfaces, hardware-level security has stopped being a niche concern. Here is the BMC and firmware attack surface, and how UK organisations should harden the layer beneath the OS.
What the BMC is and why attackers want it
The baseboard management controller is a dedicated processor on the motherboard that exists to manage the server out of band: power it on and off, mount virtual media, view the console, update firmware and read sensors - all independently of the operating system, often over a separate network port, and even when the host is powered down. It is the remote-hands capability that makes modern data centres operable. It is also, from an attacker's view, close to ideal: privileged, persistent and rarely monitored.
Because the BMC sits below the OS, malware that establishes itself there survives operating-system reinstalls and is invisible to host-based security tools that only see the OS and above. An attacker who controls the BMC controls the machine more completely than root does - they can manipulate firmware, alter boot, and persist through almost any remediation short of replacing or fully reflashing the hardware. That combination of power and stealth is exactly why firmware-level compromise is taken so seriously.
The vulnerability classes that keep recurring
BMC and firmware vulnerabilities tend to fall into a few familiar buckets. Authentication weaknesses - default or weak credentials, flaws that allow bypassing login - turn the management interface into an open door. Web-interface bugs in the BMC's own management UI can allow command injection or remote code execution. Exposure is its own vulnerability: BMCs reachable from the general network, or worse the internet, dramatically widen the attack surface. And firmware integrity gaps - the inability to verify that firmware has not been tampered with - let malicious firmware take hold and persist.
None of these is exotic; they are the predictable consequence of a powerful subsystem that historically received less security scrutiny than the OS. The defences are correspondingly well understood, which is the encouraging part - this is a manageable problem if it is actually managed. Treat the BMC as a first-class part of your security posture, the same way you would any privileged management plane, and fold it into the controls our cyber security practice applies.
- •Weak or default credentials and authentication-bypass flaws on the management interface
- •Remote code execution and command injection in the BMC web UI
- •BMCs exposed to the general or public network instead of an isolated segment
- •Missing firmware integrity verification, allowing persistent malicious firmware
Isolation: the single highest-value control
The most effective defence is also the simplest: do not let the BMC be reachable from where it does not need to be. Management interfaces belong on a dedicated, isolated management network - physically or logically separated, firewalled, and never exposed to the internet. The dedicated BMC network port exists precisely so the management plane can live apart from production and user traffic; using it properly removes the largest class of attacks at a stroke by shrinking who can even reach the interface.
Layer access control on top: strong, unique credentials with default passwords eliminated, role-based access, multi-factor authentication on the management plane where the platform supports it, and tight control over who can reach the management network at all. Isolation plus disciplined access control addresses the majority of real-world BMC compromise, because most incidents start with an exposed or weakly-authenticated interface rather than an exotic firmware exploit.
Secured-core servers and firmware integrity
Hardware vendors now ship platform-level defences for exactly this layer. Secured-core servers and equivalent programmes build a hardware root of trust that verifies firmware integrity through the boot chain, so the platform can detect or refuse tampered firmware and establish that the BMC and BIOS are running known-good code. Features such as verified and measured boot, silicon-rooted trust and runtime firmware protection move integrity from hope to something the hardware actively enforces.
For new purchases, these capabilities should be on the requirements list, not an afterthought - it is far easier to buy a platform with a hardware root of trust than to bolt firmware assurance onto one without it. When you are specifying servers, fold firmware security into the build rather than treating it as a post-deployment task, using our server configuration service to choose platforms with the right protections.
Patch cadence and regulatory pressure
Firmware needs patching like any other software, and historically it has been the most neglected. A disciplined cadence - tracking vendor BMC and BIOS advisories, testing, and applying firmware updates on a defined schedule rather than never - closes the recurring vulnerability classes before they are exploited. Frameworks raise the stakes: NIS2 expands cyber-security obligations across more UK-facing organisations and their supply chains, and a baseline such as Cyber Essentials Plus expects systematic patching and secure configuration - both of which logically extend to firmware and management interfaces, not just the OS.
The practical posture is to treat the BMC and firmware as in scope for your security and compliance programme: hardened configuration, isolated management network, a real patch cadence, and platforms with firmware integrity built in. Keeping firmware current is also where break-fix and lifecycle support matter - our hardware maintenance and break-fix service helps keep firmware patched across a fleet rather than letting it drift.