- 01ATT&CK v15 is the largest cloud + ICS expansion since v10. Cloud identity / persistence and ICS remote-services additions are the highest-impact for enterprise detection.
- 02Renumbering and sub-technique splits silently invalidate existing mappings. A re-tag audit is mandatory; otherwise your coverage heatmap is fiction.
- 03Coverage-as-code (mappings stored in the detection repo, not the SIEM) is the only pattern we have seen survive three+ ATT&CK releases without drift.
- 04The single highest-leverage detection investment for 2026 is cloud identity persistence (T1098.001/.003/.005 family) — it underwrites most cloud-tenant compromises we investigate.
- 05Board ATT&CK reporting is most defensible when it shows three numbers: coverage % per tactic, MTTD per tactic, and analyst-confirmed true-positive rate per technique.
MITRE ATT&CK v15 made the most consequential cloud and ICS additions in several releases. For detection engineering teams, the practical work is twofold: re-mapping existing content to the new technique IDs (renumbering and sub-technique splits silently break references) and identifying the coverage gaps the new techniques expose.
This piece is for the detection engineer who has to do the re-tagging and the threat-intel lead who has to brief the CISO on what the new release means for the program.
Why ATT&CK releases hurt detection programs.
ATT&CK is structurally a versioned schema. Each release renumbers, splits, retires, and re-titles techniques. Detection content that hard-codes technique IDs (T1078.004, etc.) decays the moment the next version ships. The fix is mechanical: store mappings as data in your detection repo, run a CI job to verify against the latest STIX bundle, fail builds on broken references.
The structural diff — where v15 changed your map
Below is the practitioner's summary of the v15 diff areas that move actual detection content. We exclude purely editorial changes; we include anything that changes how a SIEM rule should be tagged or grouped.
/ATT&CK_V15 · DIFF_HOTSPOTS
| Area | What changed | Impact on detection content |
|---|---|---|
| Cloud Identity | New / refined sub-techniques on IdP federation persistence | High — most cloud-tenant compromise paths now have explicit tags |
| Cloud Persistence | Service principal additions, federated cred theft | High — covers Golden SAML and OAuth-app abuse properly |
| ICS | Remote services + engineering workstation refinements | High for OT estates; otherwise minor |
| Mobile | MDM compromise + supply-chain install expansion | Medium — affects MTD-tagged content |
| Defense Evasion | Cloud-native evasion + log-tampering sub-techniques | Medium — most SIEM rules need re-tag, not re-write |
| Credential Access | Cloud creds family clarified | Low-medium — better tagging, similar detections |
The re-tagging discipline — a one-week project, done right
Re-tagging detection content after an ATT&CK release is mechanical work, but the discipline matters. Below is the cadence we run for clients on the day a major release lands. Done well, it is a one-week project with two engineers; done badly, it produces a coverage heatmap that lies for years.
- 01Day 1 — Pull the new STIX bundle. Diff against the previous version programmatically. Generate the list of: renumbered IDs, retired IDs, new sub-techniques, deprecated sub-techniques.
- 02Day 2 — Run the diff against your detection repository. Auto-update obvious renames. Flag deprecated mappings for human review. Open one issue per affected detection.
- 03Day 3–4 — Detection engineers walk the flagged list. For each, decide: re-tag to nearest equivalent, split coverage across new sub-techniques, or open a new-detection ticket if no equivalent exists.
- 04Day 5 — Refresh coverage heatmap from the updated mappings. Compare to the pre-release heatmap; investigate any tactic that lost coverage. Brief the SecOps lead.
Coverage-as-code — the pattern that survives the next release
The single highest-leverage operational investment in the wake of v15 is moving ATT&CK mappings out of the SIEM (where they live as untyped strings) and into the detection-content repository (where they live as data validated by CI). The pattern is simple but transformative.
Why this pattern survives.
When the next ATT&CK release lands, a single CI job runs the official STIX bundle against your detection repo, fails the build for any unknown technique ID, and opens one PR per stale detection. The discipline becomes operationally cheap. Detection content stops drifting from the framework — which is the entire point.
/COVERAGE_AS_CODE · detection rule front-matter
# detections/cloud/idp_federation_persistence.yaml
title: "IdP federation trust modified by non-IdP-admin principal"
severity: high
data_sources:
- aws.cloudtrail
- azure.signin
attack:
framework_version: "15.1"
techniques:
- id: T1556.007 # Modify Authentication Process: Federated SSO
tactic: defense-evasion
- id: T1078.004 # Valid Accounts: Cloud Accounts
tactic: persistence
detection:
query: |
source IN (cloudtrail.UpdateSAMLProvider,
azuread.SetDomainAuthentication)
AND actor.role NOT IN identity_admin_roles
references:
- https://attack.mitre.org/techniques/T1556/007/
last_validated: 2026-04-12
owner: detection-engineering@alexa.example
The cloud identity gap v15 lays bare
If you do nothing else with v15, build the detection coverage for cloud identity persistence. Across our 2024–2025 incident response engagements, federated-identity persistence was the technique we most often saw as the second hop after the initial breach — and the technique most often missing from the victim's detection content.
- 01T1556.007 — Modify Authentication Process: Federated SSO (Golden SAML pattern)
- 02T1098.005 — Account Manipulation: Device Registration (rogue MFA enrollments)
- 03T1098.003 — Account Manipulation: Additional Cloud Roles (privilege addition under noise)
- 04T1199 — Trusted Relationship (CSP / partner tenant abuse)
- 05T1606.002 — Forge Web Credentials: SAML Tokens (credential-skip persistence)
Using ATT&CK in board reporting — three numbers, not seven
ATT&CK heatmaps are visually compelling and operationally useless for board conversations. The metrics that survive a CFO's challenge are quantitative and trended. Pick three.
/ATT&CK_BOARD_METRICS
| Metric | What it proves | How to compute |
|---|---|---|
| Coverage % per tactic | Detection breadth, by attacker phase | Detections-with-mapping / techniques-in-tactic |
| MTTD per tactic | Detection latency, by phase | From SIEM event time → analyst confirm |
| TP rate per technique | Detection precision, by phase | Confirmed true positives / fired alerts |
A 30-day plan to land v15 cleanly
- 01Days 0–7 — Run the re-tag audit. Land coverage-as-code in the detection repo. CI gate on technique-ID validity.
- 02Days 7–14 — Build the cloud identity persistence detection family (T1556.007, T1098.003/.005, T1606.002). Validate with a purple team exercise.
- 03Days 14–21 — Refresh the coverage heatmap. Brief SecOps + threat-intel leadership on the gap closures and the residual gaps.
- 04Days 21–30 — Stand up the three board metrics. Publish the first quarterly trend snapshot. Schedule the next release-day re-tag drill before v16 lands.
Monday morning — the test that proves coverage-as-code is real.
Pick one of your highest-severity detection rules. Open it. Find the ATT&CK mapping. Confirm it cites a technique ID, a sub-technique where applicable, and the framework version. If any of the three is missing, your coverage program is documentation. Fix that one detection by EOD; propagate the schema to the rest of the repo this week.
- ▸Sample one high-severity detection
- ▸Verify mapping cites technique + sub-technique + version
- ▸If missing, treat as the canonical fix template
- ▸Land CI validation against the latest STIX bundle this sprint
Closing — ATT&CK is a contract, treat it like one
ATT&CK is the closest thing the industry has to a shared vocabulary for attacker behavior, and it works only if your detection content honors the contract. v15 is a forcing function. Re-tag, formalize coverage-as-code, close the cloud identity persistence gap, and report three numbers — not seven — to the board. The next release will then be a one-week refresh instead of a quarterly fire drill.