There's a phrase I keep hearing in cyber circles lately, at in-person conferences, on LinkedIn, pretty much everywhere:
"SIEM is dead."
I get why it's catchy. But SIEM has died more times than a soap opera villain, and it keeps showing up for next season. Before SIEM, it was the perimeter that was dead. Then antivirus. Then passwords. (Passkeys are coming for them, but plenty are still living on sticky notes under keyboards.)
Here's where I land: the way a lot of companies have been buying and feeding their SIEM deserves to go away. SIEM itself doesn't. So before anyone orders flowers, let's look at what's actually changing.
Follow the money (and the marketing)
There's so much cybersecurity marketing out there that it's hard to tell which tools and controls matter against today's threats. Every booth on the expo floor has "AI" printed on it somewhere. Some of it is impressive. Some of it is a chatbot wearing a trench coat.
"X is dead" is about the oldest trick in the marketing book. If the old category is dead, you'd better buy the new one. It makes for a great keynote slide. It also skips the question I'd want answered first: what was the old thing doing for us, and do we still need that done?
For SIEM, the job was visibility across the environment, catching attackers, running investigations, and keeping records for compliance. Attackers are still here. So are auditors. The open question is whether there's a smarter way to do it.
The "send it all" era
For years, the big legacy players (think Splunk and QRadar) priced on how much data you ingested and how much you stored. That model let them charge what they charged.
And the advice that came with it was always the same: send everything. Firewall logs, DNS queries, DHCP renewals, every time a printer had feelings. Get it all in, and figure out what's useful later.
Later almost never came. What came instead was a giant bill, a pile of alerts nobody had time for, and a very expensive junk drawer.
If your vendor makes more money every time you send another log, of course they'll tell you to send more.
The market has caught on. Cisco bought Splunk, and IBM sold its QRadar SaaS business to Palo Alto Networks. When the biggest names in a category start changing hands, something is shifting.
Enter the AI-native challengers
That market shake-up opened the door for a wave of AI-native SIEMs and security data lakes. The newest pitch I keep hearing goes something like:
"Why store everything yourself? Leave the logs where they are. Our AI will call your sources' APIs, pull what it needs on demand, and only keep the signals that matter."
I'll be fair. That sounds great, and some of the thinking behind it is smart. Nobody enjoys paying to store terabytes of noise, and using AI to pick out signal is a useful idea.
The problem is the bill.
You swapped a storage bill for a token bill
When AI is querying everything on demand, you're still paying. You've just moved the cost from storage to compute, specifically the tokens it takes to pull, parse, and reason over that data each time. During an active incident, when you're firing off question after question, that meter moves fast. It's like cutting the cable bill and then signing up for nine streaming services.
Also, tokens right now are about as cheap and subsidized as they'll ever be. AI providers are pricing to win market share, and that won't last.
We've been here before: Moving everything to the cloud was going to save us all a fortune, remember? For plenty of companies it did, right up until the egress fees and surprise invoices showed up and someone had to go hire a FinOps team. Prices settled at their real level. I expect AI inference to follow a similar path.
Cost isn't the only catch, either:
Retention: If the source system only keeps 30 days of logs, then so do you, which hurts when you find out about a breach on day 45.
Availability: Your investigations depend on someone else's API being up and free of rate limits, usually at the exact moment you need answers.
Compliance: Telling an auditor or your cyber insurance carrier "we can go fetch it if we need it" makes for a tough conversation.
A better approach: store what matters, keep what you're required to keep
In my opinion, the best way to get real security value out of logs sits somewhere between hoarding everything and storing nothing. Only store the logs that matter.
That's how we approach it at Huntress. Our smart filtering removes logs that aren't security relevant before they ever hit storage, so you're paying for signal and not chatter. The logs that drive detections and investigations stick around.
Filtering doesn't mean ignoring compliance. If HIPAA, PCI DSS, CMMC, or your cyber insurance policy says you need certain records for a certain amount of time, keep them. Those logs might not catch an attacker in real time, but after an incident they're how you show you did things right.
When I talk with teams about this, I usually suggest running every log source through a simple filter:
Detect: Does this help us spot or investigate a threat? Keep it.
Prove: Does a regulation, auditor, or insurer require it? Keep it.
Drop: Neither? Drop it. Nobody's going to miss the printer logs.
The bill shrinks, sure. The bigger win is fewer false positives, faster investigations, and analysts who spend their day hunting threats rather than scrolling past junk.
So where does AI belong?
AI isn't the bad guy here. It absolutely has a place in a modern SIEM. What I care about is whether it's running on every log, all the time, with the meter spinning, or whether someone decided where it actually helps.
Once you've filtered down to security-relevant data, AI gets a lot more useful and a lot cheaper, because it has far less to dig through.
Correlation is where I think it shines most. A VPN login from a country the user has never been to is interesting on its own. Now add an encoded PowerShell command running on a server that same account touched ten minutes later, and then a new inbox rule in their Microsoft 365 account forwarding mail to an outside address. Separately those are three data points. Together they're an incident. Pulling EDR and ITDR telemetry together with the logs coming in from across the rest of IT, and lining it all up into one timeline, is a great job for AI.
It also helps with the grunt work of an investigation, like summarizing what a user did in the last 24 hours instead of handing an analyst 4,000 raw log lines. It can add context during triage, such as whether an IP has a bad reputation or whether this process normally runs on this host. And it can write up findings in plain English for the people who don't speak fluent ES|QL, which is most of leadership and every auditor I've met.
In every one of those cases, AI shows up after the filtering, at a specific point where it helps someone make a better call. Detections and real SOC analysts still decide whether something is malicious. That control is what keeps things predictable. You know where AI is being used, so you have a decent idea what it'll cost, and it isn't dreaming up alerts out of nowhere, which keeps false positives down.
Who owns what? The shared responsibility nobody puts on the sales slide
SIEM is one piece of the bigger SecOps picture, alongside EDR, identity threat detection, security awareness training, backups, and an incident response plan you've hopefully tested at least once. So when you're figuring out what to run in house and what to hand to a partner, keep in mind that even with a managed SIEM, some of the work stays with you.
Cloud providers figured this out years ago. AWS will lock down the data center, but if you leave an S3 bucket open to the internet, that one's on you. Managed SIEM works the same way.
What your partner should handle
Some activity looks malicious in pretty much any network. Credential stuffing. A user getting hammered with MFA prompts until they finally tap "approve." Shadow copies getting wiped. Someone dumping credentials out of memory with Mimikatz.
This is where you should be able to fully lean on a partner like Huntress. Our SOC sees attacker tradecraft across hundreds of thousands of environments, so when a new technique or IOC pops up in one place, we go looking for it everywhere else. One internal team can't get that view on its own. Detection engineering, tuning, 24/7 triage, and active remediation (isolating hosts, killing sessions, locking accounts, cleaning up persistence) are all things we own, across endpoint, identity, and SIEM. We don't just hand you a pile of alerts.
What only you can catch
Then there's the stuff that could be totally fine or a huge red flag, and the only way to know is whether your team expected it.
A remote access tool you didn't approve. ScreenConnect showing up on a workstation could be your help desk. It could also be an attacker, or a "helpful" vendor, setting up shop. Only you know which RMM tools are sanctioned in your environment.
A new admin account. Was that new domain admin part of a change ticket, or did it just appear on a Friday afternoon?
An off-hours login to a critical system. For one company that's the overnight batch job. For another it's the first sign someone has the keys to the ERP.
A service account wandering off its usual path. Service accounts are supposed to run in the background, not log into the VPN from a laptop. If one shows up in your VPN logs, someone may be using its credentials as a side door.
Firewall rule or group policy changes outside a maintenance window. If nobody on your team made the change, someone else did.
Your approved software list, your change calendar, and your maintenance windows live with your team. We can tell you a service account just logged into the VPN. Only you can say whether Jim from IT set that up as a "temporary" workaround three years ago.
That's where your own saved queries and custom detections come in. You know what "weird for us" looks like, so you write the logic, and you decide what to do when it fires. The SIEM gives you the data in one place to do it.
Response is a team sport, too
A partner like Huntress can stop the bleeding and clean up after it. But some calls only you can make. Do you take the production line offline? Notify customers? Loop in legal, the insurer, or HR? Which servers can be isolated on a Tuesday afternoon, and which ones need a phone call first?
Get your own leadership, IT, legal, and HR on the same page before an incident. Decide who owns which calls, who gets the phone call, and which actions are pre-approved. With Huntress, you choose where and how we respond in your environment, so those decisions carry straight through to how we act. Revisit them after every incident. Trust me, you don't want to be figuring out who's allowed to disable the CEO's account at 2 a.m.
The partnerships I've seen work best aren't "set it and forget it." It's more like "set it, tell us what matters, and we'll both sleep better."
So, is SIEM dead?
Nope. If there's one thing I'd want you to take away, it's to be intentional.
Be intentional about what you store. Keep the logs that help you detect and the ones that help you prove, and drop the rest. Be intentional about where you use AI. Point it at the spots where it sharpens the picture, like tying endpoint, identity, and log data together, instead of running it everywhere because you can. And be intentional about who's watching for what. Lean on a partner for the threats that look bad anywhere, and build your own detections for the things only your team would know are off.
The question I'd ask isn't whether SIEM is dead. It's whether yours is earning its keep.
Want to see what a SIEM looks like when it only keeps what matters? See Huntress Managed SIEM in action.
