MITRE ATT&CK vs MITRE Engage: Describing Adversaries vs Engaging Them

Teams that adopt MITRE ATT&CK for detection often stall when they try to add deception, because ATT&CK tells you what adversaries do but says nothing about how to plan, run and stop an operation that interacts with them. MITRE Engage fills that gap, and the two are designed to be used together: Engage maps its activities onto ATT&CK techniques so deception follows observed behaviour. It is written for CTI analysts, detection engineers, deception owners and SOC leads who know the basics; the overviews are the MITRE ATT&CK Guide for Defenders and the MITRE Engage Guide.

Key takeaways

• One describes, the other plans. ATT&CK is a knowledge base of adversary tactics and techniques based on real-world observations; Engage is a framework for planning and discussing adversary engagement operations built from denial and deception.
• The mapping is the join, and it is coarse. Engage links 175 ATT&CK techniques to 29 adversary vulnerabilities and an engagement activity, in 793 rows, at technique level only, with no sub-techniques. Treat a row as a hypothesis to test, not a ready plan.
• The mapping has aged well but not perfectly. Checked against ATT&CK v20.1, 174 of the 175 mapped technique IDs are still current; the exception is the former Impair Defenses technique, which ATT&CK has revoked.
• Different owners, different risk. ATT&CK work is mostly analysis and sits with CTI and detection engineering. Engage work changes the environment the adversary sees, so it needs rules of engagement, gating criteria and legal sign-off before the first lure.
• Decoy machine credentials are the best first overlap. Credential access techniques such as T1552 Unsecured Credentials and T1528 Steal Application Access Token map mainly to Lures in Engage, and a decoy API key or service account has no legitimate user, so any use is a high-confidence signal.

The short answer

Use ATT&CK to answer "what will an adversary do here, and can we see it?": threat modelling, detection priorities, coverage reporting, emulation scope and incident write-ups. Use Engage to answer "given that behaviour, how do we expose, affect or learn from the adversary on our terms, and when do we stop?": deception design, operation planning, safety controls and after-action learning. ATT&CK is the demand signal; Engage is one of the ways to act on it, alongside conventional detection and mitigation.

Two frameworks, two threat models

ATT&CK: the adversary as a sequence of observable behaviours

ATT&CK models the adversary as someone pursuing tactical goals (the 15 Enterprise tactics, from TA0043 Reconnaissance to TA0040 Impact) through techniques that leave evidence. Its threat model is implicitly "the adversary will try to stay unseen and we must find the evidence". The v20 release reflects that view: the old defence evasion tactic now appears as TA0005 Stealth and TA0112 Defense Impairment, separating hiding from actively degrading defences. MITRE is explicit that the matrix documents only observed real-world behaviour.

The architecture, in words: a STIX 2.1 graph where techniques link to groups and software that used them, to mitigations, and, since the detection strategies model, to detection strategies and analytics that name data components such as process creation or logon session. The v20.1 Enterprise data holds 706 detection strategies and 1,773 analytics.

Engage: the adversary as a decision-maker with exploitable dependencies

Engage starts from a different premise, stated in its mapping document: when an adversary engages in a specific behaviour, they are vulnerable to exposing an unintended weakness. The handbook defines cyber denial as preventing or impairing the adversary's ability to operate, and cyber deception as revealing deceptive facts and concealing critical ones so the adversary cannot form correct estimates. Adversary engagement is the two used together within strategic planning, to raise the cost and lower the value of the adversary's operations.

The architecture, in words: two strategic goals (SGO0001 Prepare, SGO0002 Understand) bracket three engagement goals (EGO0001 Expose, EGO0002 Affect, EGO0003 Elicit). Each goal has approaches, such as EAP0002 Detect or EAP0006 Reassure, and each approach lists activities, such as EAC0005 Lures or EAC0011 Pocket Litter. Underneath sits the ATT&CK mapping, which joins a technique to an adversary vulnerability (EAV) and to the activity that exploits it. MITRE's build guidance then splits any operation into a Collection System, which watches, and an Engagement Environment, which the adversary operates in, kept as separate as possible so the adversary cannot see or tamper with the monitoring.

How the mapping works in practice

The mapping is one to many: one ATT&CK technique can have several vulnerability and activity pairs. MITRE's example is T1018 Remote System Discovery: an adversary doing discovery is vulnerable to collecting deceptive artefacts, so the defender can use lures to make them reveal behaviour. The official rows for credential access show the pattern most relevant to identity teams:

Three properties of the mapping change how you should use it:

• Technique level only: none of the 793 rows names a sub-technique. If your ATT&CK coverage map works at sub-technique level (T1552.001 Credentials In Files, T1552.005 Cloud Instance Metadata API), you must decide which Engage row applies to each sub-technique yourself and record that judgement.
• Lures dominate: Lures appear in 174 rows, far more than any other activity, followed by Information Manipulation and Security Controls. The mapping will suggest a lure for almost everything; the planning process is what tells you whether a lure is the right answer for this objective.
• Version drift is small but real: the mapping was built against the ATT&CK release current in 2022. Joining it to v20.1 data, 174 of 175 technique IDs resolve to current techniques. The one that does not is the former Impair Defenses technique, now revoked, so rows that used it must be re-pointed to the techniques that replaced it (for example T1685 Disable or Modify Tools) before they appear in a plan or report.

A practical join: export your prioritised techniques from the MITRE ATT&CK Coverage Mapping Guide work as a Navigator layer, load the Engage attack_mapping.json from the official repository, join on technique ID, and flag techniques where detection coverage is weak but an Engage row exists. Those are your candidate engagement opportunities.

Where each framework fails on its own

Controls each framework needs around it

Around ATT&CK: a pinned version for every coverage map and report; a test record (date, method, result) for every technique claimed as covered, ideally from purple team exercises (see the Purple Teaming Guide); a translation step for revoked and renamed IDs at each release; and threat intelligence that ranks techniques for your sector rather than treating the matrix as a checklist.

Around Engage: the planning artefacts the framework itself requires. In MITRE's terms these are an operational objective tied to a named Target Adversary, rules of engagement, and gating criteria that force a pause or end of the operation. The build guidance adds a Collection System kept separate from the Engagement Environment, and a failsafe that cuts internet access if a regular beacon stops. Add your own: a register of every decoy credential and decoy object with an owner, an expiry review and the alert route; written approval from legal for any activity that introduces vulnerabilities (EAC0023) or manipulates security controls (EAC0018); and a reset baseline (EAC0019) so the environment can be restored.

Decoy credentials for non-human identities

The strongest everyday overlap between the two frameworks is the decoy machine credential. ATT&CK documents how adversaries harvest secrets from files, environment variables, CI variables and instance metadata (T1552 and its sub-techniques), steal OAuth tokens (T1528) and then use them (T1550.001 Application Access Token, T1078.004 Cloud Accounts). Engage maps the credential techniques mainly to Lures. MITRE D3FEND names the defensive technique D3-DUC Decoy User Credential, and NIST SP 800-53 covers the control as SC-26 Decoys. Non-human decoys have no human owner to trip them by accident, so false positives can be close to zero.

Design rules: grant decoys no real privilege; make the alert route independent of the systems an intruder might disable; record every decoy in the NHI inventory with a flag so access reviews and secret scanners do not "clean it up" or raise it as a leak; and rotate decoys that appear in public leak monitoring. Placement detail is covered in the Honeytokens and Canary Credentials Guide and, for agents, the AI Agent Honeytokens and Canaries. A single decoy key that alerts is a detection control in ATT&CK terms; it becomes an Engage operation only when you plan what happens next (observe, redirect, or end) under rules of engagement.

Decision criteria

• Start with ATT&CK only if you have no ranked technique list, no test record for existing detections, or a SOC that cannot triage the alerts it already has. Engage operations add work for the same analysts.
• Add Engage Expose activities (lures and decoy credentials) once your coverage map shows techniques you cannot detect well with logs, typically discovery and credential access, and you have an owner for decoy alerts. This is where small teams get most value; MITRE's 10-step process document says that by defining goals clearly and scoping engagements tightly, even small organisations can run them.
• Move to Elicit or Affect operations only with a named objective, legal approval, a separate collection capability and staff who can watch an operation live. Most organisations below a large enterprise or government scale should stay at Expose.
• Use ATT&CK for all reporting, including the results of engagement operations: write up what the adversary did in ATT&CK terms so the findings feed back into detection and threat models. Engage's own Understand phase (SAC0006 After-Action Review, SAC0009 Threat Model) points the same way.
• Small vs large: a small team uses ATT&CK for a top-20 technique list and Engage for a handful of decoy credentials with a written gating rule. A large organisation runs a deception function with its own environment build, persona work and a quarterly after-action cycle feeding CTI.

Worked scenario: one stolen key, two lenses

A software company's threat model ranks credential theft from build systems as a top risk after reviewing incidents such as the CircleCI Breach, where secrets held in a CI platform had to be rotated at scale. The detection team's ATT&CK map shows T1552.001 Credentials In Files and T1552.004 Private Keys as weak: file reads on build agents are poorly logged, and secret scanning finds committed keys, not keys read by an intruder.

1. ATT&CK step: the team confirms the techniques are current in v20.1, records the data components that would be needed (file access on agents) and accepts that full logging is too costly. The gap is documented with the date checked.
2. Engage join: the T1552 rows point to Lures and System Activity Monitoring under EAV0028 and EAV0011. The team decides the objective is Expose only: detect use of build-agent secrets by anyone other than the pipeline.
3. Planning: three decoy cloud keys with no permissions are placed in agent images, each unique per agent pool, registered in the NHI inventory and excluded from scanner alerting. The gating criterion is simple: any decoy use opens a priority incident and the operation ends; there is no attempt to observe the intruder further.
4. Event: six weeks later a decoy key is used from an unfamiliar network. The audit log shows an identity enumeration call. Because each key is unique, the team knows which agent pool was read.
5. Back to ATT&CK: the incident report records T1552.001 then T1087 Account Discovery, the response rotates every real secret on that pool, and the coverage map now shows T1552.001 as detected by decoy, with the test date.

How to implement both without duplication

1. Pin versions: record the ATT&CK version (v20.1 at the time of writing) and Engage v1.0 in your programme documents.
2. Build the ATT&CK priority list: 20 to 40 techniques from threat intelligence for your sector, each with current detection status and test date.
3. Join to Engage: load the official mapping, re-point revoked IDs, and mark techniques that are weakly detected and have an Engage row.
4. Pick one Expose objective: usually decoy credentials for NHIs or decoy accounts in the directory. Write the operational objective, gating criteria and rules of engagement on one page and get legal and SOC sign-off.
5. Pilot: deploy in one environment segment, run a planned trigger test to prove the alert reaches the SOC, and measure noise for two to four weeks.
6. Roll back cleanly: keep the decoy register and baseline so every decoy can be removed in one change if it causes confusion or breaks a process.
7. Feed results back: each trigger and test updates the ATT&CK coverage map and the threat model; review quarterly.

Measuring the combined programme

• Weak-coverage techniques with an engagement control: share of priority techniques rated weak in ATT&CK coverage that now have a tested decoy or engagement activity.
• Decoy false positive rate: decoy alerts traced to legitimate activity (scanners, administrators) per month; the target is near zero, and every case should change placement or registration.
• Trigger test pass rate: planned decoy tests whose alert reached the SOC queue within the agreed time.
• Time from decoy trigger to containment: for real triggers, from first decoy use to rotation of the real secrets in scope.
• Feedback yield: new or changed detections, threat model entries or ATT&CK mappings produced per after-action review.
• Mapping hygiene: count of revoked or unmapped IDs in coverage and engagement records after each ATT&CK release; target zero within 30 days.

Framework mapping

For how D3FEND relates to ATT&CK more broadly, see MITRE ATT&CK vs MITRE D3FEND.

Common failure patterns

• Ignoring revoked IDs: carrying rows for the revoked Impair Defenses technique into a v20 coverage report breaks the join and misstates coverage.
• Decoys that look like leaks: unregistered decoy keys raised by secret scanners as incidents, or deleted in an access review, waste effort and erode trust in the programme.
• No stop condition: an operation with no gating criteria drifts into watching an intruder for too long, which increases risk to real systems.
• Engagement results not written in ATT&CK: findings stay in a deception console and never improve detection rules or the threat model.
• Decoy alerts routed through the same pipeline an intruder can disable: T1685 Disable or Modify Tools against the collector silences the decoy too.

Practitioner checklist

• Record the ATT&CK and Engage versions in every coverage map and engagement plan.
• Maintain a ranked technique list with detection status and test dates.
• Join the official Engage mapping to that list and re-point revoked IDs such as the former Impair Defenses technique.
• Decide sub-technique applicability for each Engage row you use, and record it.
• Write objective, gating criteria and rules of engagement before deploying any decoy.
• Register every decoy credential in the NHI inventory with an owner and alert route.
• Route decoy alerts through a path an intruder cannot easily disable.
• Run a trigger test for every decoy at deployment and at least quarterly.
• Write every engagement result in ATT&CK terms and feed it to detection and CTI.

Standards and references

• MITRE: ATT&CK
• MITRE: ATT&CK Resources
• MITRE: Engage
• MITRE: Engage data, handbook and mapping documents (GitHub)
• MITRE D3FEND: Decoy User Credential
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: MITRE Engage Guide, Deception Technology Guide, Honeytokens vs Honeypots, Threat-Informed Defence Guide, Detection Engineering for Non-Human Identities Guide.