Indicator Expiration in Threat Intelligence: Why You're Still Blocking Dead IPs

Most threat intelligence programs have a hoarding problem. Indicators of compromise flow in from feeds, enrichment layers, and analyst submissions. They accumulate in your SIEM, your firewall blocklists, your SOAR playbooks. Months later, the vast majority of those indicators are dead. The IP addresses have been reassigned. The domains have changed hands. The file hashes describe malware variants that haven't been active since Q3 of last year.

Photo by Ann H on Pexels.

You're still blocking them. You're still alerting on them. You're generating analyst workload on ghosts.

This isn't an edge case problem. Studies from threat intel vendors consistently show that IP-based indicators have a useful half-life measured in days, not months. One frequently cited figure puts it at roughly seven days before an IP rotates out of adversary control. Yet most organizations let indicators sit in their blocking infrastructure for 90, 180, or 365 days by default, if they expire them at all.

Why Indicators Go Stale (and Why It Matters Operationally)

Adversary infrastructure is ephemeral by design. Commodity threat actors use bulletproof hosting, botnets, and cloud instances they can spin up and abandon in hours. Nation-state actors are even more deliberate: they avoid reusing infrastructure precisely because they know defenders collect and share IOCs. By the time an IP address makes it through your ingestion pipeline, gets validated, gets added to your blocklist, and gets pushed to production, the adversary may have already moved.

What you're left with is blocking someone else's compromised web server that's now hosting a legitimate Romanian e-commerce site. Your firewall drops legitimate traffic. Your analysts investigate alerts that go nowhere. Your false positive rate climbs, analyst trust in the tooling drops, and the real signals start getting buried.

Expiration isn't housekeeping. Stale indicators actively degrade your detection capability by raising the noise floor.

Building Expiration Into the Pipeline

The fix requires treating indicators as time-series data rather than static records. Every indicator that enters your system should carry a confidence score and an expiration timestamp, both of which decay as a function of indicator type, source reliability, and observed reuse.

Here's a reasonable starting point for expiration windows by indicator type:

• IP addresses: 7 to 14 days (rotate to watchlist after 3 days of no hits)
• Domains: 30 to 60 days, conditional on DNS resolution still returning adversary-linked infrastructure
• File hashes (MD5/SHA1): 90 days unless the malware family is still actively deployed
• File hashes (SHA256 of specific variants): can extend to 180 days with active campaign confirmation
• TTPs and behavioral patterns: no expiration; these belong in detection logic, not blocklists

The last point is the one most programs get wrong. Teams treat MITRE ATT&CK technique references as interchangeable with atomic indicators. They're not. A specific C2 IP expires in days. The technique of using DNS tunneling for exfiltration doesn't expire. Mixing these in the same expiration policy guarantees you'll either block things too long or retire detection logic too early.

graph TD
    A[/Indicator Ingested/] --> B{Type Classification}
    B --> C[IP Address]
    B --> D[Domain]
    B --> E[File Hash]
    B --> F[TTP/Behavioral]
    C --> G(TTL: 7-14 days)
    D --> G2(TTL: 30-60 days)
    E --> G3(TTL: 90-180 days)
    F --> H[No Expiration: Detection Logic]
    G --> I{Active Hit?}
    G2 --> I
    G3 --> I
    I -->|Yes| J[Reset TTL + Flag for Review]
    I -->|No| K[Archive and Remove]

The Confidence Decay Function

Beyond static TTLs, better programs implement confidence decay: a score that starts at ingestion and drops over time unless the indicator gets a fresh confirmation. A newly reported C2 IP from a trusted ISAC partner might start at 85% confidence. After seven days without a hit in your telemetry, it drops to 40%. At 40%, it moves off the active blocklist to a watchlist. Another seven days with no confirmation, it drops to 15% and gets archived.

This isn't a theoretical model. MISP supports decay algorithms natively, and you can implement simpler versions with a scheduled job that reads your indicator store and adjusts scores based on age and hit frequency. The specific thresholds matter less than having thresholds at all.

Some programs resist expiration because the security team doesn't want to be responsible for "unblocking" something that later gets used in an attack. That's a governance problem, not a technical one. The answer is an audit trail that shows the indicator expired on a given date for documented reasons, with a clear reactivation process if the indicator resurfaces in new reporting. Keeping stale indicators forever to avoid accountability conversations is how you end up with 2 million entries in your blocklist and analysts who've stopped trusting alerts.

What Good Looks Like

A mature indicator lifecycle program runs on pipeline logic, not manual hygiene. Ingestion assigns type, source, confidence, and TTL automatically. A decay job runs daily, adjusting scores and triggering state transitions. Indicators with zero hits over their TTL window archive themselves with no analyst touchpoint required. Indicators that generate confirmed hits reset their TTL and get flagged for enrichment review.

Analysts spend their time on active, high-confidence indicators. The blocklist stays lean enough to be operationally meaningful. False positive rates drop because you're not matching traffic against a graveyard.

Your threat intelligence is only as good as the trust your team places in it. That trust erodes every time an analyst chases an alert tied to an IP that was decommissioned before they even joined the organization. Fix the expiration logic and you fix a larger problem: analysts who actually believe what the pipeline is telling them.