Look for rules that once fired but no longer do, detections tied to retired data sources, and alerts that stopped after a schema or platform change. Decay often shows up after migrations, identity provider swaps, or log pipeline changes, because the detection logic no longer sees the same telemetry.
What decay looks like in a detection estate
A decaying detection estate usually shows up as silent failure, not noisy failure. The most useful warning signs are detections that have stopped firing after a platform, schema, or identity provider change, rules that still exist but now point at retired fields or sources, and a widening gap between the telemetry you collect and the logic your detections expect.
Another early signal is drift between ownership and reality. A rule may still be “green,” yet no one can explain what it protects, what event path it depends on, or who is responsible for validating it after a log source or ingestion path changes.
When that happens, the estate often has the outward shape of coverage but not the operational substance. The detection catalog can look complete while actual observability has been quietly reduced by data loss, field renaming, parser changes, or broken correlations.
Why decay happens after migrations and pipeline changes
Decay often follows the same change patterns because detection logic is tightly coupled to telemetry shape. If a migration alters event names, field mappings, authentication context, or collection timing, a previously reliable rule may no longer match the same activity even though the underlying threat is still present.
That is especially common when log pipelines are refactored, sources are retired, or identity infrastructure is swapped. The detection layer may still ingest data, but the semantics have changed enough that the rule no longer “sees” the behavior it was written to detect.
The practical problem is that detection engineering is a dependency chain. When upstream telemetry shifts, the estate can fail in a way that looks like low alert volume, when the real issue is reduced signal quality or broken logic.
What to check before you trust coverage
Start with the detections that have the highest blast radius if they fail: authentication abuse, privilege escalation, sensitive data access, and lateral movement. Then verify whether each rule is still bound to active data sources, current field names, and live alert routing. A detection that never fires may be healthy, stale, or simply blind.
Look for evidence that the detection was tested against current telemetry after change events. The strongest sign of health is not a long rule list, but proof that the rules still correlate to present-day logs, current asset inventories, and current identity paths.
For operational teams, this is where a detection review must move beyond content review and into telemetry validation. The question is not only whether the rule is well written, but whether the estate still emits the signals that make the rule meaningful.
Risk and Threat Considerations
A decaying detection estate creates silent exposure because defenders may believe monitoring still works after the underlying signals have changed. That gap is attractive to attackers, since it can leave weak authentication, abuse of service accounts, or post-compromise movement less visible than the team assumes.
Failure mechanism: telemetry drift, source retirement, parser breakage, or schema changes remove the event patterns a rule depends on, so the control remains deployed but no longer detects the intended behavior.
Impact: compromise can persist longer, alerts can fail to fire on material activity, and incident response may start from a weaker signal than the team expects, increasing dwell time and response cost.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | Enterprise Matrix | Detection decay must be tested against adversary technique coverage and attack-path visibility. |
| Recommendation — Map current detections to ATT&CK techniques and retest coverage after telemetry changes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Decaying detections often stem from log source, schema, or collection failures. |
| Recommendation — Validate log collection and field integrity after every pipeline or source change. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Detection estate decay directly weakens continuous monitoring of security events. |
| Recommendation — Reconfirm that monitoring still sees the events your detections depend on. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Rules decay when the logged events no longer match the behaviors being monitored. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Stale detections require ongoing review of whether alerts still represent current telemetry. | |
| Recommendation — Review logged event types after schema, platform, or identity changes. Periodically validate that audit analysis still produces meaningful alerts. | ||
Practitioner Guidance
What to verify: Treat every major platform, identity, or pipeline change as a detection validation event. Confirm that the highest-value rules still map to active sources, current field names, and current enrichment paths, not just to the old design documents.
What to measure: Track the percentage of detections with a recent positive validation against live telemetry, plus the number of rules tied to deprecated sources or unmapped fields. If those counts rise after change work, the estate is degrading even if alert volume looks stable.
Common mistake: Teams often equate “no alerts” with “no incidents.” In a decaying estate, quiet can mean blind, so rule health should be assessed alongside telemetry freshness and coverage after every migration or parser change.
Practitioner takeaway: The critical question is whether your detections still observe current reality. If the answer depends on legacy telemetry, the estate is already decaying even if the dashboard still looks normal.