A control you switched on is not a control that's in force

By Daniel S. · July 16, 2026

TL;DR: Every security control has two halves — the configuration (what you wrote down) and the enforcement (what the machine is actually doing right now). Reading a config file, checking a BIOS toggle, or confirming a hook is installed tells you about the first half and nothing at all about the second. In one week I found four controls that were switched on and not in force, including a box certified as key-only SSH that was accepting passwords from the entire LAN. The fix is one sentence, and every instance below is a variation on it: ask the running system, not the file.

The distinction, precisely

You harden a service. You edit the config, you set the flag, you install the gate. Then you check your work by looking at the thing you just wrote — the file is there, the toggle says enabled, the hook is in the directory.

Every one of those observations is a fact about your intent. None of them is a fact about the machine's behavior. In between the two sits a long chain of things that can silently fail: a daemon that never reloaded, a config directory that isn't actually included, a firmware setting that's pending a reboot, a dependency the gate couldn't find.

When that chain breaks, you don't get an error. You get a control that looks on from every angle you thought to check, and is off in the only sense that matters. And you find out when someone walks through it.

Here are four, all real, all from about one week.

1. The box certified key-only that was accepting passwords

A Linux box in my fleet was hardened with password authentication disabled — SSH keys only. It had been certified as key-only; a check ran, the check passed, the certificate was issued.

It was accepting password logins from the entire house LAN. It had been for a day. And the install password — a throwaway, written down in plain text in a repo because it was "going to be disabled anyway" — worked.

Here's the part worth sitting with: the certification wasn't lying. It read the config, and the config said what it was supposed to say. What nobody had done — not once — was ask the running daemon what it was actually enforcing, or, better, try to log in with a password and watch the server refuse.

The fix that finally closed it wasn't a better config. It was two commands:

# 1. Ask the DAEMON what it is enforcing, not the file what it says
sshd -T | grep -i passwordauthentication
# passwordauthentication no

# 2. GROUND TRUTH: attempt the thing that must fail, and watch it fail
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@host
# Permission denied   <-- THIS is the certificate

That second command is the whole post in one line. The control is proven by the attack being refused, not by the config being present.

sshd -T matters on its own, by the way, because sshd_config is not one file anymore — it pulls in drop-in directories, and it can carry conditional Match blocks that override the global setting for particular users or subnets. A file you read and a config the daemon assembled are two different objects.

2. Secure Boot "enabled," enforcing nothing

Secure Boot has a toggle. The toggle can read enabled while the platform enforces nothing.

The state is called Setup Mode, and it means the platform's key hierarchy hasn't been established — there's no Platform Key enrolled, so there is nothing to check signatures against. Secure Boot is on. Secure Boot is verifying nothing. Both statements are true simultaneously, and the BIOS screen shows you only the first one.

So "is Secure Boot enabled?" is the wrong question. The right one is "is it enabled and are keys enrolled?" — two facts, and the reassuring one is the one that's easy to check:

mokutil --sb-state          # SecureBoot enabled
bootctl status | grep -i secure   # reports enforcing vs setup mode

A toggle is a claim about configuration. Enrolled keys are the enforcement. Check both or you've checked neither.

3. The firmware knob that was written and never applied

This one I wrote about separately, because it cost me a night, but it belongs here too.

Some machines let you write BIOS settings from a running OS. You write the value. You read it back. It returns exactly what you wrote.

It is a pending setting, and the read-back is your own input handed back to you in an authoritative voice. The firmware may apply it on the next boot. It may silently decline. The value you're reading proves neither.

The only thing that settles it is a positive artifact — some observable downstream fact that cannot be true unless the setting really took effect. In that case it was a PCI BAR collapsing from 16GB to 256MB, visible in lspci. The read-back was a rumor; the BAR size was a receipt.

Whenever you set something, ask yourself: what would be observably different in the world if this had actually worked? Then go look at that, not at the knob.

4. The security gate that was installed and checked nothing

This one happened while I was writing this post, which is either funny or ominous depending on your week.

I have a pre-commit hook that blocks personal data from ever being committed. It's good. It has no override flag, on purpose. It has been tested.

Someone installed it into a second repository — correctly, following the documented procedure. The hook file was present. It was executable. It was in .git/hooks/. Every single thing you would check to confirm "the gate is installed" was true.

And it checked nothing at all. The hook located its scanner by a path relative to the repository — and in this repository, that path didn't exist. The code did the natural thing:

if [ -f "$scanner" ]; then
    "$scanner" || exit 1      # block the commit
fi
# ...falls through here, exit 0, commit proceeds

A missing dependency read as a pass. The gate was installed, present, executable — and it waved through a test commit containing a street address and a phone number without a murmur.

The fix is a one-word change in posture: if the gate cannot run, the gate FAILS.

[ -f "$scanner" ] || { echo "leak-guard: scanner not found — BLOCKING" >&2; exit 1; }
"$scanner" || exit 1

An if around your security check is a bug. "I couldn't check" and "I checked and it's fine" must never produce the same exit code, and the default when you're unsure has to be no.

Why "just read the config" can never work

Look at the four failures together and the pattern isn't carelessness, it's category error:

In every row, the left column is a document and the right column is a running system. Documents are easy to read, which is exactly why we keep reading them and calling it verification. But a control is not a document. A control is a behavior, and behaviors can only be observed by making the system behave.

The three-rung ladder

Every fix above is one of these, and they get stronger as you climb:

1. Ask the running system, not the file. sshd -T, not cat sshd_config. The effective config, the loaded module, the live register.
2. Demand a positive artifact. Some downstream fact that cannot be true unless the control is really in force. The collapsed BAR. The enrolled key. Not the setting — the consequence of the setting.
3. Attempt the thing that must fail, and watch it be refused. Try the password login. Commit the fake address. Boot the unsigned binary. This is the only rung that produces a certificate rather than an opinion, and it's the one almost nobody climbs to, because it feels redundant right up until the day it isn't.

That box was certified key-only for a day. The config file was perfect the entire time. One password login attempt — four seconds — would have caught it, and nobody ran it, because the config said so and the config was easier to read.

Go try the password. Go commit the fake address. Watch the thing you built refuse the thing it exists to refuse. Until you've seen that, you don't have a control — you have an intention with good documentation.