How threat intelligence decays and when to reassess it

Intelligence has a half-life

The indicator blocklist from 18 months ago is still running. A detection rule built for a campaign the adversary abandoned two quarters ago is still firing — or worse, silently passing. An analytic judgment that said, “This threat group does not target financial infrastructure in this region,” was accurate when the analyst wrote it. At some point, it stopped being accurate. None of these were wrong when they were created. They simply decayed over time, and nothing triggered a reassessment.

This is the accumulation problem. Intelligence-derived controls, documented judgments, and indicator feeds remain in operating environments long after the intelligence behind them has lost its validity. The problem is not bad intelligence. It is intelligence that was trusted indefinitely instead of being reviewed and maintained. NIST SP 800-150 recommends that shared threat indicators be maintained and re-evaluated as their context and confidence change over time, rather than treated as permanently valid (Source: NIST SP 800-150 Guide to Cyber Threat Information Sharing, https://csrc.nist.gov/pubs/sp/800/150/final).

What this article addresses is the reassessment discipline across intelligence types — what decays on which clock, what triggers reassessment for each, and how stale analytic judgments get corrected before they drive a wrong decision. Indicator decay and specificity framing, as well as per-item re-evaluation conditions at intake, are covered in their respective program references; those mechanics are assumed here, not repeated.

Decay rates by intelligence type

Intelligence does not age uniformly. Treating a single expiry interval as valid across all types — "review everything quarterly" — misallocates reassessment effort and leaves some categories trusted far past their useful life while over-cycling others.

Indicators (IPs, domains, file hashes) lose operational blocking value as adversary infrastructure rotates. A C2 IP that was live and attributed six months ago may now host a legitimate CDN, or have been reassigned to a different actor entirely. Blocking it provides little defensive value while false-positive risk accumulates. The retrospective and enrichment value of historical indicators persists — an IP that appeared in a campaign timeline remains useful for forensics even after it goes cold as a live IOC — but that is a different use case than active blocking. Reassessment here is time- and rotation-driven, not evidence-driven.

Behaviors and TTPs operate on a different clock entirely. MITRE ATT&CK documents adversary techniques as a durable taxonomy that changes when adversaries re-tool, not when their infrastructure rotates (Source: MITRE ATT&CK, https://attack.mitre.org/). A detection rule written against a named group's persistence mechanism — specific registry key modifications, a characteristic lateral movement sequence — retains detection value as long as the adversary continues using that technique. The trigger for reassessment is adversary re-tooling: public reporting of new tradecraft, detection gaps emerging in telemetry that should be catching the behavior, or attribution updates indicating the group has shifted methodology. In many environments, TTP-based detections can remain valid for 12–24 months or longer before re-tooling evidence surfaces — the right cadence depends on how closely the team tracks the relevant adversary cluster, not on a fixed interval.

Vulnerability intelligence is event-driven. The risk calculus around an unpatched CVE changes materially when a patch ships, when proof-of-concept exploit code goes public, when exploitation is confirmed in the wild, or when the affected product reaches end-of-life, and no patch will ship. The reassessment trigger is not a calendar date — it is each of those events. An unpatched vulnerability with no public exploit carries a different operational priority than the same CVE after weaponized exploit code circulates in criminal forums. Vulnerability remediation lifecycle and SLA mechanics are owned by vulnerability and attack surface management functions — this article owns the intelligence reassessment that changes the risk framing driving those decisions, not the remediation process itself.

Analytic judgments — attribution, targeting likelihood, campaign assessments — are the hardest category because they are rarely expressed with an explicit expiry. A judgment written at medium confidence that a specific threat group does not operate in a sector may be based on absence of evidence from a particular collection window. New evidence can corroborate or directly contradict that judgment, and without a reassessment mechanism, the original judgment persists. Confidence tiers should move as evidence arrives — a judgment that was medium confidence with supporting indicators should be revisited when those indicators age out or when contradicting reporting surfaces.

Decay and Reassessment Table

What triggers reassessment

Calendar reviews catch some decay. They miss the rest. A robust reassessment model maps trigger types to intelligence types rather than applying a uniform review cadence across the board.

Time and rotation drive indicator reassessment. An indicator that has not been confirmed active within a period defined by the team's risk tolerance and the source confidence should be flagged for review. The specific interval is an organizational choice shaped by threat exposure, source quality, and operational cost of false positives — not a universal standard.

Adversary re-tooling drives TTP reassessment. The signal arrives from external reporting (ISAC advisories, vendor TTP updates, updated ATT&CK technique pages), from internal detection gaps (a hunt that should surface known activity and does not), or from attribution updates that shift the group's known methodology. Teams with limited adversary tracking capacity can approximate this by reviewing TTP-derived detections when any of the above inputs arrive, rather than on a fixed schedule.

Events drive vulnerability intelligence reassessment. Patch release, PoC publication, confirmed exploitation, and EOL are each discrete triggers. An event-driven model means the intelligence function updates risk framing on each trigger occurrence, not at the next quarterly cycle. When a CVE moves from "no public exploit" to "confirmed in-the-wild," that is a reassessment moment whether or not a review was scheduled.

New or contradicting evidence drives analytic judgment reassessment. This is the trigger category most dependent on active collection — if no one is looking for contradicting evidence, it will not surface. A defensible practice is to document, at judgment creation time, what evidence would cause the judgment to be revised upward or downward in confidence, and to watch for that evidence specifically.

Environment and control change on the defender side creates a gap that none of the adversary-focused triggers cover. If an intelligence-derived control was justified because a specific asset class was in scope, and that asset class is decommissioned, the intelligence justification has changed even if the adversary has not. If a control the intelligence supported was removed for operational reasons, the intelligence function should know. This is the trigger type most often missed in environments that treat intelligence and operations as sequential rather than connected.

Expiring intelligence-derived controls

Controls accumulate. A block added when an IP was a live C2, a detection rule written for a campaign that has since ended, an escalation threshold set in response to a threat level that has since changed — each was justified by intelligence. When the intelligence decays, the control's justification decays with it. Without an explicit link between the control and the intelligence that warranted it, the control persists on inertia.

The operationally sound approach is to attach an expiry condition or a revocation trigger to controls at creation time, tied to the decay clock of the intelligence that justified them. For indicator-based blocks, this can be a time-based expiry with an option to renew on reconfirmation. For TTP-based rules, the trigger is a re-tooling signal rather than a date. For vulnerability-driven escalation thresholds, the trigger is the relevant event (patch, exploit maturity change).

The intelligence function owns the trigger to revisit — the reassessment decision that the underlying intelligence has decayed or changed. The receiving function (detection engineering for rules, vulnerability management for vulnerability controls) owns whether and how the control itself is retired or modified. Detection-rule lifecycle mechanics belong to the detection engineering function. Vulnerability remediation lifecycle belongs to vulnerability and attack surface management. This boundary is functional: intelligence reassessment does not require the intelligence team to manage the control's technical lifecycle, but it does require them to communicate when the justification has changed.

Practically, this means the intelligence-derived control record should carry: the intelligence source and confidence level at creation, the decay trigger type for that intelligence category, and a reference to the receiving function responsible for action. GRC owns evidence standards and retention for these records — the revocation decision is an intelligence reassessment output; the evidence record of it is governed by GRC.

Reassessing analytic judgments

An analytic judgment is not a standing fact. It is a confidence-weighted assessment based on evidence available at a point in time. When evidence arrives that corroborates or contradicts the judgment, confidence should move. When it does not — when a judgment remains unchanged despite new reporting, a shift in collection coverage, or the expiry of the indicators that supported it — the intelligence is stale in a way that is harder to detect than an expired IP block.

Confidence tiers are only operationally meaningful if they change as evidence changes. A judgment logged at medium confidence based on two corroborating sources should be revisited when a third source contradicts it, when the sources are retracted, or when the collection window that produced the underlying indicators has long since closed. In practice, this means building the reassessment condition into the judgment record at creation time: what would move this from medium to high confidence, and what would move it down.

The failure mode is a judgment that was accurate when written and has since become a constraint on decision-making. "This actor does not target our sector" shapes detection priorities, escalation thresholds, and investment decisions. If that judgment was documented 18 months ago and has not been revisited, it may be driving decisions based on evidence that no longer holds. Reassessment does not require a formal review board for every judgment — it requires a mechanism to surface contradicting evidence and a record of when confidence changed and why. For high-stakes judgments (attribution, sector targeting, threat level), a defined review trigger and a confidence-change log are operationally worth the overhead.

The Reassessment test

Pull the current list of active intelligence-derived controls — indicator blocks, detection rules, escalation thresholds, documented analytic judgments. For each one, answer three questions:

In many environments, a significant share of active intelligence-derived controls will not have a documented answer to question one. That is the accumulation problem in its operational form. The controls that have no named decay trigger and no owning function for reassessment are the ones most likely to be stale when they matter.

The test is not a one-time audit. It is a standing check: for the intelligence and analytic judgments currently in force, the team should be able to name which are past the decay horizon for their type and what trigger would prompt reassessment. If neither answer is available, the intelligence has been treated as permanently valid — which is the condition NIST SP 800-150 treats as a maintenance failure. (Source: NIST SP 800-150 Guide to Cyber Threat Information Sharing, https://csrc.nist.gov/pubs/sp/800/150/final)

Sources