OS drift has an owner. Hypervisor drift has an owner. The tooling in both cases is mature, the baselines are defined, and there is a team with a name that is accountable when the configuration deviates. Hardware-layer drift, meaning the BIOS settings, firmware versions, and BMC configurations on physical servers, tends to have none of that. Not because it is technically hard to detect, but because it falls in the gap between the server team and the platform team and neither team claims it.

The result is predictable. Large estates accumulate years of untracked configuration variation. A server provisioned in one quarter ships with different firmware than the one provisioned the next. BIOS settings drift when someone walks through the datacenter to address a specific ticket and changes a setting that is not in any version control system. BMC configurations diverge between sites because they were set by hand during a hardware refresh and never audited again. None of this is flagged, because nobody is watching.

This becomes a problem in a specific and unpleasant way: an external audit asks for the hardware configuration baseline. At that point the organization discovers there is no baseline to show. That is not a maintenance gap. That is a control failure. The auditor does not care that the server team thought it was the platform team’s responsibility and vice versa. They care that nobody defined the baseline and nobody has evidence it has ever been enforced.

The detection and remediation mechanics at the hardware layer are genuinely different from what teams use for OS and hypervisor work. That part of the problem is real, and it is worth treating separately. But the mechanics do not matter until someone assigns ownership. A team that owns the baseline will figure out the tooling. A team that does not own it will not, regardless of what tooling exists.

The fix is unglamorous. Assign a team. Define a baseline. Audit against it before the auditor does.