What are common mistakes with the Pyramid of Pain?

By NHI Mgmt Group Editorial Team Updated October 18, 2026 Domain: Threats, Abuse & Incident Response

Common mistakes are treating the Pyramid of Pain as a checklist, overvaluing any single indicator type, and ignoring context about the adversary and environment. Teams also confuse easier detections with lasting disruption. Use it to prioritise detections that increase attacker effort, but still combine indicators, behaviour, and response actions.

Where the Pyramid of Pain Gets Misused

The most common mistake is turning the pyramid of pain into a scorecard instead of a prioritisation tool. It is meant to help teams choose detections that force adversaries to work harder, not to rank every indicator as inherently good or bad. Another trap is assuming one highly “painful” indicator will outweigh weak coverage everywhere else; in practice, lasting disruption usually comes from layered detection and response, not a single insight.

That is why the question is not whether a detection sits higher on the pyramid, but whether it changes the attacker’s economics in your environment. A technically elegant indicator that does not survive routine rotation, infrastructure churn, or adaptation by the adversary may look strong on paper and still deliver only short-lived value.

What Good Use Looks Like in Practice

The framework works best when you combine several forms of evidence: observable indicators, behavioural signals, and response actions that make reuse costly. Threat intelligence guidance is most useful when it connects those layers, because it helps teams move from isolated indicators to intelligence that can actually shape detection, hunting, and containment decisions.

Context matters as much as the indicator itself. A hash, domain, or IP can be useful when it is tied to a campaign and validated against the environment, but the same artifact can become obsolete quickly or be reused by unrelated activity. Teams make better decisions when they ask what else would still hold if the specific indicator changed: the infrastructure pattern, the behavioural sequence, the tooling choice, or the response playbook.

The other recurring mistake is confusing easier detection with lasting disruption. Lower-level indicators are often simpler to collect, but they are also easier for an adversary to replace. Higher-value detections usually require more engineering, more tuning, and more disciplined response, but they force the attacker to alter tactics, tooling, or infrastructure in ways that are harder to scale.

How to Avoid the Most Expensive Errors

Use the pyramid as a decision aid, not as a substitute for threat modelling. The useful question is whether a detection can survive routine changes in infrastructure, credential use, and campaign workflow. If it cannot, it may still be worth collecting, but it should not be treated as the primary control.

Another frequent error is building detections without a response path. If the team cannot triage, enrich, contain, or hunt on the signal, then even a strong indicator produces limited operational value. The point of the pyramid is not collection for its own sake, but selecting detections that can lead to meaningful action.

Teams also overfit to one adversary pattern and then assume the same indicator value will transfer everywhere. The better practice is to tie indicators to a known behaviour set, verify how often they decay, and watch whether the response they trigger still matters after the first wave of cleanup. That keeps the pyramid grounded in operational reality rather than theory.

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 NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1583 — Acquire Infrastructure	The question is about adversary-focused detection and attacker adaptation.
Recommendation — Map indicators to attacker infrastructure patterns and hunt for recurring acquisition activity.
NIST CSF 2.0	DE.AE-02 — Threat and Vulnerability Information	The Pyramid of Pain is used to prioritise threat information by operational value.
	DE.CM-01 — Detection Processes	Common mistakes involve weak detection design and overreliance on low-value indicators.
Recommendation — Use threat information to prioritize detections that meaningfully change defender response. Tune detection processes to correlate indicators with behaviours and response actions.

Practitioner Guidance

What to prioritise: Prioritise detections that force the adversary to change behaviour, not just replace an artifact. If the signal only tells you that something happened, but does not alter the attacker’s next move, it is usually too low-value to anchor the programme.

What to verify: Check whether each proposed indicator still retains value after rotation, reuse, or environmental churn. A useful test is whether the same logic would still help if the adversary changed one visible element while keeping the campaign intact.

Common mistake: Do not treat the pyramid as a checklist of “more painful is always better.” The strongest programmes mix indicators, behaviour, and response so that detections remain useful even when any single artifact becomes stale.

Practitioner takeaway: The Pyramid of Pain is most effective when it drives resilience against adaptation, not when it is used to justify isolated detections that look sophisticated but fail to change attacker cost.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org