Every server sold today contains a second, much smaller computer that most admins never think about until something goes wrong. This is the Baseboard Management Controller (BMC) — sold under the names iDRAC (Dell), iLO (HPE) and XClarity Controller (Lenovo) — a dedicated chip with its own firmware and processor, powered from the server's standby rail, so it keeps working even when the operating system has crashed or the machine is switched off at the front panel. For UK teams running kit in colocation or unattended offices, that independence is the whole point: it can replace a site visit with a browser session. This explainer covers what a BMC actually does, how iDRAC, iLO, XCC and IPMI differ, and the segmentation habits that stop this remote root path becoming a liability.
View the data behind this chart
| Layer | Detail |
|---|---|
| Host operating system | Runs on main CPU, unreachable if the OS crashes |
| BMC controller | Own ARM CPU (400-1200 MHz), own firmware and web… |
| Standby power rail | Keeps the BMC alive even when the server is off |
What out-of-band management actually is
Out-of-band management (OOBM) means administering server hardware through a channel that is completely separate from the server's own operating system and its normal network path. The component that makes this possible is the BMC — a dedicated management controller built into the motherboard, present specifically for this kind of access rather than for running applications or serving users.
Because the BMC has its own hardware and firmware, it doesn't depend on Windows, Linux or a hypervisor being alive to respond. It stays reachable even if the host operating system has crashed entirely, or if the server has been switched off at the front panel — because the controller draws its power from the standby rail rather than the main system supply. That's the practical distinction UK admins should hold onto: 'powered off' at the chassis is not the same as unreachable.
The computer inside your computer
The BMC is a genuinely separate machine sitting on the same board. Current generations typically run on ARM processors clocked in the region of 400–1200 MHz — modest by server-CPU standards, but enough to run its own web server, authentication stack, and management logic independently of the host.
Across the different vendor consoles, the practical toolkit is consistent. A BMC typically gives an admin five core capabilities that cover most of what a hands-on visit would otherwise be needed for.
- •A remote virtual console — as if a screen and keyboard were plugged directly into the box
- •Remote power cycling, independent of whether the host OS is responding
- •Virtual media mounting, so an ISO can be attached over the network for a reinstall
- •Sensor monitoring for temperature, fans, voltages and other hardware health data
- •Access to hardware event logs, useful for diagnosing faults the OS never saw
IPMI, Redfish, iDRAC, iLO and XCC: what's actually different
IPMI (Intelligent Platform Management Interface) is the older, generic cross-vendor standard that most out-of-band discussions still reference — it defines a baseline protocol for talking to a BMC regardless of who built the server. Redfish is the newer API family that has grown up alongside IPMI, giving automation tools a more modern, RESTful way to drive the same underlying hardware controls.
Dell, HPE and Lenovo each wrap this same underlying idea in their own branded console: iDRAC on Dell PowerEdge, iLO on HPE ProLiant, and XClarity Controller (XCC) on Lenovo ThinkSystem. Despite the different names and interfaces, vendor implementations expose very similar core capabilities to each other — the console, power control, virtual media, sensors and logs described above are present in some form across all three. The real differences buyers should weigh are less about raw feature checklists and more about how well each platform's Redfish support, licensing structure and firmware update process fit an organisation's operational habits — see our iDRAC, iLO, and XCC comparison for the platform-by-platform detail.
Does out-of-band thinking apply beyond the server itself?
The BMC as described here is specifically a server-hardware component — it's the concept that iDRAC, iLO, XCC and IPMI all implement. Other categories of rack equipment increasingly ship with their own independent management planes built on the same underlying logic: a controller that survives a main-OS or main-network outage and offers a separate way in.
Where this matters for a UK buyer is procurement discipline — treating any device with its own persistent management interface, not just the server fleet, as something that deserves the same segmentation and patching attention as the BMCs covered in this piece, rather than an afterthought bolted onto a network diagram.
The UK cost case: what disappears when OOBM is used properly
The clearest financial case for OOBM shows up in colocation. When a server is racked in a facility the admin doesn't sit next to, out-of-band access is especially valuable because it can eliminate most physical visits and smart-hands requests that would otherwise be needed just to power-cycle a box, remount an ISO, or read a hardware log after a fault.
For a UK organisation paying for engineer call-outs or smart-hands time by the hour, every one of the five core BMC functions above is a task that no longer needs a person standing at the rack. The exact pounds saved depend on the colocation contract and how often a fleet needs hands-on intervention, but the direction of the saving is consistent: fewer dispatched visits, faster fault turnaround, and less downtime spent waiting for someone to arrive on site.
Worked example: recovering a frozen server in a UK data centre
Picture a Dell PowerEdge racked in a UK colocation facility. Monitoring shows the host has stopped responding to pings and SSH; the OS is unreachable. Instead of raising a smart-hands ticket, the admin connects to iDRAC over the dedicated management network, authenticating through VPN or a bastion host rather than any direct internet-facing route.
- •Open the virtual console to see the last on-screen state — often a kernel panic or hung boot screen invisible to in-band monitoring
- •Check sensor readings and the hardware event log for anything abnormal before assuming it's a software-only fault
- •Issue a remote power cycle from the BMC, which works regardless of whether the host OS responds, because the controller sits outside the operating system entirely
- •If the OS needs reinstalling, mount a recovery ISO as virtual media and boot from it, exactly as if a technician had walked in with a USB stick
The exposure UK admins overlook: BMC security
The same independence that makes a BMC useful is exactly what makes it a target. It is, in effect, an always-on remote root path into server hardware that exists whether or not anyone is actively using it, and it should be treated with the same seriousness as any other privileged access system — not as a convenience feature bolted on for out-of-hours emergencies.
Three habits matter most. Never expose a BMC interface directly to the public internet — access should go through a VPN or a bastion host, and the interface itself should sit on a dedicated management network, isolated from production traffic. Change default credentials on every unit; vendor-default logins on a BMC are a well-known attack path. Keep BMC firmware current — vulnerabilities in these controllers are a regular, recurring occurrence, which makes patching cadence part of routine server BMC firmware security rather than an afterthought.
At the network level, it helps to know what you're segmenting. IPMI traffic runs over UDP 623, and the web-based console on most modern BMCs defaults to HTTPS on port 443 — both should be scoped to the management VLAN only, never opened on a general-purpose firewall rule.
Choosing and hardening: a practical decision framework
The buying question for a UK organisation isn't simply which vendor console has the longest feature list — as established, iDRAC, iLO and XCC all expose broadly similar core functions. The more useful questions are whether the platform supports modern Redfish-based automation alongside legacy IPMI, whether it fits centralised lifecycle and patch management across a mixed fleet, and whether its licensing and access model makes it easy to enforce VPN/bastion-only access rather than tempting an admin to open a shortcut.
- •Put every BMC on an isolated management VLAN, never on the same subnet as production traffic
- •Require VPN or bastion-host authentication before any BMC session — no direct internet exposure
- •Change default credentials on day one, per device, before the server enters production
- •Track BMC firmware versions as part of routine patch management, given how regularly vulnerabilities surface
- •Favour platforms with strong Redfish support if the goal is scripted, fleet-wide automation rather than one-box-at-a-time console access
Sources
Every figure in this article traces to the sources below.
- •DataColoc — BMC/IPMI/iDRAC/iLO fundamentals and hardening advice
- •ServerFault — difference between iDRAC, IPMI and iLO
- •HostiServer — out-of-band server management (IPMI/iDRAC/iLO), BMC hardware and standby power
- •HostiServer (CZ) — Redfish API alongside IPMI in modern OOBM
- •Aikaboom — vendor BMC implementation comparison