Imagine hiring a security guard and then asking them to review 4,484 possible incidents before their shift ends. Not real incidents — possible ones. They'd have approximately 6 seconds to assess each one, decide whether it's genuine, escalate if necessary, and move on to the next.
That is, roughly, the situation facing the average SOC analyst today.
Now imagine asking that same security guard to also periodically interrupt every employee in the building with a pop-up reminder about their badge policy. And their clean-desk policy. And their password policy. And a system maintenance notification. And a cookie consent refresh. And an SSL certificate warning on the internal wiki.
At some point — and we passed that point some time ago — the warnings stop being useful. They become noise. And noise is not a security asset. It is a security liability.
Key insightEvery unnecessary warning trains your employees to dismiss warnings. There is no neutral. Every false alarm makes the next real one slightly less likely to be taken seriously.
The numbers behind the problem
These numbers tell a coherent story: we have built security systems that generate far more signal than can be meaningfully processed, and employees have adapted by developing automatic dismissal behaviour. The system is producing the opposite of its intended effect.
This is not a new finding. Google's Security team identified the "crying wolf" problem in browser security warnings as far back as 2009. The research literature on habituation — the process by which repeated stimuli lose their effect — has been clear for decades: the more often a warning appears without consequence, the faster it is dismissed the next time.
We know this. We have known it for years. And we have continued to add more warnings anyway.
How we got here
The growth in security alerting is not irrational. Every new system added to the enterprise estate generates its own alerts. Every new attack technique requires a new detection rule. Every compliance framework mandates another layer of notification. Every vendor promises that their alerts are the ones you actually need.
The result is additive. Nobody decides at a system level to generate 4,484 alerts per analyst per day. It happens one alert category at a time, each one justified in isolation, the cumulative effect invisible until someone actually does the maths.
The same dynamic plays out at the employee layer. Cookie consent banners were added to comply with GDPR. SSL warnings were added to flag insecure connections. Phishing simulation warnings were added to reinforce training. Password expiry notifications were added to enforce rotation policy. Each one was someone's reasonable response to a real problem. The aggregate experience is an environment where warning dismissal is the only rational adaptation.
The habituation trap: Neuroscience is not negotiable. The human brain's response to repeated stimuli that produce no consequence is automatic and unconscious. Employees who dismiss security warnings are not being careless. They are being adaptive — making a rapid, learned assessment that this warning, like the previous hundred, does not require action. You cannot train people out of this. You can only change the warnings.
What warning fatigue looks like in practice
A normal Tuesday for someone in your finance team
8:47am: "Your password expires in 14 days." Dismissed. 9:12am: Cookie consent banner on the supplier portal. Clicked "Accept All." 10:23am: Browser warning — the internal expenses tool has a certificate that expires next week. Clicked "Proceed anyway." 11:05am: Phishing simulation email lands. Clicked the link — it was a test. Completed the mandatory 3-minute training video that results from failing. 2:18pm: "Your session will expire in 5 minutes." Clicked "Stay signed in." 3:44pm: "This website's security certificate cannot be verified." Dismissed. 4:52pm: A real phishing email arrives from someone impersonating their CFO. They read it quickly. It looks urgent. They've just dismissed six security prompts today. They click.
The attack succeeded. Nobody in this story did anything unreasonable.
The most dangerous thing about warning fatigue is that it is invisible until an incident makes it visible. The dismissal behaviour is so automatic, so practised, that employees often cannot report it accurately in post-incident reviews. They don't remember dismissing a warning. They were not thinking about dismissing it. It happened the same way blinking happens.
The difference between volume and value
There is a simple distinction that most security alert architectures ignore: the difference between warnings that exist and warnings that work.
A warning exists when it is generated and displayed. A warning works when it changes what someone does. These are not the same thing, and optimising for the first without measuring the second is how you end up with 4,484 alerts per day and declining outcomes.
| Warning type | Typical result | Why |
|---|---|---|
| Generic "this site might be unsafe" | ~96% click-through rate | No specificity, no consequence history, applies to too many safe sites |
| Password expiry notification | Dismissed until the last day | Deferred-cost decision — the pain of acting now outweighs the vague future consequence |
| Phishing simulation result pop-up | Completed and forgotten within 48 hours | Retrospective — the teachable moment was the click, not the debrief 10 seconds later |
| Contextual, specific, in-the-moment warning | Meaningful behaviour change | Specific, relevant, arrives at the exact moment of risk, explains the consequence |
The pattern is consistent across the research: specificity and timing are the two variables that determine whether a warning actually works. A warning that is specific to the action being taken, delivered at the moment the action is about to happen, and framed in terms of the actual consequence — that warning changes behaviour. A warning that is generic, delayed, and consequence-free does not.
Key insightThe question is not "did we show a warning?" The question is "did the warning change what the person did?" These are different measurements, and only the second one tells you anything useful about security outcomes.
Three principles for warnings that actually work
Specificity over generality
"This tool is not approved for use with customer data, because customer data is subject to your GDPR obligations and this tool's data processing terms have not been reviewed" is a warning that can be understood and acted on. "This site may be unsafe" cannot. The more specific the warning, the less it blends into the background noise of undifferentiated alerts.
Timing is everything
A warning delivered before the risk exists is a reminder. A warning delivered after the action is a debrief. A warning delivered at the exact moment the action is about to occur is an intervention. Only the intervention can change the outcome. Annual training modules, quarterly phishing simulations, and post-incident retrospectives are all valuable inputs to a security culture — but they cannot substitute for intelligence that operates at the moment of risk.
Volume control is a security measure
Reducing the number of warnings an employee sees is not a compromise of security posture — it is an improvement to it. A warning that appears rarely carries more weight than one that appears constantly. Security teams that ruthlessly audit their alert inventory, eliminate false positives, and merge overlapping notification streams are not cutting corners. They are protecting the signal value of the warnings that remain.
The CISO's alert fatigue calculus
Security leaders are in an uncomfortable position when it comes to alert volume. The pressure runs almost entirely in one direction: add more detection, add more alerting, add more coverage. If an incident occurs and a warning could have been generated, the question asked in the post-mortem is always "why didn't we have a warning for that?" The question "did our existing warnings actually change behaviour?" is asked far less often.
This creates an institutional incentive to add alerts and a weak incentive to remove them. The result, compounded over years, is the environment we are in: one where both SOC analysts and end users are so habituated to security noise that neither is meaningfully responding to it.
The CISO who wants to actually improve security outcomes needs to be willing to measure warning efficacy, not just warning volume. That means tracking click-through rates on security warnings, measuring how often employees actually read and act on alerts versus dismiss them, and treating a low habituation score as a security metric worth optimising — not just a training failure to remediate.
The boldest security move many organisations could make in 2026 is not adding a new detection layer. It is auditing their existing warning infrastructure, identifying everything that employees have learned to dismiss, and eliminating it — replacing volume with precision.
What the research says about what works
The evidence on effective security communications is robust and largely consistent. Warnings work when they are relevant to the specific action the person is taking, appear at the precise moment the action is occurring, explain the real consequence of proceeding (not a generic "this may be unsafe"), offer a clear and easy alternative to the risky action, and are infrequent enough that they have not been habituated.
The warning that checks all five of these boxes is, in most enterprise security stacks, essentially absent. The warning that checks none of them — the generic, always-on, consequence-free alert — is ubiquitous.
This is not a technology problem. The technology to deliver precise, contextual, moment-of-risk warnings exists. It is an architectural and prioritisation problem: most security investment has gone into generating more signal, not into ensuring that signal actually reaches people in a form they can act on.
How Mungo Labs approaches the warning problem
The entire premise of Mungo Labs is that the moment of risk is where security has to operate — not in the training room, not in the post-incident review, and not in the quarterly compliance report. The warning that arrives at the exact moment an employee is about to take a risky action, specific to what they are doing, in plain language they can understand, is the warning that changes behaviour.
Our work with early design partners is built around this principle: not more warnings, but better ones. Warnings that arrive once, matter when they do, and create a genuine moment of pause at the point where a decision is still being made. That's what "intelligence at the moment of risk" means in practice — and it is the architectural shift we think the industry needs to make.
If this is a conversation you are having inside your organisation, we'd like to be part of it.
Are your warnings working — or just appearing? There is a difference between a security system that generates alerts and one that actually changes behaviour.
Schedule a Discovery Call →