When Red Teams Go the Distance: Working with Sustained Operations

Sustained red team operations aren't just longer pentests. They're a different muscle — one that flexes over quarters, not weeks. I've seen teams nail the first month, then slowly drift into reactive patching disguised as adversarial simulation. The hard part isn't the technical work; it's keeping the adversarial mindset alive when everyone else has moved on to the next fire.

This field guide sketches what sustained ops look like in practice: where they fit, where they break, and what you'll wish you'd known on day one. No hype, just the messy middle.

Where Sustained Red Teams Actually Show Up

Real-world contexts: compliance-driven vs. threat-driven

Sustained red teams don't live in theory. They show up in two distinct flavors, and confusing them is how budgets get wasted. Compliance-driven ops surface when a regulator or auditor demands evidence of continuous testing — think PCI DSS or FedRAMP, where the ask is "prove you look for gaps every quarter." The team runs the same playbook four times a year, files reports, and everyone calls it done. That's a treadmill. Threat-driven ops are different. They start with a specific adversary profile — maybe a state-backed group that hunts industrial control systems, or a ransomware crew that takes 47 days from initial access to encryption. The red team calibrates to that timeline, that TTP set, that operational tempo. I have seen organizations run both in parallel and wonder why the compliance track found nothing while the threat track triggered three incident response activations. Wrong order. The threat model should dictate the schedule, not the calendar.

The gap between annual pentests and continuous simulation is not just frequency — it's feedback. A pentest drops a pile of findings and walks away. Sustained ops build a relationship with the defenders. The team sees what gets fixed, what gets deferred, and — the odd part is — what gets broken again by the next deploy. That hurts. Most teams skip this: they chase new attack paths instead of watching old ones heal. The catch is that a sustained operation without a feedback loop is just expensive pentesting with more meetings.

Who asks for sustained ops and why

The request rarely comes from the CISO. It comes from the SOC director who has watched the same phishing campaign succeed three quarters in a row. Or from the detection engineer who can't tell if their new Sigma rule actually fires because nobody tests it against real tradecraft. These people want a sparring partner, not a report. They want a red team that sticks around long enough to see the detection pipeline mature. That sounds fine until the purple team sessions turn into blame sessions. The pitfall is letting the sustained timeline blur the difference between testing and fixing — the red team's job is to find seams, not to patch them. When that line dissolves, the team becomes an extension of engineering, and the adversarial edge dulls fast.

One concrete scene: a telecom company I worked with brought in a sustained red team after an insider-threat scare. The board wanted reassurance. The defenders wanted a repeatable stress test. The red team stayed for six months, running the same initial-access payload every six weeks. By month three, detection coverage had jumped from 12% to 68%. By month five, the defenders were building their own honeypots off the red team's infrastructure. The odd part? The compliance auditors didn't care. They wanted a checklist. The real win was invisible to them. That's the tension — sustained ops produce operational muscle memory, not checkbox artifacts, and the people who fund them often ask for the wrong kind of proof.

'The red team that stays long enough to see the defenders improve is the same red team that watches its own best attacks get burned.'

— former detection engineer, critical infrastructure firm

So who else asks? Product security teams building internal red cells. CISO offices recovering from a breach — they want to know if the fix held. And sometimes, a board member who read about 'continuous security validation' in a Gartner note. The last group is the most dangerous. They push for sustained ops as a badge, not a practice. The result is a team that runs forever but never hits anything new. That's not sustained operations. That's perpetual motion without friction — and friction is what makes the work honest.

Foundations People Get Wrong

Mistaking longevity for depth

A client once told me their red team had been 'running continuously for eighteen months.' Proudly. They expected a medal. Instead I asked what they’d found in month fourteen that they hadn’t already mapped in month two. Silence. Long-running engagement doesn't equal deep engagement — it often means the same shallow loops spinning faster. Sustained ops look like a treadmill: lots of motion, zero forward progress. The trap is equating calendar span with adversarial coverage. Your team can burn six months circling the same five footholds while attackers fly right past you using a technique nobody bothered to re-examine. Duration is a bet on repetition; depth is a bet on discovery. Most bets are placed on the wrong horse.

Flag this for penetration: shortcuts cost a day.

Flag this for penetration: shortcuts cost a day.

The myth of 'always-on' adversarial coverage

Continuous engagement sounds bulletproof. Always-on. Like a 24/7 pressure test. That sounds fine until you realize no human team, not even a well-funded one, can sustain peak adversarial friction for three hundred sixty-five days. Somebody sleeps. The odd part is—teams design sustained ops as if they were a permanent fixture, then get surprised when operators burn out, tools degrade, and the red cell starts rubber-stamping findings instead of hunting fresh ones. What usually breaks first is the assumption that coverage can be uniform. It can't. A team that runs year-round will have high-intensity weeks and low-intersection lulls. The honest conversation nobody wants is this: always-on coverage is a marketing phrase, not a capability. You get spike days, plateau weeks, and blind gaps. Plan for that, or plan to be wrong.

'We thought continuous meant thorough. It just meant we exhausted our playbook faster than we exhausted our target.'

— Red cell lead, after year two of a sustained contract

Scope creep disguised as maturation

The trickiest foundation error is conflating scope growth with team growth. A sustained red team starts with a clean mandate: test this environment, these controls, these attack paths. Then month three arrives, and someone asks, 'Can you also look at the cloud migration? And maybe the supply chain? And while you’re at it, our new vendor risk framework?' That's not maturation — that's scope creep wearing a smarter shirt. Maturation means deepening the same target, finding subtler seams, measuring repeat failure. Creep means adding more targets while keeping the same shallow carve. Most teams I have seen revert to shallow coverage not because they're lazy, but because they accepted every expansion without retiring any old work. The result? A sprawling engagement that touches everything and pressures nothing. The corrective is brutal but clean: every new scope item demands one old scope item dropped. No exceptions. That hurts. It also keeps sustained ops honest.

So before you celebrate a two-year continuous engagement, ask yourself: did we learn something genuinely new in month twenty-three, or did we just keep the machine running? Wrong order is common. Fix it early.

Patterns That Hold Up Over Time

Rotating focus areas and objective-based cycles

Most red teams start strong, then flatten. They hammer the same apps, the same network segments, the same tired phishing lures until defenders learn the script. That sounds fine until the team realizes they're measuring activity, not adversarial value. The fix is brutally simple: rotate focus areas every 6–8 weeks on a strict calendar cycle. Not when the team feels like it—when the calendar says so. I have seen teams run four concurrent cycles: one on identity infrastructure, one on cloud-native configs, one on supply-chain dependencies, and one on physical-to-digital handoffs. Each cycle has a crisp objective—compromise the Okta MFA chain, or exfil from a locked-down S3 bucket—not a vague "find vulnerabilities." The objective kills the cycle when met or when the timebox expires. That hurts. It forces the team to leave partially explored ground and trust that defenders will remember the pressure.

Embedding operators into product teams temporarily

The pattern that holds best over time: put a red team operator inside a product team for two sprints, then pull them out. No badge-sharing, no permanent transfer. Just a focused burst where the operator attends standups, reads the backlog, and pairs with developers on threat models for features about to ship. The catch is the operator must not fix bugs—they observe and document attack paths that survive code review. Most product teams resist this. They see an auditor, not an ally. But the ones that stick with it discover something odd: the operator stops finding the same SQL injection variations and starts surfacing logic flaws in auth flows that were never documented. The trade-off is real—you lose the operator's dedicated red team hours for six weeks. You gain a permanent shift in how the product team thinks about access control. Worth it? Only if you measure by reduced incident response calls six months later.

Measurement that doesn't ruin the mission

Long-running ops die when the metrics board dictates the next move. I have watched teams pivot from "test detection coverage" to "find 10 critical findings per quarter" because leadership wanted a dashboard. That's how you get teams re-finding the same CVEs instead of chasing novel attack chains. The better pattern: track two numbers only—mean time to execute a new TTP not seen in the last 90 days, and the count of detection gaps closed by defenders after a report. That's it. No "findings per hour" or "coverage percentage." The first number forces innovation; the second forces the blue team to act. A single rhetorical question keeps the mission honest: Did our operation make the organization harder to compromise than it was last quarter? If the answer is no, the pattern is broken.

Rotation prevents boredom. Embedding transfers context. Sparse metrics prevent the team from gaming itself.

— Lead operator, 18-month sustained engagement

One final note on the human side: sustained ops burn operators out faster than any one-week assessment. The natural instinct is to push harder—more hours, more campaigns, more after-action reports. The anti-answer is rest. Rotate operators off the sustained work for two weeks every quarter. Let them do a short scoping review or write tool documentation. The team returns with fresh eyes and refuses to repeat stale patterns. That's the slow, boring, correct way to keep adversarial value alive over eighteen months.

Not every penetration checklist earns its ink.

Not every penetration checklist earns its ink.

Anti-Patterns and Why Teams Revert

The 'pentest-plus' trap

Most teams start sustained ops by bolting a compliance checklist onto a continuous scanner. Wrong order. You get a tool that fires every Tuesday, reports the same missing patch for six months, and calls it "continuous." That sounds fine until leadership asks: What new risk did we find this week? The answer is usually nothing—because the scan surface stays static. I have seen three different red teams collapse inside six months because they treated sustained work as pentest-as-a-service, just with a recurring invoice. The trap is seductive: you already know how to run a two-week assessment, so you stretch the timeline, pad the scope, and pretend that's depth. It's not. Depth means chasing the same attack path through three different privilege escalation chains, not running the same SQLi test against the same endpoint every month. The pitfall is boredom—the team stops hunting because the tool already flagged everything.

Alert fatigue from continuous scanning

The catch is worse than wasted cycles. When scanning runs weekly, defenders tune out. They see the same critical-severity alert on a dev box that can't be patched until the next release window. That ticket sits. Then another. Then the ops team starts muting the channel. The odd part is—the red team usually blames the client for not fixing things, but the real failure is signal decay. Sustained ops that rely on unmodified scan configurations produce noise, not intelligence. We fixed this by introducing a two-week quiet period between active scans and forcing manual validation for every finding before sending it to the client. Cut the alert volume by 60%. What remained got fixed. That's the editorial signal: if your sustained operation generates more tickets than conversation, you're running compliance theater, not threat emulation.

'We used to run eight tools continuously. Now we run two and spend the saved hours chaining findings across systems.'

— team lead, financial sector red cell, after dropping their tool count

When leadership demands a report every week

This is where sustained ops die fastest. A weekly report forces the team to manufacture findings—either by inflating low-severity issues or re-reporting old ones as "persistent." I once watched a team pad their output with five "informational" recommendations about log retention purely to hit page count. The client's CISO noticed and terminated the contract. The anti-pattern is simple: reporting cadence should match operational tempo, not calendar rhythm. A real finding is rare—maybe three to five genuine breakthroughs over a three-month sustained engagement. Everything else is maintenance, recon, or waiting. When you force weekly output, you incentivize shallow work. The fix is brutal but clean: report only when you have something novel. If that means three weeks of silence, defend it. Leadership that can't tolerate quiet periods should not buy sustained ops—they should buy a penetration test every quarter and stop pretending.

The hardest lesson is admitting when the model itself is broken. Sustained ops revert because humans get tired, tools get stale, and clients confuse activity with progress. That hurts. But the teams that survive refuse to pad, refuse to scan on autopilot, and refuse to write a report just because the calendar says Thursday.

Maintenance, Drift, and Long-Term Costs

Tooling Rot and Credential Hygiene

The first year of a sustained red team operation feels sharp. Tools run clean, credentials rotate like clockwork, and every C2 beacon chirps on schedule. Give it six months. What usually breaks first is the credential chain—service accounts that expire while nobody watches, API tokens scrawled into internal wikis that nobody touches. I have watched teams lose access to an entire Azure tenant because someone forgot a 90-day rotation window. The fix is boring: automated expiration alerts, a calendar that screams, and a rule that no credential lives longer than the operation's shortest contract cycle. But teams skip that. They assume the initial setup holds. It doesn't.

Tooling rot creeps in quieter. A payload generator that compiled flawlessly in month one starts throwing linker errors after a dependency update. The team's custom implant—built for deployment speed—now fails against the target's latest EDR signatures. Most teams treat this as a one-time investment. Wrong order. You need a dedicated tooling hygiene budget, measured in hours per week, not a sprint at kickoff. The catch is that budget rarely exists on paper; operations assume the gear works until the seam blows out mid-campaign.

Team Turnover and Knowledge Loss

Red teams turn over faster than blue teams. That's a fact of the industry—contractors cycle, internal staff burn out from sustained pressure, and the operator who built the persistent access in month one leaves in month six. What walks out the door? Not just code. Context. The exact session negotiation that kept the foothold undetected. The quirks of a specific domain trust that never made it into a document. I have seen a replacement operator accidentally nuke a year-long persistence chain because the handoff notes said "maintain beacon X" but omitted that it piggybacks on a scheduled task tied to a specific user's logon.

Documentation helps, but only if it's red-teamed itself. Most teams write runbooks that read like installation guides—smooth, linear, and useless under pressure. The fix is ugly: force a quarterly knowledge dump where each operator explains their persistent access to someone who has never touched it. Record the gaps. That hurts because it exposes how much you rely on tacit memory. But the alternative is worse—a team that rebuilds its entire adversarial infrastructure every six months, bleeding time and stealth with each handoff.

Field note: penetration plans crack at handoff.

Field note: penetration plans crack at handoff.

Budget Cycles That Don't Align with Adversary Timelines

Real adversaries plan in years. Red team budgets plan in fiscal quarters. That mismatch kills sustained operations more reliably than any defender. A team gets approval for a 12-month engagement, builds persistent access across the network, then hits a budget review in month eight—and leadership wants to "pivot to a different threat model." The persistence stays, but the team responsible for maintaining it vanishes. The result is drift: accounts go stale, monitoring nodes lose heartbeat, and the entire investment decays into noise.

One solution I have seen work is to treat maintenance as a separate line item, not a tail of the initial deployment. Argue that sustaining access costs 30–40% of the original build effort per year. Most leaders balk at that number, but they accept it when framed against the cost of rebuilding from scratch after a six-month gap. The odd part is—this is basic asset management. We apply it to servers. We forget it applies to adversarial infrastructure too. Budget cycles that ignore this produce a red team that resets constantly, never learning what a patient adversary actually sees.

“The longest campaign I ever held was three years. The hardest part wasn't the targets. It was keeping my own team from forgetting why we were there.”

— Operator handle redacted, private conversation, 2023

That quotes the root cost: attention decay. Sustained ops demand a stamina that most organizations have not baked into compensation, promotion paths, or even meeting structures. If you can't pay for the boring work—rot checks, credential swaps, the fourth campaign review—you're not running a sustained operation. You're running a string of short engagements with long gaps. That's cheaper upfront. It also teaches your team nothing about what endurance actually costs. Next time you budget, ask: what happens when the tool breaks and the person who built it's gone? If the answer is "pause the operation," then you have not planned for maintenance—you have planned for drift.

When to Say No to Sustained Ops

Organizational maturity below a certain threshold

Sustained red teaming is a scalpel, not a sledgehammer. I have walked into shops where the incident response team still prints alerts and hands them to the night shift on paper. That shop doesn't need three operators running continuous adversary simulation against a network that can't detect a plaintext password spray. The investment rots. Before you sell sustained ops, ask one hard question: can the blue team use what we find? If detection workflows are manual, if patching cycles run quarterly, if nobody reads the purple-team debrief — stop. The burn rate outpaces the absorption rate. You're not building muscle; you're feeding a fire that the org can't yet carry water to. Maturity below a threshold means the money goes further on fundamentals: tabletop exercises, basic telemetry, one solid sensor deployment. Sustained ops become a noise generator when the foundation is still dirt.

When the threat model doesn't justify the burn rate

Not every environment faces a sophisticated, well-resourced adversary that adapts monthly. Some teams protect a legacy product with three hundred users and a third-party SOC that barely covers weekends. Running a four-person red cell against that? The odd part is — the question isn't can we, but should we. Sustained operations demand budget, attention, and emotional bandwidth from defenders. If the threat model says phishing and ransomware through commodity tools, a biennial penetration test plus a phishing simulation platform beats a full-time red team. That hurts to admit — I have recommended exactly this to a CISO who wanted the prestige of "continuous ops." Prestige doesn't stop ransomware. The burn rate of a sustained team can hire two additional detection engineers instead. Pick the trade that raises the floor, not the ceiling.

'Sustained ops are a recurring expense of attention. If the organization can't sustain attention, the ops become an expensive habit.'

— paraphrased from a SOC director who declined a red team renewal

Alternatives that might serve better

Sometimes the right answer is a pulse, not a constant hum. Short-duration engagements — two weeks every quarter, with specific objectives tied to the current threat landscape — deliver pressure without exhausting the defender. I have seen teams pivot from permanent red team presence to rotating purple-team sprints: five days of attack, five days of defense, a week of documentation. The cost drops by sixty percent. The learning accelerates because both sides have a shared deadline. Another alternative: embed one adversary-emulation specialist into the security team for a fixed three-month tour, rather than running an external sustained cell. That person builds tools, trains analysts, and leaves behind scripts that work after they go. Sustained ops are not a badge of maturity. They're a capacity decision. If the capacity is not there, the right call is not yet. Say no now, build the thing that makes yes worthwhile later.

Open Questions Every Team Should Ask

How do we measure success without gamifying failure?

Every sustained team I have seen wrestles with this quietly. You run tests for six months. The blue team catches most of them. Is that success — or is the red team just predictable now? The trap is obvious: if you measure by findings per quarter, the team will manufacture low-value alerts to hit a quota. We fixed this once by switching to a 'time-to-bypass' metric. That worked for a cycle, then the blue team learned to watch for the new pattern. The catch is that any static metric eventually gets gamed. Most organizations pick three rotating measures and still feel wrong about all of them. Maybe that tension is the point — you never want a single number that feels safe.

What happens when the red team finds nothing for months?

Silent quarters break teams. I worked with a group that went four months without a single high-severity finding. The blue team celebrated. The red team started hiding micro-findings to appear active. Wrong order. The real problem was structural: the red team had stopped varying their approach. They ran the same playbooks against the same surfaces. An empty findings log is either a sign of mature defenses or a symptom of stale operators. The tricky bit is telling them apart. Most shops default to 'our defenses are working' and never audit the red team's methodology. That hurts. If no findings arrive for two months, rotate the red team's access or change the attack surface — force a reset.

Long quiet stretches don't mean safety. They often mean the red team has stopped trying the hard stuff.

— red team lead, after an eight-month dry spell that hid two critical blind spots

Who owns the backlog of findings — red, blue, or product?

This is where sustained operations tear at the seams. A red team finds a privilege escalation path in a service that won't be refactored for eighteen months. The finding gets filed. Who chases it? If red team owns the backlog, they become ticket naggers — not attackers. If blue team owns it, findings get triaged against operational firefighting and buried. Product teams often say they own it, then deprioritize because 'the red team will test again next quarter anyway.' That sounds fine until the seam blows out in production. We fixed this by creating a shared 'risk registry' owned by nobody and audited by a rotating chair. Imperfect, but it stopped the blame game. The unresolved tension remains: sustained operations produce a constantly growing list of unfixed problems. No org chart solves that entirely — you need a culture willing to sit with the discomfort of unfinished work. Most teams skip this.