This report is designed for security administrators, IT operations teams, and SOC analysts who need granular visibility into every security finding in their Microsoft Entra environment. It provides a searchable, entity-level breakdown of all findings with technical descriptions, remediation steps, compliance mappings, and portal links.
How this data was obtained: the Siemserva auditor read this tenant's Microsoft 365, Intune, Defender, and Entra ID configuration directly through Microsoft's official cloud APIs: Microsoft Graph (identities, roles, Conditional Access, applications, Intune devices and policies, and sign-in and audit logs) and the Microsoft Defender for Endpoint vulnerability management API. Patch and vulnerability findings are enriched with public threat intelligence (MSRC, CISA KEV, EPSS, NVD). Access is read-only; nothing in the environment was changed during the audit. Findings reflect the environment as of the audit date shown in the report header.
Siemserva's audit discovered 22 findings across 3 tenants, spanning 18 unique check types and 36 affected entities. The largest concentration — 132% (29 findings) — is in General Security, making it the primary area to investigate. Estimated total remediation effort is ~1.4–2.6 business days.
Immediate Attention: 7 findings are rated Critical or High and should be addressed first. Critical findings concentrate in General Security (2). Scroll to the Findings by Entity table for a searchable drill-down, or use the Detail Reference below for step-by-step remediation.
Quick Wins: 2 High or Critical finding types can be resolved in under 30 minutes each, providing fast, measurable risk reduction.
Critical — severe security gaps detected that require immediate action.
The Siemserva Risk Heatmap is a deterministic risk score (0-100, higher is worse) computed the same way in every Siemserva report: no AI, no sampling, no external data. The worst severity present places the score in a band (Critical 85-100, High 65-84, Medium 40-64, Low 20-39, Healthy below 20), and within the band the score rises with the count of worst-tier findings on a saturation curve, so the first few findings have the most impact.
Critical — AI assessment: severe gaps, immediate action required.
The AI Risk Assessment is an independent evaluation performed by a large language model that reads every finding in this audit. Unlike the deterministic Heatmap above, the AI considers contextual factors that a formula cannot — such as how findings combine to form attack chains, whether a misconfiguration exposes privileged accounts or sensitive data, and the blast radius of each gap across your tenant. The AI assessed risk at 72, lower than the Siemserva Risk Heatmap score of 86. This can happen when the AI considers compensating controls or partial mitigations that the deterministic formula does not account for. The severity band above uses 86 (the Senserva floor) because it is grounded in actual finding counts and severity distribution. Together, the two gauges give you both an objective, repeatable baseline and contextual intelligence about the real-world severity of your security posture.
| Entity | Tenant | Privilege | Context |
|---|---|---|---|
| WS-PC-123 | Contoso Retail | Not Privileged | — |
| WS-PC-170 | Zava Demo | Not Privileged | — |
| Entity | Tenant | Privilege | Context |
|---|---|---|---|
| Expedite critical updates (autopatc…) | Fabrikam Engineering | Not Privileged | — |
| Expedite critical updates (autopatc…) | Contoso Retail | Not Privileged | — |
| Expedite critical updates (autopatc…) | Zava Demo | Not Privileged | — |
| Entity | Privilege | Context |
|---|---|---|
| ExpiredVendorIntegration | Not Privileged | — |
| Entity | Privilege | Context |
|---|---|---|
| CVE-2025-29824 | Not Privileged | — |
Consolidated patch and vulnerability posture across Windows Autopatch, Windows Update for Business / Intune update rings, and Microsoft Defender for Endpoint threat & vulnerability management. Configuration-level findings and per-device patch gaps are unified here so the full patch story sits in one place.
6 finding types across Windows Update for Business and Windows Autopatch. Configuration-level findings (update rings, update-profile assignments, Autopatch updatable-asset enrollment, deployment audience health, the catalog probe, and CVE-coverage gaps in active deployments).
2 devices with 1 distinct finding type. Sources: Defender for Endpoint machinesVulnerabilities (CVE + product roll-up), getmissingKbs (KB-level patch gaps), Windows build lag, and Defender coverage gaps. One row per (device, finding) tuple; sorted by severity then device name.
| Severity | Device | Tenant | Finding | Details |
|---|---|---|---|---|
| Critical | WS-PC-123 | Contoso Retail | Intune Device Vulnerability Kev | Device has one or more vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. |
| Critical | WS-PC-170 | Zava Demo | Intune Device Vulnerability Kev | Device has one or more vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. |
| End of per-device patch posture — 2 rows across 2 devices | ||||
Across 36 tenants scanned, the dominant risk is a patch management execution failure: devices carry CISA KEV-listed vulnerabilities (Critical) while the Autopatch infrastructure meant to remediate them is misconfigured — empty audiences, unenrolled asset groups, and excessive reboot delays create a false sense of coverage. Two tenants have devices with actively exploited CVEs confirmed in the wild, and at least one tenant has a KEV-specific Autopatch gap meaning the fix exists in the catalog but is never delivered. Identity risk signals (risky sign-ins proceeding without challenge) and cosmetic-only sensitivity labels compound the exposure across the fleet. ---
Key risks identified by AI with attack scenarios and blast radius, ordered by severity.
1. [Critical] — KEV-Listed Device Vulnerabilities (Active Exploitation) Devices in Tenant-001 and Tenant-002 carry CVEs on CISA's Known Exploited Vulnerabilities catalog, meaning threat actors are actively using these vulnerabilities in the wild right now.
IntunePolicyAutopatchDeploymentNoMembers and IntunePolicyAutopatchUpdatableAssetGroupNotEnrolled mean the automated remediation pipeline is broken — patches exist but are not delivered. Risky sign-ins (ImRiskLevelDuringSignin) proceeding without challenge suggest identity signals are also not being actioned, leaving both endpoint and identity vectors open.Portal: https://security.microsoft.com/
2. [High] — Autopatch Deployment Has Zero Members (Patch Pipeline Broken) Three tenants (Tenant-001, Tenant-002, Tenant-003) have Autopatch deployments with empty audiences, meaning the patch management system is running but delivering nothing.
IntuneDeviceVulnerabilityKev (Critical) and IntunePolicyAutopatchCveGapKev (High) to persist. Combined with IntunePolicyAutopatchUpdatableAssetGroupNotEnrolled, the entire Autopatch stack is non-functional across all three affected tenants.Portal: https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/overview
3. [High] — KEV CVE Has No Active Autopatch Deployment (Tenant-001) Finding IntunePolicyAutopatchCveGapKev confirms that for at least one KEV-listed CVE, a KB fix exists in the Windows Update catalog but no deployment targets it.
IntuneDeviceVulnerabilityKev (Critical) confirming that devices are already vulnerable AND the deployment gap is confirmed. This is not theoretical — the KEV hit and the gap hit co-exist in the same tenant.Portal: https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/overview
4. [High] — Expired Application Secret (Tenant-001) AsAppSecretExpired indicates an app registration's secret has lapsed, breaking dependent service authentication and creating pressure for emergency credential handling.
Portal: https://entra.microsoft.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade
5. [Medium] — Autopatch Asset Groups Not Enrolled in Deployment Service IntunePolicyAutopatchUpdatableAssetGroupNotEnrolled across all three tenants means Entra security groups are registered as Autopatch targets but their member devices have never been enrolled with the deployment service.
IntunePolicyAutopatchDeploymentNoMembers persistent — even if audiences are populated, unenrolled devices do not receive patches.Portal: https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/overview
6. [Medium] — Excessive Reboot Delay in Autopatch Deployments IntunePolicyAutopatchDeploymentRebootDelayLong in all three tenants means devices can defer reboots beyond 5 days after patch delivery, leaving them technically "patched" but functionally vulnerable.
Portal: https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/overview
7. [Medium] — Critical CVE Patch Gap in Autopatch (2 tenants) IntunePolicyAutopatchCveGapCritical in Tenant-001 and Tenant-002 shows CVSS 9.0+ CVEs with available KB fixes that no active deployment covers.
IntuneDeviceVulnerableSoftware (Low) which confirms installed vulnerable software is already inventoried — the risk is known but unaddressed.Portal: https://security.microsoft.com/
8. [Medium] — Cosmetic Sensitivity Labels with No Protection (3 tenants) PurviewLabelNoProtection across all three tenants means sensitivity labels are applied to content but enforce no encryption, rights management, or content marking.
Portal: https://compliance.microsoft.com/
9. [Low] — Risky Sign-Ins Proceeding Without Challenge (8 events, 3 tenants) ImRiskLevelDuringSignin recorded risk signals at sign-in but no blocking or MFA step-up was enforced, meaning sessions proceeded despite the risk detection.
ImConditionalAccessPolicyBlocksAllButAllowedCountries, Info) exists in Tenant-001 but the risky sign-in events span Tenant-001, Tenant-002, and Tenant-003 — suggesting the other tenants may lack equivalent location controls.Portal: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/RiskySignInsBlade
| Severity | MCSB Controls | SCuBA Controls |
|---|---|---|
| Critical | LT-1, LT-3 | — |
| High | IM-3, LT-1, LT-3, PV-6 | MS.AAD.5.1v1, MS.AAD.5.2v1, MS.AAD.5.3v1 |
| Medium | DP-1, DP-3, IM-6, LT-1, LT-3, PV-6 | MS.AAD.3.3v2, MS.AAD.3.4v1, MS.AAD.3.5v1 |
| Low | IM-1, LT-1, LT-3, PA-4 | MS.AAD.1.1v1, MS.AAD.2.1v1, MS.AAD.2.2v1, MS.AAD.2.3v1, MS.AAD.3.1v1, MS.AAD.3.2v1 |
Note: Finding counts and domain statistics shown in the tables above are computed directly from audit data and are authoritative. If the AI narrative below differs from those numbers, the data tables are correct.
The most significant pattern in this scan is not any single vulnerability but the compound failure of the entire Autopatch pipeline across all three affected tenants. Three distinct findings — IntunePolicyAutopatchDeploymentNoMembers, IntunePolicyAutopatchUpdatableAssetGroupNotEnrolled, and IntunePolicyAutopatchDeploymentRebootDelayLong — form a kill chain against the patch management system itself: assets are not enrolled, deployments have no audiences, and even when patches land, reboot deferral keeps devices vulnerable.
The consequence is confirmed by IntuneDeviceVulnerabilityKev (Critical, 2 tenants) and IntunePolicyAutopatchCveGapKev (High, Tenant-001): the patch pipeline failure is not hypothetical — it has already resulted in devices carrying KEV-listed CVEs with no active remediation path. The CVE gap findings (IntunePolicyAutopatchCveGapCritical, IntunePolicyAutopatchCveGapHigh) show the pipeline is failing at multiple CVSS severity tiers simultaneously.
Why Microsoft dashboards miss this: Intune's Autopatch dashboard shows deployment status as "healthy" when audiences are configured but empty. There is no native alert that correlates "zero enrolled devices" + "KEV CVE present on device" + "no deployment covers the KEV KB." This analysis surfaces the three-layer failure as a single attack chain that Secure Score and the Intune compliance dashboard each only partially surface in isolation.
Eight risky sign-in events (ImRiskLevelDuringSignin) across three tenants proceeded without MFA challenge or block. The geo-fencing CA policy (ImConditionalAccessPolicyBlocksAllButAllowedCountries) exists in Tenant-001 but the distribution of risky sign-in events across all three tenants suggests Tenant-002 and Tenant-003 lack equivalent compensating controls.
The expired app secret (AsAppSecretExpired, Tenant-001) adds a credential lifecycle gap. Emergency rotation under production outage pressure is a known source of security regressions — weak secrets, plain-text storage, over-permissioned replacements. The absence of certificate-based authentication on this registration compounds the risk.
Why Microsoft dashboards miss this: Entra's Risky Users blade surfaces individual risk detections but does not correlate "risk detected + no CA policy enforced + session proceeded" as a unified finding. The cross-tenant pattern (3 tenants, 8 events, no enforcement) is only visible when looking across the fleet, not within a single tenant's dashboard.
Sensitivity labels across all three tenants (PurviewLabelNoProtection) have HasProtection = false, meaning they are cosmetic classifiers only. Content labeled "Confidential" or equivalent receives no encryption, no rights management, and no content marking. This creates a compliance theater risk: leadership and auditors see a labeling program in place, but the labels provide zero technical enforcement against exfiltration, forwarding, or unauthorized access.
This finding compounds with the risky sign-in gap: if a compromised account accesses labeled-but-unprotected content, the data leaves with no technical barrier and no rights-management audit trail to reconstruct what was accessed or shared.
Why Microsoft dashboards miss this: Microsoft Purview's label dashboard shows label adoption rates and coverage statistics but does not surface the distinction between labels with and without protection actions in its summary metrics. A tenant can show 90% labeling coverage while 100% of those labels enforce nothing — a gap this analysis directly identifies from the HasProtection field.
The highest-risk narrative in this scan connects four findings into a single chain:
IntunePolicyAutopatchDeploymentNoMembers + IntunePolicyAutopatchUpdatableAssetGroupNotEnrolled → Autopatch is inert.IntuneDeviceVulnerabilityKev → KEV CVEs persist on endpoints because the patch pipeline cannot deliver fixes.ImRiskLevelDuringSignin (no enforcement) → A compromised identity can reach the vulnerable endpoint without challenge.PurviewLabelNoProtection → Data accessed via the compromised session and vulnerable endpoint carries no rights management, enabling silent exfiltration.No single finding here would individually score Critical across all four dimensions. The compounding of medium-severity infrastructure failures with Critical endpoint vulnerabilities and uncontrolled identity sessions creates a full attack path from initial access through data exfiltration that native dashboards do not present as connected.
This is not a complete list of all relevant references. Additional documentation and portal links appear throughout the report sections above.
36 entities with findings, sorted by worst severity. Click any row to expand and see full finding details including risk, remediation actions, and compliance mappings.
Produced by: Siemserva CLI (--reporter --reporter-ai)
Active validators: the AI text was checked against the following rules before the report was written.
System prompt: the exact instructions given to the AI to produce the analysis above.
You are a Microsoft 365 and Azure security expert covering Entra ID, Intune, Exchange Online, SharePoint, Teams, OneDrive, and connected workloads. You surface insights that Microsoft's own dashboards do not show. Analyze the scan results to discover novel patterns and correlations. Focus on: - Cross-domain interactions (e.g., Identity gaps + weak Logging = blind spots for incident response) - Privilege escalation paths that combine multiple medium-severity findings into high-severity attack chains - Correlations between finding clusters that suggest systemic issues (e.g., apps with excessive permissions also lacking conditional access = compounding risk) - Things that will make a security professional think "I didn't know that" — go beyond what Secure Score and Microsoft Defender show Be analytical, not alarmist. Evidence-based, not prescriptive. Every insight must reference specific findings from the scan data. Show the data, let the reader draw conclusions. Your audience: security managers, IT directors, SOC leads, and MSSP consultants who need to explain risk to business stakeholders. Formatting rules (the response will be displayed in a terminal and an HTML report): - You MUST use these exact section headers in this order: ## Executive Summary ## Risk Score ## Fix First ## Quick Wins ## Risk Assessment ## Recommendations ## Full Analysis ## References - Executive Summary: 2-4 sentences for a security manager. Lead with the overall risk posture, highlight the most critical gap, and state what immediate action is needed. - Risk Score: A single integer 0–100 representing YOUR independent risk assessment (higher = more risk). Band logic: Critical present → 85–100; High only → 65–85; Medium only → 40–65; Low only → 20–40; nothing → 0. Adjust within the band for privilege exposure and lateral-movement risk. Output ONLY the integer (e.g. "78"). - Fix First: Exactly 3 fixes — highest-impact / lowest-effort changes. Each item: what to change, why it has highest risk-reduction value, estimated time to implement. Numbered list. - Quick Wins: Fixes completable in under 30 minutes each. Bullet list. Each item: the fix, the direct portal link to do it, and the specific finding it closes. Distinct from Fix First — focus on speed, not impact. - Risk Assessment: for each distinct risk write a structured entry. Start each with a bold title and severity label: **[Critical/High/Medium] — [Risk Name]**, then one sentence explaining what the misconfiguration enables. Follow with 2–3 sub-bullets: (1) realistic attack scenario an adversary would use, (2) blast radius if exploited, (3) any compounding factors with other findings. Include a direct link to the relevant Microsoft admin portal blade for context. Order by severity (Critical first). Cite specific finding names from the scan. - Recommendations: numbered list of the TOP 10 prioritized actions (highest risk first). Do not exceed 10 items. For each recommendation: (1) bold action title, (2) why this priority (severity × blast radius), (3) exact step-by-step instructions (2–3 steps), (4) a direct "Fix it now →" link to the exact Microsoft admin portal blade (Entra, Intune, Defender, Exchange, SharePoint, Teams), (5) relevant MCSB/SCuBA control code with link to learn.microsoft.com. Be specific — reference the exact finding name from the scan data. - Full Analysis: concise technical summary by domain (3-5 paragraphs total). Use ### sub-headers for each domain. Focus on cross-domain dependencies, attack chain connections, and execution order. Do NOT repeat step-by-step fixes already covered in Recommendations. For each domain, include a brief "Why Microsoft dashboards miss this" insight — explain what this analysis surfaces that the native Microsoft Secure Score, Entra recommendations, or Defender dashboards do not show (e.g., cross-domain attack chains, privilege compounding across roles, stale account blast radius, conditional access bypass combinations, or correlation patterns between findings). Only mention gaps where the value is clear and specific — do not make generic claims. - References: max 10 URLs on separate lines (not inline in prose). Pick the 10 most relevant. Prefer portal action links and Microsoft Learn documentation. Quality over quantity. - LINK LIST LIMITS: Any bulleted or numbered list of links must contain at most 10 items. This applies to Quick Wins, Fix First, Recommendations, References, and every other section. - Use bullet points (- or *) for lists, one item per line. - Keep lines under 90 characters. - Use short paragraphs (2-3 sentences max). Direct portal links — use these EXACT URLs in recommendations so admins can click straight into the right blade to fix issues: - Entra overview: https://entra.microsoft.com/ - Conditional Access policies: https://entra.microsoft.com/#view/Microsoft_AAD_ConditionalAccess/ConditionalAccessBlade/Overview - Authentication methods: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/AdminAuthMethods - MFA settings: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/MultifactorAuthenticationMenuBlade - Named locations: https://entra.microsoft.com/#view/Microsoft_AAD_ConditionalAccess/ConditionalAccessBlade/NamedLocations - Users: https://entra.microsoft.com/#view/Microsoft_AAD_UsersAndTenants/UserManagementMenuBlade/AllUsers - Groups: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/GroupsManagementMenuBlade/AllGroups - PIM: https://entra.microsoft.com/#view/Microsoft_Azure_PIMCommon/CommonMenuBlade/quickStart - PIM roles: https://entra.microsoft.com/#view/Microsoft_Azure_PIMCommon/ResourceMenuBlade/~/roles - App registrations: https://entra.microsoft.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade - Enterprise apps: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps - Consent & permissions: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/ConsentPoliciesMenuBlade - Security defaults: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/SecurityDefaultsBlade - Risky users: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/RiskyUsersBlade - Risky sign-ins: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/RiskySignInsBlade - Sign-in logs: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/SignInLogsMenuBlade - Audit logs: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuditLogsBlade - Diagnostic settings: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/DiagnosticSettingsMenuBlade - Device management (Intune): https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/overview - Compliance policies: https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesComplianceMenu - Microsoft Defender: https://security.microsoft.com/ - Exchange admin: https://admin.exchange.microsoft.com/ - SharePoint admin: https://admin.microsoft.com/sharepoint - Teams admin: https://admin.teams.microsoft.com/ Compliance framework links — cite these for MCSB and SCuBA controls: - MCSB overview: https://learn.microsoft.com/en-us/security/benchmark/azure/overview - MCSB controls: https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-identity-management (replace "identity-management" with: privileged-access, network-security, data-protection, asset-management, logging-threat-detection, etc.) - CISA SCuBA: https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project - CIS Benchmarks: https://www.cisecurity.org/benchmark/microsoft_365 When referencing a specific control (e.g., IM-7, PA-4, LT-1), link to the relevant MCSB page section. The HTML report renders markdown links as clickable hyperlinks. Reference link policy — ONLY cite URLs from these approved domains. Do NOT cite vendor blogs, cost management articles, FinOps content, product comparison sites, or any non-security reference. Approved domains: - learn.microsoft.com (Microsoft Learn documentation) - docs.microsoft.com (Microsoft Docs — legacy URLs) - entra.microsoft.com (Entra admin portal) - security.microsoft.com (Microsoft Defender / Security portal) - intune.microsoft.com (Intune admin portal) - admin.microsoft.com (Microsoft 365 admin center) - admin.exchange.microsoft.com (Exchange admin center) - admin.teams.microsoft.com (Teams admin center) - compliance.microsoft.com (Microsoft Purview) - cisa.gov (CISA SCuBA guidance) - nist.gov (NIST SP 800 publications) - owasp.org (OWASP Top 10) - techcommunity.microsoft.com (Microsoft Tech Community official posts only) If no approved source exists for a claim, omit the link rather than cite an off-topic one.