Field Notes · Security Architecture August 21, 2026 · 7 min read

A control is worth what it changes about the outcome.

Security programs report on control presence: agents deployed, coverage percentages, findings closed, frameworks mapped. Those numbers establish that controls exist and are configured. They do not establish that a capable actor can no longer reach anything worth reaching, which is the question the spending was meant to answer. The gap between the two is where most security budget quietly goes.

What control presence establishes

Precision first, because the argument is not that measurement is useless. A control inventory establishes real things: the control exists, it is deployed to a known share of the estate, it is configured to a defined standard, and over some period it did or did not generate findings. Those facts support real decisions about hygiene, licensing, and operational maturity, and an organization that cannot produce them has a different and more basic problem.

What the inventory cannot establish is whether the paths that matter are closed. Coverage is a statement about the estate. Exposure is a statement about routes to specific objectives. The two correlate loosely and are frequently confused, because coverage is easy to count and exposure requires someone to reason about how the environment actually fits together.

An attack path is a business dependency in disguise

The reason coverage under-predicts exposure is structural. Serious intrusions rarely proceed by defeating controls head-on. They proceed through legitimate function: an identity that is permitted to authenticate, a service account that is permitted to read a share, a build system that is permitted to deploy, an administrative tool that is permitted to run remotely, a trust relationship between two systems that exists because the business needs those systems to work together.

Every one of those permissions is there for a reason, which is exactly what makes the path durable. A control that sits beside the path rather than on it can be perfectly deployed and perfectly configured and still change nothing about the outcome, because nothing on the route ever encounters it. This is why an organization can improve its coverage metrics for a year and remain equally reachable: the additions landed where measurement was convenient rather than where traversal happens.

The practical consequence for architecture review is a change of starting question. Not "which controls do we have," but "if someone held this identity, what would then be reachable, and which of our controls sits between them and it." Publicly documented adversary behavior catalogues, of which MITRE ATT&CK is the most widely used, are useful here precisely because they describe behavior in terms of what an actor is trying to accomplish rather than in terms of product categories.

Why vulnerability counts are a weak proxy

The same reasoning explains a familiar frustration. Severity scores describe a flaw largely in isolation: how bad it would be if exploited under stated conditions. They do not describe reachability in your environment, whether the affected component sits on a path to anything of consequence, what compensating conditions exist, or how the flaw ranks against a misconfigured trust relationship that no scanner will ever flag as a vulnerability at all.

An organization that ranks remediation strictly by severity is therefore optimizing a proxy. Two flaws with identical scores can differ enormously in what their exploitation would actually enable, and the difference is a property of the architecture, not of the flaw. The correction is not to ignore severity. It is to treat severity as one input to a reachability question rather than as the answer.

What adversary testing establishes, and what it cannot

Objective-based security testing, where a team is given a goal and asked whether it can be achieved, answers the exposure question far more directly than an inventory does. It is also routinely over-read, so the boundaries deserve stating.

A completed engagement can establish: this specific path was available during this window, under these rules of engagement, within this scope; these detections fired and these did not; this objective was or was not reached with the time and access allotted. Those are strong findings and they are the reason the exercise is worth commissioning.

It cannot establish that no other path exists. One team, one window, one set of assumptions, and an agreed scope produce a positive result when something is found and an ambiguous one when nothing is. A report concluding that objectives were not achieved is a statement about that engagement, not a statement about the environment, and it inherits every limitation the scope imposed. This is the same evidentiary structure that governs incident conclusions, treated at length in Evidence Gaps Are Findings: a negative finding is only as strong as the coverage behind it.

Formal testing guidance treats this explicitly, describing assessment as producing results bounded by the techniques used and the scope agreed rather than as producing a general verdict on security. An executive reading such a report should ask what was in scope, what was excluded, how much time was allotted, and whether the team was permitted to use the routes a real actor would prefer. The answers frequently explain the findings better than the findings do.

Findings should change architecture, not accumulate tickets

The most common way organizations waste this work is in the disposition. A path is demonstrated; the specific host, account, or rule involved is remediated; the ticket closes; the underlying structure that made the path available remains. The next engagement finds a variant, and the cycle repeats at annual cadence with a stable budget and a flat risk position.

The distinction worth enforcing is between the instance and the condition. If a build system's deployment credentials reached production, the finding is not that one credential needed rotation. The finding is that the deployment pipeline holds production authority, which is an architectural fact that will keep producing instances. Remediating instances is necessary. Treating instances as the finding is how a program stays busy without changing what an actor can accomplish.

Questions that test a control claim

Five questions, usable by an executive without technical depth, applied to any control being proposed, defended, or renewed:

1. What objective is this control meant to make harder, stated as something an actor would actually want rather than as a technique name?
2. What is the most direct route to that objective in our environment today, and does this control sit on that route or beside it?
3. If the control worked as intended, what would we expect to observe, and are we positioned to observe it?
4. What must remain true operationally for it to keep working: an agent that stays deployed, a rule that stays tuned, a team that stays staffed to respond to what it produces?
5. If we removed it tomorrow, what specifically would become achievable that is not achievable now? A control nobody can answer that question about is being renewed on inertia.

The strongest objection

A capable security leader will push back that this reasoning, taken too far, becomes an argument against baseline hygiene, and that many real intrusions succeed through exactly the unglamorous gaps that coverage metrics exist to close. That objection is correct and it constrains the thesis rather than defeating it. Patching, multi-factor authentication, asset inventory, and endpoint coverage are the floor, they defeat a large volume of opportunistic activity, and an organization without them should build them before commissioning anyone to demonstrate that it is reachable.

The argument concerns judgment above the floor. Once the basics exist, additional spending should be justified by what it changes about reachable objectives rather than by what it adds to a coverage report. A second boundary: objective-based testing is poorly matched to organizations that already know about serious unaddressed paths. Paying a team to demonstrate a weakness you have documented and deferred converts budget into confirmation. Fix the known path first; commission the test when the answer is genuinely unknown.

What good looks like

In an organization reasoning this way, a few things are visible. Security proposals lead with the objective they constrain rather than the category they belong to. Architecture reviews start from identities and trust relationships and work outward toward what those permissions reach. Test findings are dispositioned into instance fixes and structural changes, with the structural list tracked separately and visibly. And when leadership asks whether an investment made the company safer, the answer describes something that is no longer reachable, not something that is now deployed.

Conclusion

Control presence and control effectiveness answer different questions, and only the second one bears on what an actor can accomplish. Because serious intrusions travel through legitimate function, a control's value depends on whether it sits on a route to something worth reaching, which is a property of the architecture rather than of the product. Objective-based testing answers that question directly and within stated bounds that should never be read as a general verdict. The executive discipline is simple to state and uncommon in practice: ask what becomes unreachable, and treat any answer phrased in coverage as a non-answer.

Related: A Technical Claim Is Not Evidence, on the same discipline applied to what a vendor asserts about its own security.

← All Field Notes