Red Team vs Blue Team vs Purple Team

A red team attacks, a blue team defends, and a purple team is the two working side by side to turn attacks into better detections. The colors name roles in a security exercise, not job titles. The red team emulates an adversary. The blue team runs detection and response. The white team referees and keeps the exercise safe and lawful. Purple teaming is the collaboration itself: a red operator runs a known technique while the blue team watches the telemetry, and together they build or fix the detection on the spot. This guide sets out what each role does, how a purple team exercise runs step by step, the tools involved, the metrics that matter, and when to run a red team versus a purple team.

The four roles, side by side

Three of these roles have formal definitions in the US government glossary, and the fourth is a way of working rather than a standing team. Reading them together is the fastest way to see how the colors fit. The red team emulates the adversary, the blue team defends, the white team referees, and purple is red and blue in one room.

The government definitions are precise. A blue team is "the group responsible for defending an enterprise's use of information systems by maintaining its security posture," per the NIST glossary. A red team is an authorized group that emulates an adversary against that posture. The white team enforces the rules and referees. We cover the red team side in depth in what is red teaming.

Why purple is a function, not a standing team

There is no NIST definition of a purple team, and that absence is the point. Red, blue, and white are defined roles; purple describes red and blue collaborating, with the hand-off collapsed so detection improves in the same session as the attack. Some organizations stand up a small purple team to run the cadence, but the value comes from the working mode, not the headcount. You can run purple teaming with an external red team and your own blue team, with two internal groups, or with a managed detection provider on the blue side. What makes it purple is that the attacker and the defender see each other's work in real time and fix the gap together, rather than trading a report weeks later.

How a purple team exercise runs

A purple team exercise is a short, repeating loop that takes one attacker technique from idea to a working detection, then measures the result. The discipline is in running it the same way every time so the coverage numbers mean something across cycles. Six steps make up the loop.

First, select the technique. Threat intelligence points to the tactics and techniques a relevant adversary uses, and the team picks one, named by its MITRE ATT&CK identifier so everyone is talking about the same behavior. Second, execute it. The red operator runs the technique in scope, often with a small, repeatable test rather than a full intrusion. Third, observe. The blue team checks the SIEM and EDR for the telemetry the technique should have produced, and records whether it was logged at all. Fourth, tune. If the activity was invisible or did not alert, the red and blue teams write or fix the detection together, then and there. Fifth, retest. The red operator runs the same technique again to confirm the new detection fires. Sixth, record. The result goes against the technique in a tracking tool, so the team can show coverage rising over time.

That loop is why purple teaming compounds. Each cycle leaves behind a tested detection and a measured result, so the program builds a coverage map rather than a pile of one-off findings.

A worked example: one technique through the loop

Kerberoasting shows the loop in concrete terms, and it is a technique most Active Directory environments are exposed to. In ATT&CK it is T1558.003, under the Credential Access tactic. An attacker who holds any domain account requests Kerberos service tickets for accounts that run services, then cracks those tickets offline to recover the service account passwords, often reaching high privilege without touching a domain controller directly.

Run through the loop, it goes like this. The team selects T1558.003 because threat intelligence shows the adversary they care about uses it. The red operator requests service tickets for every service account in scope, a single noisy action the blue team should see. The blue team checks the SIEM for Windows event 4769, the Kerberos service ticket request, and finds the events are logged but no rule alerts on the pattern of one account requesting many tickets. They write that rule together, with a threshold that fires on bulk requests while staying quiet on normal traffic, which keeps alert fidelity high. The red operator reruns the request, the new rule fires, and the team records T1558.003 as covered, with the time from action to alert captured. One cycle has turned a blind spot into a tested detection, and the same pattern repeats for the next technique.

The tools, described accurately

The tooling splits cleanly into offense, a shared language, a tracking layer, and the blue team's stack. Naming the real tools and what they do is useful, because vendor copy tends to blur them.

The shared ATT&CK language is what lets a red operator, a blue analyst, and a tracking tool all mean the same thing by a technique. Atomic Red Team and MITRE ATT&CK supply the tests and the taxonomy. Atomic Red Team and MITRE Caldera run the techniques, and VECTR records the results so coverage is a number you can track.

The metrics that make it real

A purple team program lives or dies on four measurements, because without them the exercise is theater. The first is detection coverage by ATT&CK technique: the share of tested techniques that produce an alert, read technique by technique rather than as a single percentage. The second is time to detect: how long from the action to the alert. The third is time to respond: how long from the alert to a contained incident. The fourth is alert fidelity: how many of the alerts are true positives worth an analyst's time, because a detection that fires on everything is close to useless. Tracked across cycles, these numbers show whether the program is buying real defense. The one worth watching hardest is coverage by technique, because it tells you precisely which adversary behaviors you would miss.

When should you run a red team instead of a purple team?

Run a red team when you want the unvarnished truth about whether you would be caught, and a purple team when you want to build detection coverage fast. The two answer different needs. A red team runs under secrecy, so the detection timeline it produces is honest, and that is the right tool when leadership asks whether the security operations function would stop a determined attacker. A purple team runs in the open, with both sides collaborating, so it is the right tool when you already know there are gaps and you want to close them technique by technique. Most mature programs sequence the two: a red team measures where detection stands, and purple teaming then turns each missed technique into a tested detection. If your team is not ready to be tested under secrecy yet, a tabletop exercise rehearses the response first. The sequencing choice overlaps with the penetration test decision, which we lay out in red team versus penetration testing.

How purple teaming turns a red team report into durable detections

The highest return on a red team comes after the report, when purple teaming converts the narrative into detections that stay. A red team report carries an ATT&CK coverage map showing which techniques the operators used and which of your controls caught them. Purple teaming walks that map technique by technique: replay the technique with the blue team watching, confirm whether current tooling sees it, write or tune the detection where it does not, and retest until it fires. The metric that tracks this across cycles is the self-detection rate, the share of offensive activity your own tooling catches first. It should climb every cycle, and it predicts real incident outcomes better than any finding count. Without this follow-through, a red team is an expensive way to feel bad once a year.

Where in-house teams and MDR or SOC providers fit

Who owns the blue side changes how you run purple teaming, but not whether you can. If you run your own security operations center, your detection engineers own the rules, and a purple team session ends with them committing a new detection to your own stack. If you use a managed detection and response provider or a co-managed SOC, the provider owns or shares the detection content, so you coordinate the exercise with them and agree who writes the rule. In a co-managed model the detections live in your tenant, where you can read and keep them, which makes purple teaming build a durable asset rather than a dependency. The ownership differences between these models are the subject of MDR versus SOC as a service, and our SOC as a service runs the blue side in the client's own tenant for exactly this reason.

Frequently asked questions

What is the difference between red, blue, and purple teams? The red team emulates an attacker and tries to reach an objective. The blue team defends by detecting, investigating, and responding. Purple is the two working together, with a red operator running a technique while the blue team watches the telemetry and tunes the detection on the spot. A white team referees the exercise and keeps it safe and lawful.

What is a purple team exercise? A purple team exercise is a short, repeating loop: select an attacker technique by its MITRE ATT&CK identifier, have the red operator execute it, check whether the blue team's tooling logged and alerted on it, tune or write the detection together, retest to confirm it fires, and record the result. Each cycle leaves behind a tested detection and a measured coverage number.

Is a purple team a permanent team? Usually not. NIST defines red, blue, and white teams but not a purple team, because purple describes a way of working rather than a standing group. Some organizations assign a small team to run the cadence, but you can run purple teaming with an external red team, two internal groups, or a managed detection provider on the blue side. What makes it purple is real-time collaboration.

What tools do purple teams use? Purple teams use MITRE ATT&CK as the shared language, Atomic Red Team and MITRE Caldera to run attacker techniques, and VECTR to track and score the results and measure detection coverage. On the defending side they work in the SIEM, EDR, and SOAR that make up the blue team's detection stack. ATT&CK ties them together so every tool means the same thing by a technique.

When should you run a red team instead of a purple team? Run a red team when you want an honest measure of whether you would detect a determined attacker, because it runs under secrecy. Run a purple team when you want to build detection coverage fast, because it runs in the open with both sides collaborating. Mature programs do both: a red team measures where detection stands, and purple teaming closes each gap technique by technique.

What metrics does a purple team track? Four: detection coverage by ATT&CK technique, time to detect, time to respond, and alert fidelity. Coverage by technique matters most, because it shows exactly which adversary behaviors would slip past your tooling. Tracked across cycles, the self-detection rate, the share of offensive activity your own tools catch first, tells you whether the program is improving real defense.

If you are planning a purple team program or a red team to seed it, our offensive security team runs both under one method, so the detections you build outlast the engagement.