ATT&CK T1527 was a valid technique ID in 2019 and is absent from today's matrix - what happened?

## What actually happened in July 2020 Until ATT&CK v7 the Enterprise matrix had exactly two numbered levels: tactics (the adversary's goal) and techniques (`T####`). Techniques sat at wildly different grain - one might describe something as broad as "use a valid account", another something as narrow as "pass the hash". The v7 release, published in July 2020, added a third level: **sub-techniques**, written as the parent's number plus a three-digit suffix, `T1550.001`. That restructure was not a cosmetic renaming. It rearranged the identifier space, and it did so in three distinct ways that you need to be able to tell apart. **1. Parent kept, children added.** `T1078` Valid Accounts stayed `T1078` and acquired `T1078.001` Default Accounts, `.002` Domain Accounts, `.003` Local Accounts and `.004` Cloud Accounts. An old reference to `T1078` is still a live identifier - it is simply coarser than what you could write today. **2. Revoked and replaced.** Several top-level techniques were folded in as sub-techniques of a newly created parent. `T1527` Application Access Token became `T1550.001` under the new parent `T1550` Use Alternate Authentication Material. The old number is marked revoked in the released data and carries a pointer to its replacement, so the old reference can still be resolved - but the number itself is no longer something you would write today. **3. Deprecated.** A small number of techniques were withdrawn with no successor, because the behaviour was judged not to be a distinct technique, or out of scope for the matrix. There is nothing to map those forward to. ## Why this matters more than it sounds The instinct people bring from other catalogues is that an identifier is a permanent key: a CVE identifier, once assigned, always points at the same flaw in the same product. ATT&CK identifiers do not work that way. The catalogue is a **living description of adversary behaviour**, revised roughly twice a year as the authors learn more and as the behaviour space changes. Numbers move because the model of the behaviour improved, not because the behaviour did. That has a direct consequence: **the release version is part of the identifier's meaning**. `T1527` in a 2019 assessment and `T1550.001` in a 2026 one are the same claim about the same behaviour. Two mappings written against different releases are not directly comparable until you normalise them to one release. ## The worked example Consider a SaaS tenant where an application holds a consent grant with a mail-read scope and has been reading the same mailboxes the same way for five years. When that access is used to reach data, the behaviour is "use an application's access token instead of a user's credential". - Written up in 2019: `T1527` Application Access Token. - Written up in 2026: `T1550.001` Use Alternate Authentication Material: Application Access Token. The grant did not change. The scope did not change. The mailboxes did not change. Only the label did. If you line up five years of mappings by raw identifier and read the shape of the curve, the July 2020 release boundary will show you a cliff in one number and a birth in another, and both are artefacts of the catalogue. ## What a good answer includes Say that the restructure happened and roughly when; say that the behaviour is unchanged; and say how you would resolve the old number without guessing - the replacement relationship is published with the data, so a revoked identifier can be followed to its successor mechanically. Then add the practical habit: **record the ATT&CK release version alongside every technique identifier you write down.** It costs nothing at the time and it is the only thing that makes an old mapping interpretable later. The answer to avoid is "the technique was removed because nobody does it any more". Removal from the current matrix says something about the catalogue's structure; it says nothing whatsoever about whether adversaries still do the thing.