Microsoft Security Copilot: Fix Setup & Config Errors
Why Microsoft Security Copilot Stops Working (Or Never Works at All)
I've worked with dozens of security teams who expected Microsoft Security Copilot to just light up the moment they signed their agreement , and then watched it do absolutely nothing. No response to prompts. Plugins that refuse to connect. Embedded experiences in Defender XDR that are greyed out entirely. I know that feeling. When a tool is supposed to help you triage incidents at machine speed and it can't even get past the login prompt, it's genuinely maddening.
Here's the reality: Microsoft Security Copilot is not a simple toggle-on product. It sits on top of a layered stack , Security Compute Units (SCUs) for capacity, plugin configurations for data sources, role-based access controls for who can even see it, and product-level integrations with Defender XDR, Microsoft Sentinel, Microsoft Intune, and Microsoft Entra. If any single layer in that chain is misconfigured, the whole experience breaks. And Microsoft's error messages, when they appear at all, rarely tell you which layer is the problem.
The most common reasons I see Microsoft Security Copilot failing in the field:
- SCU capacity not provisioned or provisioned in the wrong Azure region, the product literally cannot run without compute units assigned to your tenant.
- Plugin permissions not granted, Security Copilot relies on plugins as data sources. If your Microsoft Defender Threat Intelligence plugin, Sentinel plugin, or Intune plugin aren't authorized, you'll get empty or irrelevant responses.
- Missing role assignments, the Security Copilot Administrator or Security Copilot Contributor roles need to be explicitly assigned in Microsoft Entra. Default global admin doesn't always carry through the way you'd expect.
- Trying to use it on a US Government cloud, this one catches a lot of public sector customers. Security Copilot is not designed for GCC, GCC High, DoD, or Microsoft Azure Government tenants. If you're on one of those, you're blocked by design, not by a bug.
- Embedded experiences not appearing in Defender XDR, this is typically a plugin toggle issue or a Defender plan licensing gap.
- Prompts returning vague or hallucinated answers, usually a sign that the grounding plugins aren't properly connected, so the language model is working without your organization's actual security context.
The frustrating part is that the product's own error surface is thin. You won't always see a red error screen. Sometimes it's just a blank response, or a "something went wrong" with no event ID or error code attached. That's what this guide is built to cut through. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into plugin configs and registry paths, there's one check that resolves the majority of Microsoft Security Copilot issues I see. Go straight to the Security Copilot capacity settings and confirm your SCUs are actually provisioned and running.
Here's how to check:
- Open Microsoft Security Copilot at
securitycopilot.microsoft.comand sign in with your work account. - Click the Settings gear icon in the lower-left navigation rail.
- Select Owner settings from the menu that appears.
- Look at the Security compute units section. You should see a number greater than zero assigned, along with an Azure subscription and a region.
- If the value reads 0 SCUs or the field is blank, that's your problem. No SCUs means no compute. The product physically cannot process any prompts.
If SCUs are at zero, click Set up a capacity and walk through the provisioning wizard. You'll need an Azure subscription with sufficient permissions (Owner or Contributor on the subscription). Pick the region closest to your users, latency matters for interactive security workflows. Start with a minimum of 1 SCU for testing, but plan for 3–5 SCUs for a real security operations team doing active incident response.
Once SCUs are provisioned, go back to the main prompt window and type something simple like "What are the top recent threat intelligence articles from Microsoft Defender?", if you get a real, contextual response, the base layer is working and you can move on to fine-tuning your plugins and integrations.
Even with SCUs provisioned, users who don't have the right roles assigned in Microsoft Entra will hit a wall the moment they try to access Security Copilot. This is one of the most common causes of "access denied" or a completely blank experience after login.
Microsoft Security Copilot uses two primary roles:
- Security Copilot Administrator, full access including owner settings, plugin management, capacity configuration, and the audit log.
- Security Copilot Contributor, standard user access for running prompts, using promptbooks, and interacting with the embedded experiences.
To check and assign these roles:
- Open the Microsoft Entra admin center at
entra.microsoft.com. - Navigate to Identity > Roles & admins.
- Search for "Security Copilot" in the role search box.
- Click on Security Copilot Administrator, then click Add assignments and select the appropriate admins.
- Repeat for Security Copilot Contributor for your security analysts.
One thing that trips teams up: being a Global Administrator in Entra does not automatically grant Security Copilot access. You still need the explicit role assignment. This is by design, it enforces least-privilege for AI-powered security tooling.
After assignment, have the affected user sign out of all Microsoft sessions, wait 2 minutes, and sign back in. Role changes don't always propagate instantly to active sessions. If they still can't access the product, run this PowerShell check to confirm the role assignment landed:
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
Get-MgDirectoryRole | Where-Object { $_.DisplayName -like "*Security Copilot*" }If the command returns your two Security Copilot roles with members, the assignment is confirmed on the directory side.
Microsoft Security Copilot doesn't answer questions from thin air. It grounds its responses in real data pulled through plugins. If your plugins are disabled or unauthorized, you'll get responses that feel hollow, generic, or just wrong, because the AI is operating without your actual environment's context. This is one of the biggest reasons security teams dismiss the product as "not useful" when it actually just needs to be properly wired up.
To manage plugins:
- In the Security Copilot portal, click the Settings gear icon in the lower-left.
- Select Plugins from the menu.
- You'll see sections for Microsoft plugins and Non-Microsoft plugins.
- Under Microsoft plugins, confirm these are toggled ON:
- Microsoft Defender XDR, needed for alert triage, incident context, and KQL query generation.
- Microsoft Sentinel, needed for SIEM data, hunting queries, and incident correlation.
- Microsoft Intune, needed for device compliance and endpoint security context.
- Microsoft Defender Threat Intelligence, needed for threat actor profiles, CVE data, and intelligence articles.
- Microsoft Entra, needed for identity risk signals and user context.
For each plugin, click Set up if it hasn't been configured. Some plugins require you to authorize them against a specific workspace (Sentinel) or tenant connection (Defender XDR). Follow the authorization prompts, they'll redirect you briefly to consent screens. This is normal and expected.
Once plugins are enabled, go back to the main prompt window and ask: "Summarize the top active incidents in Microsoft Defender XDR right now." If the plugin is connected properly, you'll get a real list. If you still get a generic "I don't have access to that information" response, the plugin's authorization didn't complete, go back and re-authorize.
One of the most powerful ways to use Microsoft Security Copilot is directly inside Microsoft Defender XDR, right on the incident page, alert details, and hunting workspace. But a lot of teams set up the standalone portal correctly and then find that nothing appears inside Defender XDR. The Security Copilot button is missing, or greyed out, or clicking it does nothing.
Here's what to check:
Check 1, Defender XDR plan level. The embedded Security Copilot experience in Defender XDR requires that your organization has Microsoft Defender for Endpoint Plan 2 or Microsoft Defender XDR at minimum. Defender for Business or Defender for Endpoint Plan 1 won't surface the embedded prompting interface. Go to Microsoft 365 Defender > Settings > Endpoints > License and confirm your plan.
Check 2, Confirm the Defender XDR plugin is enabled. Even if you did this in step 2, double-check by going to Security Copilot portal > Settings > Plugins > Microsoft Defender XDR. Make sure it says On and shows a green connected indicator. If it says "Not configured," click Set up and re-authorize.
Check 3, Browser extension or policy blocking the frame. The embedded Security Copilot panel in Defender XDR renders inside an iframe. If your browser has strict iframe policies or if a corporate proxy is stripping certain headers, the panel will appear blank or won't load. Test in a private browser window with extensions disabled. If it works there, the issue is a local browser configuration.
After completing these checks, navigate in Defender XDR to Incidents & alerts > Incidents, open any active incident, and look for the Security Copilot panel on the right side of the incident page. If it appears and shows an incident summary, you're fully connected.
A promptbook is a saved sequence of prompts that automates a repeatable investigation workflow inside Microsoft Security Copilot. Think of it as a runbook, but written in plain English and executed against your live security data. If your team keeps running the same five questions every time an alert fires, a promptbook eliminates that manual work entirely.
If you're trying to use a promptbook and it's either not appearing or not returning expected results, here's how to troubleshoot and build one correctly:
- From the Security Copilot home screen, click the Promptbooks icon in the left navigation (it looks like a stacked page icon).
- Click New promptbook.
- Give it a name, something specific like "Incident Triage, Initial Scope" works better than "My Promptbook 1".
- Add your first prompt: "Summarize this incident and list all affected devices and users."
- Click the + button to add a second prompt: "Generate a KQL query to hunt for similar activity across the past 30 days."
- Add a third: "What threat intelligence exists on the top indicators of compromise from this incident?"
- Click Save promptbook.
To run it: open any incident, click the promptbook name, and hit Run. Security Copilot will execute each prompt in sequence, passing context forward between steps. This is the grounding process at work, each step gets richer because it builds on what came before.
If the promptbook runs but returns empty steps, the issue is almost always the plugin required for that specific prompt isn't authorized. Match each prompt to its plugin dependency and verify that plugin is enabled in your Plugin settings.
This one is subtle but important. Microsoft Security Copilot can appear to be working, it returns responses, it doesn't throw errors, but the answers are vague, off-topic, or clearly not based on your actual environment. This is the grounding problem, and it's almost always fixable.
Security Copilot works by taking your prompt, preprocessing it through a grounding step that adds specificity and context, then sending the modified prompt to the language model. After getting a response from the model, it post-processes the output using plugins to add real data. If your plugins aren't feeding real context in either direction, the model falls back to general knowledge, which is not what you want when you're triaging a live incident.
Steps to improve response quality:
Be explicit about your data source in the prompt. Instead of "What's happening with this alert?", say "Using Microsoft Defender XDR, summarize incident INC-00234 and list all associated MITRE ATT&CK techniques." The more specific your prompt, the better the grounding works.
Check the Defender Threat Intelligence plugin specifically. Vague threat context in responses almost always means this plugin isn't connected. Go to Plugins > Microsoft Defender Threat Intelligence and confirm it's authorized. Then ask: "What do you know about threat actor Midnight Blizzard based on Microsoft's threat intelligence?", a connected plugin will return a detailed, sourced answer.
Use the feedback buttons. Every Security Copilot response has a thumbs up/thumbs down button. Use them consistently. Microsoft uses this signal (in aggregate, with privacy controls) to improve response quality over time. More importantly, clicking thumbs down opens a feedback field where you can note what was wrong, this is also logged to your Security Copilot audit log for your own review.
Verify you're in the right session type. The standalone portal at securitycopilot.microsoft.com gives you a broader, unconstrained prompt workspace. The embedded experience inside Defender XDR or Sentinel is scoped to that product's context. If you're in an embedded experience and asking about Intune device compliance, the response will be weak because you're outside Intune's context scope. Match your prompt location to your data source.
Advanced Troubleshooting for Microsoft Security Copilot
Using the Security Copilot Audit Log
If you're an administrator trying to figure out why a specific user's experience is broken, the audit log is your best diagnostic tool. It records every action taken within Security Copilot, prompt submissions, plugin activity, promptbook executions, and owner setting changes.
To access it: go to Security Copilot portal > Settings > Owner settings > scroll down to Audit log. Click View audit log. This takes you to the Microsoft Purview audit log, pre-filtered for Security Copilot events. Look for events with SecurityCopilot as the workload. You can filter by user, date range, and operation type to narrow down exactly what happened, and what failed.
Admin Activity Export API for Bulk Diagnostics
For enterprise environments where you need programmatic access to audit data, Microsoft provides the Admin Activity Export API. This lets you pull Security Copilot activity logs into your SIEM or custom dashboard. If you're running Security Copilot at scale across a large SOC, this is how you monitor usage patterns, identify users who can't connect, and detect anomalous prompt behavior.
The API endpoint requires an Entra access token scoped to your tenant. You'll authenticate via OAuth 2.0 and call the activity export endpoint documented in the Security Copilot developer reference. Parse the returned JSON for "operationType" fields, errors will surface as distinct operation types that you can alert on.
Enterprise and Domain-Joined Scenarios
In large enterprise environments, Conditional Access policies in Microsoft Entra are a frequent culprit. If your CA policies require compliant devices or specific named locations for app access, users on non-compliant devices or VPN-connected sessions from unexpected locations will silently fail to authenticate to Security Copilot. Check your Conditional Access policies in Entra and look for any policy that targets "All cloud apps", make sure Security Copilot (application ID bb558b01-a7be-4f00-b288-0d3b6bab3a71) is either explicitly included or not unintentionally blocked.
Group Policy can also interfere if your organization uses GPO to control browser behavior, proxy settings, or certificate trust. Security Copilot's portal and embedded experiences communicate over HTTPS to Microsoft's cloud endpoints. If a GPO is forcing traffic through a TLS-inspecting proxy that doesn't trust Microsoft's certificates, the connection will fail with no obvious error message. Test by accessing the portal from a machine not subject to the relevant GPOs and compare the result.
Checking the Microsoft Sentinel Connection
The Sentinel plugin for Microsoft Security Copilot requires you to specify which Log Analytics workspace to connect. If you have multiple workspaces, which is common in enterprise environments, the plugin may be connected to the wrong one and returning no data. Go to Plugins > Microsoft Sentinel > click the plugin name > review the configured workspace. If it's pointing at a test workspace instead of your production workspace, that's your issue. Re-authorize against the correct workspace.
If you've confirmed SCUs are provisioned, roles are assigned, plugins are authorized, and you're on a commercial cloud tenant, and things still don't work, it's time to escalate. This is especially true if the Security Copilot portal returns HTTP 500 errors consistently, if the audit log shows authorization failures you can't explain, or if a specific Microsoft security product integration is broken despite your plugin being correctly configured. Contact Microsoft Support and open a ticket under the Security category. Include your tenant ID, the specific symptom you're seeing, and the timeframe when it started. Screenshots of the plugin status screen and any error messages in the audit log will dramatically speed up your support case.
Prevention & Best Practices for Microsoft Security Copilot
Getting Microsoft Security Copilot working is one thing. Keeping it working, and making sure your security team actually gets value from it, is a different discipline. I've seen organizations where the tool was technically functional but practically unused because nobody had set up the right workflows. Here's how to avoid that.
Set up regular plugin health checks. Plugin authorizations can expire, especially when service accounts used for authorization have password rotation policies or when the underlying Microsoft product (Sentinel, Defender) goes through a major update. Once a month, have an admin walk through the Plugins page and confirm every plugin shows a green connected status. It takes 10 minutes and prevents weeks of degraded responses going unnoticed.
Train your team to write specific prompts. The quality of your Security Copilot experience is directly tied to the quality of your prompts. Generic prompts get generic responses. Build an internal prompt library, a SharePoint page or Teams channel works fine, where analysts share the prompts that returned the most useful results. Over time this becomes a real institutional asset. Microsoft provides prompting tips in the official documentation as a starting point.
Use promptbooks for every repeatable workflow. If your team follows the same investigation steps more than twice a week, that workflow belongs in a promptbook. Common candidates: initial alert triage, threat actor research, KQL query building for a new detection rule, executive incident summary generation. Promptbooks also enforce consistency, every analyst runs the same investigation steps, not just the senior ones who remember all the questions to ask.
Review the audit log monthly for capacity planning. The Admin Activity Export API and audit log data tell you how many prompts are being run per day, by which users, and which plugins are being accessed most. If you're consistently hitting SCU limits, indicated by slower response times during peak hours, you need to scale up capacity before it starts affecting your actual incident response work.
Keep an eye on US government cloud restrictions. If your organization is transitioning to or from a US government cloud environment, be aware that Security Copilot availability changes significantly. Commercial cloud tenants have full access; GCC, GCC High, DoD, and Azure Government tenants do not. If you're planning a cloud migration, include this in your security tooling assessment so you're not left with a gap.
- Schedule a monthly 10-minute plugin health check, confirm every plugin shows green before it quietly breaks on you.
- Build a shared prompt library in Teams or SharePoint so your whole team benefits from the best-performing prompts your analysts discover.
- Create at least one incident triage promptbook before your next major security event, you want it ready, not built during an active breach.
- Pull the audit log into your SIEM via the Admin Activity Export API so you have visibility into Security Copilot usage patterns alongside your other security telemetry.
Frequently Asked Questions
What exactly is Microsoft Security Copilot and how is it different from regular Copilot?
Microsoft Security Copilot is a generative AI security solution built specifically for security operations work, incident response, threat hunting, intelligence gathering, posture management, and policy management. It's not the same as Microsoft 365 Copilot, which handles productivity tasks like email and documents. Security Copilot is purpose-built for defenders and runs on OpenAI architecture combined with Microsoft's own security-specific plugins and global threat intelligence. It integrates directly with security products like Defender XDR, Sentinel, Intune, and Entra, so it can answer questions about your actual environment, not just general knowledge. Think of it as having a very fast, very knowledgeable tier-2 analyst available at all times who already has eyes on all your security tools simultaneously.
Where can I actually use Microsoft Security Copilot, is it only in the standalone portal?
No, you can access Security Copilot in two distinct ways. The standalone experience lives at securitycopilot.microsoft.com and gives you an open-ended prompt workspace with full access to all your connected plugins and promptbooks. But there are also embedded experiences built directly into other Microsoft security products. Inside Microsoft Defender XDR, you'll find Security Copilot on the incident page, in the threat hunting workspace, and in alert details. Microsoft Sentinel, Intune, Entra, Azure Firewall, Azure Web Application Firewall, Microsoft Purview, and Defender for Cloud also have their own embedded Security Copilot surfaces. The embedded experience is scoped to the context of that specific product, while the standalone portal lets you pull from all connected plugins at once.
How does Security Copilot actually generate its responses, is it just ChatGPT for security?
It's built on OpenAI's architecture, but the process is significantly more structured than a general chat model. When you submit a prompt, Security Copilot first runs a grounding step, it preprocesses your prompt using your connected plugins to add specificity and organizational context before the language model ever sees it. The modified prompt goes to the language model, which generates a response. Then Security Copilot post-processes that response using your plugins again to add real data from your environment, actual alert data, threat intelligence articles, device records, and so on. So the final response you see has been grounded in your actual security environment twice: once before and once after the language model processes it. That's why plugin configuration is so critical, without connected plugins, you're missing both grounding steps.
Can I use Microsoft Security Copilot if my organization is on a US government cloud?
Not currently. Microsoft's official position is explicit: Security Copilot is not designed for customers on US government clouds, which includes GCC, GCC High, DoD tenants, and Microsoft Azure Government. This applies to the standalone portal and all embedded experiences. If you're on one of these clouds and trying to figure out why Security Copilot doesn't appear in your Defender XDR or why the portal gives you an access error, that's the reason, it's not a bug you can fix. For guidance on when or if government cloud support might come, you'd need to speak with your Microsoft account representative directly, as Microsoft hasn't published a public timeline.
What are Security Compute Units and how many do I actually need?
Security Compute Units (SCUs) are the billing and capacity model for Security Copilot, they represent the computational resources allocated to your tenant for processing prompts. Without any SCUs provisioned, the product doesn't work at all. Each SCU is provisioned as a unit of capacity per hour through an Azure subscription. For a small security team doing light usage, occasional incident triage and threat research, 1–2 SCUs is a reasonable starting point. For an active SOC doing continuous monitoring, hunting, and incident response across multiple analysts simultaneously, you'll typically need 5–10 SCUs to avoid response degradation during peak hours. Microsoft's capacity page in the Owner settings shows your current usage so you can right-size over time. Start conservative and scale up based on actual usage data rather than guessing upfront.
Can my developers build custom agents or plugins for Security Copilot?
Yes, this is a real and documented capability. Microsoft has a full developer path for extending Security Copilot with custom agents, and developers can also build and publish plugins to a security store. Agents can be built using natural language descriptions, the agent builder form UI, YAML file uploads, manifest files, or the Model Context Protocol (MCP). Each method has different complexity trade-offs, natural language and the form are entry points for security practitioners who aren't full-time developers, while YAML and MCP are more appropriate for engineering teams building production-grade integrations. Custom plugins can pull in data from your own systems, ServiceNow, internal threat intelligence platforms, custom CMDB data, and make that context available during Security Copilot's grounding process so responses reflect your specific environment's topology and history.