An IOC is not a fact. It is a perishable claim. Treat indicators like radioactive isotopes with a half-life and your blocklists, hunts, and reports get a lot more honest.
Indicators of compromise have a shelf life. A hash for a payload sample is useful for weeks. An IP address used as a command and control node may be useful for hours. A domain registered for a phishing campaign may be useful for days, until the actor rotates. A YARA rule for a tool family can be useful for years.
Most threat intel teams treat all of these the same. They land in a feed, they get pushed to the SIEM and the proxy, and they sit there until someone notices the blocklist is twelve thousand entries long and the SOC is drowning. The fix is not better feeds. The fix is admitting that an IOC is a perishable claim and managing it like one.
Why decay matters in practice
When a stale IOC stays in a blocklist it does three kinds of damage.
It produces false positives. The IP that hosted a malicious payload six months ago is now hosting a marketing site for a small business. Blocking it generates a ticket. The ticket goes to the SOC. The SOC reviews, removes the block, and apologizes to the business unit. Repeat across a few hundred stale entries and you have spent a meaningful percentage of your SOC capacity removing your own old work.
It produces a false sense of coverage. Leadership sees a dashboard that says the program is blocking nine hundred thousand indicators. No one is asking how many of those would actually match current adversary infrastructure. The number flatters everyone and protects no one.
It hides real signal. When the average alert is a stale IOC firing on a benign host, analysts learn to dismiss the source. The next true positive from the same feed gets the same reflexive close out.
A simple confidence and decay model
You do not need a research grade model. You need a model the SOC will respect and the engineer can implement.
Start with three fields on every indicator. Confidence at ingest, a half life in hours, and a floor below which the indicator is retired.
Confidence at ingest is a number between zero and one hundred. It captures how strongly you believe the indicator is malicious right now. A hash extracted from an active incident on your network is high. A domain pulled from a public OSINT post with no analysis is low. Pick three or four anchor examples and write them down so every analyst rounds the same way.
Half life is the time in hours after which the confidence drops by half. The half life is set by the indicator type and the source. A C2 IP from a fast flux network might have a six hour half life. A payload hash might have a one thousand hour half life. A YARA rule for a long lived tool family might have no decay at all.
Floor is the confidence below which the indicator is dropped from active blocking and demoted to hunt only. A reasonable starting floor is ten.
The current confidence at any moment is calculated as the initial confidence multiplied by one half raised to the power of elapsed hours divided by the half life. It is one line of arithmetic. It runs in a nightly job. Anything below the floor moves out of the blocklist.
Suggested defaults to start from
Treat these as starting points to argue with, not as truth.
Hashes for fully analyzed payload samples. Initial confidence ninety. Half life two thousand hours, roughly twelve weeks. Floor ten.
Hashes from unverified open source posts. Initial confidence forty. Half life seven hundred and twenty hours, roughly thirty days. Floor ten.
Domains used in active phishing campaigns. Initial confidence eighty. Half life seventy two hours, roughly three days. Floor ten.
IPs used as C2 nodes. Initial confidence seventy. Half life twenty four hours. Floor ten.
IPs used as scanning or proxy infrastructure. Initial confidence thirty. Half life six hours. Floor ten.
URLs for credential phishing kits. Initial confidence seventy. Half life forty eight hours. Floor ten.
Behavioral signatures, YARA rules, Sigma rules. No decay. They describe behavior, not infrastructure. They are retired on review, not on a clock.
The point of writing these down is that the team now argues about specific numbers instead of waving hands.
Two queues, not one
Once decay is in place, indicators flow through two queues with two different consumers.
The active blocking queue contains indicators above the floor with current confidence high enough to enforce. These go to perimeter blocks, EDR blocks, mail quarantine, and proxy categories. The bar for entry is high. The cost of a false positive is real.
The hunt queue contains indicators below the floor or with confidence too low to justify a block. These do not enforce. They feed hunts, lookups, and enrichment. When a host beacons to a low confidence IP, the SOC sees the context but no alert pages anyone. If a hunt confirms the indicator is live, the analyst can boost it back into the active queue with fresh confidence and a fresh clock.
This split is the single most useful change a team can make. It captures every indicator the team has worked on without paying SOC time for every old one.
Sources of fresh evidence to reset the clock
Decay is not a one way street. When new evidence arrives, the clock resets. Useful triggers include the following.
The indicator hits in your own telemetry. A live hit on the network is the strongest possible evidence that the indicator is current.
The indicator appears in a fresh report from a trusted partner with a recent observation date. The recency of the observation matters more than the source's prestige.
The indicator is referenced in a new sandbox detonation of a recent sample. If a fresh payload still beacons to the same node, the node is still live.
The indicator is reported as taken down by a sinkhole or law enforcement action. In this case the confidence does not refresh upward. The indicator is moved to a historical bucket for context only.
Each trigger has a defined effect on the confidence and the clock. Write them into a short table. Do not let analysts adjust on feel.
Operational hygiene
A decay model needs three pieces of plumbing to be real.
A nightly job that walks the indicator set, recomputes current confidence, and moves items between active and hunt queues. The job emits a small report. New indicators added. Indicators promoted. Indicators demoted. Indicators retired. The report goes to a channel the team actually reads.
A source attribution field on every indicator. When the team needs to debate whether a feed is producing more value than noise, the answer is in the data. Sources whose indicators consistently get demoted within their half life are tuned down or dropped.
A review cadence for behavioral signatures. YARA and Sigma rules do not decay automatically, which means they need a human cadence. A quarterly review covers it. Each rule owner confirms the rule is still relevant, the false positive rate is acceptable, and the rule still matches what it claims to match.
What changes for the SOC
The SOC sees fewer alerts and trusts the ones that fire. The blocklist shrinks by an order of magnitude. The number of business unit tickets from stale blocks drops to near zero. Analysts start asking for hunt queue access because the low confidence pool turns into a useful enrichment source.
Leadership sees a smaller and more honest dashboard. Active blocked indicators by source. Average current confidence. Median time from ingest to retirement. Hunt confirmations per month that returned to active blocking. Those are the metrics that map to outcomes.
The point
An IOC is a perishable claim about adversary infrastructure or tooling. Treat it that way. Assign a confidence at ingest, a half life that matches the type, and a floor for retirement. Split active blocking from hunt only. Reset the clock on fresh evidence. Review behavioral signatures on a human cadence. Your blocklist shrinks, your SOC trusts the feed, and your reports start to reflect what is actually still live.