Sub-technique coverage

Expanded Definition

Sub-technique coverage is the degree to which a security control, test, or detection maps to the exact sub-technique an adversary uses, rather than only the broader parent technique. In practice, this matters because broad coverage statements can hide blind spots in real execution paths, especially where a tactic is implemented through several distinct procedures. For teams working with threat models, detection engineering, or purple-team validation, sub-technique coverage is a way to ask whether the control works against the actual method observed in telemetry, not just whether it matches the label in a matrix.

The distinction is especially important in adversarial AI and cyber threat analysis, where taxonomy can outpace operational proof. Frameworks such as the MITRE ATLAS adversarial AI threat matrix are useful for organizing threats, but the presence of a mapping does not guarantee resilient detection. NHI Management Group treats sub-technique coverage as evidence-based: a detection should show how it captures the specific behavior, inputs, or tool sequence associated with the sub-technique. The most common misapplication is claiming full coverage from a parent-technique mapping, which occurs when teams stop at taxonomy alignment and never validate the exact procedure.

Examples and Use Cases

Implementing sub-technique coverage rigorously often introduces more test cases, tuning effort, and validation overhead, requiring organisations to weigh reporting simplicity against operational confidence.

• A detection may identify suspicious credential access broadly, but only sub-technique coverage proves it still alerts when an attacker uses token theft, session replay, or API-key extraction as distinct methods.
• Threat hunters may map an alert to a general exfiltration technique, then refine the rule set after confirming which sub-technique is actually present in endpoint, cloud, or identity logs.
• For agentic AI systems, coverage is stronger when telemetry shows the exact tool-use sequence or prompt-injection pathway being detected, not merely an AI abuse category.
• Red-team exercises can score coverage gaps when a control catches one execution path but misses a closely related sub-technique that uses different commands, inputs, or infrastructure.
• Governance teams can use sub-technique coverage to separate policy claims from proof by documenting which test evidence supports each detection statement and which does not.

Operational teams often use this term alongside defensive validation methods described in MITRE ATLAS adversarial AI threat matrix when they need to distinguish broad AI abuse categories from specific attacker procedures.

Why It Matters for Security Teams

Sub-technique coverage matters because incomplete mappings can create a false sense of readiness. Security leaders may believe a control is effective when, in reality, it only covers the easiest or most visible execution path. That gap can affect detection engineering, incident response playbooks, and control assurance reporting. In identity-heavy environments, the issue becomes even more consequential: a control may appear to cover credential abuse, but still miss the sub-technique used to compromise a session token, abuse delegated access, or manipulate an NHI workflow. For AI security teams, the same problem appears when a model abuse category is treated as covered without validating the exact prompt, tool call, or retrieval path that an attacker can exploit.

Sub-technique coverage also improves communication between blue teams, risk owners, and auditors because it replaces vague claims with testable statements. Where frameworks such as MITRE ATLAS adversarial AI threat matrix help classify threats, sub-technique coverage helps prove whether a control actually works against them. Organisations typically encounter the cost of weak coverage only after an incident reveals that a supposedly covered technique still succeeded through an untested sub-technique, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When do IAST and RASP create a false sense of coverage for NHIs?
• Should organisations prioritise least privilege or broad platform coverage first?
• How do you know if passwordless coverage is actually enterprise-wide?
• What do security teams get wrong about SAST and DAST coverage?