> For the complete documentation index, see [llms.txt](https://helpdesk.augmentt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://helpdesk.augmentt.com/stonly-import-secure-defender/troubleshooting-defender-policy-deployment-and-compliance.md). # Troubleshooting Defender Policy Deployment and Compliance *Source guide title in Stonly: "What are you seeing?". This is an interactive decision tree in Stonly; it has been flattened here, with each entry state as a section.* Use this troubleshooter when a Defender policy deployment fails, a recommendation sits as Partially Compliant after you've made the change in the tenant, or a check shows as Not Measured. **How Augmentt reports Defender posture.** Augmentt's Defender security recommendations are sourced from the Microsoft Secure Score. Microsoft indicates that a 24–72 hour delay is to be expected for the Secure Score to reflect changes made to the tenant's posture. Pick the state that matches what you're seeing in Augmentt: * Policy deployment failed with a Forbidden / 403 error * Recommendation shows Partially Compliant after I made the change * Check shows Not Measured / no data * I just need to check which Defender licenses are required ## Forbidden / 403 on deploy A Forbidden response almost always means Augmentt's connection to the tenant doesn't carry the permission it needs to write the Defender configuration — not that the policy itself is wrong. There are four places this breaks, in the order they're most likely to be the cause: 1. Admin role on the connection 2. Permissions granted by the integration type 3. Defender licensing in the target tenant 4. Overall connection health ### 1. Check the admin role on the connection Open the customer in Augmentt, go to **Configuration → Integrations**, and look at the M365 connection's service account. Defender policy writes require one of: * Global Administrator * Security Administrator * Exchange Administrator (for Safe Links / Safe Attachments / anti-phishing policy writes) If the account is only Security Reader or Global Reader, reads will succeed and writes will fail with Forbidden. Promote the role (or re-authorize with a correctly-scoped account), then retry the policy deployment. ### 2. Check the integration type's permissions The type of integration decides which Microsoft permissions Augmentt can use: * **CSP with AdminAgents group membership** — the broadest grant. Writes to Defender policies generally succeed. * **GDAP** — Augmentt builds and maintains the GDAP relationship during onboarding, so you don't typically assemble it manually. What can break later is the relationship being revoked, consent expiring, or a partner-side change that severs it. If the integration is GDAP-based and policy writes are failing, check the M365 connection's health indicator in Configuration → Integrations and follow the connection-errors troubleshooter if it's warning or red. * **Direct integration** — Augmentt registered the app in the customer tenant during onboarding and the integrated service account was assigned the required roles at that time. If someone on the customer side has since removed or demoted the service account (dropping Global, Security, or Exchange Administrator), policy writes will start failing with Forbidden. Verify the current role assignments in Entra admin center → Users → \[the Augmentt service account] → Assigned roles. ### 3. Confirm the tenant's Defender licensing A Forbidden response can also surface when the tenant simply doesn't have the Defender license the policy requires. Microsoft's response to a policy-write call against an unlicensed tenant is an authorization error, not a licensing error — which is why this one often gets misdiagnosed as a permissions issue. Check the tenant's active Microsoft subscriptions in **Microsoft 365 admin center → Billing → Your products**, then compare against the license matrix below. ### 4. Check the integration's connection health If admin role, integration-type permissions, and licensing all look right, the last thing to rule out is the M365 connection itself. Stale consent, a revoked token, or a customer-side Conditional Access change can all break a previously-working connection. In Augmentt, open **Configuration → Integrations** for the customer and check the M365 integration's connection health indicator. If it's warning or red — or you've worked through everything above and the deploy is still failing — walk through **Troubleshooting M365 Integration Connection Errors**. It covers Conditional Access, Risky User detections, and the disconnect/reconnect workflow in one place. Once the integration is back in a healthy state, retry the Defender policy deployment. ## Partially Compliant after change If you changed the setting in the Defender portal (or via Augmentt) and the recommendation still reads Partially Compliant, one of four things is usually happening: 1. You're inside the Secure Score propagation window (24–72h) 2. The recommendation is a composite — you only flipped one of the sub-settings 3. The policy applies to a narrower group than the check expects (scope mismatch) 4. Augmentt's cached view hasn't refreshed since the change ### 1. Rule out the Secure Score propagation window first Augmentt reads Defender posture from the Microsoft Secure Score. Microsoft's own documentation notes that changes can take 24–72 hours to reflect in the Secure Score value. Quick check: 1. Open Microsoft Defender portal → Secure Score for the tenant. 2. Find the same recommendation by name. 3. Compare its state to what Augmentt shows. If Microsoft Secure Score and Augmentt agree, you're inside the propagation window. Let it run overnight and re-check. If Microsoft Secure Score shows the change has taken effect but Augmentt still shows Partially Compliant after 72 hours, continue to the next check. ### 2. Check composite recommendations Several Defender recommendations are composite — they roll up multiple underlying settings. A common example: an anti-phishing recommendation that requires impersonation protection enabled, mailbox intelligence enabled, and actions set to Quarantine. Flipping one of these moves the roll-up from 0 to about 33%, not to Compliant. Open the recommendation in the Microsoft Defender portal and expand the details panel. Microsoft lists the underlying sub-settings and their current state. Any sub-setting that still reads non-compliant keeps the roll-up at Partially Compliant. Apply the missing sub-settings and wait one full Secure Score refresh cycle. ### 3. Check the policy's user/group/domain scope Defender policies can be scoped to specific users, groups, or domains. Microsoft's Secure Score evaluates whether the policy covers all users in scope; if you deployed a policy to a pilot group only, the recommendation will read as Partially Compliant even when the policy itself is perfect. Check the policy's scope in the Defender portal: 1. Defender portal → Email & collaboration → Policies & rules → Threat policies 2. Open the policy. 3. Look at the Users, groups, and domains section. If the scope excludes domains or user groups that Secure Score expects covered, either widen the scope, or — if the narrow scope is intentional — acknowledge the control as Partially Compliant by design. ### 4. Force a posture refresh in Augmentt Augmentt caches Defender posture between ingestion cycles to keep the UI responsive. Occasionally the cached view lags behind the live data, especially right after a Microsoft-side fix. 1. In Augmentt, open **Secure → Defender** for the customer. 2. Click **Refresh posture** (or reload the page if no explicit button is shown). If the value still lags, wait for the next ingestion cycle (runs on a rolling schedule throughout the day) and re-check. ## Not Measured / no data Not Measured means Augmentt didn't receive a value from Microsoft for that check on the most recent ingestion — not that the control is failing. The four causes, in order of likelihood: 1. The tenant doesn't have the Defender licensing the check requires 2. The check exists in Microsoft Secure Score but reads as Not Measured there too 3. Augmentt's last ingestion cycle missed the tenant (auth or API throttling) 4. The check is in a known Microsoft error state on their side ### 1. Confirm the required Defender license is assigned Not Measured on a Defender check usually means the tenant doesn't carry the license Microsoft requires for that specific control. The control exists in Augmentt's catalogue, but Microsoft returns no data because the feature isn't provisioned in the tenant. Confirm the tenant's subscriptions in **Microsoft 365 admin center → Billing → Your products** and compare against the license matrix below. ### 2. Compare against Microsoft Secure Score Open Microsoft Defender → Secure Score for the tenant and find the same control by name. If Secure Score also shows Not Measured, the issue is on Microsoft's side — their evaluator hasn't run yet, or the tenant needs a one-time configuration touch for Microsoft to start measuring. Follow the Microsoft "How to address this" guidance on the Secure Score card itself. If Secure Score shows a value but Augmentt shows Not Measured, the data didn't make it into Augmentt's last ingestion. Continue to the next check. ### 3. Check Augmentt's last ingestion cycle If Microsoft Secure Score has the value and Augmentt shows Not Measured, Augmentt didn't successfully pull the data on its last cycle. Common causes: * A stale M365 integration connection (consent lapsed, token revoked) * Microsoft Graph throttling that caused the tenant to be skipped on that cycle * A customer-side Conditional Access policy blocking the service account during the ingestion window Check connection health in **Configuration → Integrations**. If it's warning or red, follow *Troubleshooting M365 Integration Connection Errors*. Otherwise, wait for the next scheduled ingestion cycle (runs throughout the day) and re-check. ### 4. Rule out known Microsoft-side error states Some Defender controls intermittently return error states from Microsoft's evaluator that surface in Augmentt as Not Measured. The most common patterns: * Recently-renamed controls that Microsoft re-keys on their side — both Secure Score and Augmentt will show Not Measured for about one evaluation cycle. * Tenants in Microsoft-managed migration windows (most often GCC High and sovereign-cloud tenants). * Controls that depend on Microsoft 365 apps the tenant hasn't finished provisioning (for example, a newly added Exchange Online license that hasn't replicated). If Microsoft Secure Score shows the same control as Not Measured and Microsoft's "How to address this" guidance doesn't apply, give it one full Secure Score refresh cycle (up to 72h) before escalating. ## Defender license matrix (quick reference) Use this as a quick reference when a tenant's Defender posture checks aren't producing the results you expect. The matrix covers the six Augmentt Defender checks most commonly flagged in support tickets. | Augmentt check | Minimum required Microsoft license | | -------------------------------------------- | ------------------------------------------------------------- | | Safe Links policy (users, groups, domains) | Defender for Office 365 Plan 1 | | Safe Attachments policy | Defender for Office 365 Plan 1 | | Anti-phishing policy (impersonation, spoof) | Defender for Office 365 Plan 1 | | Preset security policies (Standard / Strict) | Defender for Office 365 Plan 1 | | Attack simulation training | Defender for Office 365 Plan 2 | | Threat Explorer / Real-time detections | Plan 1 (Real-time detections) · Plan 2 (Threat Explorer full) | **Where Defender for Office 365 is included:** Plan 1 ships with Microsoft 365 Business Premium and is available as a standalone add-on; Plan 2 is included with E5 Security and E5, or as a standalone add-on. *Last validated against Microsoft documentation on 2026-04-22. Microsoft updates these service descriptions periodically — re-check the Microsoft Learn pages if you're diagnosing a check introduced or renamed recently.* ## Escalation checklist When you open a ticket with Augmentt Support, include the following so we can move straight to investigation: * Customer tenant ID (GUID) and the Augmentt customer name * Exact Augmentt check / policy name you're trying to deploy or that's showing the issue * Screenshot of the error (or the state — Partially Compliant / Not Measured) * Approximate time (with timezone) you last made the change in the tenant * Integration type (CSP / GDAP / Direct) and the admin role assigned to the service account * Confirmation that the Microsoft Secure Score shows the same value for the same control (if relevant) * Whether you've already completed this troubleshooter and which step you stopped at That last item is the one that saves the most cycles — it tells us exactly where to pick up. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://helpdesk.augmentt.com/stonly-import-secure-defender/troubleshooting-defender-policy-deployment-and-compliance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.