The static risk fallacy

I came to security from law school, where risk is framed as liability. Liability, at least as I was taught it, is always about totality. It’s about the portfolio, not the one-off. No one I worked with in my internships or in school ever said, “let’s approve each individual legal risk and not worry about the whole.” You always consider the overall facts.

In security, I keep seeing the reverse. We argue each instance on its own, as if repetition doesn’t change exposure.

I’ve heard this pattern described as “blessed risks,” risks that get sanctified through repetition after a single approval. I call the broader concept the static risk fallacy.

What the fallacy looks like

The pattern goes like this:

1. One high-impact risk is judged tolerable or necessary.
2. Someone argues that because of (1), more of the same risk doesn’t meaningfully increase exposure.

The flaw is simple: risks accumulate. A system can tolerate one point of failure, but not ten.
Yet the fallacy is common because it feels intuitive. If we did a thing once and it was “security approved,” what’s the harm in doing it again?

Two layers of accumulation

The fallacy operates at two layers.

• Inside the organization. A large number of privileged accounts, repeated vendor integrations, a backlog of unpatched systems. Each may be justified on its own, but together they multiply exposure.
• Across the ecosystem. When thousands of companies accept the same risk, such as relying on xz, a library with a single maintainer, one compromise can become everyone’s incident.¹

Both layers matter, but you have a lot more control over the first one. Your internal portfolio of exceptions creates local fragility. Shared dependencies create systemic fragility.

Where it shows up

The fallacy appears across security domains. Each case follows the same pattern: accept one instance of risk, then assume repetition doesn’t meaningfully change exposure.

Why it feels persuasive

The static risk fallacy is seductive because of how humans reason about thresholds. If we’ve already justified one risky choice, it feels consistent, almost fair, to justify the next. Psychologists call this creeping normality. Gradual shifts don’t feel like changes until you step back and see the total.⁸

But in security, the total is what matters. Ten admin accounts aren’t the same as one admin account. Each one is another path to failure. Let’s look at this in more detail.

The visualization below demonstrates this mathematically. Each bubble represents a privileged account with a 1% annual compromise probability. Slide the controls to see how risk accumulates as you add more accounts. Red bubbles show compromised accounts in a single Monte Carlo simulation, a method that uses random sampling to model probability outcomes.

How frameworks (half) address it

To their credit, the major frameworks do nod to accumulation.

• NIST SP 800-30 explicitly notes that organizations may use risk aggregation to combine several lower-level risks into higher-level risks, helping manage assessments across multiple information systems or business processes.⁹
• NIST SP 800-39 explicitly requires organizations to establish forums to consider all types and sources of risk, including aggregated risk, assigning this responsibility to the Risk Executive Function.¹⁰
• ISO/IEC 27005:2018 → 2022 encourages reviewing risks in aggregate, and the update explicitly adds cascading and cumulative effects.¹¹

But in practice, these are hints, not requirements. None of them force the moment where someone must say, “Stop. The total is now unacceptable.” Risk registers stay siloed, and risks are often evaluated based on what they would do individually.

How this differs from normalization of deviance

The term normalization of deviance comes from Diane Vaughan’s study of the 1986 Challenger disaster.¹² Engineers saw problems with the shuttle’s O-rings but, because launches kept succeeding, those warning signs became routine. Risk was normalized because it hadn’t yet caused catastrophe.

While fascinating and certainly applicable, it’s distinct from the static risk fallacy. Normalization of deviance keeps you from considering the reality of a single risky behavior. The static risk fallacy keeps you from recognizing the math of repetition, where one acceptable risk may become unacceptable simply because it was done over and over.

• Normalization of deviance: “This hasn’t failed yet, so it must be fine.”
• Static risk fallacy: “If one is fine, then ten must be fine.”

How to push back

• Shift the frame. “We’re not approving one more admin. We’re deciding if we want ten people with prod-wide keys.”
• Name the blast radius. “Adding this vendor means our outage surface now includes their outage plus the last three we onboarded.”
• Cap repetition. “Approve this if we can retire two others.”
• Make accumulation visible. Add a line to your governance: “Risk Approval Threshold. Before approving additional instances of an existing risk type, calculate the new aggregate probability and confirm it remains within organizational risk tolerance.”

Breaking the pattern

The static risk fallacy isn’t just about math. It’s about how we make decisions under uncertainty. Each “yes” feels independent and disconnected, but real exposure steadily increases.

The defense is twofold: assume breach and justify repetition.

Assume breach. If john.admin will eventually be compromised, how do we limit the blast radius? Zero-trust architecture, just-in-time access, privileged access management, and segmentation all reduce the impact when — not if — individual risks materialize.

Justify repetition. Before adding the tenth admin account, ask: Is this worth multiplying our aggregate exposure? Can we achieve the same outcome through existing accounts, temporary elevation, or automated processes? In each instance, consider the whole.

The static risk fallacy may seem a little basic. Viewed in abstract, it seems like common sense. But, at real organizations, being able to effectively communicate about it and counter it will help you keep your organization’s security posture strong.