Adversary emulation vs red teaming

Adversary emulation vs red teaming: which one answers the board's question

When a board or regulator asks whether the organization would detect a specific threat, the answer depends on which question sits underneath. Adversary emulation tests known actor behavior against your defenses, while red teaming tests whether an objective can be reached and whether defenders notice. Emulation works from a documented playbook, so it answers "would we catch this group doing what it is documented to do?" Red teaming answers "can someone get to the crown jewels, and would anyone know?" Choose adversary emulation when the question names a threat actor or a sector-relevant campaign and the team needs repeatable, technique-level evidence. Choose red teaming when the question is about overall resilience to a determined attacker who is free to pick a route.

The MITRE Center for Threat-Informed Defense publishes full emulation plans for named actors under an Apache-2.0 license, mapped to ATT&CK, and MITRE Caldera can automate parts of those plans. These assets make emulation cheaper to repeat, but they do not make it a substitute for an objective-driven test. Combine the two when the board wants both a documented actor scenario and an answer about end-to-end impact. Regulated entities should also check what their supervisor expects. Under DORA, threat-led testing has its own scenario and duration rules, so confirm with your competent authority whether a voluntary exercise will be accepted or whether a formal TLPT is required.

The right choice follows the question, not the maturity of the program. An emulation that cannot reach the objective tells the board little about overall exposure, and a red team that never follows a documented actor tells the board little about specific detections. Before scoping, write the board's question in one sentence and confirm who will accept the answer, then pick the format that produces evidence for that sentence.

How the two approaches compare on goals, scope and method

This table compares adversary emulation and objective-driven red teaming on goal, threat input, scope, method and output, so you can match the exercise to the question your board is asking. Read each row as a choice you make before the engagement starts, because the rules of engagement and plan design follow from it.

Dimension	Adversary emulation (MITRE library plans)	Objective-driven red team (CA-8(2) style)
Primary goal	Test whether defenses detect and stop the documented behaviors of a named or representative adversary, one technique at a time if needed.	Test whether the organization can detect and respond to an attacker working toward a defined objective, such as access to a crown-jewel system.
Threat input	A documented actor profile, such as the full plans for APT29 or FIN6 in the MITRE Adversary Emulation Library, built from public threat intelligence and mapped to ATT&CK.	Current threat intelligence chosen for the engagement, which may draw on sector threat reporting or a regulator-set scenario.
Scope of behavior	Full emulation plans cover an adversary from initial access through exfiltration. Micro plans test compound behaviors such as process injection, web shells or log clearing shared across many actors.	Any technology-based or social engineering path that reaches the objective, as NIST SP 800-53 CA-8(2) describes. Techniques are chosen by testers during the exercise.
Who designs the plan	The emulation plan is largely fixed in advance. The team adapts execution details, such as tooling and timing, to the target environment.	Testers and the client agree objectives, boundaries and attack paths. The team chooses its own route within those limits.
Method at a buyer's level	Repeatable and scripted where possible. Automation with MITRE Caldera, an Apache-2.0 platform, can run parts of a plan and support manual operators.	Human-led and adaptive. Testers chain techniques creatively, and may include phishing, phone pretexts or physical access as NIST describes.
Rules of engagement	Must name the plan, the actor profile, the techniques allowed and the systems in scope, and agree how stop conditions and deconfliction work.	Must name objectives, permitted attack types, social engineering limits, exclusions and the legal authorization. NIST SP 800-115 Appendix B provides a template.
Output	Technique-by-technique results mapped to ATT&CK, showing which behaviors were detected, blocked or missed. Useful for tuning controls.	A narrative of the attack path, the objective reached or not, and where defenders noticed. Useful for judging response capability.
Fit with compliance regimes	Supports detection validation expected under CIS Safeguard 18.4 and similar controls. Not sufficient alone for DORA threat-led testing, which needs its own scenario and duration rules.	Matches the red team concept in NIST SP 800-53 CA-8 enhancements. Under DORA, a voluntary red team does not replace a TLPT where one is required, so confirm scope with your authority.
Question it answers for the board	Are the actors that matter to us detected by the controls we already pay for?	Could an attacker reach our most important asset without us noticing, and how quickly would we respond?

How an adversary emulation plan runs step by step

The sequence turns a named threat actor's documented behavior into a controlled test, so the team can see which controls fired, which did not, and what to fix first. Each step has a defined output that feeds the next.

Select a named actor and plan
The team chooses a threat actor from the MITRE Center for Threat-Informed Defense's Adversary Emulation Library, which is licensed under Apache-2.0 and covers named actors such as APT29, FIN6, FIN7, menuPass, OilRig, Sandworm, Turla and Wizard Spider. The plans are built from public threat intelligence and annotated with MITRE ATT&CK. Choose a full emulation plan when you want the actor's behavior from initial access through exfiltration, or a micro plan when you want to test one shared behavior such as process injection or log clearing. The step is done when the scope, chosen plan and the reason for choosing it are written down and approved by the sponsor.
Map techniques to your environment
Walk through the plan's ATT&CK techniques and decide which ones apply to your estate, operating systems, identity stack and cloud accounts. The ATT&CK Enterprise matrix lists 15 tactics used to plan adversary emulation in ATT&CK v20, released on 13 October 2026, so the mapping should be checked against the version the plan references. Mark techniques that cannot be run safely in production, and record the substitutes you agree on. The step closes with a technique list where each line names the target system, the expected telemetry and the owner who will review it.
Agree rules of engagement
Testers, the system owner and the sponsor agree in writing on the rules of engagement. NIST SP 800-115 provides a rules of engagement template in Appendix B that covers scope, timing, contacts, permitted techniques, data handling and stop conditions. Confirm which actions are off limits, how the team will halt the exercise, and who is told if real attackers appear to be present. Legal review of the authorization letter is a separate item from the technical plan. The step is done when every named owner has signed the document and the stop procedure has been tested by a contact call.
Prepare execution tooling and automation
Decide which steps the testers run by hand and which are automated. MITRE Caldera is built on ATT&CK to automate adversary emulation, assist manual red teams and automate incident response, and it is licensed under Apache-2.0. Caldera can run abilities and chain them into operations, but you still need to review each ability for the target environment before it runs. Confirm the agents, network paths and logging configuration in a non-production environment first. The step is done when a dry run confirms that each planned action executes as intended and that the operator console records what was sent to each host.
Execute each step in order
The testers run the plan through its phases, moving from initial access toward the objective in the sequence the actor documents. The operator logs the time, host, technique and outcome of every action, so that defenders can later line up their alerts with the test. Halt conditions in the rules of engagement apply throughout, and any unplanned impact is reported at once. The step is complete when every planned technique has been attempted, skipped with a recorded reason, or stopped under a stop condition.
Record which controls fired
Defenders and testers compare the operator log against SIEM alerts, endpoint detections and response actions. For each technique, record whether it was prevented, detected, detected late, or not detected, and name the control or rule responsible. CIS Controls v8.1 Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques testers used, which is the check this step supports. The step closes with a per-technique table that the detection engineering team can act on.
Report gaps and assign fixes
Write up the gaps as findings with the technique, the affected systems, the evidence and a recommended fix such as a new detection rule, a hardening change or a process update. Separate what the plan confirmed from what it did not test, so the board does not read silence as coverage. Agree owners and a retest for each fix, and feed unsuccessful techniques back into the next emulation cycle. The step is done when every gap has an owner, a fix or accepted risk, and a retest date agreed with the sponsor.

Adversary emulation vs red teaming by scenario

Use this scenario when the question is whether your defenders would detect a specific adversary that targets your sector. An emulation plan replays the documented behaviors of that actor, step by step, so results map directly to the techniques your detections should cover. The MITRE Center for Threat-Informed Defense publishes full emulation plans for named actors under the Apache-2.0 license, built from public threat intelligence and annotated with ATT&CK, which gives you a starting point you can review and adapt.

Scope you supply: the actor, the time period of interest and the systems in the attack path, agreed in writing with a rules of engagement document.
Defender involvement: the SOC needs to know the exercise is running, or the team should run it in a purple format so each technique is checked against logs and alerts.
Threat fit: confirm that the chosen actor is relevant to your sector and your threat intelligence, not just the most famous name in the library.
Main risk: a faithful replay can pass or fail on technique coverage while missing the weaknesses that a motivated adversary would find on their own path.
Caldera use: MITRE Caldera, licensed Apache-2.0, can automate parts of a plan, but confirm which abilities it runs and what it needs in your environment.

Before you commission this scenario, confirm with the provider how they map each emulated step to ATT&CK techniques and how results will be recorded for your detection engineering backlog.

What each approach finds and what it misses

Emulation and red teaming answer different questions, so each one surfaces different weaknesses. The cards below show where each approach is strong, where it leaves gaps, and which blind spots both share.

Gaps against documented behavior

An emulation plan replays a named actor's documented techniques, such as those in the MITRE Adversary Emulation Library, step by step. This reliably shows whether your prevention and detection cover the specific behaviors that actor uses, and which ones fire no alert at all. Check that the plan maps to ATT&CK techniques your logging can actually see, and that each step has an expected detection recorded before the exercise starts. A clean run only proves coverage of the steps that were executed.

Creative chaining across steps

Emulation follows a script, so it can miss attack paths that combine low-severity weaknesses into a new route. A red team that chooses its own objective will often find these chains, such as a stolen token that unlocks a misconfigured service account. Ask whether the emulation plan allows operators to deviate from the script, and whether the exercise has a reserved window for open-ended exploration. Without that window, the test answers a narrower question than the board may assume.

Unexpected paths to the objective

An objective-driven red team picks its own route, which can expose access paths nobody modeled, including identity misconfigurations, forgotten administrative interfaces and trust relationships between systems. These findings are often the most useful for leadership because they show what an attacker could reach. The trade-off is repeatability. Two red team runs may take different paths, so results are hard to compare over time or to tie to one threat actor.

Repeatable coverage of one actor

Emulation suits regression testing. After a detection change, you can rerun the same actor's steps and confirm the alerts now fire. A red team cannot offer that same repeatability because its path changes with each engagement. Confirm with your provider whether the plan will be executed as written, how each step is scored, and whether the ATT&CK mapping is recorded in a form you can rerun next year.

Shared blind spots in business logic

Neither approach reliably finds flaws in business logic, such as a discount that stacks incorrectly or an approval step that can be skipped by changing request order. Emulation has no script for logic it was not built around, and red teams may not understand the transaction rules well enough to abuse them. Application security testing and threat modeling are better suited to this gap. Ask your provider how logic flaws will be covered and who owns that work.

Why combining methods makes sense

NIST SP 800-115 states that organizations often combine assessment techniques to reach an in-depth assessment at an acceptable level of risk, and it does not endorse one methodology over another. In practice, teams often run emulation to confirm known actor coverage, then give a red team an open objective to test what the plan missed. Agree on how findings from each exercise will feed the same remediation backlog so the combined result is more than two separate reports.

When compliance frameworks call for each approach

If your organization is a financial entity that its competent authority has designated for threat-led penetration testing, the format is largely set for you. DORA Article 26 requires threat-led penetration testing at least every three years for designated entities. The operational rules sit in Delegated Regulation (EU) 2025/1190, which requires at least three TLPT scenarios, with at most one non-threat-led, and active red team testing of at least 12 weeks with weekly progress reports. A single named-actor emulation plan can supply one scenario, but the regulation expects a set, so plan for more than one threat-based scenario. Confirm with your competent authority whether you are in scope and which scenario set it expects.

Outside the EU rules, NIST SP 800-53 Rev. 5 control CA-8 covers penetration testing, and its enhancement CA-8(2) describes red team exercises as an extension of penetration test objectives. Those exercises test how well your cyber defenses work and may include technology-based and social engineering attacks. CA-8 is selected in the high baseline in SP 800-53B Release 5.2.0, so confirm whether your authorization boundary uses that baseline. CIS Controls Safeguard 18.4 asks you to validate security measures after each test so that detections cover the techniques the testers used. An emulation plan mapped to ATT&CK technique IDs makes that validation easier to trace than a free-form red team debrief.

A voluntary red team or emulation exercise can satisfy an internal board or policy requirement for testing without meeting a regulator's TLPT rules. It does not count as TLPT, however, unless it follows the authority's scenario set, duration, tester requirements and attestation. Before you buy, ask your competent authority three questions: whether you are designated, whether the test must follow the TIBER-EU framework or a national scheme, and whether it accepts an internal exercise as evidence. Get the answers in writing, because they decide whether one test can serve both purposes.

What you receive from each approach

This table sets the outputs of an adversary emulation against those of an objective-driven red team, so you can see what lands on your desk and who acts on it. Read each row as a question to ask a provider before signing a scope, since the exact report format varies by firm and engagement.

Deliverable	Adversary emulation	Red team exercise
Core document	A mapped emulation plan showing each step of the named actor's documented behavior against ATT&CK techniques	An attack narrative describing the path the testers chose toward the agreed objective
Execution record	Execution log by ATT&CK technique, so each planned step has a recorded outcome	Timeline of actions and objective evidence, such as proof of access to an agreed target
Detection results	Which steps were detected, blocked, or missed, mapped to the techniques that were tested	Whether defenders noticed the activity at all, and how they responded, judged against the objective
Improvement output	A list of tuning actions for detections and controls, tied to specific techniques	Joint review with defenders covering what worked, what failed, and what should change
Regulated threat-led tests	TIBER-EU produces no pass or fail result, so the outputs are findings and lessons, not a score	Same principle applies under TIBER-EU, so confirm with your authority what evidence it expects
Ownership of fixes	Each remediation item should name an owner and a retest criterion, confirmed in the written scope	Each remediation item should name an owner and a retest criterion, confirmed in the written scope

What drives cost and effort for each approach

Adversary emulation and red teaming are both paid for mainly in people hours, but the mix differs. Emulation cost grows with the number of plans and techniques, while red team cost grows with the length of the objective-driven engagement and the defender time needed to review it.

Scope and number of scenarios

Each named actor plan or red team objective is a separate body of work to scope, prepare and debrief. A single full emulation plan covering one actor from initial access through exfiltration costs far less than several plans run in parallel. Ask the provider how many scenarios are priced, whether plan changes after kickoff are billed, and whether the quote covers one-time setup or each repeat run. Regulated TLPT work has a minimum of three scenarios, so check whether the quote is built on that floor.

Threat intelligence input

Emulation depends on current, sourced intelligence about how a named actor operates. Teams that build plans from the MITRE Adversary Emulation Library need less analyst time for the base plan but still need tailoring to their own environment. Red teams with a threat-led scope pay for intelligence gathering that may be performed by a separate provider. Ask who produces the intelligence, how often it is refreshed, and whether it is delivered as a written report.

ATT&CK techniques in scope

The number of ATT&CK techniques a plan covers sets the size of the test matrix and the detection checks that follow. ATT&CK v20 lists 15 Enterprise tactics used to plan emulation, so a plan that spans most tactics is a much larger job than one limited to initial access and lateral movement. Ask the provider to list the techniques in scope and to state which are excluded because they are unsafe for production.

Automation level for Caldera

MITRE Caldera automates adversary emulation, so a team that wants repeatable runs will spend more on platform setup, ability development and tuning than on manual execution. A fully manual red team spends more time on hands-on operator work. Caldera is licensed under Apache-2.0, so the software itself adds no license fee, but hosting, integration and maintenance do. Ask whether the quote includes building and documenting custom abilities and who keeps them current.

Defender time for joint review

Both approaches generate detection gaps that defenders must review, and that review consumes internal staff time. Emulation runs often produce a technique-by-technique detection record that is quicker to walk through, while a covert red team produces a narrative that takes longer to reconcile with logs. Budget for SOC analysts, detection engineers and system owners to attend debriefs. Ask whether the quote includes a joint review session and a written detection gap list.

Testing duration

Engagement length is a major cost driver because testers, operators and project management are billed for active time. Threat-led exercises under the EU TLPT rules have a minimum of 12 weeks of active red team testing with weekly progress reports. Emulation of a single plan can be shorter, but the provider should state the active testing window and any blackout periods in writing. Ask what happens if testing is paused for a production freeze and who pays for the idle weeks.

Legal and rules of engagement work

Every engagement needs a written rules of engagement and an authorization letter, and this work is paid up front. NIST SP 800-115 provides a rules of engagement template in Appendix B that many teams adapt. Covert red teams add more legal review because they may involve social engineering, third-party systems or cloud providers. Ask who drafts the rules, who signs the authorization, and whether legal review by your counsel is included or billed separately.

Retest and repeat cycles

Most costs recur only when the program repeats. A one-time emulation proves a point in time, while recurring runs test whether fixes hold and whether detections cover the same techniques after each change. CIS Safeguard 18.4 expects security measures to be validated after each test. Ask whether retests are included in the quote, how many are covered, and whether repeat runs reuse existing plans or require new scoping.

Questions buyers ask before commissioning either approach

Should we buy adversary emulation or red teaming first?

Buy the approach that answers the question your board is asking. If the question is whether a named threat group's documented behaviors would be detected, start with adversary emulation. If the question is whether a covert attacker with a defined objective could reach it by any path, start with a red team. Many teams run a scoped emulation first because it produces a repeatable baseline that a later red team can build on. Both need a written scope, rules of engagement, stop conditions and an agreed definition of what the exercise is meant to show before work starts. DeployOpen plans, implements and runs these exercises as fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work begins, so the first conversation should settle which question to answer.

What does an adversary emulation or red team cost us?

Cost depends on the scope agreed in writing, the threat intelligence the exercise must draw on, the size and complexity of the target environment, and the number of people needed on both sides. The main paid components are planning, threat research, operator time, reporting and the debrief, plus any lab or tooling built for the exercise. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for a breakdown by phase, which activities are one-time, whether retesting or a follow-up emulation is included, and how much internal staff time the quote assumes. Costs recur when you move from a one-off exercise to an annual program or a retainer, which covers ongoing work and is priced separately from the first engagement.

How long does an emulation or red team engagement take?

Duration depends on scope, the number of scenarios, access arrangements and how much time defenders spend on the joint review. No single duration applies to every engagement, so ask each provider for a phased schedule in the written scope. If the exercise is a DORA threat-led test, regulation sets a floor: Commission Delegated Regulation (EU) 2025/1190 requires active red team testing of at least 12 weeks, with at least weekly progress reports. A voluntary emulation of one actor's documented behaviors is bounded by the plan and the detection work around it, so it can run for a shorter period, but confirm that against your scope. Ask for milestones covering preparation, active testing, reporting and the joint review.

What does the work need from our internal team?

Three groups of people make the work productive, and the time they give is often the largest hidden cost. First, a named sponsor with authority to approve the rules of engagement and to stop the exercise if a system or service is at risk. Second, system owners who can confirm backups, change windows, test accounts and the systems that must stay out of scope. Third, detection and response staff who take part in the joint review and turn findings into detection rules and fixes. If the scope includes social engineering or physical access, legal and HR must also sign off on authorization letters before any activity begins. Ask the provider to list these roles and time commitments in the written scope.

Can our own staff run an emulation with MITRE Caldera?

A team with ATT&CK skills and a lab can run a basic emulation with MITRE Caldera, which is licensed under Apache-2.0 and describes itself as a platform built on ATT&CK for automating adversary emulation and assisting manual red teams. The Adversary Emulation Library supplies full emulation plans for named actors, such as APT29 and FIN7, that map to ATT&CK and can guide which behaviors the operators run. The harder work is deploying agents safely, choosing abilities that match a plan, limiting blast radius and interpreting results for detection engineering. Confirm the Caldera version and plugins with the project before deployment, and weigh your team's capacity alongside the license terms. DeployOpen can plan, implement and run emulation work in your environment under a written scope.

Does an emulation or red team satisfy DORA TLPT requirements?

Not by default. DORA Article 26 requires threat-led penetration testing at least every 3 years for entities that their competent authority identifies, and Commission Delegated Regulation (EU) 2025/1190 sets rules for the test itself. Those rules include at least three TLPT scenarios, with at most one that is non-threat-led, active testing of at least 12 weeks and tester requirements. Confirm with your competent authority whether your entity is in scope, what it accepts as a TLPT, and who may perform the test. A voluntary emulation or red team can still strengthen your program, but record it as voluntary unless the authority has accepted it as meeting the TLPT requirement.

Does either approach satisfy a CIS Control 18 requirement?

Either approach can support CIS Control 18 work, but neither satisfies it alone. Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, and Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques the testers used. An emulation built on ATT&CK techniques maps well to the validation step. A red team with a defined objective can also cover the penetration test requirement if its written scope includes the external and internal tests the safeguards describe. Check the current CIS Controls text and confirm in the scope which safeguards the work covers and what evidence each produces. DeployOpen prepares controls and evidence for assessments but does not issue audit reports or certifications.

Which accreditation should a testing provider show before we sign?

Ask for evidence of CREST accreditation for the company and CREST certification for the individuals who will run the work, then check both against CREST's records before signing. CREST (International), a UK not-for-profit company, accredits member companies and certifies individuals in disciplines including security testing, red teaming and threat intelligence. The Bank of England names CREST as the accreditation and certification body for CBEST, so the check matters most for regulated UK firms, though it is a useful test anywhere. Ask each provider for certificate references, the disciplines covered, expiry dates and the named testers. Ask DeployOpen, like any shortlisted provider, to state in the written scope which accreditations apply to the people doing the work.

How DeployOpen scopes, delivers and supports adversary emulation and red teaming

DeployOpen plans, runs and documents adversary emulation and red team work inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

The written scope names the objective, the target systems and the rules of engagement before any testing begins.
We agree whether the exercise follows a named actor's documented behaviors or an open objective chosen by the team.
Scope records which ATT&CK techniques are in play, what is out of bounds and who approves the exercise.
Quotes follow from the written scope, so the scope document is where you check what the price covers.

How we build

We prepare the emulation plan or red team scenario against your environment and confirm it with your team.
Automation, where used, runs on your own systems, and we document each step that is automated and each that is manual.
Testing is carried out against the agreed scope with controls in place for stopping, escalating and cleaning up.
We record the techniques attempted, the detections that fired and the gaps observed during the exercise.

How we hand over

Deliverables include a written report mapping observed behaviors to ATT&CK techniques and the scope used.
Findings are separated into detection gaps, control weaknesses and process issues so each has a clear owner.
We walk your security and leadership teams through the results and the evidence behind each finding.
Confirm with us in advance what evidence format your auditors or regulators will need from the exercise.

How we support

Ongoing support, repeat exercises and continuous testing are available as retainers agreed separately from the initial scope.
Retesting after fixes confirms that detections now cover the techniques the team used.
DeployOpen prepares systems, controls and evidence for assessments. Independent auditors and certification bodies issue any formal reports or attestations.
Ask us to confirm how a retainer changes scope, cadence and reporting before you sign.