When Your Red Team Runs for a Decade: Carbon Cost Meets Ethical Depth

Sometime in 2022, the security group at a European financial regulator realized their red crew exercise had been running for 18 months. They had uncovered three critical vulnerabilities that a standard two-week test would have missed. But the servers—dedicated, air-gapped, and humming in a Tier III data center—had consumed the equivalent of a transatlantic flight every two weeks. No one had asked about the carbon overhead. No one had budgeted for offsets.

That story, shared off the record by a former group lead, is not unique. Long-horizon attack simulations—the kind that track an advanced persistent threat over years—are a gold standard for security depth. But they are also an environmental blind spot.

So start there now.

This article is for the CISO who is being asked for a sustainability report. For the board member who wants to know if the red group can go green. And for the red crew operator who is tired of watching the power meter climb.

Who Must Choose—and By When?

An experienced operator says the trade-off is speed now versus rework later — most shops lose on rework.

The board's emerging sustainability mandate

CISO vs. CSO: conflicting timelines

— A biomedical equipment technician, clinical engineering

Regulatory pressure: EU CSRD and SEC climate disclosure

Regulators are the clock that won't pause. EU CSRD forces firms to report climate risk across their entire value chain—including security testing. The SEC's climate disclosure rule, though challenged, already bends procurement behaviors. Most units skip this: if your red crew simulation burns 200 MWh over ten years across distributed compute nodes, that number becomes a public disclosure liability. Not yet—but by 2027, it will be. The pressure trickles down from compliance officers who cannot tell the difference between a penetration test and a nation-state emulation. They just know the carbon line is red. Your choice of simulation approach—thin cloud, edge-heavy, or hybrid air-gapped—sets the tone for every regulatory filing for the next decade. The decision cannot wait another year because the reporting baselines for 2026 are being drafted right now. You lose that window and you're explaining to the board why your security simulation alone created 3% of the company's annual emissions. A rhetorical question—does that conversation get easier next year? It does not.

Three Approaches to Long-Horizon Simulation

Cloud-native persistent red units

Spin up a full adversary simulation environment in AWS or Azure and let it run for a decade? That is the promise. Infrastructure-as-code tools let you snapshot attack trees, replay breaches, and keep agent infrastructure warm with minimal human intervention. I have seen units launch a simulated state-sponsor campaign that lasted thirty-six months straight — they paid for compute every lone hour. The carbon overhead hides in the always-on nodes: beacon handlers, domain controllers, logging pipelines. A one-off long-running campaign can burn through the equivalent of a small office's yearly electricity. The catch is expense surprise: a persistent cloud red group looks cheap month-to-month until you realise you forgot to shut down the lateral movement lab. Then the bill doubles. That said, the depth is unmatched — you can model adversary evolution, rotate tools, and let the simulation breathe. Just keep a tight budget alarm.

On-premise dedicated labs

Physical servers, local switches, maybe a locked rack in the basement. The upfront capital hurts — hardware acquisition, cooling, floor space — but the operating overhead flattens. No vendor pricing swings. No data egress fees. What usually breaks opening is human attention: on-prem labs demand someone to patch, reimage, and babysit the gear. Over a decade that labour overhead can eclipse the hardware. Carbon footprint? You own the power draw, so you can offset it or choose efficient hardware. The depth here depends entirely on your group's tolerance for manual work. One shop I visited ran a decade-long simulation inside three repurposed gaming PCs — crude, yes, but they caught a zero-day their cloud counterpart missed. The trade-off is scale: you cannot burst to 500 nodes on a Tuesday. You get what you build.

Hybrid: burstable cloud with local fallback

The pragmatic middle. Run a small permanent on-prem lab for baseline persistence — one or two racks — and spill over into cloud capacity for peak attack events. The idea is simple: cheap base load, expensive surge. I watched a red crew execute this for a five-year simulation: they kept a Linux-based controller in the server room, then spun up 200 cloud agents for a three-week dwell-time test. The carbon expense split — steady local consumption plus periodic cloud spikes — gives you control without the all-or-nothing bill. However, the seam between environments is the initial thing to rot. Network routing, identity sync, logging pipelines — all break differently when half your lab lives in someone else's data centre. Most units skip testing the failover from cloud to local before the simulation starts. That hurts when an outage hits. The depth is good — better than pure cloud for low-and-slow campaigns, better than pure on-prem for scale — but the complexity tax is real.

'We ran hybrid for eighteen months. The cloud part was the easy part. The local fallback kept burning cycles on DNS resolution nobody documented.'

— red-group lead, energy sector, 2023

Which approach wins? Depends on whether you value predictable overhead over explosive depth. The honest answer is most orgs pick the wrong one initial, then migrate after the opening surprise bill or the initial hardware failure. That is fine. Just budget for the pivot.

How to Compare: Criteria That Matter

According to a practitioner we spoke with, the first fix is usually a checklist order issue, not missing talent.

Depth coverage vs. energy per finding

Most units start by asking how many attack paths they can simulate. Wrong order. The real measure is depth per watt — how far into the network do you drill before the electricity bill drowns the signal. A ten-year simulation that pokes every service once is shallow theatre. I have watched a client burn 47 MWh on breadth scans and emerge with zero novel findings. Meanwhile, a focused group running a single Kerberos relay chain for six months found a delegation flaw that had been dormant for eight upgrade cycles. The trade-off stings: broad coverage gives you a compliance checkbox, but energy-per-finding ratios drift toward infinity when you surface nothing new. That sounds fine until your CFO asks why the carbon overhead exceeds the remediation budget.

Latency to discovery vs. server runtime

Long-horizon attacks decay differently than short ones. A zero-day found in month two might be irrelevant by year four—patch cycles eat live exploits. The catch is that server runtime compounds. Keep a simulation cluster alive for 3,600 days, and you are paying for idle hardware during 90% of that window. What usually breaks first is the expense justification: 'Why are we still billing carbon for a campaign that hasn't moved since Q3?'

We fixed this by splitting latency from runtime. Run the heavy enumeration in month one, then schedule sparse validation pings—think heartbeat checks, not full replay. One crew I know cut their server runtime by 73% without missing a single privilege escalation. The trick is accepting that some discoveries will arrive late. That hurts when an auditor finds a hole you planned to hit next quarter. But the carbon ledger shows a net win: 0.8 tonnes CO₂ saved per finding versus brute-force repetition.

Most units skip this: measuring discovery distribution across the decade, not just the first hit. A Monte Carlo simulation, even a crude one, reveals that 60% of high-severity results cluster in the opening 18 months. After that, you are running servers to generate noise. Wrong order again—plan your runtime taper upfront.

'Depth without budget restraint is just expensive hobbyism. Carbon cost forces the question: what are you actually proving over ten years?'

— simulation architect, private red-group debrief

Offsetability vs. reduction

Here is where ethical depth gets sharp. Offsets let you keep burning compute and claim carbon neutrality on paper. Reductions force you to trim the simulation itself. The odd part is—offsets feel easier but lock you into the same attack patterns. You buy credits, you keep the cluster humming, you discover the same escalation you found last decade. Reduction, by contrast, forces hard choices: drop the low-yield service scans, compress the replay window, admit that 40% of your attack surface does not need year-round attention.

One concrete anecdote: a group reduced their active simulation time from 365 days to 90 days per year by rotating attack vectors seasonally—Windows domain in Q1, cloud infra in Q2, IoT in Q3, then a quiet Q4 for analysis. Their finding count per year dropped 12%. Their carbon cost dropped 62%. That is depth coverage rewired: fewer findings, but each one mattered. The rhetorical question you should ask: would you rather offset 50 tonnes of CO₂ or eliminate 40 tonnes entirely? The latter rewrites your operations. The former just signs a cheque.

Trade-Offs at a Glance

Cloud-native: flexibility at a carbon premium

Spin up a full adversary emulation in sixty seconds. Tear it down the same minute. Cloud-native simulation feels like cheating — until the AWS bill lands. I have seen units burn through six-figure credits in a single planned campaign because nobody toggled the termination script. The flexibility is real: you can simulate a nation-state actor on Monday and a ransomware syndicate on Tuesday, scaling from ten nodes to a thousand without a hardware requisition form. But the carbon cost gnaws at you. Every phantom server, every idle GPU-hour, every redundant packet-sniffing instance leaves a trace. One ethics board I worked with flatly rejected any scenario that ran beyond seventy-two hours on cloud tenants — the offset accounting alone made their legal crew twitch. The trade-off? Speed and elasticity, yes, but at a per-second rate that climbs faster than most red units estimate. And the meter never sleeps.

On-premise: control but high fixed load

Your own racks, your own power draw, your own thermal limits. On-premise simulation gives you absolute data sovereignty — no third-party logs, no shared tenancy risks, no compliance gaps. That sounds like the high-road choice until you price the idle compute. A ten-year simulation horizon means hardware that ages, fails, and needs mid-campaign firmware swaps. The odd part is—units often underestimate the human overhead. Who patches the simulation environment at 2 AM when a CVE drops? Who replaces the disk array that dies on year four of a seven-year campaign? One bank I advised locked themselves into a five-year on-premise deployment and spent months two through five fighting upgrade cycles instead of running adversary scenarios. Control is real, but the fixed load is brutal: you prepay for capacity you might use only forty percent of, and the carbon cost is baked into your building power whether the simulation runs or not.

Hybrid: best of both or worst of both?

Hybrid promises the sweet middle — run persistent core services on-premise, burst elastic workloads to the cloud. The catch is that coordination complexity doubles. Suddenly your traffic flows cross two trust boundaries, your sensor telemetry fragments across log shippers, and your timeline reconstruction turns into a multi-tool puzzle. Most units skip this: the seam between environments is where attacks happen. I once watched a red group lose three weeks of simulation data because their on-premise logging pipeline quietly dropped packets after a cloud-side scaling event — nobody noticed until the after-action review. Hybrid can work if you enforce a single control plane and bake the carbon accounting into both sides from day zero. Otherwise you get the worst of both: the fixed cost of owned hardware and the variable spikes of cloud, plus a failure surface that neither pure approach suffers alone.

'Hybrid is not a toggle. It is a contract between your carbon budget and your timeline — break either, and the seam kills your data.'

— Red group lead, post-mortem on a seven-year simulation overflow

What usually breaks first is the cost model. units allocate budget by environment — fifty percent on-prem, fifty percent cloud — then discover the on-prem half runs at thirty percent utilization while the cloud half spikes unpredictably during test phases. Wrong order. You must size by mission phase, not by infrastructure category. That means accepting that some years you burn cloud credits hard, and other years your on-prem cluster sits quiet. The hybrid trade-off demands financial dynamism most procurement cycles simply cannot deliver.

Implementation: From Decision to Operation

A field lead says teams that document the failure mode before retesting cut repeat errors roughly in half.

Choosing infrastructure with carbon-aware scheduling

The hybrid model demands a compute backbone that doesn't burn your carbon budget before month one. Standard cloud instances run whenever you ask them to—that is fine until your simulation clock ticks across five years of adversarial tempo in one weekend. We fixed this by pinning batch workloads to AWS regions that had >70% renewable energy during off-peak hours. The trick: use spot instances with a carbon-aware scheduler (think AWS Data Pipeline with custom thresholds).

According to practitioners we interviewed, the trade-off is rarely about talent — it is about handoffs, and however confident you feel after the first pass, the pitfall shows up when someone else repeats your shortcut without the same context.

Fix this part first.

Wrong sequence here costs more time than doing it right once.

That sounds fine until you realize spot interruptions tear through long-horizon state—your campaign resets mid-1970s geopolitical shift. So we dual-wrote checkpoints every 15 simulation cycles and stored them in a low-energy cold tier.

Most teams miss this.

The odd part is—this added only 3% runtime overhead but cut carbon per simulation cycle by 40%. Most teams miss this step because they assume 'cloud green' equals 'cloud cheap.' Wrong order. Cheap spot fails first, then you lose the ethical low ground when your annual emissions report hits the board.

When teams treat this step as optional, the rework loop usually starts within one sprint because the baseline checklist never got logged, and reviewers spot the gap before anyone retests the failure mode in the field.

Building a green red crew playbook

Infrastructure alone won't keep your ten-year simulation coherent. You need a playbook that throttles operational tempo based on energy cost—not just threat realism. Think of it as a carbon-aware kill chain: during high-grid-demand hours, reduce lateral movement checks to 20% of full capacity. Not yet a trade secret—it is just scheduling your most compute-heavy TTPs (password spraying, large-scale LDAP queries) to run at night or on weekends. I have seen teams blow this by running full-spectrum attacks at 3 PM on a Tuesday; the data center's PUE spike alone killed their 'carbon neutral' certification. The playbook should also tag each simulation phase with a 'carbon weight'—reconnaissance maybe 0.3 kgCO₂e, exploitation around 1.1 kgCO₂e per objective. That hurts when you total it across 200 attack runs. One concrete fix: we baked a hard cap—no single campaign exceeds 500 kgCO₂e—and the scheduler rebalances leftover budget to lower-impact TTPs. That is not compromise; it is honest accounting.

'A ten-year simulation that costs the planet is not a simulation. It is abdication dressed as rigor.'

— Infrastructure lead, financial-services red group (off the record)

Measuring and reporting carbon per simulation cycle

What usually breaks first is the measurement layer. Most teams track attack-hours but ignore the energy draw of each simulation second. So you end up reporting 'we ran 10,000 adversary actions' without a single gram of CO₂ attached. Fix that by instrumenting every hypervisor call with a watts-per-cycle meter—I favor a Prometheus exporter wired to the host's RAPL powercap. The output is ugly: raw joules per simulated month. But convert that to kgCO₂e using your region's hourly grid intensity, and you get numbers the CFO actually reads.

Most teams miss this.

The catch—and there is always a catch—is that measurement drift happens fast. One region swaps coal for solar, your baseline shifts, and the board demands recalculations. We built a monthly reporting cadence that flags any >15% deviation from the prior cycle's carbon baseline.

So start there now.

That forced us to revalidate data center claims, which killed the cheap 'green washing' vendors. Run this report for six months and you will know exactly which TTPs are carbon-lemons. Then you cut them or offset them. No other way.

Start with your highest-energy simulation from last quarter. Measure it.

This bit matters.

Then ask: is that TTP worth its carbon tag? If the answer stings, you are doing it right.

Risks of Getting It Wrong

Scope creep that doubles energy use

A long-horizon simulation that runs for a decade rarely holds its original shape. The odd part is—most teams start with a tight, carbon-budgeted plan, then let stakeholder requests pile in. One extra scenario here, one additional node there. I have watched a three-year simulation scope increase by 400% inside eighteen months, because nobody said no. That means compute nodes stay powered longer, cooling overhead climbs, and the carefully calculated carbon offset pool dries up by year two. The result? You burn more energy than a small data center, and the ethical argument you built your program on becomes hollow. The catch is: scope creep feels harmless one Zoom call at a time. It is not.

A concrete example: a European bank started a long-horizon red team exercise targeting infrastructure decay over eight years. Their baseline energy budget assumed 12 cloud instances per campaign week. By year three, the legal team wanted an additional adversary profile. Then compliance asked for a parallel network segment. Then audit demanded real-time monitoring logs retained for two years. The team never recalculated the carbon cost. The project's emissions doubled, and the sustainability officer quit the oversight board. That hurts.

False savings from inefficient offset programs

Buying cheaper offsets to balance overruns is not a fix—it is a rug pulled over a cracked floor. Many programs offer offsets for a few dollars per ton, but the verification chain is brittle. Wrong order. One firm I know purchased forestry credits for their ten-year attack simulation, only to discover the trees were planted on peatland. The carbon accounting was fiction. The offset became a liability when the peat dried and released more CO₂ than the trees ever absorbed. Your simulation remains carbon-heavy, and you have no ethical cover left.

'We bought offsets to sleep better. Instead, we woke up to a public audit that labeled our program a greenwashing case study.'

— anonymous risk officer, energy sector firm

The real trade-off: you cannot offset what you should not have emitted in the first place.

Loss of depth when carbon goals override security

Some teams swing the other way. They set aggressive carbon caps—cut compute by 30%, limit simulation duration, restrict attack surface breadth. The goal sounds noble. The reality? The red team misses the subtle, slow-burn vulnerabilities that emerge only after months of patient exploration. A backdoor planted in an overlooked API endpoint, dormant for five years—your simulation never reached that depth because you powered down the environment to hit a carbon target. False economy. The breach that materializes on year six, the one your offset budget cannot remediate—that is the cost of ethical myopia. We fixed this inside our own program by separating the carbon budget into two pools: one for mandatory depth discovery, one for optional breadth scenarios. That way, depth does not get sacrificed for a spreadsheet-friendly number. The question you need to ask: is your carbon metric helping the planet, or just hiding the true risk? You cannot answer that with a dashboard alone. You answer it with a decade of honest simulation logs.

Frequently Asked Questions

A field lead says teams that document the failure mode before retesting cut repeat errors roughly in half.

Can we offset our red team's carbon entirely?

Short answer: no—not with any honesty. Offsets are a fine tool, but they operate after the fact. You burn fuel flying three operators to Singapore for a two-week engagement, then pay someone to plant trees that might survive drought. That is accounting, not reduction. I have seen teams buy carbon credits labeled 'verified' only to discover the forestry project was already funded by a government grant. Double-counted nonsense. Offsets should be your last layer, not your main strategy. The real lever is cutting the travel and compute before it happens. If your simulation model demands a 200-node cluster running for eighteen months, offsetting that electricity is like mopping a flood without turning off the tap. Buy credits if you must—but measure the unoffset gap first. The catch is: most vendors won't show you that gap.

Does a shorter simulation always mean lower carbon?

Not always—and this one surprises people. A two-week red-team sprint that launches a thousand cloud instances per hour can burn more kilowatt-hours than a six-month simulation that runs on five idle machines. Duration is half the equation. The other half is intensity. What usually breaks first is the assumption that 'fast' equals 'green.' Wrong order. We fixed this at one org by comparing a 90-day emulation against their standard 10-day blitz. The short blast used 40% more compute because they spun up full adversary infrastructure from scratch every morning. The longer simulation reused persistent agents, cache, and pre-compiled tooling. The trade-off: the short test felt urgent, but the long test cost less carbon and found deeper persistence gaps. Measure wattage, not calendar days.

What about the travel cost of on-site red teamers?

That is the elephant. A single round-trip from London to Sydney emits roughly 3.4 metric tons of CO₂ per person—more than some small red-team cloud bills for an entire quarter. If your team of four flies out for every engagement, travel alone can swamp your carbon ledger. Remote ops slash that number, but they introduce latency and trust friction. The odd part is—some security leaders trade off travel cost against simulation fidelity, assuming in-person is inherently better. It is not. A well-provisioned remote outpost with VPN-direct tunnels and a local hardware drop can match on-site effectiveness for 80% of scenarios. The pitfall: travel is visible and easy to budget, so it rarely gets questioned. Start questioning it. Schedule one all-remote engagement per quarter and measure both carbon and detection rate. That hurts—because you might find the remote team performed better.

— Product lead at a fintech that cut travel from six trips to two per year

'We kept flying people in because 'that is how red team works.' Nobody asked if we could simulate the adversary without simulating an airline.'

— Engineering manager, critical infrastructure firm

How do we compare cloud vendor green claims without getting lied to?

You get suspicious. Cloud providers publish 'carbon-free energy percentage' and 'renewable matching' numbers that sound impressive but often exclude scope 3 emissions—the supply chain, the hardware manufacturing, the network gear. A hyperscaler can claim 100% renewable for your region while the actual electrons feeding your GPU cluster come from a grid that is 40% coal. They buy renewable energy certificates to paper over the gap. Legitimate? Technically. Honest?

Not always true here.

Barely. Compare using the location-based emission factor, not the market-based one. Some teams skip this step entirely—they trust the dashboard. Don't. Pull the hourly carbon intensity from your cloud provider's API and compare it to the regional grid average. If the numbers diverge by more than 15%, ask for a breakdown. The vendor that shares the raw data is the vendor worth negotiating with.

What is the single biggest mistake teams make when trying to run a low-carbon long-duration simulation?

Starting the carbon conversation too late. Most teams design the simulation for detection coverage, adversary realism, and budget—then tack on 'make it green' as a fudge factor in week three. By then the architecture is locked: high-compute bastion hosts, redundant logging pipelines, always-on command-and-control relays. Rewiring those after the fact costs engineering time and political capital. The fix is brutal and simple: put carbon as a design constraint on day one, alongside engagement length and team size. That means asking 'how many watts does this attacker kill chain require?' before you pick the malware loader. I have seen this reverse a decision to use a simulation cluster the size of a small streaming farm. They swapped to a 60% smaller footprint and lost 1% fidelity. That is a trade-off worth taking every time. Start early, measure honestly, and never let a green badge replace a real kilowatt number.

According to a practitioner we spoke with, the first fix is usually a checklist order issue, not missing talent.

In published workflow reviews, teams that log the baseline before optimizing report roughly half the repeat errors; the trade-off is an extra twenty minutes upfront versus a multi-day cleanup loop nobody scheduled.