To evaluate a red team's MITRE ATT&CK mapping, ignore the technique count and grade whether each technique is tied to a named objective, described at the procedure level, and paired with a detection outcome. A proposal that lists 200 technique IDs proves nothing. A proposal that shows how ten techniques would advance a specific goal in your environment, and what your blue team should detect when they run, proves a great deal. Breadth is easy to generate. Depth is what you are paying for.
That distinction matters more in 2026 than it did a year ago. MITRE released ATT&CK v19 on April 28, 2026, and Enterprise ATT&CK now contains 15 tactics, 222 techniques, and 475 sub-techniques, with the old Defense Evasion tactic split into Stealth (TA0005) and Defense Impairment (TA0112) (MITRE ATT&CK, April 2026 Update). The matrix is bigger and easier than ever to paste into a slide. A vendor can claim to "cover" almost all of it in a single line, and unless you know how to read that claim, you cannot tell rigor from a copy-paste.
This is a defender's rubric for grading that claim. It is vendor-neutral, it works on any adversary emulation or red team proposal, and it is built to be reused. Grade the mapping before you sign.
TL;DR: the fast read
The single tell: a headline technique count ("we cover 200+ ATT&CK techniques") is a red flag, not a credential. The full Enterprise matrix is only 222 techniques (MITRE ATT&CK), so "200+" means "we pasted the matrix."
What good looks like: techniques mapped to named objectives, described at the procedure level, each paired with a stated detection outcome for your blue team.
What padding looks like: a flat list of technique IDs with no objective, no procedure, no telemetry, and a "full ATT&CK coverage" claim.
How to grade it: score six criteria zero to two (objective linkage, depth, detection outcomes, threat-informed selection, honest scoping, evidence artifacts). Twelve is excellent; below seven, push back.
The deliverable to demand: an ATT&CK Navigator layer marking each technique as attempted, detected, or missed (MITRE ATT&CK Navigator).
Key takeaways
A wide matrix is padding, not coverage. Adversary emulation is depth-limited by objective and scope. No credible engagement exercises 200 techniques meaningfully, so a broad technique list signals a tool template rather than a tailored plan.
Objective linkage is the highest-signal green flag. ATT&CK tactics represent the "why" behind a technique (MITRE ATT&CK). If a proposal cannot say which objective a technique advances in your environment, the mapping is decorative.
Detection outcomes separate a red team from a checkbox. The value of emulation is the evidence your blue team gets: which detection should fire, and whether it did. A proposal that never mentions your telemetry is testing for a report, not for your defenses.
Threat-informed selection beats full-matrix sweeps. A technique set derived from ATT&CK Groups and Software relevant to your sector (MITRE ATT&CK Groups) is worth more than a generic pass over every tactic.
Honest scoping is a quality signal. A vendor who tells you which tactics are out of scope, and why, understands emulation better than one who claims to cover everything.
Methodology and sources
This rubric is grounded in MITRE ATT&CK as the primary reference for adversary behavior. Structural facts (tactic, technique, and sub-technique counts, the Defense Evasion split, the tactic-to-procedure hierarchy, ATT&CK Groups and Software, and the Navigator deliverable format) come from MITRE's own documentation as of the ATT&CK v19 release on April 28, 2026, the most current version at the time of writing. Every figure links to its MITRE source so any claim can be audited inline. The grading criteria reflect how experienced buyers of threat-led testing tell tailored, human-led emulation apart from a tool-generated technique list. Figures that could not be confirmed against a named MITRE page were left out rather than estimated.
Why ATT&CK coverage claims mislead
ATT&CK organizes adversary behavior into tactics (the goal), techniques (how they pursue it), sub-techniques (a more specific how), and procedures (the exact in-the-wild implementation). Breadth lives at the tactic and technique level; depth lives at the sub-technique and procedure level (MITRE ATT&CK FAQ).
A technique-count claim advertises breadth, which is the cheapest thing in the framework to produce: the matrix is public, and a breach-and-attack-simulation tool can emit a coverage list automatically. The number tells you how many rows a tool touched, not whether a human operator reasoned about your environment, chose techniques that advance a real objective, and confirmed what your defenses did in response. Depth cannot be generated. It takes an operator who knows your crown jewels, selects a small set of techniques that chain toward them, and documents the procedure and the resulting detection. That is the work. Everything else is formatting.
The grading rubric: green flags vs red flags
Use this as a checklist against any proposal. The more green flags, the more you are buying genuine emulation. The more red flags, the more you are buying a matrix screenshot.
Green flags: genuine, human-led, objective-linked coverage
Every technique is tied to a named objective. The proposal reads "we will attempt T1550 to reach the payments database," not "T1550 (in scope)." Techniques appear because they advance a goal, and the goal is one of your crown jewels.
Depth reaches the procedure level. For the techniques that matter, the plan describes the specific procedure the operator would run in your environment, not just a technique ID. This is the tactic-technique-sub-technique-procedure hierarchy actually used.
Detection outcomes are first class. Each technique carries a stated expectation for your telemetry: which log source or detection rule should fire, and the plan to report whether it did. Coverage is framed as "your SOC should see X," not only "attacker did X."
Selection is threat-informed. The technique set is derived from a threat actor or profile relevant to your industry, referencing ATT&CK Groups and Software rather than a full-matrix sweep (MITRE ATT&CK Software).
Scoping is honest. The proposal states which tactics and techniques are out of scope and why, for example no destructive Impact techniques in production. It does not claim full coverage.
Evidence artifacts are promised. Deliverables include procedure logs, timestamps, and screenshots mapped to technique IDs, packaged as an ATT&CK Navigator layer that marks each technique attempted, detected, or missed.
Red flags: padding and tool-generated technique lists
A headline technique count. "We cover 200+ ATT&CK techniques" is padding. Real emulation is depth-limited, so breadth as a selling point is a tell.
Bare technique IDs. A flat list of IDs with no objective, no procedure, and no environment specificity is a copy-paste of the matrix.
No detection language anywhere. If the plan never references your telemetry, SIEM, or EDR, it is not testing your defenses.
"Full ATT&CK coverage" or "100% of the matrix." This claim is the clearest sign of a checkbox exercise. Nobody exercises 15 tactics and 222 techniques meaningfully in one engagement.
The list is identical across their case studies. If the same technique set appears in every past report regardless of client, it is a default tool template, not a tailored plan.
No named adversary or profile. A technique set with no reference to ATT&CK Groups or a stated threat model was not threat-informed.
Scoring a proposal in five minutes
Turn the rubric into a number. Score each criterion 0 (absent), 1 (partial), or 2 (strong), then total out of 12.
Criterion | What a 2 looks like | Score (0-2) |
|---|---|---|
Objective linkage | Every technique maps to a named crown-jewel objective | |
Procedure-level depth | Specific procedures described for the techniques that matter | |
Detection outcomes | Expected telemetry and blue-team reporting stated per technique | |
Threat-informed selection | Technique set derived from a relevant ATT&CK Group or profile | |
Honest scoping | Out-of-scope tactics named with rationale, no "full coverage" claim | |
Evidence artifacts | Navigator layer plus procedure logs and screenshots promised |
Reading the total: 11 to 12 is a strong, human-led proposal. 7 to 10 is workable but push on the weak criteria before signing. Below 7 is likely a padded, tool-generated list; ask the vendor to rebuild the mapping around your objectives or walk.
Seven questions that expose padding
Send these to any shortlisted vendor. Genuine operators answer them in a paragraph. Padding stalls.
For three techniques you list, show the specific procedure you would run in our environment and the objective each advances.
For those three, which detection or log source should fire, and how will you report what our SOC saw versus missed?
Which threat actor or profile did you base this technique set on, and why is it relevant to our sector?
What is explicitly out of scope in the matrix, and what was the reasoning?
Will the deliverable include an ATT&CK Navigator layer marking each technique attempted, detected, and missed?
How much of this plan is generated by a tool versus authored by the lead operator?
Can you show a redacted past report where a listed technique produced a detection-gap finding?
Question 6 is the quiet one. There is nothing wrong with automation in the workflow, but you want to know where the human judgment sits. If the honest answer is "the tool wrote the plan," you are grading a template.
What this means for defenders and buyers
Grade the mapping before you sign, not after the report lands. The proposal is where padding is cheapest to hide and easiest to catch. Run the six-criterion scorecard on every shortlisted vendor.
Buy depth and detection outcomes, not technique count. The output that changes your security posture is the list of detections that failed to fire, mapped to techniques you care about. Optimize the purchase for that.
Demand the Navigator layer as a deliverable. An attempted-detected-missed layer turns a red team engagement into a durable coverage baseline you can re-test against next cycle. Our guide on how to evaluate a penetration test report applies the same evidence-first lens to the deliverable.
For regulated buyers, padding does not satisfy a threat-led regime. Threat-led testing expectations under frameworks such as DORA, CBEST, and OSFI-style intelligence-led testing hinge on mapping real objectives to adversary behavior and demonstrating detection outcomes. A technique-count list will not carry that evidence. Scope objectives first, as covered in our note on red team objectives and crown-jewel scoping.
This is exactly how Stingrai runs adversary emulation. Our human-led red team engagements map every objective to ATT&CK, reach the procedure level on the techniques that matter, and feed your blue team detection evidence rather than a matrix screenshot. Where web applications are in scope, our autonomous agent Snipe hunts complex, high-impact classes such as broken authorization, IDOR, and business logic flaws, and senior operators validate and extend what it finds. If you are weighing point-in-time emulation against a continuous model, our comparison of red team, penetration test, and continuous validation sets out the tradeoffs, and Stingrai PTaaS delivers the ongoing version.
Frequently asked questions
How do I evaluate a red team proposal's MITRE ATT&CK coverage and spot padding?
Ignore the technique count and grade six things: whether each technique is tied to a named objective, whether the plan reaches the procedure level, whether detection outcomes are stated, whether selection is threat-informed, whether scoping is honest, and whether evidence artifacts are promised. A proposal that lists 200-plus technique IDs with no objectives, no procedures, and no detection language is padding. Genuine emulation ties a small set of techniques to your crown jewels and reports what your blue team saw or missed.
Is a higher ATT&CK technique count better in a red team proposal?
No. It is usually worse. Enterprise ATT&CK contains only 222 techniques as of v19 (MITRE ATT&CK), so a "200+" claim means the vendor pasted most of the matrix. Adversary emulation is depth-limited by objective and scope, and no credible engagement exercises that many techniques meaningfully. Prioritize depth and detection outcomes over breadth.
What is the difference between ATT&CK breadth and depth?
Breadth is how many tactics and techniques a plan touches. Depth is how far down the hierarchy it goes, from technique to sub-technique to the exact procedure run in your environment (MITRE ATT&CK FAQ). Breadth is cheap to generate from the public matrix. Depth requires a human operator reasoning about your systems, so depth is the signal of quality.
How many tactics and techniques are in MITRE ATT&CK in 2026?
As of ATT&CK v19, released April 28, 2026, Enterprise ATT&CK contains 15 tactics, 222 techniques, and 475 sub-techniques (MITRE ATT&CK, April 2026 Update). Version 19 split the former Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112), so proposals that still reference a 14-tactic Defense Evasion model are working from an older matrix.
What is an ATT&CK Navigator layer and why should I ask for one?
The ATT&CK Navigator is a MITRE tool for annotating the matrix, and a coverage layer is a color-coded view of which techniques were attempted, detected, or missed (MITRE ATT&CK Navigator). Asking for it as a deliverable forces the vendor to produce per-technique outcomes rather than a flat list, and it gives you a reusable baseline to re-test against next cycle.
What does threat-informed technique selection mean?
It means the technique set is chosen to emulate a specific adversary or threat profile relevant to your industry, using ATT&CK Groups and Software as the reference, rather than sweeping the whole matrix (MITRE ATT&CK Groups). A threat-informed plan explains which actor it emulates and why that actor is a plausible threat to your sector.
Does automation in a red team plan mean it is padded?
Not by itself. Automation is legitimate across discovery, execution, and reporting. The question is where human judgment sits. Padding is when a tool wrote the whole mapping and nobody tailored it to your objectives or environment.
How does Stingrai map red team objectives to ATT&CK to support compliance evidence?
Stingrai runs human-led adversary emulation that maps each engagement objective to ATT&CK techniques and reports detection outcomes to your blue team. That evidence supports threat-led testing programs under frameworks such as DORA, CBEST, and OSFI-style intelligence-led testing, and it strengthens SOC 2, ISO 27001, and PCI DSS programs. Learn more about Stingrai's red team service.
References
MITRE ATT&CK. Updates: April 2026 (ATT&CK v19). April 28, 2026. https://attack.mitre.org/resources/updates/updates-april-2026/. Release notes confirming 15 tactics, 222 techniques, and 475 sub-techniques, and the split of Defense Evasion into Stealth (TA0005) and Defense Impairment (TA0112).
MITRE ATT&CK. Enterprise Tactics. https://attack.mitre.org/tactics/enterprise/. The 15 Enterprise tactics and the definition of a tactic as the adversary's objective.
MITRE ATT&CK. Enterprise Matrix. https://attack.mitre.org/matrices/enterprise/. The full Enterprise matrix of tactics and techniques used to sanity-check technique-count claims.
MITRE ATT&CK. Groups. https://attack.mitre.org/groups/. Documented adversary groups used for threat-informed technique selection.
MITRE ATT&CK. Software. https://attack.mitre.org/software/. Adversary tooling and malware mapped to techniques, used for threat-informed emulation.
MITRE ATT&CK. ATT&CK Navigator. https://mitre-attack.github.io/attack-navigator/. The MITRE tool for building coverage layers marking techniques attempted, detected, or missed.
MITRE ATT&CK. Frequently Asked Questions. https://attack.mitre.org/resources/faq/. Reference for the tactic, technique, sub-technique, and procedure hierarchy.
MITRE ATT&CK. Data and Tools. https://attack.mitre.org/resources/attack-data-and-tools/. The machine-readable ATT&CK data set behind Navigator layers and coverage tooling.
