What is a red team engagement?

Key takeaways

• A red team engagement is objective-driven, not asset-driven. The team is told what to accomplish, not what to attack.
• It exercises the full attack surface by default: network, application, identity, physical access, and people.
• The defending team is usually unaware. That is what produces realistic detection and response data.
• Output includes a written report, evidence package, a debrief with the blue team, and (in mature programs) a purple-team walk-through.
• A red team engagement is an event, not a state. To stay accurate between engagements, pair it with continuous adversarial simulation.

How is a red team engagement different from a penetration test?

A penetration test answers a narrow question: which of these specific systems are exploitable, given this much time. The scope is asset-based: a defined IP range, a specific web application, a domain controller. The tester writes a report listing vulnerabilities, with severity scores and reproduction steps. Most pen test engagements run one to three weeks, end with a report, and do not test detection or response.

A red team engagement answers a different question: if a motivated attacker tried to accomplish X, would they succeed, and how would the organization find out. The scope is objective-based: gain access to the engineering network, exfiltrate a sample of CAD files, route a wire transfer, plant a payload on a PLC engineering workstation. Anything not explicitly out of scope is on the table, including social engineering, physical access, and abuse of legitimate workflow.

Four operational differences follow:

1. The asset list is the start, not the scope. A red team chooses paths the defender did not anticipate, including paths that involve vendors, contractors, personal devices, or the front gate.
2. Detection and response are in scope. Half the value of a red team is data on what the blue team noticed, when, and what it did with that signal. A pen test does not measure this.
3. People are in scope by default. Phishing, vishing, pretexting, and physical entry are first-class techniques in a red team, not an optional add-on.
4. The deliverable is a story, not a list. A red team report narrates the attack chain in the order it actually happened, with timestamps, decisions, and the controls that did or did not fire. A vulnerability list is part of the appendix.

For the closely related categories, see What is breach and attack simulation (BAS)?, What is continuous penetration testing?, What is assumed-breach testing?, and What is purple teaming?.

The phases of a red team engagement

A typical engagement runs through six phases. The order is roughly sequential, but phases overlap once the engagement is underway.

1. Scoping and rules of engagement. The executive sponsor and the red team agree on objectives (what success looks like), permitted techniques (and explicitly prohibited ones), in-scope and out-of-scope assets, target population for social engineering, hours of operation, escalation contacts, and a get-out-of-jail letter for physical components. This phase ends with a signed document and a small list of "trusted agents" inside the client who know the engagement is happening.

2. Reconnaissance. The team builds an attacker view of the organization. Sources include public records, SEC filings, LinkedIn, conference speaker pages, podcast appearances, code repositories, breach corpora, and (for physical scopes) site observation and badge harvesting at conferences or trade shows. See What is OSINT (open-source intelligence)? for the underlying mechanics.

3. Resource development and weaponization. Phishing infrastructure stood up. Lure content drafted to match the reconnaissance profile. Vishing scripts written. Physical entry pretexts designed for the specific facility. Where appropriate, custom tooling built or off-the-shelf tooling adapted.

4. Initial access. The team executes the first foothold attempt. This is often spear phishing against a named target (What is spear phishing?), but it can be a vishing call to the help desk (What is vishing?), an OAuth consent grant, a USB drop, or a physical entry during a vendor delivery window.

5. Post-exploitation. Once inside, the team moves toward the engagement objectives: lateral movement, privilege escalation, credential harvesting, data discovery, and (where authorized) interaction with operational systems. Each step is logged against MITRE ATT&CK techniques for downstream analysis.

6. Reporting and debrief. The engagement ends with a written report, an executive presentation, and a technical debrief with the blue team (or a purple team session). The report describes the chain of access and decisions, the controls that fired or failed, and prioritized remediation.

Why mid-market manufacturers benefit from red teaming

For organizations between fifty and five hundred employees, red teaming closes a specific gap: the gap between "we have controls" and "the controls work against someone who actually wants in".

Mid-market manufacturers usually have a defensible posture on paper. Endpoint protection is deployed. MFA is enabled on email and remote access. There is some form of network segmentation between IT and OT. The annual penetration test report shows mostly low and medium findings. Compliance against NIST CSF 2.0, NIST SP 800-171, or CMMC 2.0 is in progress or complete.

The gap is that none of this evidence shows what happens when a focused attacker chains together a phone call, an OAuth grant, and an unattended badge to walk a wire transfer out the door. A red team engagement produces that evidence directly. It also produces three artifacts the organization cannot generate on its own:

• A measurement of detection and response under pressure, against techniques the blue team has not seen before.
• A small set of high-impact findings traced from root cause to business outcome (instead of a CVE list).
• A documented dataset that becomes a baseline for continuous adversarial simulation and (eventually) cyber insurance underwriting evidence.

For organizations whose primary security investment to date has been compliance, a red team is often the first time the organization sees an outside attacker view of itself. The findings reframe the budget conversation.

Examples of red team objectives and outcomes

A red team is scoped to objectives. Examples of objectives ARG has seen at mid-market manufacturers, and the kinds of outcomes that follow:

• Initiate an unauthorized wire transfer. Objective: route a payment to an attacker-controlled account through normal AP workflow. Outcome on the first attempt: vendor-invoice manipulation with a callback to a spoofed number routed the payment in roughly forty-eight hours. Detection happened only when the real vendor followed up about non-payment.
• Exfiltrate engineering files for a specific product line. Objective: obtain CAD or BoM files for a named product. Outcome: spear phishing against an engineering manager, followed by lateral movement to a file server that engineering and IT both had access to. Time to objective: nine business days.
• Gain interactive access to a SCADA HMI. Objective: reach an operator console for a specific production line. Outcome: physical entry as a contracted electrical inspector during a known audit week, with engineering workstation access while alone in the control room. See What is SCADA security?.
• Trigger a tabletop-grade incident. Objective: cause the security and operations leadership to convene an incident response decision in real time. Outcome: simulated ransomware staging detected (or not detected) by EDR; the team then escalated visibly to test the incident response plan.
• Subvert a vendor change. Objective: alter a vendor instruction in transit (delivery address, banking details, software update). Outcome: a forged email from a vendor account, sent from a similar domain, accepted without secondary verification.

Each objective produces a story: how the team got in, where it went, what it touched, what fired, and what did not. That story is the deliverable.

What deliverables come out of a red team engagement

A red team engagement of any seriousness produces five artifacts:

1. Executive narrative. A short document, written for non-specialists, describing the attack chain, the business outcomes that were achievable, and the most material remediation.
2. Technical report. The detailed account: timestamps, techniques mapped to MITRE ATT&CK, screenshots, logs, and reproduction steps where useful.
3. Evidence package. Raw artifacts: phishing infrastructure logs, vishing recordings (where consent permits), physical entry photos, sample exfiltrated data with hashes, OSINT package against named targets.
4. Detection-and-response analysis. What the blue team saw, when, what they did, and what they missed. Time-to-detection, escalation path accuracy, and decision quality under pressure.
5. Prioritized remediation. Not a CVE list. A small set of changes (process, configuration, procurement, training) that close the most material chains, in order of expected impact.

The deliverable should be usable by three audiences: the owner or CTO who pays for it, the IT lead who has to act on it, and the eventual cyber insurance underwriter who will read it as part of a renewal package. See What is cyber insurance underwriting?.

Best practices for scoping a red team engagement

A red team is high-leverage, but it is also operationally sensitive. Scope determines whether it produces real findings or theater.

1. Pick objectives that map to business loss. Wire fraud, IP exfiltration, production downtime, customer-data exposure. If the objective is "get domain admin", the engagement will succeed and tell you nothing useful.
2. Permit the full attack surface unless there is a specific reason not to. Excluding social engineering or physical access narrows the engagement to a network test. Real attackers do not have those constraints.
3. Define out-of-scope clearly. Production OT/ICS interaction without paired safety, denial-of-service, destructive payloads, attacks on personal devices outside agreed targets. Everything else is on the table.
4. Keep the trusted-agent list small. Two or three people, including at least one executive sponsor and one technical contact. Larger lists leak; leaks invalidate detection data.
5. Plan for the get-out-of-jail moment. A signed authorization letter, a 24-hour contact number, and a documented path for halting the engagement. This protects the engagement and the testers.
6. Decide on detection visibility up front. Some engagements run "no-knowledge" for the blue team. Some are run as paired purple-team exercises. Some are run no-knowledge first, then re-run as purple-team after the initial debrief. Each produces different data; pick deliberately.
7. Schedule the debrief before the engagement starts. Putting it on the calendar in advance is the difference between a deck that sits and a deck that drives change.
8. Treat the report as evidence. Findings should be reproducible. Photos, logs, timestamps, named targets. The report has to hold up under hostile reading: an underwriter, a board member, a regulator.

Red team engagement FAQs

How long does a red team engagement take?

Most red team engagements run four to twelve weeks end to end. Reconnaissance and planning take one to three weeks, active execution two to six weeks, and reporting one to three weeks. Engagements with a physical component or multi-facility scope sit at the longer end.

Should the internal IT team be told a red team is happening?

Usually only a small group of executive sponsors knows. The defending team (blue team) being unaware is the whole point: it produces realistic detection and response data. A short list of trusted contacts holds the rules of engagement, the get-out-of-jail authorization, and the contact path if something goes wrong.

What is the difference between red team, blue team, and purple team?

The red team attacks. The blue team defends. A purple team is the structured collaboration between the two, where attackers share technique in real time so defenders can build detections during the engagement rather than afterward. See What is purple teaming?.

Can a red team engagement disrupt operations?

A well-scoped engagement should not. Rules of engagement explicitly exclude denial-of-service, destructive payloads, and any technique against production OT/ICS systems without paired safety controls. The risk is real, which is why scoping, signed authorization, and a documented escalation path are non-negotiable.

How ARG conducts physical-plus-digital red team engagements

ARG runs red team engagements as the on-site anchor of a continuous adversarial simulation program. The structural choice is to integrate the physical and digital sides rather than treat them as separate engagements.

The on-site component is delivered by David Ashby, drawing on a manufacturing background at Quality Electrical Systems. Physical reconnaissance, gate and shift observation, badge work (What is badge cloning?), pretext entries, and on-floor social engineering are conducted during the on-site week or weeks. The operator is credible to plant staff because the operator has worked on a plant floor.

The digital component is built and operated by James Wall. OSINT collection, lure infrastructure, LLM-personalized phishing content, vishing scripting with voice cloning support, and post-exploitation tooling run on infrastructure ARG owns and controls. Findings are mapped to MITRE ATT&CK techniques and logged against the engagement timeline.

The deliverable is one engagement, one narrative, one set of prioritized remediation. The continuous simulation layer that follows the engagement then re-tests the remediated controls on an adaptive schedule, so that findings either stay closed or surface again in the monthly packet.

For organizations evaluating a first red team, ARG's founding client program pairs the engagement with the continuous layer at locked pricing for two to three years.

Apply as a founding client or see how the engagement works for the full delivery cycle.