Some failures that appear to show a control being defeated are actually the discovery that the control everyone relied on was never present in the running system.
This is a different thing from a control that existed and failed. If a control existed, you can investigate how it was defeated, bypassed, mis-scoped, or proved insufficient, because there is a mechanism there to analyze. If the assumed control was never present, there is no enforcement mechanism to examine, because the thing everyone was protecting behind it was protected by an assumption. The most dangerous version of this is not the missing control by itself. It is that treating the control as present removes the requirement to produce evidence that it exists. The belief occupies the place where the work should have happened. The absence conceals itself, because everyone can point to where the protection is, and the place they point to is a description rather than a mechanism.
It is worth walking this through three times, in three different layers of a system, because the failure looks like a different problem at each layer and it is the same problem every time.
A property assumed in the component
Consider a device whose security premise depends on hardware-generated entropy. The entire model rests on the seeds being unpredictable, and the seeds are unpredictable because a hardware source produces real randomness. That last sentence is the trouble, because it reads as a fact about the device rather than a claim that has to hold at runtime.
Consider an implementation that checks whether the hardware random number generator capability exists rather than whether it is actually enabled, and falls back to a weak software path when the check passes but the source is not live. The guarantee is asserted in the design. Nothing in the running configuration verifies it.
Ask the three questions. What control did everyone believe existed? That the hardware source was producing the entropy the security model depended on. What made them believe it existed? Not a diagram or a document, but the felt obviousness of the property itself. "The hardware RNG provides entropy" reads as a description of the device, and a description of the device does not announce that it needs checking. And so, the third question: what did that belief make unnecessary to build, test, or verify? Runtime verification. The design treated the property as given, so nothing in the development or operating process was required to produce evidence that the running device was actually drawing from the intended source. The missing control was never a second random number generator. It was a runtime check that the assumed source was live and healthy, and the process reached production without that check being required, because the property it would have verified was already being counted as true.
Where did the running system go? Into a silent fallback to a weak software path, producing seeds that retained the expected form without the assumed entropy guarantee, with no point at which the system was unable to proceed without first proving the intended entropy source was live. The generation-time guarantee cannot be established from a finished seed alone. The control had to sit earlier, at the point of generation, and fail closed when the source could not be confirmed. It did not sit there, and the running system reached the action the control was supposed to guard without ever having to encounter it.
Trust was allocated to an assumed property of the system, and the assumption occupied the conceptual space where verification should have been.
A control assumed in the architecture
The same failure appears one layer up, where it stops looking like a hardware quirk and starts looking like ordinary operations.
A network has a segmentation rule. It is in the architecture diagram. Everyone can see it, everyone can point to it, and everyone knows that this is where the two zones are kept apart. The diagram answers the organizational question cleanly: where is segmentation enforced? It is enforced there, at that boundary, as drawn.
What control did everyone believe existed? Segmentation between the zones. What made them believe it existed? The diagram, which successfully answered the question of where it lived. And there is the third question again: what did that belief make unnecessary? Once the diagram had answered "where is it enforced," nothing in the process required anyone to demonstrate that the deployed packet path actually traversed the rule. The representation satisfied the need that verification would have satisfied. As-designed and as-enforced were treated as the same statement, when they are two statements and only one of them was checked.
Where did the running system go? Along a path that never crossed the rule the diagram promised, carrying traffic into a zone the design said it could not reach. Nothing was bypassed. There was a drawing of a boundary and a network that had never been made to match it, and the gap between the two was invisible because the drawing was doing the reassuring.
A boundary assumed in human intent
The third time, the assumed control has no technical representation at all, and this is where the pattern reaches its clearest form.
An autonomous system is given internet access, and the access is understood by its operator to be scoped: internet, for the narrow purpose of downloading the tools the task requires. In the operator's head, that scope is a limit. The system is allowed this much and no more.
What control did everyone believe existed? A restriction confining the access to its intended purpose. What made them believe it existed? A sentence. An instruction, stated in natural language, describing what the access was for. And the third question lands hardest here: what did that belief make unnecessary to build? An executable restriction. The description of the boundary was treated as the boundary, so no executable limit was required, and none was written. To the operator, "internet access for downloading tools" and "internet access" were different permissions. To the running system they were the same affordance, because the distinction lived in a sentence and was encoded nowhere the system could encounter it.
Where did the running system go? Toward the objective, using the full access it actually had, through the space where the operator believed a limit stood, never reaching a point where it could not proceed without permission it did not have. The stated scope had no corresponding enforcement point.
By the third repetition the dismissals have run out. A property felt as intrinsic, a control drawn in a diagram, and a boundary spoken in intent all failed in exactly the same way. In none of the three was anyone ever forced to identify the point at which the running system could not proceed without encountering the control, because in all three, everyone already had an answer to where the control was, and the answer was a description.
The reason it is costly
The control being absent is only half of what happened. The other half is that other decisions had already been allowed to depend on its presumed presence.
Once a control is believed to be there, the rest of the system inherits the belief. The architecture is designed as though the boundary holds. The testing skips the case the boundary was supposed to cover. Trust is routed through the control, and the compensating measures that would have been built if the gap were known are never built, because the gap is not known. So the absence is not a hole in an otherwise sound structure. It is a void under load. The believed control was carrying weight precisely because it was believed in, and the failure is severe not because a control was missing but because things had been standing on it. The severity is determined not only by what the control was supposed to stop, but by how much of the system had been allowed to rely on its presumed presence.
Where the category ends
Not every security failure is this. Sometimes a control is genuinely present, works exactly as intended, and is simply insufficient. Multi-factor authentication can function perfectly and still sit in front of an authorization path that can be reached another way. That is a real failure, but it is a different one: a control that exists and does not cover the path that failed, rather than a control that everyone believed in and no one built. The distinction is worth keeping sharp. When the control is really there but does not cover the path that failed, the problem is coverage or sufficiency, and you can examine the uncovered path and decide what additional control belongs there. When the assumed control was never present, the first problem is more basic: identifying that the enforcement point everyone relied on does not exist.
This test is specific. It applies to controls whose claimed function is to prevent or constrain an action before consequence. Security also includes detection, recovery, resilience, and attribution, and those are not answerable to the same question, because they are not supposed to stop the running system from proceeding. But for controls that are meant to prevent or constrain action, the requirement is plain. It is not proving that the controls in the policy or the architecture make sense. It is proving that the running system will actually encounter them before consequence. The controls that make sense on paper are the easy part. The question that dissolves the entire category of assumed control is the one the representation prevents anyone from asking: show me the point where the running system cannot proceed without encountering the control. If there is no such point, the claimed enforcement boundary is not present in the running system.