What is red teaming in cybersecurity?

A red team engagement emulates a realistic attacker pursuing a specific goal -- reaching customer payment data, say, or pushing code to production -- usually without the defending team knowing it is underway. The point is not to list every vulnerability but to find out whether the organisation would notice, investigate and contain a real intrusion, and how far the attacker gets before it does.

What is the difference between a red team and a penetration test?

A penetration test tries to find as many exploitable weaknesses as possible in a defined scope, usually with the defenders aware of it, and reports a list of findings. A red team pursues one or a few objectives by whatever realistic path works, usually covertly, and reports a timeline of what the attacker did and where the defenders did or did not see it. A pen test measures the system; a red team measures detection and response.

How does red teaming relate to threat modeling?

A threat model works out, on paper and at design time, which attacker goals matter and which paths lead to them. A red team picks one of those goals and tries to reach it against the live organisation. The model supplies realistic objectives and attack paths for the exercise; the exercise tells you which of the model's mitigations -- especially detective ones like monitoring and alerting -- actually work.

What is purple teaming?

Purple teaming is a collaborative format where the attacking (red) and defending (blue) teams work together openly: the red team executes a technique, the blue team checks whether it was logged and alerted on, and both tune detections on the spot. It gives up the realism of a covert exercise in exchange for much faster improvement, and is often the better first step for teams that have never been red-teamed.

When is an organisation ready for a red team exercise?

Generally once it has fixed the findings from regular penetration testing and has someone who is actually watching for and responding to alerts. Without a functioning detection and response capability there is nothing for a red team to test, and the exercise mostly rediscovers what a cheaper pen test would have found.

What Is Red Teaming?

Most security testing asks whether a system can be broken into. Red teaming asks a different question: if someone were breaking in right now, would anyone notice? A red team plays a realistic attacker, chooses a goal that would genuinely hurt the organisation, and tries to reach it quietly, the way a real intrusion would unfold. What it measures is less the systems themselves than the people and processes that are supposed to catch an attack in progress.

Quick definition: Red teaming is an objective-driven, usually covert exercise in which a team emulates a realistic adversary from first foothold to final goal. A pen test asks "what's exploitable here?" and a threat model asks "what could go wrong with this design?" A red team asks "would we detect and stop this attack, and how far would it get first?"

Where the term comes from

The name is borrowed from military wargaming, where a "red" force plays the opponent so that the "blue" force can test its plans against someone actively trying to defeat them. The idea travelled well beyond the military: intelligence analysts, physical security teams and, more recently, AI safety researchers all use "red teaming" for some version of deliberately arguing the other side. That breadth is why the term gets used loosely.

In security, the colours stuck. The red team attacks. The blue team defends: the security operations centre, incident responders, whoever reads the alerts. A small white team (sometimes called the control group) knows the exercise is happening, sets the rules and can call it off if something real breaks. And purple teaming, covered below, is what happens when red and blue sit in the same room.

Red team vs. pen test vs. threat model

The threat modeling vs. penetration testing comparison already covers the first two in depth. Red teaming is the third leg of that triangle, and it differs from both on almost every axis, not just in degree:

	Threat model	Penetration test	Red team
Question	What could go wrong with this design?	What's exploitable in this scope?	Would we detect and stop a real attacker?
What's being tested	The architecture, on paper	The running system	The organisation: people, process and tooling together
Shape	Broad: every component and flow on the diagram	Broad within scope: find as much as possible	Narrow and deep: one or a few objectives, any realistic path
Defenders know?	They're the ones doing it	Usually yes	Usually no; only the white team does
Stealth	Not applicable	Rarely matters; noisy scanning is fine	Central; getting caught is a result, not a failure
Output	Design decisions and a risk register	A list of verified findings	An attack timeline marked with where defenders did and didn't see it
When	Design time, and on every significant change	Periodically, or before a major release	Once the basics are in place, typically far less often

The row that matters most is "what's being tested." A pen test that finds nothing tells you the scoped systems held up. A red team where the attacker reached the goal unseen can still have found zero new vulnerabilities, if it got there with a phished password and a legitimately over-permissioned account. That outcome is a serious finding even though there's nothing to patch, because what failed was detection.

What an engagement actually looks like

Details vary by provider and by regulator, but most engagements follow the same broad arc:

Objectives, not scope. Instead of "test these twelve hosts," the brief is a goal, sometimes called a flag or crown jewel: read a production customer record, push a commit to the deploy pipeline, initiate a payment. How the team gets there is mostly up to them, within the rules of engagement.
A realistic adversary. Good engagements emulate a specific kind of threat actor rather than "a hacker": the groups that plausibly target your sector, using their known TTPs. Teams often map the plan and the report to MITRE ATT&CK technique IDs so defenders can check their detections technique by technique.
Rules of engagement. What's off-limits (often production databases, certain people, physical premises, denial of service), how the red team proves it reached a goal without causing harm, and how the white team stops the exercise if the blue team escalates to a real incident response with real consequences.
The campaign. Initial access (phishing, an exposed service, a stolen credential, sometimes walking in the door), then establishing a foothold, escalating privileges and moving towards the objective, all paced to stay below the defenders' radar. Engagements commonly run for weeks rather than days, because patience is part of what's being emulated.
The report. A timeline of every step, each marked with whether it was prevented, logged, alerted on, investigated or missed entirely. The useful output is rarely "we got in"; it's where the chain could have been broken and wasn't, which is the same idea as interrupting the Cyber Kill Chain at any stage.

A common variant is assumed breach: rather than spending a third of the engagement on getting in, the white team hands the red team a foothold, such as a standard employee laptop or a low-privilege account, and the exercise starts from there. It skips the part every organisation already assumes will eventually succeed and spends the time on what happens next. It's also the most practical way to test insider scenarios, since the starting point is effectively an insider's access.

Purple teaming, tabletops and "AI red teaming"

Three neighbouring practices get folded under the same name, and it helps to keep them apart:

Purple teaming drops the secrecy. The red team runs a technique, the blue team checks whether it showed up in logs and alerts, and both fix the gap on the spot before moving to the next one. You lose the realism of a covert campaign and gain a much faster feedback loop. For a team that has never been red-teamed, it's often the better first step.
Tabletop exercises red-team the response plan rather than the systems: a facilitator walks the incident team through a scenario on paper and watches for decisions nobody owns. Cheap, and useful well before you're ready for anything live.
AI red teaming usually means adversarially probing a model's behaviour (jailbreaks, prompt injection, harmful outputs) rather than emulating an intruder against an organisation. It shares the mindset but not the method. If you're building on LLMs, the attack surface it probes is covered in threat modeling AI agents and LLMs.

How red teaming and threat modeling feed each other

The two sit at opposite ends of the lifecycle, one before anything is built and one against the live organisation, which makes them unusually good partners.

The threat model supplies the objectives. Picking red team goals is hard without one: "get domain admin" is the traditional default, and it may have little to do with what would actually hurt your business. A threat model has already identified which assets matter, which trust boundaries protect them, and which paths lead there. The root nodes of your attack trees are, almost by definition, a ready-made list of red team objectives, and their branches are candidate routes.

The red team tests the mitigations a model can't verify. Look at the mitigations column of most risk registers and you'll find a lot of "logged and monitored," "alert on anomalous access," "SOC investigates." Those are detective controls, and on paper they're indistinguishable from controls that work. Nobody finds out whether the alert fires, whether anyone reads it, or whether it gets closed as a false positive until an attack happens. A red team is the controlled way to learn that before a real attacker teaches it to you. The same goes for the repudiation row of STRIDE: the threat model says the logs exist, and the red team checks whether they're good enough to reconstruct what happened.

The findings flow back into the model. Every undetected step in the red team's timeline is a risk the model either missed or rated too low. Mapping the report back onto your data flow diagram shows where the attacker crossed boundaries you'd assumed were well watched, and the fixes become new entries in the register with owners and dates, not a slide in a debrief deck.

When you're ready for one (and when you aren't)

A red team is the most expensive and most realistic of the three, and it's easy to buy too early. It earns its cost when:

Pen test findings are being fixed, not just filed. If routine testing still turns up easy wins, a red team will walk through the same gaps and you'll pay a premium to relearn them.
Someone is actually watching. Red teaming tests detection and response. With no SOC, managed detection service or on-call process that reads alerts, there's nothing for it to measure; start with tabletops and purple-team sessions instead.
You know what you're protecting. Without a clear idea of your critical assets, which is exactly what a threat model produces, the objectives end up generic and so do the findings.
Leadership can hear the result. A red team that reaches its goal is a successful exercise, not a failed security programme. If the outcome will be used to blame the blue team, people will learn to game it instead.

Some organisations don't get to choose. Financial-sector regulators in several jurisdictions run intelligence-led red-teaming schemes, such as CBEST in the UK and TIBER-EU in Europe, and the EU's Digital Operational Resilience Act (DORA) requires threat-led penetration testing, which is red teaming in all but name, for financial entities that fall within its scope. Who's in scope, how often, and under which methodology are set by the regulation and the relevant authority, so check the current text rather than relying on a summary, including this one.

Common mistakes

Calling a pen test a red team. If the defenders know it's happening and the brief is a list of hosts, it's a pen test, and a perfectly good one. Relabelling it doesn't test detection.
Measuring success by "did they get in." They nearly always get in eventually. The valuable data is how long it took to be noticed, at which step, and what happened after.
Generic objectives. "Domain admin" proves something, but often not the thing your business is most worried about. Objectives should come from your own threat model.
Treating it as a pass/fail audit of the blue team. The blue team should be the main beneficiary of the exercise. A replay session where both sides walk through the timeline together is usually worth more than the report.
Fixing the path rather than the class. Closing the specific misconfiguration the red team used leaves every similar path open. The question to ask afterwards is why that whole category of step went unseen.

None of the three practices replaces the others. A threat model works out what could go wrong before anything exists, a pen test proves what's exploitable in what was built, and a red team finds out whether the organisation would notice when it matters. Each one is blind where the others can see, so the useful question is never which to pick but which one your programme is missing right now.

Regulated sectors increasingly mandate adversary-emulation testing alongside design-time risk analysis. See the industry threat modeling guides for what applies in fintech, healthcare, critical infrastructure and more.