When in Doubt, Call It a Red Team

I've lost count of how many times someone has asked me for a red team when what they actually needed was something else.

That's not a criticism, it's a symptom of a bigger problem.

Over the last few years, "red teaming" has become a buzzword. Vendors advertise it. Executives ask for it. Security leaders put it on roadmaps. Somewhere along the way, it became synonymous with the domain of offensive security.

So, you might be thinking:

"Does it really matter what we call it?"

I believe it does.

Terminology matters because definitions shape expectations.

A penetration test, threat model, purple team exercise, tabletop exercise, and red team are all valuable. But they're designed to answer different questions.

When we use these terms interchangeably we create unrealistic expectations, request the wrong assessments, measure success incorrectly and, ultimately, miss the insight we were actually trying to gain.

One of the biggest misconceptions is that a red team is simply a more advanced penetration test.

It isn't. It's a different discipline with a different purpose.

Choosing the wrong assessment doesn't just waste time and money, it addresses the wrong question.

Don't Pick the Service First

Every offensive security activity exists to answer a question or understand a risk.

Oftentimes organizations choose the assessment first, then trying to make their objectives fit.

Instead, start with the question.

None of these assessments are interchangeable.

Each exists for a different purpose, produces different outcomes, and helps organizations make different decisions.

The App That Didn't Need a Red Team

One scenario I have encountered, often goes something like this.

A team is preparing to launch a new customer facing application and asks for a red team.

My first question is always the same:

"What are you hoping to validate?"

The answer sounds something like this:

"We want to test the authentication workflows and device registration."

What the team is really trying to understand is whether the application's authentication controls function securely and whether weaknesses exist within those workflows.

That's exactly the type of question a penetration test is designed to answer.

If a red team engagement were conducted instead, it might still provide valuable insights. However, it wouldn't directly answer the team's original objective. To validate the application's authentication controls, a penetration test would still be required.

A red team would approach the engagement very differently.

Rather than asking:

"Can these authentication controls be bypassed?"

It would ask something closer to:

"Could an adversary compromise customer accounts, achieve a defined objective, and would the organization detect and respond before meaningful impact occurred?"

Notice the difference?

The mobile application may still form part of the attack path, but it is no longer the objective. The objective is to emulate adversary behaviour against the organization as a whole.

Same application. Completely different question.

The Question Only a Red Team Can Answer

Red teams deliver the most value when an organization already has a solid security foundation.

That doesn't mean every vulnerability has been eliminated or every control is perfect.

It means you've reached the point where asking "What vulnerabilities exist?" is no longer your biggest challenge.

Instead, you're asking questions like:

• Can our security operations detect attacker behaviour and patterns?
• Are our incident response processes effective under pressure?
• Can an attacker achieve a meaningful operational impact, bypassing layered controls?
• Do our people, processes, and technology work together the way we think they do?

Those are red team questions.

A penetration test evaluates the security of a defined system or application. A red team evaluates the resilience of the organization.

A red team may evaluate identity, physical security, social engineering, detection capabilities, incident response, and operational decision making. Whatever is necessary to emulate a realistic threat that's pursuing a defined objective.

Success isn't measured by the number of vulnerabilities identified. It's measured by whether the objective could be achieved, how effectively the organization responded, and what was learned as a result.

Identify your Question Before the Assessment

Before requesting a red team, take a step back and ask yourself:

• What are we trying to learn?
• What decision will this assessment help us make?
• Are we validating the security of a system? Or, the resilience of the organization?
• Do we need to identify vulnerabilities? Or, do we need to understand whether an adversary could achieve a meaningful objective?

The answers usually make the right assessment obvious.

Sometimes that assessment will be a penetration test, sometimes it will be threat modelling, and sometimes, yes, it will be a red team.

None of these assessments are inherently better than the others. They're simply different tools designed to answer different questions.

Definitions matter because they shape expectations.

So the next time someone says:

"We need a red team."

Ask one question first.

"What are you actually trying to understand?"

The answer might change the assessment entirely.