Copilot for Security goes GA with hourly SCU pricing on April 1

With general availability of Copilot for Security coming up, I've seen security teams get noticeably more curious, and the conversations have become more concrete. That's especially true for teams already working with Microsoft Defender XDR and Sentinel. Microsoft announced April 1, 2024 as the GA date and will bill through consumption-based Security Compute Units (SCUs) charged per hour. That announcement raises at least as many practical questions as it does excitement. If you already run security operations on Microsoft, the main thing is to understand what actually changes with this offering and what stays as it is.

Security Compute Units are billed by the hour

SCU-based hourly pricing (announced at $4 per SCU per hour) is quite different from the license models we're used to in the security stack. In practice, you can start Copilot for Security as small as you want, with just a few SCUs that are provisioned and metered as you go. In many of the tenants I work in, people like this flexibility because teams want to show value before they commit serious budget. The model invites careful experimentation. During early pilots in particular, you have to watch actual usage and spend closely. Microsoft states clearly that you can scale capacity up or down as requirements change, which keeps risk and cost under control.

SOC teams already on Defender XDR and Sentinel benefit first

The teams that gain the most right away are SOCs that already work heavily in Defender XDR and Sentinel. You can use Copilot for Security in its standalone portal, but it's also embedded directly in Defender XDR, Sentinel, Intune, Entra and Purview, so analysts get answers in context, inside the tools they already use. Promptbooks and plugins are meant to speed up research and reporting. If your detection and response stack isn't mature, though, or you rely on a non-Microsoft SIEM/SOAR, Copilot for Security won't fill those gaps on its own. Its answers depend entirely on the underlying data and the signals available. It doesn't replace analysts, but it can help them work faster and more effectively.

Practical tip: Start with a few SCUs, track how they're used and compare usage against your goals and budget at regular intervals. That gives you the most solid basis for a business case for Copilot for Security.

Copilot for Security adds its own layer of roles

Access control matters a lot in day-to-day operations. Permissions aren't handled only through Entra ID roles. Copilot also has its own owner and contributor roles, which give you granular control over resources and capabilities. In many tenants, access and role assignment is already a constant struggle, and Copilot for Security brings another layer that has to be documented and monitored properly. Map the Copilot permissions to your existing Defender XDR and Sentinel roles so that no gaps or over-privileged users slip through.

Good answers depend on good data

One question comes up again and again: where does Copilot for Security get its data, and what happens to sensitive information? The official documentation states that data is processed within the Microsoft cloud and isn't used to train third-party models. You still need to check which data Copilot can actually see and whether the important logs, workbooks or templates exist at all. For scenarios like incident analysis or Entra ID investigations, Copilot relies on the data sources connected to the Microsoft stack. If key logs are missing or the data is incomplete, the answers will be incomplete as well. I'd recommend reviewing your detection and audit pipelines so Copilot has the best possible basis to work from.

The following diagram shows how Copilot for Security connects user queries, Microsoft cloud components and data sources:

flowchart LR
  user["User"] --> portal["Copilot for Security Portal"]
  portal --> scus["Security Compute Units"]
  portal --> defender["Defender XDR"]
  portal --> sentinel["Microsoft Sentinel"]
  portal --> entra["Entra ID"]
  portal --> purview["Purview"]
  defender --> logs["Security Data"]
  sentinel --> logs
  purview --> logs

Figure: Context sources and data flow of Copilot for Security in one view.

A small pilot with real measurements is the right start

Generative AI in security gets a lot of hype, and I'd be careful with it. My recommendation is to activate only a handful of SCUs for Copilot for Security, keep a close eye on usage and judge value (and cost) against clear metrics before you scale. The official getting started guide is useful for the initial setup. If you already have a solid Defender XDR or Sentinel deployment, you can pilot Copilot for Security as an add-on without a large upfront investment. That makes it easier to justify the spend and to show management and compliance a measurable benefit.

Copilot for Security is powerful but not magic

Security teams will certainly be interested in Copilot for Security, but it won't solve every problem. The hourly SCU model makes organizations think hard about usage and ROI, and at the same time it allows flexible pilots sized to real needs. Without good data and sound detection processes, Copilot for Security is just a nice new interface. For security teams focused on Microsoft, it's still an option I'd seriously look into. I'm curious how the first projects turn out. If you're interested in Copilot more broadly, my article on Copilot with Commercial Data Protection vs. Copilot for Microsoft 365 might also be worth reading.