Red teaming is an authorized simulation of a real adversary that runs against an organization's people, processes and technology at once, aiming at a specific objective without being detected. Success is measured by what the attackers reach and by what the defenders notice, not by how many vulnerabilities the exercise turns up.
In Fluid Attacks' State of Attacks 2026 report, which covers security testing performed between January 1 and December 31, 2025, 87% of critical-severity vulnerabilities were identified through manual review rather than by automated tools. Those are the flaws an adversary chains into an attack path, and they are the ones a scanner is least likely to surface.
This page explains the discipline: what red teaming is, how an exercise runs, the frameworks that structure it, how it differs from penetration testing, and what to demand from a provider. It also states Fluid Attacks' position plainly.
What is red teaming?
Red teaming is a goal-driven adversary simulation. A team of offensive specialists, authorized in writing and usually unknown to the defenders, picks a concrete objective — domain administrator privileges, a payment system, a named customer database — and works toward it with whatever mix of technical exploitation, social engineering and physical access the rules of engagement allow.
Stealth is the defining constraint of red teaming, and it is what separates it from every other assessment. If the defenders know the attack is coming, they behave differently, and the exercise stops measuring the thing it exists to measure. Rafael Alvarez, CTO and co-founder of Fluid Attacks, put the principle bluntly in a post on attacking without announcing:
"It's absurd that, in these attacks, red team members report progress or request permissions from blue team members…"
The scope is the whole organization, not a system. That is why red teaming reaches employees, suppliers, badge readers and help desks, and why it ends in a narrative — how an attacker got from outside to the objective — rather than in a list of findings.
Three things it is not:
Not a longer penetration test: a pentest tries to find as many flaws as possible inside a defined boundary. A red teaming engagement stops as soon as it has one chain that works.
Not a vulnerability assessment: severity scores describe flaws in isolation. Red teaming describes what happens when several of them are used together.
Not breach and attack simulation: BAS replays known techniques automatically and continuously. Red teaming depends on people improvising against a live target.
Why is red teaming important?
Red teaming is important because it tests the two capabilities no scan can evaluate: whether defenders detect an intrusion while it is happening, and whether the organization's response contains it. Everything else an assessment measures is a precondition for those two.
Detection is a claim until someone tests it
An EDR deployment, a SIEM correlation rule and an incident response runbook are all assertions about what would happen during an attack. They stay assertions until an adversary moves through the environment and someone checks what fired, who saw it, and how long it took to act.
That measurement is the product of red teaming, and it is why Alvarez argues the defenders should be left guessing. If they cannot tell a simulated attacker from a real one, he writes, the blue team "will always be in a state of alert and respond according to defined procedures". A team on permanent alert is the point, not a side effect.
The way in is rarely the one you defended
Two breaches make the case. The 2013 Target intrusion is the textbook supplier-to-core attack path, and the U.S. Senate Commerce Committee staff report of March 2014 analyzed it as a kill chain, documenting the points where the attack could have been stopped. The attackers are widely documented to have entered through a third-party vendor's stolen credentials before reaching payment systems — a path no assessment scoped to a single application would find.
In 2021, Colonial Pipeline's CEO told the U.S. Senate Committee on Homeland Security and Governmental Affairs that the attackers "exploited a legacy virtual private network (VPN) profile that was not intended to be in use" (written testimony, June 8, 2021). CISA's advisory on DarkSide ransomware maps the techniques used afterward to MITRE ATT&CK. No scanner flags a forgotten VPN profile, because it functions exactly as designed. Red teaming starts from the attacker's question, not the tool's, and treats that profile as what it is: an unguarded door.
Weak authentication is where the chains start
This is not anecdotal. In Fluid Attacks' State of Attacks 2026 report, the vulnerability type accounting for the largest share of total risk exposure was authentication mechanism absence or evasion, at 19.1%. Authentication is both the most valuable control for an adversary to defeat and the one organizations most often assume is solved — which is why a red teaming engagement usually goes after it first.
Red teaming and Fluid Attacks
Fluid Attacks does not offer red teaming
Fluid Attacks does not sell red teaming, and does not run red team engagements. Its offering is continuous application security testing across eleven techniques: SAST, AI SAST, DAST, SCA, CSPM, MAST, Secret Scanning, Container Scanning, Secure Code Review, Pentesting as a Service (PTaaS) and Reverse Engineering. None of the eleven is an adversary simulation run against defenders who were never told.
The subject is not foreign. Fluid Attacks' pentesters hold certifications built specifically for this discipline — OSEP, CRTP, CRTM, Red Team Operator, Active Directory Red Team Specialist, AWS and Azure Red Team Expert — and the 59 tools they use are published openly, among them BloodHound, CrackMapExec, Rubeus, mimikatz and Covenant. The working knowledge of red teaming is in the building. The engagement is not on the price list.
What Fluid Attacks does instead, and why
The argument for continuous testing over periodic exercises is about what expires. A point-in-time assessment describes a system that no longer exists the moment the next commit lands, and the gap widens with every deployment.
The numbers behind that position are specific. In Fluid Attacks' benchmark of 36 third-party AppSec tools run against a target of evaluation containing 1,201 vulnerabilities across 105 CWE categories, a Fluid Attacks pentester working for 49 days found 1,076 of them — 89.6% recall at 100% precision. The best automated result in the same test, from Fluid Attacks' own scanner, was 22.7% recall, and the average across the other 34 tools was 1.7%. Most tellingly, 743 vulnerabilities — 61.9% of the total — were found by the pentester alone, invisible to every tool in the comparison.
Recall and precision per tool; the pentester found 743 vulnerabilities no tool detected.
What red teaming covers that continuous testing does not
Stating the limit matters more than the pitch. Continuous application security testing examines code, infrastructure, cloud configuration and dependencies. It does not phone an employee pretending to be IT support, it does not walk into a building behind someone holding a door, and it does not measure how long a security operations center takes to escalate an alert at 3 a.m.
Those are real attack surfaces, and red teaming is the discipline built to test them. An organization that needs that measurement needs a red teaming engagement and should buy one. Saying otherwise would be selling a scanner as a substitute for a fire drill.
Where the two meet
The vulnerabilities red teaming chains together are the same ones continuous testing finds and closes first. Fluid Attacks' public vulnerability database catalogs 384 weakness types mapped to 182 security requirements, 2,021 fixes and 66 indexed standards — among them MITRE ATT&CK, where 36 ATT&CK mitigations are tied to numbered requirements, and NIST SP 800-115.
Fluid Attacks maps 36 MITRE ATT&CK mitigations to its own numbered security requirements.
Three entries sit squarely in the middle of a typical attack path: privilege escalation, authentication mechanism absence or evasion and administrative credentials stored in cache memory. Each carries an expected remediation time — 60 minutes for the first. Closing them beats learning through an exercise that they were links in a chain.
How to choose a red team provider
Here is what to verify before signing.
Intelligence-led accreditation: CREST accredits providers under disciplines built for this work, among them Intelligence Led Penetration Testing (STAR) and STAR-FS. Ask which accreditation the provider holds and for which service, then confirm it yourself in the CREST Marketplace rather than taking a sales deck at its word.
Rules of engagement in writing, before anything starts: objectives, out-of-scope systems, permitted techniques, escalation contacts and debriefing dates. Alvarez's rule is the right floor: "The red team must have complete authorization on paper and by email and all forms of legal protection…"
An early-alert criterion agreed in advance: define which findings are serious enough to stop the exercise and be contained at once, and which wait for the report. Without that line a provider either interrupts constantly or sits on something urgent.
Independence, and proof you checked it: TIBER-EU puts the burden on you, stating that the entity being tested "should carry out due diligence to make sure its chosen provider meets all the requirements". Vetting the provider is your job, not theirs.
Evidence you can act on: agree the formats before the engagement starts. Fluid Attacks publishes the evidence formats it supports — annotated screenshots, video recordings of the attack, executive PDF and technical XLSX reports — and a comparable list is fair to demand of anyone.
Consent and ownership: the provider must confirm authorization from the owner of every asset in scope. In Fluid Attacks' documented SLA scope, ownership is one of four criteria bounding what can be tested.
Red teaming, penetration testing and BAS are not alternatives
These three are usually presented as a maturity ladder, which is misleading: they answer different questions, and an organization can need all three at once. Two variables separate them cleanly — who knows the attack is happening, and how wide the target is.
| Breach and attack simulation | Penetration testing | Red teaming |
Question answered | Do our controls stop known techniques? | What is exploitable in this system? | Can an adversary reach the objective undetected? |
Target | Security controls | A defined system or application | The whole organization, including people and facilities |
Defenders aware | Yes | Usually yes | No, by design |
Executed by | An automated platform | Pentesters | Offensive specialists, often with threat intelligence support |
Ends with | A control coverage report | A list of vulnerabilities with evidence | A narrative of one or more attack paths |
Cadence | Continuous | Continuous or periodic | Periodic, weeks to months per exercise |
Of the three, red teaming is the only one judged on going unnoticed, and that difference drives everything else: scope, duration, cost and who gets told. Run red teaming against a company that has never done secure code review and you buy an expensive confirmation of what cheaper tests would have found in an afternoon.
Red team, blue team, purple team and white team
Four teams appear in a mature exercise, and conflating them is the most common source of confusion about red teaming.
Team | Role | Typical activities |
🔴 Red team | Offense | Adversary simulation, stealth, chaining exploits into attack paths, testing incident response by provoking it |
🔵 Blue team | Defense | Detection through SIEM and EDR, forensic analysis, threat containment, configuration hardening |
🟣 Purple team | Collaboration | Live sessions where offensive techniques are executed while defenders tune detection rules in real time |
⚪ White team | Control | Authorizes the exercise, holds the rules of engagement, arbitrates incidents, is the only internal group that knows |
The names are not universal in red teaming: TIBER-EU calls the fourth group the control team and adds a fifth on the regulator's side.
Purple teaming is a working mode rather than a standing department, and it trades measurement for learning. Once the attackers announce what they are doing so defenders can watch, the exercise has stopped being red teaming: it is now excellent for tuning detection rules and useless for finding out whether those rules would have fired on their own.
How a red team exercise runs
A red teaming engagement moves through six phases, and the only one most organizations plan properly is the first. The table below maps each phase to what defenders should be able to see, and to the weakness type in Fluid Attacks' catalog that typically makes the phase possible.
Phase | What the attackers do | What defenders should detect | Related weakness |
1. Objectives and rules | Defines the objective, scope, permitted techniques and escalation path with the white team | Nothing — this phase is deliberately invisible | — |
2. Reconnaissance | Open-source intelligence on employees, suppliers, exposed assets and technologies | Unusual enumeration of public assets | — |
3. Initial access | Phishing and other social engineering, credential reuse, exposed services, physical entry | Anomalous logins, new devices, mail gateway alerts | |
4. Privilege escalation | Abuse of misconfigured roles and cached credentials to gain administrative access | Privileged account creation, token manipulation | |
5. Lateral movement | Lateral movement across hosts and trust relationships toward the objective | East-west traffic between systems that never normally talk | |
6. Objective and reporting | Reaches the objective, documents the chain, debriefs all teams | Data staging and exfiltration volumes | — |
The tooling red teaming uses is well known and largely public: BloodHound maps Active Directory attack paths, mimikatz harvests credentials, CrackMapExec automates movement between hosts, and frameworks such as Covenant run command and control. Fluid Attacks' pentesters use many of the same tools in continuous testing, and the full list is published in its documentation.
One point about the last phase is routinely mishandled. Vulnerabilities found during a red teaming exercise are normally not remediated until the engagement closes: fixing them in flight severs the chain the team was building and destroys the demonstration of impact. The exception is the early-alert criterion agreed in phase one. Everything else waits for the report.
The frameworks a red team exercise is built on
Three reference works carry most of the weight in red teaming, and a provider that cannot state its position on all three is improvising.
MITRE ATT&CK
MITRE ATT&CK is a curated knowledge base of adversary tactics and techniques drawn from real-world observations. It gives both sides of a red teaming exercise one vocabulary: the attackers describe what they did in technique IDs, and the defenders check their telemetry against the same IDs. Fluid Attacks maps 36 ATT&CK mitigations to its own security requirements in its public database.
NIST SP 800-115
NIST's Technical Guide to Information Security Testing and Assessment, published in September 2008, is the formal reference for planning technical assessments, analyzing findings and building remediation strategies. Most procurement processes still point to it when they specify offensive work, red teaming included. Fluid Attacks maps its sections to 25 of its own requirements.
TIBER-EU, DORA and CREST
TIBER-EU — Threat Intelligence-based Ethical Red Teaming — was published by the European Central Bank and the EU national central banks in May 2018 as the framework for intelligence-led testing of financial entities. It separates five teams: the blue team, tested without its foreknowledge; the control team, the small internal group that knows; a threat intelligence provider; the red-team testers; and the TIBER cyber team, which oversees compliance on the authority's side. Due diligence on the providers falls to the entity under test.
The Digital Operational Resilience Act has since made threat-led penetration testing mandatory for significant financial entities in the EU, under Article 26, and TIBER-EU was updated in 2024 to align with it. That is why demand for red teaming is growing fastest in regulated sectors.
When an organization is ready for red teaming
An organization is ready for red teaming when its answer to "what is broken in our software?" has become boring. If a security testing program closes flaws continuously and the open backlog holds nothing critical, the remaining question — whether anyone would notice an intruder — is worth paying to answer.
Most organizations are not there yet. In Fluid Attacks' State of Attacks 2026 report, 70% of assessed systems had at least one high- or critical-severity vulnerability, up from 53.3% in 2024, and the overall remediation rate reached 62.2% by the end of 2025. Systems using a CI gate to block insecure builds reached 72%, against 58% for those that did not.
Three readiness signals are concrete: vulnerabilities remediated in days rather than quarters, a documented incident response process that has been rehearsed, and someone who owns the decision to escalate at night. Without the third, red teaming will prove only that nobody was watching.
Conclusions
Red teaming measures something no scanner reports: whether an organization notices and stops a real adversary. It is adversary simulation across people, process and technology, judged on objectives reached and alerts missed, and it earns its cost once the cheaper questions have already been answered.
Fluid Attacks offers continuous testing by pentesters and scanners, which closes the vulnerabilities an adversary would otherwise chain — and which, in its own benchmark, surfaced 743 flaws that no automated tool in a 36-tool comparison detected. The two are complements rather than competitors, and anyone selling the second as the first is selling a smoke detector as a fire drill.
Frequently asked questions
What is the difference between red teaming and penetration testing?
Scope and stealth. Penetration testing examines a defined system and tries to find every exploitable flaw in it, usually with the defenders' knowledge. Red teaming targets the whole organization, pursues one specific objective, includes people and physical security, and runs without telling the blue team.
Should the blue team know about a red team exercise?
No. Only the white team should know. The exercise exists to measure detection and response under realistic conditions, and defenders who expect an attack escalate faster than they would on an ordinary day. TIBER-EU builds that separation into the framework, testing the blue team without its foreknowledge.
Should vulnerabilities be fixed during a red team exercise?
Generally no — they wait for the final report. Remediating mid-exercise breaks the attack chain the team is building and destroys the evidence of real impact. The exception is a criterion agreed before the exercise starts, defining which findings are critical enough to trigger an immediate alert and containment.
Is red teaming required by any regulation?
In EU financial services, effectively yes. The Digital Operational Resilience Act requires threat-led penetration testing for significant financial entities, and TIBER-EU is the framework national authorities use to run it. Outside that sector, red teaming is generally a risk decision rather than a legal obligation.
Does Fluid Attacks do red teaming?
No. Fluid Attacks does not offer red teaming and does not run red team engagements. It provides continuous application security testing combining AI, scanners and pentesters across eleven techniques. In its benchmark against 36 third-party tools, a Fluid Attacks pentester found 1,076 of 1,201 vulnerabilities — 89.6% recall — including 743 that no automated tool detected.
Find the paths before anyone walks them
Our pentesters and scanners test your software continuously, so the vulnerabilities an adversary would chain get closed long before a red teaming exercise is worth running. Start free trial · Contact us.
Get started with Fluid Attacks' PTaaS right now
