Most advice on how to reduce security alert fatigue assumes the noise starts inside your own estate. Tune the detections, write better correlation rules, buy automation, hire another analyst. All reasonable, and all aimed at the SIEM. Meanwhile a growing share of the alerts hitting a UK security team never passed through a detection rule at all: they arrive from credential feeds, Telegram channels, lookalike domain monitoring, supplier notifications and external scanners pointed at public-facing assets nobody in the building remembers deploying.
Those alerts cannot be tuned away with a SIEM rule, because they were never generated by one. They need different treatment: attribution, deduplication and classification at the point of ingestion, before anything reaches a queue. Six sources account for most of that volume. Each has a specific fix, and each fix carries a cost worth naming out loud.
Why Tuning Detections Alone Will Not Reduce Security Alert Fatigue
Alert fatigue in cyber security is usually described as a volume problem. It is closer to a trust problem. Once a team learns that most of what lands in the queue describes something already known, already fixed, or belonging to someone else entirely, triage quality drops across everything, including the one alert that mattered.
The cost shows up in specific behaviours. Bulk closures at the end of a shift. Median time to first touch creeping from minutes into days. In teams of five or fewer, which is most in-house security functions in the UK mid-market, it also shows up as attrition, because nobody stays long in a job that consists of closing tickets that were never real.
Before changing anything, baseline honestly. Four numbers are enough:
- Alerts received per analyst per day, counting external feeds alongside internal detections.
- Percentage closed as "no action"or "duplicate".
- Median time to first touch, measured separately for internal and external sources.
- How many open alerts describe the same underlying asset or the same underlying weakness.
That last one is usually the shock. Then apply a single test to every fix that follows: does it remove the alert, merge it, or merely move it to a different inbox? Routing noise to a Teams channel is not reduction. It is relocation.
Noise Source 1: Duplicate Findings Across Overlapping Scanners
Run infrastructure scanning and web application scanning against the same public host, which is exactly what dual scanning is meant to do, and the same underlying weakness surfaces twice. Different name, different severity, different remediation text. An outdated TLS configuration appears as a network finding and again as an application finding. An unpatched web framework appears as a CVE on the host and as a version disclosure in the application layer.
Consider a mid-sized retailer with twelve public-facing hosts. The raw finding count across both scan types looks alarming in a board slide. Collapse it by asset and weakness class and it becomes a handful of distinct fixes, most of them traced back to the same outdated component deployed across several hosts by the same build process.
Deduplication logic that holds up matches on asset plus service plus CVE or weakness class. Never on the alert title. Title matching merges two genuinely different issues that happen to share vendor wording, and it fails to merge the same issue described by two tools. Auto-resolution matters just as much: a finding that has genuinely been remediated should close and stay closed, rather than reappearing as new on the next scan cycle and consuming triage a second time.
The trade-off is real. Aggressive deduplication can hide a second instance of the same flaw on a different port or a different virtual host. Keep the merged record expandable, so an engineer can see all underlying instances before signing the fix off.
Noise Source 2: Recycled Credential Dumps and Stealer Log Repetition
Credential exposure noise is mostly repetition, not new exposure. The same set of leaked credentials is repackaged, renamed, bundled with other dumps and re-sold across forums and channels for years. Every repost looks like a fresh discovery to a feed that lacks memory, which is why teams that monitor Telegram for leaked data without a deduplication layer end up reviewing the same 2016 breach four times in a quarter.
Three triage questions cut the volume quickly:
- Is the password still valid against any corporate identity provider, or has it been rotated since the breach date?
- Is the account internal (a domain identity with access) or external (a customer or partner account)?
- Is this a corporate credential, or a personal signup made with a work email address on a third-party site?
The distinction that actually changes the response is stealer logs versus old breach dumps. A stealer log means an endpoint was infected, which implies live session cookies, browser-stored secrets and possibly MFA bypass through token theft. That is an incident and should be handled as one, following a structured stealer log triage process with session invalidation as well as password resets. A recycled dump from a long-dead forum usually deserves a check that your password policy and credential stuffing protections are doing their job, and nothing more.
Keeping a dated, hashed record of every credential set you have already actioned is what stops the second, third and fourth appearance of the same dump reaching a human. It also gives you an audit trail when someone asks why a given exposure was closed without escalation.
Noise Source 3: Domain and Lookalike Alerts Without Ownership Logic
Raw DNS and typosquat feeds are, in our experience, the single largest producer of unactionable external attack surface alerts. They fire on registration alone, and most registered variants are parked forever: squatters holding inventory, defensive registrations made by your own marketing team, and brand-adjacent names that will never be pointed at anything.
A triage ladder based on observable state keeps the queue small:
- Registered but parked. Log it. No action.
- Registered with MX records. Mail is possible, so the domain can be used for impersonation of staff or suppliers. Watch it.
- Registered with a live login page. Credential harvesting is now plausible. Investigate.
- Actively serving your branding, logo or content. Collect evidence and move to takedown.
A finance firm might see forty newly registered lookalike variants in a quarter. Two acquire MX records. One eventually serves a cloned login page. That one justifies screenshots, WHOIS and hosting evidence, and a registrar abuse request. The other thirty-nine justify a line in a monthly report. Escalating on registration alone inverts that ratio and burns a week of analyst time on parked pages, which is why a signal-based approach to domain spoofing detection beats a volume-based one.
Maintain your own suppression list of legitimate domains: your defensive registrations, your partners, your agencies, your regional variants. Review it whenever the estate changes, because today's suppressed domain is tomorrow's expired registration bought by someone else.
Noise Source 4: Asset Churn, Shadow IT and Alerts on Things You Do Not Own
Cloud instances spun up for a test and never destroyed. Marketing microsites built by an agency on their own hosting. Subdomains pointed at a SaaS tool that was cancelled last year. Each of these produces findings that reach a security team with no administrative access and no budget to fix them, which is the most demoralising alert there is.
Attribution comes before alerting. Map the external footprint first (domains, subdomains, IP ranges, cloud services, exposed APIs, certificates), then assign a named owner to every asset. Anything without an owner is itself the finding, and it is a better finding than whatever the scanner reported on it.
Then alert on change, not on state. A system that reports the full condition of the estate every cycle is unusable at scale. A weekly view of what is new or different since last week stays small enough to read: a new subdomain, a certificate that changed, a port that opened, a service that moved. The full inventory refresh belongs in a report, not in a queue. Attack surface drift is continuous, so change detection is the only form of monitoring that stays proportionate to the team reading it.
Grouping by owner does the rest. Forty findings across eleven agency-managed microsites is not forty tickets. It is three conversations and one piece of scheduled work, with a named owner for each.
Noise Source 5: Supplier and Third-Party Feeds That Alert on Everything
Generic vendor CVE feeds are the easiest noise to buy and the hardest to act on. They alert on every published vulnerability in every product a supplier is known to use, with no knowledge of which version that supplier runs, whether the affected component is internet-facing, or whether the supplier holds anything of yours at all.
Tier suppliers by what they hold and what they connect to, then set thresholds per tier instead of one global setting. A tier one supplier processing personal data with a live integration into your environment warrants a low threshold and prompt notification. A tier three stationery supplier with no data and no connectivity generates a quarterly review entry, not a ticket.
Use accreditation as context rather than as a pass. Cyber Essentials certification from the NCSC scheme and ISO/IEC 27001 certification tell you a supplier has met a defined set of controls at a point in time. Neither tells you their public-facing estate is clean today. What genuinely matters is the lapse: an expired certificate against a tier one supplier is worth more attention than most CVE notifications, because it suggests something changed internally.
And be honest about ownership. If an alert concerns a system you cannot patch, it is a question for the supplier, not a ticket for your team. Route it as a question, track the answer, and keep it out of the operational queue.
Noise Source 6: VIP and People Monitoring That Matches the Wrong Person
Executive monitoring produces fatigue out of all proportion to its volume, because it consumes the most expensive attention in the business. A match on "J Patel"that turns out to be a footballer, a decade-old personal forum signup, a namesake who registered on a dating site in 2011: each one looks confident, each one requires someone senior to read it, and each one erodes trust in the whole programme.
Guarded profiles fix most of this. Build each protected person from known identifiers (corporate and personal email addresses, known usernames, phone numbers, domains they are associated with) so matches are made against identifiers rather than against a name string. Classify every matched identity as internal or external. A corporate identity in a stealer log is operational security. A personal account exposed in a consumer breach is a personal risk conversation, and often a different owner entirely.
Score risk per person as well. A chief executive's exposed home address and a graduate's old forum signup should not share a queue, a severity scale or an escalation path. Report executive exposure separately to the board on its own cadence, as covered in more depth in our guide to executive protection cyber monitoring, rather than mixing it into the daily operational stream where it will either be ignored or over-escalated.
Turning the Survivors Into Projects, Reports and Routines
Whatever survives deduplication and attribution still needs to arrive in a form someone can act on. One ticket per finding guarantees a backlog nobody schedules. Group related findings into a single piece of remediation work with one owner and one deadline: "upgrade the shared web framework across the seven hosts running version X"is work. Seven CVE tickets are not.
Route by audience, not by severity alone:
- Technical findings into Jira or your ticketing queue through the API, already grouped and attributed.
- Change summaries into a Slack or Microsoft Teams channel, weekly, covering what is new or different.
- Correlation data into the SIEM, where external exposure can be matched against internal detections.
- A short management report to leadership monthly, with trend rather than ticket counts.
Then the part most guides skip. Every suppression rule is a deliberate blind spot, accepted on purpose. That is a legitimate decision, and often the right one. What makes it dangerous is applying it anonymously. Eighteen months later, nobody can explain why an entire asset class stopped reporting, and no one notices that the agency domain you suppressed has changed hands. Treat the suppression list as a risk register entry: who approved it, when, on what rationale, and when it expires. Review on a fixed cadence, quarterly at minimum.
AI decision support helps genuinely in three places: classification, deduplication and translating a raw finding into plain English that an engineer or a director can act on. The useful question has never been whether a finding exists, but what it is, how it was discovered, and whether it actually exposes you. That is the gap Nyx, our AI security consultant, is built to close. What it does not replace is a human researcher reading a closed forum, judging whether a broker's claim is credible, or weighing a takedown decision against a legal position. Automate the repetition, keep the judgement human.
A realistic first month: baseline the four numbers, fix scanner deduplication, attribute every external asset to an owner, then tackle VIP and supplier noise once the volume is low enough to see clearly. Teams that work in that order reduce security alert fatigue to the point where the queue becomes readable again, and they do it without losing visibility of what attackers can see. If you want to understand what your external attack surface currently generates before you decide what to suppress, see how DarkInvader maps and monitors it.
Frequently Asked Questions
What causes security alert fatigue in small in-house teams?
Volume is only part of it. In teams of one to five, fatigue is driven by the proportion of alerts that are duplicates, recycled credential dumps, parked lookalike domains or findings on assets the team cannot fix. Repeated exposure to alerts with no possible action trains analysts to close in bulk, which is when genuine findings get missed.
How do you reduce security alert fatigue without missing a real incident?
Reduce at the point of ingestion rather than at the point of triage. Deduplicate on asset plus weakness class, attribute every asset to an owner, alert on change rather than full estate state, and classify exposures by type before they reach a queue. Nothing is deleted, it is merged, grouped or reported, which keeps the underlying evidence available.
Is deduplication safe, or does it hide genuine findings?
It is safe when the merge key is specific and the merged record stays expandable. Matching on alert title is unsafe, because it merges distinct issues with similar wording and misses identical issues described differently by two scanners. Always let an engineer open the merged record and see every underlying instance before closing the work.
How many alerts per analyst per day is realistic?
There is no published industry benchmark that applies across different team sizes and tool stacks, so treat any fixed number with scepticism. A more useful measure is the no-action closure rate: if most of what an analyst touches results in no action, the pipeline needs deduplication and attribution, whatever the daily count happens to be.
Should leaked credential alerts be treated as incidents?
Only some of them. Credentials appearing in a stealer log indicate an infected device, with the likelihood of stolen session tokens and browser-stored secrets, and that warrants incident response including session invalidation. A recycled breach dump from an old third-party site generally warrants validation against your identity provider and a password policy check instead.
