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.
Is Security Copilot already turned on in your tenant?
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.
What do you need before provisioning Security Copilot capacity?
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. That's Azure Contributor or Owner on the subscription or resource group, plus Security Administrator or higher in the tenant. You also need to buy at least one provisioned SCU. 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. On E5 or E7 they come from the included monthly allowance, and none of this section's buying decisions apply. If you're buying standalone, 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. On the standalone route you can't go lower than one provisioned unit, though. Microsoft requires a minimum of one, so there's no running purely on overage. One unit with overage on top is the cheapest way to trial it.
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. There's a whole post on sizing SCUs without overpaying.
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 get someone into 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 territory for Privileged Identity Management. 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 Owner settings, turn on Logging audit data in Microsoft Purview, and make sure auditing is switched on in Purview itself. You'll want those logs long before you think you need them.
How do you set up Security Copilot workspaces?
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 your tenant was set up automatically through E5 or E7, a default workspace was created for you, so it's already there whether you've looked at it or not.
If you're provisioning yourself, the first-run setup in the Security Copilot portal walks you through it:
- Pick the Azure subscription that will pay for the capacity.
- Pick or create a resource group.
- Give the capacity a name.
- Choose the prompt evaluation location.
- Set the number of provisioned SCUs, and decide on overage.
- Link the capacity to your workspace.
The rollout that works is the unexciting one. Start with a small provisioned allocation, even a single unit, 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.
I write about security, Azure, data, and the practical side of running things. If this was useful, connect with me on LinkedIn.
Originally published at alanconlon.com, where I post practical security, Azure and data write-ups every other Tuesday.
Top comments (0)