Economics deep-dive

We are our own worst enemy.

Reed's Law and the security stack we built against ourselves. The cost of running a security program doesn't grow with the number of tools you own, it grows with the number of ways those tools can combine, and that single change of accounting explains why programs freeze at a scale that feels far too small for the freeze to make sense.

Reading time: about 26 minutes. Evidence tiers are mixed and flagged inline: Tier A for the source theory (Reed, Perrow, Conway, and the companion studies behind the 2025 MIS Quarterly editorial), Tier B for the Gartner consolidation survey, Tier C for the vendor-sponsored tool-count surveys from IBM/Ponemon and Panaseer, which are self-reported and are read here as a direction rather than a magnitude.

The thing I thought I was discovering has been said, in one form or another, for a quarter century, so the move is to walk the lineage rather than pretend the ground is fresh. Bruce Schneier put the flag down in 1999 when he wrote that "the worst enemy of security is complexity," and he meant it structurally, that every added feature and option and interaction is a place where a mistake can hide and where an attacker can work. Dan Geer carried the deepest version of it, first in the 2003 paper he wrote with six co-authors, Schneier among them, arguing that reliability's central enemy is complexity, and then more sharply in his 2018 essay A Rubicon, where he made the mechanism explicit in a way that matters for everything below: "as complexity hides interdependence(s), ergo complexity is the enemy of security." That wordhides is the part I keep coming back to, because it says the danger isn't the number of moving parts on its own but the interactions between them that no one can see or account for, which is a claim about combinatorics dressed as a claim about design.

Charles Perrow got to the structural version of this from outside security entirely, in Normal Accidents in 1984, where he argued that catastrophic failure is a property of systems that are both interactively complex and tightly coupled. The reason I reach for him here is that he keeps those two as separate axes rather than folding them into one word. A system can be intricate and slack, which is where he put universities and research firms, so the surprises are survivable because there is time to notice and intervene. It can be simple and tight, which is where he put dams and power grids, so there isn't much to go wrong but there's no room to catch it when something does. It is the corner where both are true, where he put nuclear plants and chemical plants, that produces the accidents he called normal. That distinction is the one this essay needs, because it says the count of the parts and the tightness of their binding are different variables, which is the thing I come back to at the end.

More recently the idea has climbed from the machine up to the organization, and Schneier took his own 1999 line up there himself twenty-six years later, in a March 2025 MIS Quarterly guest editorial written with Anthony Vance of Virginia Tech and titled, in as many words, "Complexity is the Worst Enemy of Security": Studying Cybersecurity Through the Lens of Organizational Complexity. That is the conversation moving exactly where I want to take it, from the box on the rack to the meeting where the box gets approved. It's an editorial introducing two studies that do the measuring rather than an empirical paper itself. I should say now that the two of them are more careful than their own title, because they spend most of a page on a finding that cuts against the flat reading, granting that most technological complexity is good in the sense that it buys capabilities nobody would give up, while still holding that the finding does not negate the principle. I'll come back to that passage later, at the point where it starts costing me something.

Here is where I think Venables and Schneier and Geer are all describing the same animal from different sides. The complexity in a modern security stack is a design outcome, exactly as Venables says, but it is not any single architect's design, and no one lazily reached for it. It is the accumulated residue of a hundred locally-sound decisions, each one a best-of-breed purchase made by a competent team solving a real problem, the EDR that genuinely detected what the last one missed, the SOAR that automated the toil, the second SIEM stood up because the first couldn't hold the new log source, and every one of those was the right call in the meeting where it was made. The design failure isn't in any of the individual choices, it's in the fact that the choices compound, and that the thing they compound into was never designed by anyone at all, because the person who approved the twelfth tool wasn't reasoning about the four-thousand-odd possible groupings the twelve of them can form.

That is why I can agree with Venables and keep the title in the same breath. He is right that it's design and not fate. I'm adding the part that makes the design failure collective and combinatorial rather than personal and lazy, which is that the interactions between components grow far faster than the components themselves, so the system passes out of any individual's ability to design it long before anyone notices it has. We are our own worst enemy precisely because we built the thing that's beating us, deliberately, with good reasons at every step. The trap is that the accounting was wrong: we budgeted for the tools and paid for the combinations. Reed's Law is the name for how fast that second bill grows, and it is the piece the lineage was missing, because Schneier and Geer told us complexity hides the interdependencies and Venables told us design is the real variable, but none of them put a number on how quickly the interdependencies outrun the design.

The part that made me sure this was worth writing is that the exponent doesn't stop at the tools, because the organization that runs the tools obeys the same combinatorics, and this is the section the surveys can't reach. When you propose a change to a security program of any size, you are not negotiating with a list of owners, you are negotiating against a landscape of possible coalitions, every subset of stakeholders who could decide this change threatens them and align to slow it down. You can't know in advance which coalition will actually form, whether the identity team and the network team will make common cause against the new architecture or whether the compliance function will quietly ally with a vendor whose renewal is at stake. Because you can't know which of the 2^N − N − 1 possible groupings will materialize, you end up pricing the change as though any of them might. That pricing, the pre-negotiation you do in your own head before you even float the proposal, is the drag, and it grows with the same exponent as the tool complexity because it is the same exponent.

I've watched this from the inside more than once, on teams where a technically small change sat unmoved far longer than the work itself could explain, because moving it required a set of people to agree in a room. Each of them could see a different downstream owner who might object, so the safe move for everyone was to wait for someone else to go first. Nobody in those rooms was being lazy or obstructionist, which is the uncomfortable part and the reason this connects back to Venables, because from the inside the delay reads as prudence, as responsible change management, as exactly the diligence you'd want. Only from outside, or in hindsight, does it read as a system so interconnected that it has frozen itself. The coalition never even has to form, because the mere possibility of it is enough to price the change out.

I should be precise about what sets that exponent, because 2^N is a ceiling rather than a forecast, and the distance you sit below it is the part you control. Reed's number assumes every member can combine with every other, which is true of an idealized network and false of most real organizations, so what matters is not how many owners a program has but how tightly each one is bound to the others, whether their work has to be reconciled in a meeting or merely lands in the same format. That is a property of the interfaces between them rather than of the count. This is Perrow's distinction arriving where I said it would, since coupling is his second axis and it moves independently of how many parts there are. Melvin Conway made the structural version of the same observation in 1968, arguing that organizations which design systems are constrained to produce designs which copy their own communication structures. It's worth being careful about which structure he meant, because he was explicit that the org chart only resembles the communication structure to the degree that protocol forces communication to run along command lines. Read in the direction this essay needs, it says the two halves of the argument are one argument, because the coupling in how people actually talk and the coupling in what they build are the same coupling seen twice.

The obvious answer to everything I've said is to consolidate, to collapse the 45 or 76 tools down to one platform from one vendor and let the exponent collapse with them. That answer has a well-known rebuttal I have to deal with. Geer and his co-authors made it in 2003 in "CyberInsecurity: The Cost of Monopoly," and the argument is that a monoculture is its own kind of danger, because when everyone runs the same platform a single flaw in it becomes a systemic flaw across everyone. The diversity you gave up to reduce complexity was also buying you resilience against a common-mode failure. That paper cost Geer his job at the time and it has aged well, so I take it as a genuine constraint. The choice isn't simply complex-and-diverse versus simple-and-consolidated, it's a triangle with a third corner that most of the argument ignores.

The way I read the triangle, single-vendor consolidation trades Reed-complexity for monoculture risk, buying you a smaller exponent at the price of a shared point of failure and a lock-in that Geer would recognize on sight. Best-of-breed over proprietary glue trades the other way, buying you diversity and defense-in-depth at the price of the full combinatorial complexity, every tool speaking its own dialect and every integration hand-built, which is the world the survey numbers describe. Neither corner is comfortable, and the debate mostly proceeds as if they were the only two. The third corner is the one worth arguing for, which is diversity held together by open standards rather than by proprietary integrations, and its whole appeal is that it buys the diversity Geer wants without paying the Reed exponent that best-of-breed normally charges.

There is a version of this argument that points at whoever arrives next, and I think the theory owes them an answer rather than describing the curve and stepping around it. Everything above says complexity accretes from individually sound decisions, and hiring a specialist for a genuinely new surface is among the soundest decisions an organization makes, so every time a program decides it needs an owner for cloud security, or identity, or now AI, it is making exactly the locally-correct call this essay says compounds. I've been in the room on both sides of that, as one of the existing owners watching a new function get stood up and as the specialist being stood up. The uncomfortable thing is how similar it feels from either chair, obviously necessary and obviously the right hire, with nobody in the room asking what it will cost to coordinate with.

The answer follows from the coupling rather than from the count, which is why I wanted that distinction in the argument proper rather than buried in the caveats. A new owner can't decline to exist, because the surface is real and somebody has to know it, but they can decide how much of the organization their work has to touch in order to get done. That is the whole design problem restated at the scale of one hire. So the question worth asking of any decision a new domain makes is not how much work it adds but what shape the work has, whether it creates a new node, or a new edge between nodes, or a new place where two owners have to reconcile a disagreement they didn't previously have, or whether it merely puts more traffic down an edge that already carries some. Work routed through channels that already exist costs almost nothing on this curve. A parallel stack with its own console and its own data and its own escalation path costs the most, and it is also the most natural thing to build when a mandate is new and the budget is briefly available.

There's a stronger claim available and I want to hold it loosely, because it's a design claim I'd argue for rather than an outcome I've measured. A new domain arrives with a mandate, a budget, and a short window of permission to ask why things are the way they are, which is the one moment an organization will pay to delete something rather than add to it. The permission debt, the identity sprawl, the three overlapping governance forums that all have to be briefed before anything ships, those are things everyone agreed should be simplified and nobody was ever funded to simplify, and a new mandate is a forcing event that can pay for that work under a name the budget will actually approve. If it does, the new domain comes out complexity-negative on net, adding one owner while removing more coupling than it brought. What makes that possible is worth naming, because it isn't foresight, and the failure this essay describes was never that anyone lacked intelligence. It was that nobody was accountable for the aggregate and nobody was paid to subtract, and a new mandate is the rare moment when both of those are briefly untrue.

I want to guard that against the obvious cheat, because the fastest way to make a complexity number fall is to absorb every neighboring domain into one function and declare the result simple, and the monoculture section above is exactly why that fails. Centralizing the domains rebuilds the single-vendor corner in the org chart, trading the coalition explosion for a chokepoint where one team's blind spots become everybody's, so it relocates the complexity into a single calendar rather than reducing it. The organizational narrow waist has the same shape as the technical one, which is to let the edges keep owning their own work, the way they already own their own systems, and to standardize the interface between them instead of the ownership of them. What a new domain publishes is then a shared way of describing the risk, not a queue everything has to pass through. That is also what the Tanriverdi caveat is telling you at the org level, since a platform that centralized the data and left the permissions alone got a worse internal-breach outcome for its trouble.

The opposite failure is real too, and I suspect it's the one a person who has just read an essay about complexity is most likely to commit, which is refusing to build what the job needs because building it would spoil the argument. Some of a genuinely new surface really is new, and prompt injection and agent autonomy and model supply chain don't reduce cleanly to controls anybody already owns, so a domain that under-builds in the name of minimalism hasn't reduced complexity so much as left something undefended. The discipline I'd hold to is to add the minimum new capability the surface actually requires, keep it loosely bound to everything else, and spend the rest of the mandate deleting.