The Shared Responsibility Model Has No Word for the BMC. That Is Not a Gap in the Model — It Is Proof the Boundary Was Never There.

Every cloud and hosting contract signed in the last fifteen years rests on the same diagram. There is a line. Below the line is the provider's problem — power, cooling, hardware, hypervisor. Above the line is yours — operating system, patches, application, data. The line is why the arrangement is sellable. It tells two organisations which one gets fired.

The baseboard management controller sits below the line, is operated by the provider, and has total authority over everything above it.

That is not an edge case the model handles badly. It is a component the model has no vocabulary for, and its existence is an argument that the clean boundary the whole industry draws does not exist on physical hardware.

What actually lives down there

We counted the surface twice today. 31,325 management controllers answering the open internet. Eight hosting networks holding 28.8 percent of them. Roughly 24,650 handing out an authentication hash to anyone who asks, before login, because that is what the 2004 protocol specifies.

And a controller is not a remote-reboot button. It is a small computer with its own processor, memory, network stack and power domain, sitting beneath the operating system. On many platforms it can read host memory directly over DMA — a capability documented on the ASPEED parts that dominate the fleet, and demonstrated in working form by the BMCLeech research, whose central finding is that the host operating system cannot detect it is happening. Firmware implants at that layer, like iLOBleed, survive an OS reinstall and a disk replacement.

So the entity below the line can read the memory of the entity above it, invisibly, and persist through everything the entity above it would do about it.

Why neither party's security programme covers it

Ask a hosting provider who is responsible for a customer's BMC and you get a reasonable answer: it is the customer's machine.

Ask the customer and you get an equally reasonable answer: they never configured it, were not offered a setting for it, cannot see it from inside their operating system, and in many cases do not know their server has one.

Both answers are honest. Both are wrong in the same direction, and the result is a control plane with authority over production that appears in nobody's asset inventory, nobody's patch cadence, nobody's access review, and nobody's threat model. The provider treats it as plumbing. The tenant treats it as nonexistent. It is the only component in the stack where "not my responsibility" is sincerely believed by both parties simultaneously.

That is what makes it structurally different from an ordinary misconfiguration. An unpatched web server has a clear owner who is failing. A BMC has two owners who each correctly believe it belongs to the other.

Feature, not bug — which is why you cannot patch your way out

The instinct on reading the exposure numbers is to look for the vulnerability. There is one, in the sense that the hash disclosure is a bad protocol decision from 2004. But the thing that actually matters is not a flaw at all.

A BMC's total power over its host is the product working exactly as designed. Mounting virtual media, reinstalling the operating system, reading the console, controlling power, operating when the machine is off — that is the feature list. It is why the component exists and why data centres are staffable at all.

You cannot issue a CVE against a capability. There will be no patch that removes the BMC's authority over the host, because removing it removes the reason anyone bought it. The exposure is a configuration problem and it is fixable. The authority is permanent, and the security model has to be built around its permanence rather than in hope of its removal.

Build with intent: the primitive that is actually worth having

Here is the part worth engineering rather than only worrying about, and it comes from inverting the threat.

Every agent-based response you own runs inside the operating system. A sufficiently compromised kernel can lie to all of them — it can report a clean process list, swallow the isolation command, and tell your console the host is fine. The BMC is the one control plane that does not ask the operating system anything. It cannot be lied to by the thing it is acting on.

So the interesting primitive is not power-off. It is hibernate.

Power-off and reboot destroy volatile state, which is precisely what Tengu weaponises when it pets a hardware watchdog so that killing its process forces a reset and wipes the memory-resident evidence. Hibernate does the opposite: it writes system memory to disk and then halts. One out-of-band command, issued from below the compromise, that simultaneously contains the host and forces it to produce its own memory image on the way down. Containment and forensic capture in a single action the rootkit cannot intercept.

That is a genuinely good response primitive and it is underused.

Now the intent part, which is where the design gets decided. Build it scoped like this:

• Your hardware, your controllers, your detections, your decision. The orchestrator lives inside your management VLAN and holds credentials only for machines you own.

• Credentials per machine, in the vault, never shared with the detection layer. The thing that decides and the thing that holds the keys are separate services, and the decider can only request an action, never authenticate one.

• Hibernate, then human. The automated action is the reversible, evidence-preserving one. Nothing automated reflashes firmware or wipes anything.

• Rate-limited and quorum-gated. A detection engine that can hibernate one host per interval is a defence. One that can hibernate a fleet is an outage generator wearing a defence costume.

And build it explicitly not like this: a centralised, cross-tenant service holding BMC credentials for thousands of machines across many providers, firing automatically on detection. That is the "golden dome for the internet" version, and it fails on its own logic in three ways.

It becomes the highest-value target ever constructed. Compromising the defence does not yield one host; it yields a synchronised power-off of everything it protects. Missile defence at least has the property that capturing the interceptors does not let you fire them at the cities.

It converts detection into a remote off-switch. If looking like an attack triggers hibernation, the cheapest possible offensive play is to make a competitor's machine look attacked. You have handed adversaries an availability weapon with your own detection engine as the trigger.

And it requires the provider to act inside the tenant's machine on the provider's judgement — which is the shared-responsibility failure this whole piece is about, automated and scaled. The correct response to a boundary that does not exist is not to start reaching across it faster.

What providers should ship instead

The honest fix for the structural problem is not more provider authority. It is making the layer visible to the party who carries the consequences.

Tell the tenant the BMC exists, at provisioning, in the console, next to the specs. Expose its state as an API — is it reachable from the internet, when was its firmware last updated, when did its credential last change. Make private-by-default the default, not a support ticket. And let the tenant hold or rotate the credential on hardware they are paying for.

None of that is technically hard. All of it is a product decision that has not been made because nobody has been asked for it loudly enough, which is a fair description of most infrastructure security for the last two decades.

The limit of the argument

We hold this at 95 percent.

The technical claims underneath this are other people's research and we have credited them where we used them — the DMA work on ASPEED parts, BMCLeech, iLOBleed, and this month's Supermicro firmware advisory. What is ours is the exposure count and the argument, and an argument is a weaker thing than a measurement. Not every BMC has unrestricted DMA to host memory; it varies by platform, generation and configuration, and a defender should treat it as a capability that may be present rather than a certainty.

We are also not claiming the shared responsibility model is useless. It is a good model. It is a good model with a layer underneath it that it does not name, and naming that layer is the entire point of writing this down.

The practical version fits in a sentence, and it is the same sentence we have ended on twice today: the port is either reachable from the internet or it is not, that is the one link in the chain you fully control, and you can check it in about a minute.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com