Before you do anything with Security Copilot, check whether it’s already running. If your organisation is on Microsoft 365 E5 or E7, Microsoft may well have provisioned it for you, quietly, as part of the licence. It turns up with a monthly allocation of compute and a set of default roles already attached, and most people don’t notice until someone opens the portal and starts poking around. That “it’s already on” moment is exactly when the setup matters most, because the defaults are not what you’d choose if you’d sat down and thought about it.
I’ll leave the incident-investigation side for another day. The bit nobody walks you through is the enablement and the permissions, and that’s the bit that actually decides whether this thing is safe to have switched on.
It might already be provisioned
The licensing splits into two camps, and which one you’re in changes everything about setup.
If you’re on Microsoft 365 E5 or E7, Security Copilot is included and auto-provisioned. You get an allocation of Security Compute Units, the compute that powers it, scaled to your licence count: 400 units a month for every 1,000 paid user licences, up to a ceiling of 10,000. That allocation resets every month and doesn’t roll over, so unused capacity just evaporates. Nothing to buy, nothing to stand up. It’s on.
If you’re not on E5 or E7, none of that applies. You provision the compute yourself, which means an Azure subscription and someone with the right roles to create the capacity. Different starting line entirely, so confirm your licence position before you follow any guide, including this one. Half the confusion online comes from people following E5 steps without an E5 licence, or the reverse.
What you’re actually paying for: compute units
Security Copilot runs on Security Compute Units, or SCUs, and they come in two flavours. Provisioned capacity is always-on. You decide how many units to keep warm, and you pay for them by the hour whether Copilot does a single thing or sits idle all weekend. Overage is the opposite: on-demand units that kick in when you exhaust the provisioned ones, billed only when used.
The gotcha is the provisioned side. It’s billed hourly on what you’ve reserved, not on what you consume, so an oversized always-on allocation is money quietly leaving the building. If you’re just standing it up to have a look, Microsoft’s own recommendation is modest: three provisioned units with overage set to unlimited. Worth knowing that the standalone portal will even let you set provisioned to zero and run entirely on overage, which is effectively pay-as-you-go and a sensible way to trial it without committing to warm capacity you might not touch.
Provisioning the capacity needs more than a credit card. You’ll want Azure Contributor or Owner on the subscription or resource group, plus Security Administrator or higher in the tenant. The usage dashboard keeps ninety days of history, and it’s where you go to see what’s actually being consumed before you decide how much to reserve. Look at real usage first, size the capacity second.
The default depends on when you deployed
Copilot Contributor isn’t a Microsoft Entra role. Security Copilot has its own two platform roles, Owner and Contributor, that live inside Copilot and only govern access to the platform itself. Who gets Contributor out of the box is the part that has changed, and it’s worth knowing which era your tenant belongs to.
New instances now default to the Recommended Microsoft Security roles group: a bundle that grants Contributor access only to users who already hold security-relevant Entra roles. That’s a sensible middle ground, and if you’re standing Copilot up fresh, it’s what you’ll get.
Older instances are a different story. Earlier deployments defaulted to granting Copilot Contributor to every user in the tenant through the built-in Everyone group, and existing customers who have that assignment keep it until someone removes it. So the day-one check is simple: open Role assignment and look at what’s actually there. If the Everyone group is still assigned, remove it and replace it with either the recommended roles bundle or a scoped group of the people who should genuinely have access. One wrinkle to know before you act: once the Everyone group is removed, it can’t be assigned again, so this is a one-way door (a good one, but a door).
If you do use your own groups, note that Security Copilot only supports role-assignable groups, and assign roles to groups rather than individuals. It’s less to manage and far easier to review six months later.
Copilot inherits permissions, it doesn’t grant them
This is the part that reassures people once they understand it, and trips them up before they do. Security Copilot uses on-behalf-of authentication, which means it can never see more than the signed-in user can already see. It has no privileges of its own. It borrows yours.
So Contributor access gets someone onto the platform, but it gets them no data. To actually pull Sentinel incidents, the user still needs a Sentinel role like Microsoft Sentinel Reader. To see devices and policies through the Intune connection, they need an Intune role. Defender is the same. The real scoping of what Copilot can touch happens in the underlying products, through their normal RBAC, not in Copilot’s own settings. That’s a good thing. It means your existing least-privilege model carries straight through.
It also means you should resist a tempting shortcut. Granting someone Security Administrator hands them Copilot Owner access automatically, but it also gives them a pile of tenant-wide security permissions that have nothing to do with Copilot. Microsoft says this plainly, and they’re right: don’t hand out a privileged role just to unlock Copilot. Put the person in the scoped group instead.
Owners, and why PIM belongs here
A handful of Entra and Purview roles inherit Copilot Owner automatically: Global Administrator and Security Administrator as you’d expect, but also Billing Administrator, Intune Administrator and Compliance Administrator. A Billing Admin silently holding Copilot Owner is exactly the kind of default worth knowing about. Owner can manage capacity, plugins, workspaces and roles, so it’s worth knowing exactly who holds it by inheritance rather than by design.
For those high-privilege roles, this is textbook Privileged Identity Management territory. Make them eligible rather than permanently assigned, require activation, and you shrink the standing pool of people who can reconfigure the platform down to nobody until somebody actually needs it. While you’re in the settings, turn audit logging on. It’s a Security Administrator action, it applies across all workspaces, and you’ll want it long before you think you need it.
Workspaces and a sensible rollout
If you’re running more than one team or region, workspaces let you carve capacity up and right-size it per team, each backed by its own compute. If you provisioned Copilot before workspaces existed, one was created for you in the background, so it’s already there whether you’ve looked at it or not.
The rollout that works is the unexciting one. Start with a small provisioned allocation or none at all, a tightly scoped access group, owners locked behind PIM, audit logging on, and the underlying product RBAC doing the real gatekeeping. Watch the usage dashboard for a couple of weeks. Then, and only then, widen access and tune the capacity to what you’ve actually seen.
The interesting work, the investigations and the promptbooks, comes after all this. But none of it is safe or sensible until the boring part is done properly. Get the capacity sized, get the Everyone group out of Contributor, and let your existing permissions model do its job. That’s the whole setup, and it’s almost entirely things you already know how to do.
Originally published at alanconlon.com, where I post practical security, Azure and data write-ups every other Tuesday.
Top comments (0)