Hosts You Are Not Allowed to Touch

Constraints · July 22, 2026 · 10 min read

Every hardening programme eventually arrives at a machine where applying the standard is not merely inconvenient but impossible. Not impossible this quarter — impossible in the sense that there is no supported sequence of actions that ends with the baseline applied and the machine still usable.

These hosts get treated as an embarrassment: a residual, an asterisk, a slice of the estate marked “out of scope” that quietly grows year on year. They deserve better than that, because they are not one problem. They are four, they refuse for different reasons, and only one of those reasons is technical.

The appliance

A sealed product built on a general-purpose operating system that the vendor has decided is not yours. There may be no shell. There may be a shell that exists, works fine, and voids support the moment you use it. The configuration surface is exactly what the management interface exposes, and the operating system underneath — its accounts, its services, its listening ports, its packages — is not visible to you and not modifiable by you.

The important consequence is not that you cannot harden it. It is that you cannot enumerate it. An announcement about a flaw in a common library tells you nothing, because you have no way to determine whether the appliance contains that library, at what version, or whether the vendor considers it reachable. The machine is opaque in both directions.

The embedded controller

A device with a firmware image rather than an installation: read-only root filesystem, no package manager, configuration compiled in or held in a small fixed store, and credentials that are a property of the model rather than of the unit. Its lifetime is not a software lifetime. It is bolted to or inside a piece of physical equipment whose service life is measured in decades and whose replacement is a capital project with a shutdown, a crane, or a regulator attached.

That mismatch is the crux. Software assumes a replacement cycle of years; industrial and building equipment assumes one far longer than the working life of any operating system it happens to contain. No hardening programme resolves this, because the constraint is not in the code. It is in the concrete.

The vendor-managed host

You own the hardware. Someone else holds administrative control of it under a managed service agreement, and their obligation is availability of a service, not the security of a configuration. Two administrative authorities exist on one machine, and yours is the weaker one.

This category is uniquely frustrating because everything is technically possible. The commands would work; the baseline would apply. What prevents it is that the other party’s engineers will remove your change on their next maintenance visit, or decline to support the outcome — both reasonable responses from where they are standing. Nothing about the machine is stopping you. The relationship is.

The certified system

A machine whose usefulness depends on a statement that it has not been altered: a support contract with a supported-configuration clause, a safety certification, a regulatory validation, a calibration, an insurance condition. Change the configuration and you have not merely lost support — you may have invalidated the property that makes the machine legally usable at all.

It is worth resisting the reflex that these clauses are obstructive bureaucracy. Frequently the certification protects something real: a control system whose timing behaviour was validated as a whole, a device whose failure modes were characterised in one specific configuration, an interlock whose correctness argument assumes a particular software state. A security team that treats such a clause as an inconvenience to be routed around is proposing to trade a well-understood physical risk for a poorly understood digital one, without saying so out loud.

The shape underneath all four

Strip away the specifics and the same structure appears every time. Control over the machine is split between parties. The party with the technical ability to change it has no incentive to; the party with the incentive has no ability.

Naming that structure is the single most useful thing you can do with one of these hosts, because it immediately tells you which department owns the remedy — and it is almost never the one doing the hardening. An appliance’s opacity is a procurement outcome. A vendor-managed host’s divided authority is a contract term. A certification’s rigidity is a decision about which risk the organisation would rather carry. None of these is repaired by a configuration management tool, and every hour spent trying to repair them with one is an hour not spent where the fix actually lives.

What is genuinely available

When the machine cannot take the baseline, three moves remain.

Read the actual restriction rather than the fear of it. The prohibition is usually narrower than the way it is repeated internally. A supported configuration clause typically governs the application and the parameters the vendor tests; it rarely says anything about the credentials on the out-of-band management controller, an unused management protocol nobody has ever enabled, or the physical ports on the front of the chassis. Often nobody has read the clause in years and the restriction being honoured is folk memory. Getting a written answer to “which of these specific changes would void support” costs one email and frequently returns most of the baseline.

Harden the parts of the machine that are not the machine. The out-of-band controller is very often a separate small computer with its own network interface, its own account database and its own default credential, and it is frequently not covered by the restriction that protects the host. Console and serial access, removable media, boot order, firmware settings and physical enclosure are attributes of the box rather than of the vendor’s software. This is unglamorous work, and on an untouchable host it is often the only work available that changes anything.

Record it as an owned decision with an expiry. An exception naming the host, the control that cannot be applied, the reason, the person accountable and a date on which somebody must look again is a different object entirely from a host quietly filtered out of a report. The first is a decision the organisation has made. The second is a fact it has stopped noticing, and given enough years those are the machines that surprise everyone.

What is not available is a compensating control that is really a sentence. If the mitigation for an unpatchable controller is “it is on a restricted network”, somebody should be able to demonstrate that restriction rather than assert it, and somebody should know what happens the day an engineer connects a laptop to it for maintenance. A mitigation nobody has tested is not a control; it is a way of writing the risk down so it stops appearing on the report.

Sometimes the truthful conclusion is that a machine cannot be secured to the standard, that replacing it is a multi-year capital matter, and that the organisation is carrying the exposure in the meantime. Stated plainly, that is defensible and actionable — it puts a date and a budget line on the problem. A hardening programme is judged on the estate it can reach. A mature one is judged on how honestly it describes the estate it cannot.