The Default Is the Policy
Defaults · July 1, 2026 · 8 min read
There are two ways to make a machine behave safely. You can change what it does when nobody intervenes, or you can write down what somebody ought to do. In a hardening standard these look almost identical — each occupies a line, each has a rationale, each can be audited. In practice they are not comparable instruments, and confusing them is why estates with excellent documentation routinely contain badly configured machines.
The difference is where the cost lands.
The arithmetic of a documented instruction
A written instruction is a control whose cost is paid per host, per build, per person, per year. Every multiplier applies. Someone has to encounter the document, understand which of its statements apply to the machine in front of them, translate prose into the specific commands their version of the software requires, and do so at a moment when they are usually trying to accomplish something else entirely.
Each of those steps has a completion rate below one, and the rates multiply. This is not a claim about the diligence of engineers; it is the structure of any process assembled out of voluntary human steps. Add the ordinary erosions — the document describes a version that has moved on, the person is building the host under time pressure, the instruction is unambiguous to its author and ambiguous to everyone else — and the effective coverage of a purely documentary control falls off steadily with the size and age of the estate.
A default has none of those multipliers. It is set once, at the point that everything downstream inherits from, and it applies to machines built by people who have never heard of the standard. That last property is the whole argument. The test of a control is not what it does for the conscientious operator. It is what it does for the host that was built in a hurry by somebody who never read anything.
Which way the gradient points
The deeper effect is not coverage but direction of effort.
Under documented guidance, the safe configuration costs work and the unsafe one costs nothing. Doing nothing yields the shipped behaviour, which is frequently permissive, because software vendors optimise defaults for the installation succeeding rather than for the installation being restrictive. Every hardened machine therefore represents expended effort, and effort is exactly the resource that runs out first.
Under a secure default, the polarity reverses. Doing nothing yields the restrictive state. The unsafe configuration is what now costs work — someone has to decide they want it, name the machine, and make a change that is visible. That visibility is worth as much as the setting itself, because it converts an absence into a record. You cannot review the machines where nobody bothered to harden anything. You can review a list of the machines where somebody deliberately relaxed a control.
Most of what people call security culture is really this gradient. If the safe path is downhill, an estate stays roughly safe with ordinary effort. If it is uphill, no amount of exhortation holds the line for long.
The four places a default can fail
Defaults are the better instrument and they are not a free one. The failure modes are specific.
A strict default that breaks real work gets disabled globally. This is the important one. When a restriction collides with a legitimate workload and the only available remedy is coarse, somebody turns the control off for everything rather than for the one machine that needed it. The estate ends up worse than under guidance, because the exception is now invisible and permanent. A strict default is only safe to deploy alongside an escape hatch that is cheap, granular, and leaves a record. If relaxing a setting for one host is harder than relaxing it for all of them, expect the latter.
A default is invisible, and invisible decisions get undone. Nobody can inspect a choice they never made. An engineer debugging a failure will remove a setting whose purpose is not recoverable from the machine itself, and they are right to — an unexplained restriction is indistinguishable from a mistake. The reason has to travel with the setting, in a comment, in the provisioning code, somewhere that the person holding the shell can find it in the moment they are deciding.
A default only governs the future. Changing the image changes the machines built after the change. The existing estate is untouched, which means every default has a companion problem: the population that predates it. Ignoring that population is how an organisation ends up believing a control is universal when it applies to a quarter of the fleet.
Some controls resist defaulting entirely. A setting whose correct value depends on what the machine is for cannot be defaulted safely, only defaulted conservatively. The honest response is to default to the restrictive value and accept that a proportion of hosts will need explicit relaxation, rather than to default to the permissive value and rely on a document to fix it afterwards.
When guidance is unavoidable, make it executable
Some controls really do require judgement, and no default can carry them. The improvement available there is not better prose but feedback.
A sentence in a document has no way of knowing whether it was followed. A check does. Shipping the check alongside the instruction — something that runs on the machine, evaluates the actual state, and says plainly whether the state is what the standard describes — converts an unverifiable request into a closed loop. The value is not the enforcement; it is that the gap between intent and reality becomes observable at the point where it is cheapest to fix, which is on the machine, at build time, by the person who is already there.
That is also the fairest test to apply to any hardening standard you inherit. Take each line and ask what happens to a machine built by somebody who never read it. The lines that survive that question are your actual security posture. The rest are aspirations, and it is worth knowing which is which before an auditor, or an intruder, works it out first.