Walk through the floor of any major cybersecurity conference, and you will witness an industry quietly admitting that its defining strategy for the last decade has reached its limit.
For years, enterprise security operated under an additive doctrine: if risk increases, purchase another sensor; if complexity grows, deploy another dashboard; if an adversary discovers a novel technique, write another detection rule.
We bought our way into crushing architectural debt.
Today, enterprises maintain dozens of discrete security tools, yet breaches continue to propagate along many of the same lateral paths adversaries navigated a decade ago. Monotonic control accumulation has reached its practical limit. It generates operational friction, introduces new dependencies, and can expand the very attack surface it was purchased to defend.
The market now recognizes that security cannot remain an infinite accumulation of runtime monitors. The new watchword is minimization.
Yet, instead of confronting the hard engineering reality of structural reduction, the industry is already preparing its next comfortable compromise. Rather than deleting architectural pathways, organizations are being told to install automated valves.
The latest narrative pivot urges security leaders to reduce exposure through "dynamic trust minimization" or the elimination of "standing privileges" using automated, just-in-time access brokers.
The theory sounds elegant. Rather than granting persistent rights, keep access permissions at zero until the moment an identity requests them. Evaluate the runtime context, issue an ephemeral token, grant temporary reachability, and withdraw it immediately afterward.
This can reduce the length of time during which access is available. That is valuable. But an automated valve installed on a live pipe is not the same thing as removing the pipe.
Dynamic access models reduce the time during which an attack path is available, but they do not necessarily eliminate the path itself. They move reachability behind a software-mediated condition. The underlying capability to instantiate the path remains.
That distinction matters because dynamic access inherits critical architectural dependencies. It assumes that the identity provider, policy broker, control-plane orchestrator, endpoint telemetry, and authorization logic responsible for opening the path remain trustworthy.
Modern offensive campaigns do not politely wait for a policy broker to approve malicious activity. If an adversary compromises an identity-provider signing key, steals an active session token, manipulates the control plane, or bypasses an endpoint sensor, the attacker may regain the very reachability the dynamic-control layer was intended to suppress. The underlying execution paths and network routes remain logically or physically realizable.
Automated token lifecycles can improve access administration and constrain exposure windows. But they do not, by themselves, harden the underlying architecture. They treat security as an ongoing runtime negotiation and gamble enterprise resilience on the ability of the policy engine to remain informed, timely, and uncompromised.
Just-in-time access asks when the valve should open. Subtractive security asks why the pipe exists.
To build defensible enterprise systems, we must distinguish between two fundamentally different engineering concepts: procedural determinism and structural determinism.
Procedural controls change the conditions under which a transition may occur. Structural controls change whether the transition capability exists at all.
Procedural determinism relies on active runtime evaluation. It is an agentic reflex: an identity broker checking an attribute, an endpoint agent inspecting a process tree, or an automated control loop attempting to match an adversary's speed in real time.
Because these controls operate at runtime, they are inherently exposed to latency, incomplete telemetry, heuristic evasion, sensor blinding, policy error, and control-plane compromise. When an attacker introduces a technique that the procedural rule did not anticipate, the reflex may fail.
Structural determinism does not depend on predicting adversary intent at runtime. It constrains the physical and logical properties of the environment by removing transition capabilities from the enterprise attack graph.
Consider three examples:
A production container deployed without an interactive shell or compiler, and mounted on a non-executable filesystem, does not depend on a behavioral engine correctly classifying every novel payload. The attacker lacks capabilities that many post-exploitation paths require.
A database segment bounded by deterministic egress controls does not require an AI telemetry agent to classify every outbound connection to an unknown destination. If the route is not permitted, the transition cannot occur in the evaluated system state.
Blocking browsers and productivity applications from spawning scripting interpreters or commonly abused native binaries severs high-risk parent-child execution lineages. Instead of waiting to determine whether each invocation is malicious, the architecture removes an unnecessary transition from the attacker's reachable state space.
If a transition capability does not exist in the evaluated system, an adversary cannot traverse it. The organization no longer needs an increasingly complex runtime reflex to out-think an attacker along that path because the architecture denies the attacker the required degree of freedom.
This does not make procedural controls useless.
Some paths are required for legitimate business operations and cannot simply be erased. Those pathways still require authentication, authorization, monitoring, exception handling, and temporary access brokering.
The engineering mistake is treating dynamic governance as an architectural substitute for path deletion. Dynamic access controls work for the edges you cannot delete; they are a fragile, expensive compromise for the edges you should have eliminated in the first place.
Dynamic access is therefore best understood as temporal minimization. It governs when an authorized entity may traverse an unavoidable path. Structural subtraction reduces the set of realizable transitions available within the system entirely.
Subtraction should occur at the earliest point in time and the lowest architectural layer at which required functionality permits it.
The two approaches are complementary, but they exist in a strict hierarchy: first, delete the unnecessary path; only then install a valve on what remains.
If we are serious about moving beyond the additive trap, CISOs must change how security success is measured.
For years, security maturity has been evaluated by the presence of things: policies documented, agents installed, alerts ingested, dashboards deployed, and vendor platforms consolidated.
But consolidating 10 capabilities into a single vendor's multi-module platform is not attack-surface reduction; it is vendor consolidation. Unless the implementation changes system reachability, the underlying enterprise attack graph remains intact.
True engineering maturity must also be measured by what has been removed.
This is why we established the Path Erasure Rate, or PER, within the OWASP Subtractive Security project. Rather than relying solely on subjective maturity tiers, PER provides an objective and falsifiable measure: the proportion of scoped attack paths that have been rendered non-conductive in the evaluated system state.
The emphasis on evaluation is important. Architecture can change. A firewall rule can be modified, a shell can be restored to a future container image, and a network route can be recreated. Path erasure is therefore not a metaphysical claim of permanence. It is an empirically testable claim that a scoped path cannot be traversed under the system state being assessed.
When security engineering teams measure PER, the incentive structure changes:
Architectural success is no longer defined by how many telemetry alerts the security operations center triaged during the quarter.
Success is defined by how many unnecessary execution privileges, network routes, default binaries, trust relationships, and other attacker transitions were rendered non-conductive.
Controls can be tested according to their observable effect on reachability, rather than merely according to their presence in an inventory or policy document.
A claimed erasure can be challenged through empirical testing. If the path remains traversable, it was not erased.
PER does not determine whether every possible path should be removed. Some paths are operationally necessary, and the governance and exception handling required for those paths remain separate engineering concerns. PER measures whether the paths selected for erasure were actually rendered non-conductive.
This moves security measurement away from control accumulation and toward falsifiable state change. That distinction also prevents temporal restriction from being miscounted as structural erasure. A path that can be reconstituted by the ordinary operation of an authorization broker may be tightly governed, but it has not been erased.
Enterprise security leaders stand at an architectural fork in the road.
We can continue chasing the illusion that automated valves alone constitute attack-surface reduction, spending millions on increasingly complex identity brokers, runtime policy engines, and agentic AI loops that attempt to govern an unpruned attack graph in real time.
Or we can return to the foundational discipline of systems engineering.
We can perform the difficult work of structural subtraction: pruning attack graphs, removing ambient privileges, eliminating unnecessary routes and execution capabilities, enforcing hard boundaries, and empirically verifying that targeted paths are no longer traversable.
Automated valves still have a role. Business-required pathways must be governed, and temporary access is generally preferable to persistent access. But we should not confuse better management of a pathway with removal of that pathway.
The first changes when an attacker may traverse an edge. The second changes whether the edge exists.
Stop spending your security budget optimizing locks on doors your architecture never needed in the first place.
Weld the doorway shut.