Microsoft Security Copilot Deployment Architecture - Plan your deployment
Should Microsoft Security Copilot capacity's be provisioned in their own Azure subscriptions?
Have you Aligned your Security copilot capacity deployment with your Azure governance strategy?
Since Microsoft Security Copilot is a cloud-based service running in Azure, it must adhere to the same governance, security, and compliance frameworks as other cloud-native workloads. Well almost. In enterprise environments following Azure Landing Zone best practices, Security Copilot should be deployed in a way that aligns with established subscription models, resource segregation policies, and governance controls.
Consistency with Azure Landing Zone Design
Organizations that have implemented an Azure Landing Zone typically follow a structured subscription and management group hierarchy, ensuring:
Segregation of workloads based on function (e.g., security, networking, applications).
Controlled access and governance policies across different business units.
Enforcement of compliance and security baselines using Azure Policy and Microsoft Defender for Cloud.
Although some of this is not relevant, Security Copilot, as a critical security platform should align with this design and reside within a dedicated SEPARATE security subscription,
For context, see the examples below relating to Microsoft Sentinel.
When deploying Microsoft Security Copilot, one of the key architectural decisions is whether to provision it in its own dedicated Azure subscription or integrate it into an existing security-focused subscription. The answer depends on multiple factors, including security, operational efficiency and cost management requirements. However if in doubt, create a new Subscription!
Key Considerations for Separate Subscription Design
Let’s first understand the 3 components of RBAC relating to Security Copilot.
“Security Copilot RBAC roles are not Microsoft Entra roles. Security Copilot roles are defined and managed within Copilot and only grant access to Security Copilot features.”
This fact is important. It emphasizes the separation and standalone nature of the platform.
“Microsoft Entra RBAC grants access across the Microsoft portfolio of products including services that contain security data. These roles are managed through the Microsoft Entra admin center. For more information, see Assign Microsoft Entra roles to users.”
This item is key, as the “On Behalf Of” design means, you (The user or app orchestrating the prompt) must have access to run prompts against data and platforms connected to the tool.
“Azure RBAC controls access to Azure resources like Security Capacity Units (SCU) in a resource group, or Microsoft Sentinel-enabled workspaces. For more information, see Assign Azure roles.”
Potentially the most important item is “Azure RBAC” access to provision or de-provision the Security Copilot Capacity.
Security Copilot Stand-Alone Platform
Microsoft Security Copilot should be viewed as a standalone security platform, not just an extension of existing Microsoft Security tooling. While its native integration with Microsoft Defender XDR, Sentinel, and other security solutions is a key strength, its true power lies in its flexibility and extensibility.
By treating Security Copilot as an independent platform rather than just another Microsoft security feature, organisations can strategically architect their security operations in a way that aligns with Zero Trust principles. This means:
You could use Security Copilot with third-party integrations only – it does not require the full Microsoft security stack.
It should be secured and managed like any other cloud-hosted security solution, rather than assuming inherent security from the Microsoft ecosystem.
It supports a modular security strategy, allowing organisations to use AI-driven insights across a multi-vendor security environment.
Why This Perspective Matters
Taking this approach ensures that Security Copilot is deployed, managed, and secured with the same rigour as any other cloud-based security solution. This reinforces the Zero Trust model, where:
Every component is validated, authenticated, and monitored regardless of its origin.
Access is restricted based on least privilege rather than assumed trust.
Security Copilot is seen as a critical asset that requires dedicated security governance.
This approach forces security teams to ask:
Would we trust Security Copilot if it was developed by a third-party vendor?
Are we applying the same security governance and controls as we do for any other SaaS security tool?
By stepping back and recognising Security Copilot as an independent AI-powered security platform, organisations can fully harness its capabilities while ensuring it is deployed and managed with the level of security it demands.
So back to our architectural decision
Security & Access Control
One of the biggest advantages of placing Security Copilot in a dedicated subscription is enhanced Role-Based Access Control (RBAC) and segmentation of duties:
Security teams can enforce a least-privilege model, ensuring only specific users can access and manage Security Copilot Capacity Units (SCU).
If the tool is deeply embedded in your real-time cybersecurity operations, especially in scenarios where it supports non-human operators (e.g., automated security workflows, SOAR integrations) or is a key assistant to Level 1 (L1) analysts during night shifts, losing access, whether by accident or intent, could have devastating consequences.
Cost Management & Billing Transparency
A dedicated subscription for Security Copilot Capacity Units can significantly enhance cost tracking and visibility, making it easier to:
Attribute costs specifically to security functions rather than blending them with general IT or cloud consumption costs.
Optimize and forecast Security Copilot’s usage costs, particularly in organizations with strict budgeting and chargeback models.
Prevent unexpected cost spikes from being buried in broader cloud spending, making it easier to justify Security Copilot’s ROI to leadership.
Operational Efficiency & Governance
Managing Security Copilot Capacity Units separately allows organizations to:
Implement clear governance policies and ensure security tool management is handled by the appropriate teams.
Minimize cross-team conflicts, where non-security teams might have unintended impacts on Security Copilot’s deployment, configuration, or data access.
Maintain flexibility for future security architecture changes without disrupting business-critical applications or IT services.
Security Copilot architectural decision tree
Step 1: Subscription Considerations
Do you have an existing subscription that can be used for Microsoft Security Copilot?
Yes → Are RBAC permissions correctly configured?
Yes → Will you use a Specific New RG?
Yes → Proceed to Step 3.
NO → Create a New Subscription & RG. Assess and secure RBAC permissions.
Step 3: Do you have regulatory requirements to keep data in different Azure geographies?
Yes: Ensure your TENANT geo region is correct. Why? Understand the difference between customer and System Generated.
Understand the difference between Platform location & Prompt Evaluation!
No preference on the above: Proceed to provisioning.
Best Practices: When to Use a Dedicated Subscription for Security Copilot Capacity Units
A separate subscription is recommended if:
✔ Your organization has strict regulatory requirements for security tools and must ensure auditability and isolation.
✔ You need enhanced cost visibility and tracking for security operations.
✔ Your security team operates independently from IT and cloud engineering teams, reducing interdepartmental conflicts.
✔ You are deploying Security Copilot in a highly sensitive or regulated environment.
✔ You want strong RBAC controls to limit access and ensure least privilege access is enforced.
❌ When It’s Acceptable to Use an Existing Subscription
It may be sufficient to use an existing security-focused subscription (e.g., Microsoft Sentinel, Defender XDR) if:
✔ You already have a dedicated security subscription for all Microsoft security tools and wish to maintain a centralized approach.
✔ Your IT and security teams are aligned, and there is no risk of cross-team conflicts.
✔ Your organization prioritizes simplicity over strict subscription segmentation, and cost tracking isn’t a major concern.
✔ You have strong governance policies in place to prevent accidental misconfigurations by non-security teams.
Final Thought: Security Copilot Capacity Unit deployment as Part of a Well-Architected Security Landing Zone
Since Security Copilot operates in Azure, it should be governed closely to the same security, compliance, and operational best practices as any other cloud security tool.
Deploying Capacity Units within a dedicated security subscription, aligned with your Azure Landing Zone architecture, ensures that it remains secure, and operationally efficient while minimizing risk exposure.
#MicrosoftSecurity
#MicrosoftLearn
#CyberSecurity
#MicrosoftSecurityCopilot
#Microsoft
#MSPartnerUK
#msftadvocate