In ATT&CK, what is the difference between a deprecated technique and a revoked one?

## Two different endings for an identifier ATT&CK is revised roughly twice a year, and each release retires some identifiers. The catalogue distinguishes two ways an identifier can stop being current, and the distinction is not pedantry - it decides whether an old reference can be migrated by a script or needs a person. **Revoked.** The object was *replaced* by another object. The revoked technique remains in the released data, flagged as revoked, and carries a relationship pointing at the replacement. The canonical mass example is the July 2020 sub-technique restructure: `T1527` Application Access Token was revoked in favour of `T1550.001` Use Alternate Authentication Material: Application Access Token. The behaviour is identical; the catalogue decided it belonged underneath a broader parent. Anywhere a revoked identifier appears in an old mapping, you can follow the published pointer to the current identifier without exercising any judgment at all. **Deprecated.** The object was *withdrawn* and nothing took its place. This happens when the authors decide something was not a distinct technique after all, when it was out of scope for the matrix, or when it was better expressed some other way that is not a one-to-one substitute. A deprecated object is also retained in the data, flagged, so an old reference can still be looked up and understood - but there is no forwarding address. Neither kind appears in the current matrix. Both remain resolvable. That retention is deliberate: the catalogue's authors know that years of published material cite the old numbers, and deleting the objects would make that material unreadable. ## Why the distinction bites Suppose you hold five years of mappings and you want them all expressed against the current release. Write the obvious migration and it will do the following: - **Revoked identifiers**: resolved correctly, one hop each, no judgment needed. This is most of the volume from the v7 restructure and it is genuinely cheap. - **Deprecated identifiers**: no target. Whatever your code does with a missing target - drop the row, leave it null, throw - it is now a hole in the data that nobody will notice, because the count that comes out the other end still looks plausible. - **Split parents**: the third case, and the one that catches people who have learned the first two. `T1078` Valid Accounts was not revoked and was not deprecated; it is still live, and it merely gained four children. A migration cannot push an old `T1078` reference down to `T1078.004` Cloud Accounts, because the original author never asserted which kind of account it was. Guessing manufactures precision. So a migration has three outcomes, not two: mechanically resolvable, mechanically unresolvable, and *already valid but coarse*. Only the first should be automated. ## Handling the unresolvable ones honestly For a deprecated identifier the defensible move is to keep the original reference, stamp it with the ATT&CK release it was written against, and record that it has no current successor. If someone genuinely needs that behaviour expressed in current vocabulary, a person reads the underlying description and picks a technique - and that is a judgment with their name on it, not a data transformation. The move to avoid is quietly rewriting a deprecated reference to "the nearest surviving technique". That looks like tidiness and it is fabrication: it puts a claim into the record that no one ever made, and the original material that would let a later reader check it is usually gone. ## What the interviewer is testing The weak answer treats the two words as synonyms for "old", which tells the interviewer you have cited ATT&CK but never worked with its data. The strong answer names the asymmetry - one has a successor, one does not - and then goes straight to the consequence, because the consequence is the whole reason the catalogue bothers to distinguish them.