IOCs Are Not Intelligence

This is a div block with a Webflow interaction that will be triggered when the heading is in the view.

Most analysts don’t get into threat intelligence to manage blocklists. Yet the work that drew most analysts to the discipline - tracing campaign infrastructure, mapping adversary behavior, connecting signals across incidents to build a picture of what an attacker is actually doing - takes up a fraction of the job in most programs. The rest is queue management: ingest, normalize, triage, push downstream, repeat. By the time a confirmed Indicator of Compromise (IOC) completes that journey, the window to act on it has usually closed - and the next batch is already waiting.
The gap between what TI analysts signed up for (and are eminently capable of) and what their programs ask them to do starts with semantics. IOCs are data. Processing them is logistics. When programs treat IOC handling as the finished product and call it intelligence – they end up staffing and measuring around the wrong output. A recent survey from SANS bears this out. It found that nearly a third of CTI programs don't even try to measure their effectiveness. Analysts at these shops end up spending their time on throughput – while early signals of attacks get overlooked.
In this blog, we'll examine what separates raw indicator data from actual intelligence, what it costs a program when the indicator becomes the end product, and what changes when TI teams zoom in on output that can actually drives decision making.
What an IOC Actually Is - And Isn't
An IOC is a forensic artifact - a domain that was flagged as malicious, an IP address that was tied to a known adversarial campaign, a file signature that matched a known malicious payload. Past tense, every time. An IOC helps reconstruct what happened, identify the scope of a compromise, and confirm that a threat was present. What it doesn't do, on its own, is tell you anything about what's happening now or what's coming next.
Part of the reason for this is the speed at which attacker infrastructure moves. For example, command-and-control (C2) servers - the infrastructure attackers use to remotely direct malware and manage compromised systems - are among the most common subjects of IOC feeds. Yet according to recent research, the median lifespan of a common type of C2 server is just five days. By the time an IOC tied to one of those servers clears ingestion, deduplication, and triage, the infrastructure it describes has often been deactivated.
So, an IOC is valuable as a starting point - a raw signal that becomes useful when an analyst traces it back, maps what surrounds it, and connects it to a broader picture of attacker behavior. The problem is, in most programs, that analytical work never happens - because the volume in the queue won't allow it.
Analysts are Trapped in Triage
When the indicator becomes the unit of work, the analyst becomes a processing function. The queue refills faster than it drains, and this carries a steep price for talented analysts – which is reflected in other security arenas, too. A survey of 5,000 security professionals across 17 countries found that 76% reported experiencing burnout, with 69% saying it got worse over the prior year. This is part of the reason that the average analyst tenure is shrinking. Some security operations teams are seeing turnover cycles of less than 18 months.
These alarming numbers show a workforce that spends its days on work that doesn't match the job description. The people leaving came to do analytical work - and found that the program had no room for it. This means that security teams focusing solely on IOCs are losing the very analysts who are most capable of deriving meaning from them.
The Wrong Unit of Analysis
The meaningful work those analysts came to do requires a different kind of signal. IOCs confirm that an attacker reached your environment. But they can't tell you what the attacker built to get there, what else they prepared, or what they're planning next.
That’s why Malanta is leading the shift toward adopting Indicators of Pre-Attack (IoPAs) - a different kind of signal entirely. IOPAs reflect actual attacker preparation: domain registrations, certificate issuance, C2 provisioning, scanning behavior that appears on the open internet before any interaction with your environment occurs.
The lag between discovery of an IOPA and an IOC can be dramatic. Analysis of 2025 malware campaigns found that domains later classified as IOCs were flagged as malicious between 150 and 598 days before they were formally identified. This means that the pre-attack signal existed nearly two years before the IOC did.
This is why an IOPA can function as an intelligent. A program oriented around IoPAs asks different questions, produces different outputs, and gives analysts the kind of work that drew them to the discipline in the first place.
The Bottom Line
IOCs aren't the problem. They're the starting point - the raw material every TI program depends on. The problem is programs that mistake processing them for producing intelligence, and analysts who spend their careers doing one when they were hired to do the other.
Threat intelligence analysts have the skills, tools, and data to operate at a higher level. What they need is a different job definition - one where the unit of analysis is the campaign, the infrastructure cluster, the behavioral pattern, and the attacker's current trajectory. This output can answer questions that matter today, not yesterday. Analysis that runs early enough to change what happens next is what separates a threat intelligence program from a very expensive blocklist.








