The Security Tax Nobody Wrote Down

An engineer waits three days for access to a log store, to answer a question that would have taken four minutes. A change sits in an approval queue over a weekend because the person who signs it is out, and lands on Monday alongside nine others that were also waiting. Somebody re-authenticates for the fourth time before lunch. A quarterly password change goes in with the month appended, which is what everyone does and everyone knows.

Every one of those has a cost. Not a rhetorical cost, an actual one, paid in the hours of people who were hired to build things, and the reason it is rarely written down is not that it is hard to see. It is that saying it out loud sounds like the opening move in an argument for having less security, and nobody in a serious organization wants to be the person making that argument. So the number stays unstated, and an unstated cost cannot be weighed against anything.

I sit between these two groups and I have been wrong from both chairs. I have defended a control I could not justify because removing it felt like accepting risk I would then own personally. I have also waved through an exception, for a good team with a real deadline, that I would not defend now if I had to describe it to somebody investigating an incident. Neither of those was a failure of character. Both were a failure to know what the thing cost.

So here is the sentence the rest of this is built on, and it is not a position on how much security is correct. A control whose cost nobody has measured is a control nobody can defend when the time comes to remove it, and it is also a control nobody can justify keeping. Both halves of that matter, and the second half is the one security people should find encouraging.

The slowest path to production is often the least safe one. A change-approval queue that adds four days does not hold four days of risk still. It batches. Ten small changes that would have gone out separately arrive together, so when something breaks you have ten candidates instead of one, and the rollback takes the nine that were fine with it. The DORA program has argued the batch-size point for years from self-reported survey data, which is weaker evidence than it is usually quoted as, but the mechanism needs no survey: delay is what makes changes bigger.

A control that blocks the safe path relocates the work. The strongest thing on this list. Lock an internal artifact registry down hard enough and people stop pulling the library; they copy the three functions they need into the repository by hand. Nothing is blocked, no rule is broken, and the organization now runs code with no provenance, no version and no path for a patch to reach it. The same shape appears wherever the sanctioned route is expensive enough. The control did not remove the need. It moved it somewhere with no inventory, where the security team's own tooling is blind.

Some requirements outlive the guidance behind them. The clearest case is forced password rotation. NIST SP 800-63B, whose fourth revision was finalized last July, is unambiguous: verifiers shall not require subscribers to change passwords periodically. The previous revision said the same thing in softer language back in 2017. Nine years on, plenty of organizations still enforce a ninety-day cycle, usually because a customer questionnaire asks whether they do, and the result is predictable suffixes, more reuse across systems, and more help desk resets, which is itself one of the better-worn paths into an organization.

The two costs are not equally visible, and never will be. Friction is immediate, concrete, and lands on the person who noticed it. The cost of its absence is zero every single day until it is the whole company at once. That means engineers systematically underweight the second cost and security people overweight the first, and both are responding rationally to the evidence available from where they stand. An engineer who has never sat through an incident response has no felt experience of the second cost, which is a fact about what the job has shown them rather than a deficiency in them.

Sometimes slowing things down is precisely the function. In February 2024 attackers reached a healthcare clearing house through a remote access portal with no multi-factor authentication on it. Per the chief executive's congressional testimony that May, they were inside from the twelfth, moved laterally for nine days, took roughly six terabytes, and detonated ransomware on the twenty-first. The absent control was the one that would have added seconds to a login. A change that cannot be made quickly by an engineer cannot be made quickly by somebody holding that engineer's credentials either.

The evidence engineers ask for cannot exist. "Show me the breach this prevented" is unanswerable by construction, because a successful control produces an absence and absences do not generate tickets. Requiring that evidence before accepting a control demands a proof that can never be supplied, and an argument built on it wins every time regardless of whether it is right. The honest version of the engineer's demand is narrower and fair: show me the attack path, and show me this control sits on it. That question has an answer, checkable by somebody who does not work in security.

The framing is more security against faster delivery, as a dial with two ends, and everyone locates themselves somewhere along it. It is a false axis and it produces bad conversations, because it makes every specific question about a specific control into a referendum on how much somebody cares about risk. Nobody in the argument is actually asking for less security. What they are asking is whether this particular control, in this particular place, is buying anything.

The axis that produces useful conversations is placement rather than quantity. Two organizations can spend identical amounts of engineer time on security and get wildly different results, because one of them spent it on a quarterly password change and the other spent it on knowing what its build system can reach. That difference is not a difference in security posture in any sense that would survive an incident. It is a difference in where the same tax was levied.

And the control that fails does not stop being a control. In July 2024 a content update to an endpoint security agent stopped, on Microsoft's published estimate, roughly 8.5 million Windows machines in an afternoon. That was the security tooling, not the attacker, and it is the strongest available evidence that these things sit in the production blast radius exactly like everything else you ship. Which is an argument for governing them the way you govern the rest of production, not an argument against having them.

Friction is a budget rather than a virtue. There is a finite amount of it an organization can absorb before people start routing around it, and that ceiling is set by human patience rather than by policy. Every control spends some. Once you accept that the budget is finite, spending it on a low-value control is not a neutral act of caution; it is a decision to have less of it available for the control that matters, and the money is gone whether or not anybody chose to spend it.

The second-order effect is worse than the arithmetic. Attention is spent along with time. A team that has learned to click through one meaningless prompt has learned to click through prompts, and the muscle does not distinguish between the meaningless one and the one that would have stopped a real thing. Every low-value control degrades the response to every high-value control, which is why "it does not cost much, leave it on" is a more expensive sentence than it sounds.

Ask what specific attack this stops. Not a category. A path: who, with what access, doing what, and where this control interrupts it. If the answer is a compliance clause, that is a real answer and should be given plainly, because a contractual requirement is defensible and has an owner, and saying so stops the control masquerading as a technical judgment nobody may question. The failure to watch for is the category answer, "it prevents lateral movement", which names a class of attacks rather than describing one.

Ask what it costs, per engineer, per week. An estimate is fine and a rough one is enough, because the point is not precision. It is that the number gets written down next to the control, in the same document, so the two are visible together for the first time. Most of these come out small and a few come out startling, and the startling ones are almost never the controls anyone was arguing about. Ask the people who pay it rather than the people who administer it, because the administrator sees the policy and the engineer sees the wait.

Ask what we would notice if it were gone. The most uncomfortable of the three and the one that does the most work. If the honest answer is that nothing observable would change and no alert would fire, then either the control is inert or you have no way to know whether it works, and both are findings. A control you cannot verify is not protecting you; it is being trusted, which is the thing it was installed to avoid. The good answers are specific and slightly alarming, and a control that produces one has justified itself better than any rating could.

Friction is cheap when it is concentrated on rare, high-consequence actions and ruinous when spread evenly across everything. Time-bound privileged access is the clearest example of the good shape: standing access removed, elevation requested when needed, approved, and expiring by itself. Azure's Entra ID does this through Privileged Identity Management and AWS reaches a similar place with short-lived assumed roles, but the mechanism is not really either vendor's - the cost falls on the few actions with real blast radius rather than on every login.

The other property that makes friction cheap is legibility. A delay somebody understands, with a visible end, costs a fraction of an identical delay that appears arbitrary, because most of what people are actually reacting to is the sense that nobody weighed their time. "This request goes to a human and takes up to a day, here is who, here is why" is a wildly better control than the same wait with no explanation, and it costs nothing extra to provide.

The lifecycle is the part almost nobody builds. A control arrives with a date and a reason and then lives forever, because no process exists whose output is a removal. Give each one an owner and a review date at the moment it goes in, and the annual question becomes ordinary instead of adversarial: is this still on an attack path, does it still cost what we thought, and would we notice if it stopped. A control nobody has revisited in five years is not a decision any more. It is sediment.

I should be honest about how much of this survives contact with a real program, because it is less than I would like. The three questions are gameable: a security team can produce a plausible attack path for almost anything, and an engineering team can inflate a cost estimate at will. In a regulated environment a large class of controls is not removable however it scores, so the test applies to a smaller set than the argument implies, and on the rest the honest move is to say the requirement is external.

What I keep is smaller and I think it holds. The tax is real, it is being levied whether or not anyone writes it down, and refusing to name it does not protect the security program - it is what makes the program indefensible the first time somebody with authority and no patience goes through it line by line. Say what each control costs, next to what it stops. Then the password policy and the build system's credentials are on the same page, and anyone can see which one you have been paying for.