All Articles
Tutorialsbmcipmiredfishsysadmindedicated serverssecurityhardwarenetworking

What Is a BMC, and Why Does Every Dedicated Server Have One?

25 September 2026· 8 min read· Andrew Arscott

The Computer Inside Your Computer

Here's a fact that trips people up the first time they hear it properly explained: the "server" you're managing almost certainly contains a second, entirely separate computer — one with its own processor, its own memory, its own network port, and its own operating system, running independently of whatever OS you actually installed. It boots before your server does. It keeps running when your server is switched off, as long as the power cable is still in the wall. And it can turn your server on, watch it boot, and take over your keyboard and screen, all without your OS knowing or having any say in the matter.

That's the BMC — the Baseboard Management Controller. It's not a feature you installed. It's not software. It's a physical chip, soldered to the motherboard, present on essentially every server-grade machine sold in the last two decades, and most people managing a fleet of servers interact with it constantly without ever really being told what it is.

What It's Actually For

The BMC exists to solve a specific, unglamorous problem: what do you do when a server won't boot, and there's no screen or keyboard plugged into it, and it's in a data centre three countries away? Before out-of-band management existed, the honest answer was "send someone to the building." The BMC is the reason that's rarely necessary anymore.

It gives you three things, independent of the server's main OS or power state:

  • Remote power control — power on, power off, hard reset — the equivalent of physically holding the power button, done from a browser.
  • A virtual KVM console — Keyboard, Video, Mouse — effectively a screen and keyboard for a machine that has neither plugged in, letting you watch BIOS output, install an OS, or recover a machine that's stuck at a boot prompt.
  • Virtual media — the ability to mount a file, almost always an ISO, over the network as if it were a physical disc inserted into the drive.

It typically also exposes sensor data — CPU temperature, fan speed, power draw — and can log or alert on hardware faults the main OS would never see if it's crashed or hasn't booted yet. All of this happens over the BMC's own dedicated network port (sometimes a shared port with the main NIC, configurable either way), with its own IP address, completely separate from whatever the server's actual operating system is doing on the network.

IPMI, and the Vendor Names You'll Actually See

IPMI — Intelligent Platform Management Interface — is the industry-standard protocol for talking to a BMC. It's not a product; it's a specification, which is why the same underlying capability shows up under different brand names depending on who made the server:

  • iLO (Integrated Lights-Out) on HPE servers
  • iDRAC (Integrated Dell Remote Access Controller) on Dell
  • IPMI or a vendor-specific web UI on Supermicro boards, common on budget dedicated-server hardware
  • Redfish — the newer, REST-API-based standard steadily replacing classic IPMI, designed to be scriptable and automatable in a way IPMI's older protocol never really was

Whichever badge is on it, the underlying job is identical: an independent management plane sitting alongside the actual server, reachable whether or not the server itself is doing anything useful.

The Part Worth Taking Seriously: Security

This is the angle that doesn't get anywhere near enough attention, and it's worth knowing even if you never touch a BMC directly. A BMC is, functionally, its own small embedded Linux computer with full power over the host it's attached to — and that combination has a genuinely poor security track record.

A few reasons this matters more than it looks like it should:

Firmware that rarely gets patched. Unlike the main OS, which gets regular updates as a matter of routine, BMC firmware is often installed once and never touched again — sometimes for the entire service life of the hardware. Known vulnerabilities in IPMI implementations have sat unpatched on production servers for years, not because anyone decided the risk was acceptable, but because nobody was looking at it.

Default credentials that survive longer than they should. IPMI has a long, well-documented history of shipping with default usernames and passwords that plenty of deployments never get around to changing — and unlike a normal login, this one has direct power-control and console access to the physical machine behind it.

A network exposure that's easy to overlook. Because the BMC has its own IP and its own network path, it's entirely possible to have a server that's properly firewalled and hardened on its main interface while its BMC sits reachable on the same network — or, worse, the wider internet — with none of the same scrutiny applied to it.

None of this is a reason to avoid using a BMC — it's genuinely useful, often essential infrastructure. It's a reason to treat it with the same seriousness as any other privileged access point: change the default credentials immediately, keep it off a network segment it doesn't need to be on, and don't assume "it's just for emergencies" means "it doesn't need looking after."

Where This Fits If You're Setting Up a VM Remotely

If you've landed here from working through getting a virtual machine running on a headless, remote Hyper-V host, this is the piece that gets you in the door — I've written through that whole process separately, from first console access through to the VM actually having a network connection. The BMC and IPMI are step one of that; everything past the login screen is ordinary Windows and Hyper-V administration.

Closing Thoughts

A BMC is easy to take for granted precisely because it works quietly in the background of infrastructure most people only think about when something's gone wrong. It's worth understanding properly rather than just clicking "Connect using IPMI" without knowing what's actually on the other end of that link — not least because it's one of the few things in a server room that's still running, and still capable of doing damage, long after everything else has been switched off.

Have thoughts on this? Get in touch.