Microsoft Security Copilot breaks the per-seat habit: it is priced on consumed capacity, measured in Security Compute Units (SCUs), rather than on a count of analyst licences. An SCU represents a unit of the AI compute that powers Security Copilot's investigations, summaries, and automations. You provision SCUs to make the service available, and your bill is driven by how much capacity you reserve and how much you consume beyond it. Because the model is capacity-based rather than seat-based, the buyer-side question is not "how many analysts" but "how much capacity, provisioned how, governed by what controls." It sits alongside the other consumption-priced AI decisions in our complete Microsoft licensing guide.
This matters because a capacity model behaves very differently from a licence model at budgeting time. A per-user SKU is predictable: headcount times price. A capacity model flexes with usage, which is more efficient when managed and more volatile when not. The discipline that makes Security Copilot affordable is governing the capacity, not counting the people.
What a Security Compute Unit is
An SCU is the unit of provisioned AI capacity for Security Copilot. Capacity is provisioned by the hour: you set a number of SCUs that the service can draw on, and that provisioned capacity is what the service uses to run prompts, agents, and automated workflows. The amount of capacity a given workload consumes depends on the complexity and volume of the tasks it runs — a high volume of automated investigations consumes more capacity than occasional analyst-initiated queries.
Because provisioning is hourly, capacity can be scaled up and down. This is the central lever: an organisation can provision a baseline of SCUs for steady-state use and adjust as demand changes, rather than locking in a fixed analyst-licence count regardless of activity.
Provisioned capacity and overage
The model distinguishes the capacity you provision from usage that exceeds it. Provisioned SCUs are the capacity you reserve and pay for whether or not fully used in a given hour. Where workloads spike beyond the provisioned level, an overage mechanism allows the service to keep running by drawing additional capacity, billed on top of the provisioned baseline. The buyer-side implication is the mirror image of the Provisioned Throughput logic in Azure OpenAI: provision the baseline against typical demand, and let overage absorb genuine spikes, rather than over-provisioning a baseline sized for the rare peak.
The governance principle: with a capacity model, the cost driver is which workloads are allowed to consume SCUs and how aggressively. Automated, always-on agents and high-frequency workflows consume far more capacity than analyst-initiated queries. The single most effective cost control is deciding deliberately which automations run, at what cadence, and capping or scheduling the high-consumption ones — then sizing the provisioned baseline to that governed demand rather than to unconstrained usage.
Capacity model vs per-seat model at a glance
| Dimension | Per-seat AI SKU (e.g. M365 Copilot) | Security Copilot (SCU capacity) |
|---|---|---|
| Billing basis | Per user per month | Per provisioned SCU (hourly) + overage |
| Cost predictability | Fixed, headcount-driven | Flexes with provisioned capacity and usage |
| Main cost driver | Number of licensed users | Capacity provisioned and workload intensity |
| Scaling | Add/remove seats | Scale SCUs up or down by the hour |
| Key control | Right-size the licensed population | Govern workloads and size the baseline |
The buyer-side cost levers
Three levers control Security Copilot spend. The first is baseline sizing: provision SCUs against typical, governed demand rather than peak, and rely on overage for genuine spikes. Over-provisioning a baseline that sits idle is paid for in full, just as idle reserved capacity is in any capacity model. The second is workload governance: identify the automations and agents that consume the most capacity and decide consciously whether their value justifies their consumption — scheduling, capping, or disabling the ones that do not.
The third lever is scope and rollout pacing. Because capacity flexes by the hour, Security Copilot lends itself to a measured rollout: provision a modest baseline, instrument which use cases actually consume capacity and deliver value, then scale the baseline to match proven demand. This avoids the common pattern of provisioning generously "to be safe" and discovering the standing cost before the value is established.
Where it sits in your agreement
Security Copilot capacity is provisioned through Azure and draws on your Azure commitment, so it interacts with the broader Microsoft commitment you negotiate at renewal — much as Azure OpenAI consumption does. A fast-growing security-AI workload can draw down a commitment faster than forecast, and Microsoft will often cite AI adoption as grounds to push a larger forward commitment. Treat Security Copilot capacity as a managed, negotiable line within the wider Azure and Microsoft 365 estate rather than an unmanaged standing cost, and reconcile it against the per-seat AI you already license so the two are not paying for overlapping capability. Our Microsoft licensing experts model security-AI capacity against the wider estate so adoption strengthens, rather than weakens, your renewal position.
The decision sequence
The practical buyer sequence is: (1) identify the security use cases that justify Security Copilot and the workloads each implies; (2) start with a modest provisioned baseline and instrument actual SCU consumption by use case; (3) separate steady analyst-driven demand from high-consumption automations; (4) govern the automations explicitly — schedule, cap, or disable the ones whose value does not justify their capacity draw; (5) size the provisioned baseline to governed steady demand and let overage absorb spikes; (6) revisit capacity quarterly as adoption grows and workloads change.
The mistake to avoid is treating a capacity model like a seat model — provisioning a large fixed baseline up front and leaving it ungoverned. Capacity rewards active management. For adjacent decisions, see the consumption logic in Azure OpenAI commitment & pricing, the entitlement question in Microsoft Purview audit licensing, and the committer-based model in GitHub Advanced Security licensing. For the broader renewal framework, the Microsoft EA guide sets out how AI capacity folds into an enterprise agreement.