Files
AutopilotMonitor/rules/dist/analyze-rules.json
T
Oliver Kieselbach cf8fadfc17 fix(rules): drop AutoLogon false-positive on normal Autopilot enrollments
ANALYZE-SEC-002 fired Warning (confidence 90) on every normal user-driven
Entra-join enrollment. During ESP, Windows writes AutoAdminLogon=1 +
DefaultUserName + AutoLogonSID + no DefaultPassword for the enrolling user —
the exact fingerprint the sysinternals_autologon_suspected heuristic targeted
(enabled && user && !password). AutoLogon-enabled is registry-indistinguishable
from a Sysinternals/kiosk setup during Autopilot, so the heuristic and SEC-002
could never tell a benign enrollment from a real one.

Declare AutoLogon only when a plaintext password is actually present:
- delete ANALYZE-SEC-002 (broad AutoLogon-active warning)
- remove the non-discriminating sysinternals heuristic from AutoLogonAnalyzer
  (computation + finding label + checks.sysinternals_autologon_suspected)
- strip the sysinternals condition+factor from SEC-004 (kiosk allow-list, still
  a disabled opt-in template) and refresh its now-stale SEC-002 guidance
- ANALYZE-SEC-003 (plaintext DefaultPassword -> high) is now the sole default-on
  AutoLogon grade; the autologon_analysis event still carries all raw facts at Info

Tests: assert SEC-002 absent + no rule references the sysinternals signal; add
analyzer regression guard for enabled+user+no-password. V2-only, no ConfigVersion
bump. Build 0 err, AutoLogon 19/19, BuiltInRulesTests 8/8, web tsc clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-08 19:06:53 +02:00

1758 lines
78 KiB
JSON
Generated

{
"$schema": "../schema/analyze-rule.schema.json",
"rules": [
{
"ruleId": "ANALYZE-APP-001",
"title": "Win32 App Detection Script Failure",
"description": "Detects when a Win32 app detection script fails or returns unexpected results.",
"severity": "warning",
"category": "apps",
"enabled": true,
"baseConfidence": 60,
"conditions": [
{
"signal": "detection_failure",
"source": "event_type",
"eventType": "app_install_failed",
"dataField": "detectionResult",
"operator": "equals",
"value": "NotDetected",
"required": true
}
],
"confidenceFactors": [
{
"signal": "error_detail_match",
"condition": "exists",
"weight": 20
}
],
"explanation": "A Win32 app detection script failed or did not detect the app after installation. This causes the app to appear as 'not installed' despite successful installation.",
"remediation": [
{
"title": "Fix detection rules",
"steps": [
"Review the app's detection rules in Intune",
"Verify file/registry paths are correct",
"Test detection script manually on a device"
]
}
],
"tags": [
"apps",
"detection",
"win32"
]
},
{
"ruleId": "ANALYZE-APP-002",
"title": "App Installation Error",
"description": "Detects app installation failures with specific exit codes or HRESULT error codes and suggests fixes.",
"severity": "high",
"category": "apps",
"enabled": true,
"baseConfidence": 80,
"conditions": [
{
"signal": "install_error",
"source": "event_type",
"eventType": "app_install_failed",
"dataField": "message",
"operator": "regex",
"value": "16[0-9]{2}|0x80070[0-9a-fA-F]+|lpExitCode|unmapped.*exit",
"required": true,
"suppressByEvent": {
"eventType": "app_install_completed",
"joinField": "appId"
}
}
],
"explanation": "An app installation failed with a specific error code. Common MSI exit codes: 1603 (Fatal error during installation), 1618 (Another installation already in progress), 1619 (Package could not be opened), 1625 (Installation prohibited by policy). Common HRESULT codes are also captured.",
"remediation": [
{
"title": "Investigate the error code",
"steps": [
"Check the error code in the rule finding details",
"Look up the specific error code in Microsoft documentation",
"Review the IME logs on the device: C:\\ProgramData\\Microsoft\\IntuneManagementExtension\\Logs\\IntuneManagementExtension.log",
"Verify all prerequisites for the app are met",
"Check if another installation was running concurrently (error 1618)"
]
}
],
"tags": [
"apps",
"msi",
"error-code"
]
},
{
"ruleId": "ANALYZE-APP-003",
"title": "App Dependency Chain Failure",
"description": "Detects when an app fails because a dependency app failed to install.",
"severity": "high",
"category": "apps",
"enabled": true,
"baseConfidence": 70,
"conditions": [
{
"signal": "dependency_failure",
"source": "event_type",
"eventType": "app_install_failed",
"dataField": "message",
"operator": "regex",
"value": "dependency|prerequisite|required app|depends on|Dependency",
"required": true
}
],
"explanation": "An app installation failed because one of its dependency apps failed to install. Fix the dependency first, then retry.",
"remediation": [
{
"title": "Fix dependency chain",
"steps": [
"Identify which dependency app failed",
"Fix the dependency app first",
"Verify dependency chain order in Intune"
]
}
],
"tags": [
"apps",
"dependency"
]
},
{
"ruleId": "ANALYZE-APP-004",
"title": "Insufficient Disk Space",
"description": "Detects when disk space is critically low during enrollment, which can cause app installation failures.",
"severity": "critical",
"category": "apps",
"enabled": true,
"baseConfidence": 75,
"conditions": [
{
"signal": "low_disk",
"source": "event_type",
"eventType": "performance_snapshot",
"dataField": "disk_free_gb",
"operator": "lt",
"value": "5",
"required": true
}
],
"confidenceFactors": [
{
"signal": "app_failed",
"condition": "exists",
"weight": 15
},
{
"signal": "enrollment_failed",
"condition": "exists",
"weight": 10
}
],
"explanation": "Performance monitoring shows disk free space dropped below 5 GB during enrollment. This can cause app installation failures, especially for large Win32 apps.",
"remediation": [
{
"title": "Free disk space",
"steps": [
"Check device disk size meets minimum requirements",
"Clean up temporary files and IME cache (C:\\Windows\\IMECache)",
"Consider using a larger disk image"
]
}
],
"tags": [
"apps",
"disk-space",
"critical"
]
},
{
"ruleId": "ANALYZE-APP-005",
"title": "Content Download Timeout",
"description": "Detects when app content download times out or fails.",
"severity": "high",
"category": "apps",
"enabled": true,
"baseConfidence": 70,
"conditions": [
{
"signal": "download_timeout",
"source": "event_type",
"eventType": "app_install_failed",
"dataField": "errorPatternId",
"operator": "regex",
"value": "IME-DO-TIMEOUT|IME-ERROR-DOWNLOAD|IME-ERROR-NO-CONTENT",
"required": true
}
],
"explanation": "App content download timed out or failed. This is usually caused by network issues, proxy interference, or CDN problems. The IME log shows a Delivery Optimization timeout or download content error.",
"remediation": [
{
"title": "Improve download speed",
"steps": [
"Check network bandwidth",
"Verify proxy doesn't block *.delivery.mp.microsoft.com",
"Consider Delivery Optimization configuration"
]
}
],
"tags": [
"apps",
"download",
"timeout"
]
},
{
"ruleId": "ANALYZE-APP-006",
"title": "Reboot Required Loop",
"description": "Detects when the same app installation is attempted 3 or more times, indicating a reboot-required loop.",
"severity": "high",
"category": "apps",
"enabled": true,
"baseConfidence": 70,
"conditions": [
{
"signal": "reboot_loop",
"source": "event_count",
"eventType": "app_install_started",
"dataField": "appId",
"operator": "count_per_group_gte",
"value": "3",
"required": true
}
],
"explanation": "The same app has been installed 3 or more times during this enrollment. This typically indicates the app requires a reboot between install attempts, but the ESP is not honoring the reboot request, causing an install-detect-retry loop.",
"remediation": [
{
"title": "Fix reboot handling",
"steps": [
"Check if the app's return code mapping includes reboot codes (3010, 1641)",
"Verify ESP reboot behavior settings",
"Consider setting the app to 'Hard reboot' return code in Intune"
]
}
],
"tags": [
"apps",
"reboot",
"loop"
]
},
{
"ruleId": "ANALYZE-APP-007",
"title": "Multiple App Installation Failures",
"description": "Detects when the app tracking summary reports multiple failed app installations.",
"severity": "high",
"category": "apps",
"enabled": true,
"baseConfidence": 75,
"conditions": [
{
"signal": "summary_errors",
"source": "event_type",
"eventType": "app_tracking_summary",
"dataField": "errorCount",
"operator": "gte",
"value": "2",
"required": true
}
],
"confidenceFactors": [
{
"signal": "enrollment_failed",
"condition": "exists",
"weight": 15
}
],
"explanation": "The app tracking summary reports 2 or more failed app installations during enrollment. This suggests a systemic issue rather than an isolated app failure.",
"remediation": [
{
"title": "Review failed apps",
"steps": [
"Check the individual app_install_failed events for specific error patterns",
"Look for a common pattern (all MSI apps, all large apps, all from a specific publisher)",
"Consider whether a shared prerequisite or dependency is failing"
]
}
],
"tags": [
"apps",
"summary",
"multiple-failures"
]
},
{
"ruleId": "ANALYZE-APP-008",
"title": "Slow App Installation",
"description": "Detects app installations that take longer than 10 minutes.",
"severity": "warning",
"category": "apps",
"enabled": true,
"baseConfidence": 70,
"conditions": [
{
"signal": "slow_app_install",
"source": "app_install_duration",
"eventType": "app_install_completed",
"operator": "gt",
"value": "600",
"required": true
}
],
"explanation": "At least one app installation took longer than 10 minutes. This can indicate slow content delivery, installation overhead, or endpoint performance bottlenecks.",
"remediation": [
{
"title": "Analyze slow app behavior",
"steps": [
"Identify the affected app from matched evidence in the rule result",
"Check network throughput and proxy impact during app download",
"Consider moving large/non-critical apps out of ESP blocking scope"
]
}
],
"tags": [
"apps",
"performance",
"slow-install",
"warning"
]
},
{
"ruleId": "ANALYZE-APP-010",
"title": "App Reverted to Error After Successful Install",
"description": "Detects when a specific app (matched by appId) was first reported as successfully installed but subsequently reported an IME enforcement error — while enrollment completed successfully. The app may be broken post-enrollment.",
"severity": "warning",
"category": "apps",
"enabled": true,
"trigger": "correlation",
"baseConfidence": 75,
"conditions": [
{
"signal": "app_regression",
"source": "event_correlation",
"eventType": "app_install_completed",
"correlateEventType": "app_install_failed",
"joinField": "appId",
"dataField": "errorPatternId",
"operator": "equals",
"value": "IME-ERROR-REPORT",
"required": true
},
{
"signal": "enrollment_succeeded",
"source": "event_type",
"eventType": "enrollment_complete",
"operator": "exists",
"value": "",
"required": true
}
],
"confidenceThreshold": 70,
"explanation": "An app was initially reported as **successfully installed** (`app_install_completed`) but the IME (Intune Management Extension) subsequently reported an **Error** state for the same app via an `IME-ERROR-REPORT` event — while the overall enrollment completed successfully.\n\nThis pattern occurs when the IME re-evaluates enforcement state after the initial install report and detects a failure, e.g. `EnforcementState` transitions from `Success` → `Error`. The affected app and its details are captured in the matched evidence.\n\nCommon causes:\n- A post-install detection check fails (detection rule mismatch)\n- The enforcement error code `-2016345060` (0x87D13B9C) indicates the app state diverged from expected\n- The app may appear installed in the ESP summary but is in an error state on the device\n\n**The enrollment succeeded, but the affected app requires attention.**",
"remediation": [
{
"title": "Investigate the app's post-install enforcement state",
"steps": [
"Note the appId and appName from the rule finding — these identify the exact affected app",
"Check the Intune portal: Devices > [Device] > Apps — confirm the current enforcement state of the app",
"Review IME logs on the device: C:\\ProgramData\\Microsoft\\IntuneManagementExtension\\Logs\\IntuneManagementExtension.log",
"Search the log for the appId and look for 'EnforcementState' transitions (Success → Error) near the enrollment time",
"Error -2016345060 (0x87D13B9C) typically indicates a detection failure after install — verify the app's detection rule in Intune",
"Trigger a manual sync (Company Portal or Settings > Accounts > Access work or school > Sync) to force re-evaluation"
]
},
{
"title": "Fix detection or installation issues",
"steps": [
"If detection fails: correct the detection rule (file path, registry key, or PowerShell script) in the Intune app configuration",
"If the app itself is broken: redeploy or reassign the app to trigger a fresh install",
"Consider adding a post-install validation script to catch this scenario proactively"
]
}
],
"relatedDocs": [
{
"title": "Troubleshoot Win32 app installations",
"url": "https://learn.microsoft.com/en-us/troubleshoot/mem/intune/app-management/troubleshoot-win32-app-install"
},
{
"title": "Intune Management Extension logs",
"url": "https://learn.microsoft.com/en-us/mem/intune/apps/intune-management-extension"
}
],
"tags": [
"apps",
"win32",
"enforcement",
"post-install",
"correlation"
]
},
{
"ruleId": "ANALYZE-APP-012",
"title": "Enforcement Error Resolved by Successful Detection",
"description": "Detects when an app reported an enforcement error (unmapped exit code) but was subsequently detected as installed. The error is informational — the app installed despite the unmapped exit code.",
"severity": "warning",
"category": "apps",
"enabled": true,
"trigger": "correlation",
"baseConfidence": 80,
"conditions": [
{
"signal": "enforcement_error_resolved",
"source": "event_correlation",
"eventType": "app_install_failed",
"correlateEventType": "app_install_completed",
"joinField": "appId",
"eventAFilterField": "errorPatternId",
"eventAFilterOperator": "regex",
"eventAFilterValue": "IME-ERROR-ENFORCEMENT|IME-ERROR-UNMAPPED-EXIT",
"required": true
}
],
"explanation": "An app installation initially reported an **enforcement error** (unmapped exit code), but the IME detection check subsequently found the app **is installed**.\n\nThis happens when the MSI/EXE installer returns a non-standard exit code (e.g., 1603) that has no mapping configured in the Intune app definition. The IME treats unmapped exit codes as errors in its enforcement state, but when detection runs afterward, it confirms the app is present on the device.\n\n**The app is installed and functional.** The enforcement error is an Intune app model artifact, not a real installation failure.",
"remediation": [
{
"title": "Configure exit code mapping in Intune",
"steps": [
"Open the Intune portal > Apps > [affected app] > Properties > Edit",
"In the Return codes section, add a mapping for the reported exit code",
"Map the exit code to 'Success' or 'Soft reboot' depending on the installer behavior",
"This prevents the enforcement error from appearing in future deployments"
]
}
],
"relatedDocs": [
{
"title": "Win32 app return codes in Intune",
"url": "https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-app-management#step-4-return-codes"
}
],
"tags": [
"apps",
"enforcement",
"exit-code",
"unmapped",
"resolved"
]
},
{
"ruleId": "ANALYZE-APP-013",
"title": "App Detection Failure During ESP (0x87D1041C)",
"description": "Detects when the Enrollment Status Page failed because Intune could not verify an app was installed (HRESULT 0x87D1041C). The installer ran but the detection rule did not match afterwards.",
"severity": "critical",
"category": "apps",
"version": "1.1.0",
"enabled": true,
"baseConfidence": 90,
"preconditions": [
{
"source": "event_data",
"eventType": "esp_failure_settle_started",
"dataField": "errorCode",
"operator": "equals",
"value": "0x87d1041c",
"description": "Scope this rule to sessions where the ESP terminated against the Apps subcategory with the canonical detection-failure HRESULT. Works for any agent version, since esp_failure_settle_started is emitted by the V2 ProvisioningStatusTracker regardless of how the Installing-app promotion is later classified."
}
],
"conditions": [
{
"signal": "app_with_detection_failure",
"source": "event_type",
"eventType": "app_install_failed",
"dataField": "detectionResult",
"operator": "equals",
"value": "NotDetected",
"required": true
},
{
"signal": "esp_failure_errorcode",
"source": "event_type",
"eventType": "esp_failure_settle_started",
"dataField": "errorCode",
"operator": "equals",
"value": "0x87d1041c",
"required": false
}
],
"explanation": "App **{{appName}}** failed during the Enrollment Status Page with HRESULT **{{errorCode}}** — *Application not detected after installation completed successfully*. The installer reported success but the Intune detection rule (file/registry/script) did not find the app afterwards, so the ESP Apps subcategory failed and the device's enrollment terminated.\n\nThis is a confirmed detection-rule mismatch, NOT an install timeout — the install itself most likely completed (or the installer exited 0). Common root causes:\n\n- The detection rule looks for a registry/file path that the installer doesn't create (wrong path, wrong bitness — e.g. checking HKLM\\SOFTWARE\\... on a 32-bit installer that lands under WOW6432Node).\n- The installer writes the detection artefact AFTER the ESP's detection probe runs (e.g. async post-install task, requires reboot).\n- The detection script returns 0 with no stdout (Intune treats empty stdout as \"not detected\").\n- The installer wrote files to a user profile but the rule looks in System scope (or vice-versa).",
"remediation": [
{
"title": "Validate the detection rule against an installed device",
"steps": [
"Open Intune portal → Apps → {{appName}} → Properties → Detection rules",
"Note the exact path / registry key / script the rule checks",
"Install the app manually on a reference device (outside Autopilot) and verify the detection artefact actually exists at that path AFTER the installer finishes",
"For registry rules: check both HKLM\\SOFTWARE\\... and HKLM\\SOFTWARE\\WOW6432Node\\... depending on the installer's bitness",
"For file rules: ensure the path is what the installer actually writes (case, trailing version folder, ProgramData vs Program Files)",
"For script detection: test the script in PowerShell as SYSTEM (psexec -s) — it must write at least one line to stdout AND exit 0"
]
},
{
"title": "Investigate post-install delay",
"steps": [
"Check whether the installer schedules an async task (Windows Installer scheduled reboot, service start) that creates the detection artefact only after ESP completes",
"If yes: either move the detection artefact creation into the synchronous installer path, or add a wait step in the installer wrapper script before exit",
"As a workaround, change the detection rule to something the synchronous installer writes immediately (typically the MSI ProductCode under HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\)"
]
},
{
"title": "Cross-check the agent's per-app event",
"steps": [
"Look at the app_install_failed event in this session for DataJson.detectionResult — NotDetected confirms Intune's detection probe ran and returned negative",
"Look at app_install_failed.bytesDownloaded vs bytesTotal — if they match, the package downloaded fully (install error vs. download error)",
"Cross-reference DataJson.exitCode and hresultFromWin32 — these come from the installer itself and may explain why the detection artefact was not written"
]
}
],
"relatedDocs": [
{
"title": "Microsoft Learn: Troubleshoot Windows Autopilot ESP error codes",
"url": "https://learn.microsoft.com/en-us/autopilot/troubleshoot-tsg"
},
{
"title": "Win32 app detection rules in Intune",
"url": "https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-add#step-4-detection-rules"
}
],
"tags": [
"apps",
"detection",
"esp",
"0x87d1041c",
"intune"
]
},
{
"ruleId": "ANALYZE-CORR-002",
"title": "Disk Space Exhaustion Caused Installation Failure",
"description": "Correlates declining disk free space with app installation failure, confirming insufficient storage as root cause.",
"severity": "critical",
"category": "apps",
"enabled": true,
"trigger": "correlation",
"baseConfidence": 65,
"conditions": [
{
"signal": "low_disk",
"source": "event_type",
"eventType": "performance_snapshot",
"dataField": "disk_free_gb",
"operator": "lt",
"value": "5",
"required": true
},
{
"signal": "app_failed",
"source": "event_type",
"eventType": "app_install_failed",
"operator": "exists",
"value": "",
"required": true
}
],
"confidenceFactors": [
{
"signal": "multiple_failures",
"condition": "count >= 2",
"weight": 15
},
{
"signal": "enrollment_failed",
"condition": "exists",
"weight": 10
}
],
"confidenceThreshold": 50,
"explanation": "**Root cause confirmed:** Performance monitoring shows disk free space dropped below 5 GB during enrollment, and apps failed to install. The device likely ran out of storage during app installation.\n\nThis is common when deploying many large Win32 apps to devices with small drives (64 GB or 128 GB).",
"remediation": [
{
"title": "Reduce disk consumption during enrollment",
"steps": [
"Review total size of all apps deployed during ESP",
"Move non-critical apps to post-ESP deployment",
"Use MSIX or Store apps instead of Win32 where possible (smaller footprint)",
"Clean up IME cache: C:\\Windows\\IMECache"
]
},
{
"title": "Use devices with larger drives",
"steps": [
"Minimum 128 GB recommended for standard deployments",
"256 GB recommended when deploying large app suites (Office, Visual Studio, etc.)"
]
}
],
"tags": [
"correlation",
"apps",
"disk-space",
"performance",
"root-cause"
]
},
{
"ruleId": "ANALYZE-CORR-003",
"title": "Proxy Configuration Causing Download Failure",
"description": "Correlates an active proxy configuration with app download failures, suggesting the proxy is blocking or throttling Intune content delivery.",
"severity": "high",
"category": "apps",
"enabled": true,
"trigger": "correlation",
"baseConfidence": 60,
"conditions": [
{
"signal": "proxy_active",
"source": "event_type",
"eventType": "proxy_configuration",
"dataField": "proxyType",
"operator": "regex",
"value": "Proxy|PAC",
"required": true
},
{
"signal": "app_failed",
"source": "event_type",
"eventType": "app_install_failed",
"operator": "exists",
"value": "",
"required": true
}
],
"confidenceFactors": [
{
"signal": "download_timeout",
"condition": "exists",
"weight": 20
},
{
"signal": "multiple_failures",
"condition": "count >= 2",
"weight": 15
},
{
"signal": "enrollment_failed",
"condition": "exists",
"weight": 10
}
],
"confidenceThreshold": 50,
"explanation": "A proxy (explicit or PAC-based) is configured on this device and app installations failed. Proxies can block or throttle downloads from *.delivery.mp.microsoft.com and other Intune CDN endpoints.\n\nThis is a common root cause when apps fail consistently on proxy-connected corporate networks.",
"remediation": [
{
"title": "Verify proxy bypass for Intune endpoints",
"steps": [
"Add *.delivery.mp.microsoft.com to proxy bypass list",
"Add *.do.dsp.mp.microsoft.com (Delivery Optimization) to bypass list",
"Add login.microsoftonline.com and *.manage.microsoft.com to bypass list",
"Verify the PAC file is reachable at enrollment time (before user login)"
]
},
{
"title": "Check proxy authentication",
"steps": [
"Ensure the proxy does not require user authentication during OOBE/device phase",
"Consider using machine certificate-based proxy authentication",
"Test with proxy temporarily bypassed to confirm it is the root cause"
]
}
],
"tags": [
"correlation",
"apps",
"proxy",
"network",
"download",
"root-cause"
]
},
{
"ruleId": "ANALYZE-DEV-001",
"title": "Windows Hello Provisioning Timeout",
"description": "Detects when Windows Hello for Business provisioning did not start within the expected timeframe after ESP completion.",
"severity": "warning",
"category": "device",
"enabled": true,
"baseConfidence": 60,
"conditions": [
{
"signal": "hello_timeout",
"source": "event_type",
"eventType": "hello_wait_timeout",
"operator": "exists",
"value": "",
"required": true
}
],
"confidenceFactors": [
{
"signal": "hello_policy_detected",
"condition": "exists",
"weight": 30
}
],
"explanation": "Windows Hello for Business provisioning did not start within the expected time after ESP exit. This may indicate that the Hello policy is not configured, the device doesn't meet prerequisites, or there's a connectivity issue with the Key Registration Service.",
"remediation": [
{
"title": "Verify Windows Hello configuration",
"steps": [
"Check if Windows Hello for Business is configured in the tenant",
"Verify the policy targets the device/user correctly",
"Ensure the device has a TPM 2.0 (required for WHfB)",
"Check connectivity to the Key Registration Service (enterpriseregistration.windows.net)"
]
}
],
"tags": [
"device",
"hello",
"timeout"
]
},
{
"ruleId": "ANALYZE-DEV-002",
"title": "High Memory Usage During Enrollment",
"description": "Detects when memory usage exceeds 90% during enrollment, which can cause app installation failures or system instability.",
"severity": "warning",
"category": "device",
"enabled": true,
"baseConfidence": 55,
"conditions": [
{
"signal": "high_memory",
"source": "event_type",
"eventType": "performance_snapshot",
"dataField": "memory_used_percent",
"operator": "gt",
"value": "90",
"required": true
}
],
"confidenceFactors": [
{
"signal": "app_failed",
"condition": "exists",
"weight": 20
},
{
"signal": "enrollment_failed",
"condition": "exists",
"weight": 15
}
],
"explanation": "Memory usage exceeded 90% during enrollment. High memory pressure can cause app installation failures, system slowdowns, and ESP timeouts.",
"remediation": [
{
"title": "Reduce memory pressure",
"steps": [
"Review which apps are being installed concurrently during ESP",
"Consider staggering resource-heavy installations",
"Check minimum RAM requirements for the device (8 GB recommended)",
"Investigate if background services are consuming excessive memory"
]
}
],
"tags": [
"device",
"memory",
"performance"
]
},
{
"ruleId": "ANALYZE-DEV-003",
"title": "Unsupported Windows 11 Version",
"description": "Detects devices running Windows 11 version 22H2 or older, which is no longer supported by Microsoft.",
"severity": "warning",
"category": "device",
"enabled": true,
"baseConfidence": 90,
"conditions": [
{
"signal": "windows_11",
"source": "event_type",
"eventType": "os_info",
"dataField": "osVersion",
"operator": "contains",
"value": "Windows 11",
"required": true
},
{
"signal": "old_build",
"source": "event_data",
"eventType": "os_info",
"dataField": "currentBuild",
"operator": "lte",
"value": "22621",
"required": true
}
],
"confidenceFactors": [],
"confidenceThreshold": 40,
"explanation": "This device is running Windows 11 version 22H2 (Build 22621) or older, which has reached end of support. Microsoft no longer provides security updates or bug fixes for this version. Devices running unsupported OS versions are exposed to known vulnerabilities and may fail compliance checks.",
"remediation": [
{
"title": "Update to a supported Windows 11 version",
"steps": [
"Verify the device meets hardware requirements for Windows 11 23H2 or 24H2",
"Update the Windows Autopilot deployment profile to use a supported OS image (23H2 or later)",
"If using a custom OS image, rebuild it with a supported Windows 11 version",
"For existing devices, deploy a Windows 11 feature update via Intune or Windows Update for Business"
]
}
],
"relatedDocs": [
{
"title": "Windows 11 release information",
"url": "https://learn.microsoft.com/en-us/windows/release-health/windows11-release-information"
},
{
"title": "Windows 11 22H2 end of support",
"url": "https://learn.microsoft.com/en-us/lifecycle/products/windows-11-home-and-pro"
}
],
"tags": [
"device",
"os-version",
"end-of-support",
"windows-11"
]
},
{
"ruleId": "ANALYZE-ENRL-001",
"title": "Enrollment Failed",
"description": "Detects when the Autopilot enrollment has explicitly failed.",
"severity": "critical",
"category": "enrollment",
"version": "1.1.1",
"enabled": true,
"baseConfidence": 95,
"conditions": [
{
"signal": "enrollment_failed",
"source": "event_type",
"eventType": "enrollment_failed",
"operator": "exists",
"value": "",
"required": true
},
{
"signal": "enrollment_failed_reason",
"source": "event_type",
"eventType": "enrollment_failed",
"dataField": "reason",
"operator": "exists",
"value": "",
"required": false
},
{
"signal": "esp_failure_subcategory",
"source": "event_type",
"eventType": "esp_failure_settle_started",
"dataField": "failedSubcategory",
"operator": "exists",
"value": "",
"required": false
},
{
"signal": "esp_failure_errorcode",
"source": "event_type",
"eventType": "esp_failure_settle_started",
"dataField": "errorCode",
"operator": "exists",
"value": "",
"required": false
},
{
"signal": "failed_app",
"source": "event_type",
"eventType": "app_install_failed",
"dataField": "appName",
"operator": "exists",
"value": "",
"required": false
}
],
"confidenceFactors": [
{
"signal": "app_failed",
"condition": "exists",
"weight": 5
}
],
"explanation": "The Autopilot enrollment has explicitly failed.\n\n**Key facts extracted from this session's events:**\n\n- **Failure reason:** `{{reason}}`\n- **First failed app:** `{{appName}}`\n- **ESP failed subcategory:** `{{failedSubcategory}}`\n- **ESP HRESULT:** `{{errorCode}}`\n\nWhen an ESP Apps-subcategory failure is paired with HRESULT `0x87D1041C`, the device-side install most likely completed but the Intune detection rule did not match afterwards — see the **App Detection Failure During ESP** rule (ANALYZE-APP-013) in this same analysis for the actionable root cause and remediation steps. Any field still shown as a literal `{{…}}` placeholder was simply not recorded for this session — for example, a non-ESP failure path has no ESP failed-subcategory or HRESULT.",
"remediation": [
{
"title": "Investigate enrollment failure",
"steps": [
"Start with the more specific ANALYZE-APP-* / ANALYZE-ESP-* rules that fired alongside this one — they correlate specific HRESULTs to actionable causes (e.g. 0x87D1041C → detection rule mismatch in ANALYZE-APP-013)",
"Read the `reason` field on the enrollment_failed event for the immediate trigger (e.g. esp_terminal_failure, hello_timeout, max_lifetime)",
"If a HRESULT is present, look it up against the ESP error catalog (Microsoft Learn: Autopilot ESP error codes)",
"Review other analyze rule results for correlated issues (disk space, network, app failures)",
"Check the device event timeline for the sequence of events leading to failure",
"Verify the Autopilot profile and ESP configuration in Intune"
]
}
],
"tags": [
"enrollment",
"failed",
"critical"
]
},
{
"ruleId": "ANALYZE-ENRL-002",
"title": "Session Timed Out",
"description": "Detects when the enrollment session was force-failed by the server-side inactivity timeout (no agent telemetry for the configured SessionTimeoutHours window) without ever completing or explicitly failing.",
"severity": "high",
"category": "enrollment",
"version": "1.0.0",
"enabled": true,
"baseConfidence": 80,
"preconditions": [
{
"source": "event_data",
"eventType": "enrollment_complete",
"operator": "not_exists",
"description": "Suppress when the agent later reported a successful completion. The 5h server timeout can fire before the agent's own 6h max-lifetime, so a slow-but-successful session may complete after the sweep marked it timed out."
},
{
"source": "event_data",
"eventType": "enrollment_failed",
"operator": "not_exists",
"description": "Suppress when an explicit enrollment_failed exists — that path is already covered by ANALYZE-ENRL-001; avoid double-reporting the same session."
}
],
"conditions": [
{
"signal": "session_timeout",
"source": "event_type",
"eventType": "session_timeout",
"operator": "exists",
"value": "",
"required": true
}
],
"explanation": "The enrollment session was force-failed by the server-side maintenance sweep after `{{timeoutHours}}` hour(s) of agent inactivity — the device stopped sending telemetry and never reported completion or an explicit failure.\n\nThis usually means the agent process died or the device went offline mid-enrollment (power off, network loss, bluescreen, reimage) rather than a clean enrollment failure. Because there is no terminal `enrollment_failed` event, the more specific app/ESP rules cannot pinpoint a cause — the evidence simply stops at the last event before the gap.",
"remediation": [
{
"title": "Investigate the silent session",
"steps": [
"Open the device event timeline and look at the LAST events before the gap — the final phase / app reached is where the device went silent",
"Check whether the device is still enrolled and online in Intune; a reimaged or powered-off device explains the silence",
"Look for previous_crash_detected / agent_shutting_down events earlier in the session that hint at an agent or OS crash",
"If the device is reachable, collect the agent + IME logs and re-run enrollment, correlating with the timeout timestamp",
"If many sessions time out in the same window, check for a tenant-wide network/connectivity issue or an Intune service incident"
]
}
],
"tags": [
"enrollment",
"timeout",
"stalled"
]
},
{
"ruleId": "ANALYZE-ESP-001",
"title": "ESP Blocking App Timeout",
"description": "Detects when the DeviceSetup phase of the ESP took longer than 30 minutes, indicating a stuck or very slow blocking app.",
"severity": "high",
"category": "esp",
"enabled": true,
"baseConfidence": 50,
"conditions": [
{
"signal": "esp_stalled",
"source": "phase_duration",
"eventType": "esp_phase_changed",
"dataField": "espPhase",
"operator": "equals",
"value": "DeviceSetup",
"required": true
}
],
"confidenceFactors": [
{
"signal": "long_esp",
"condition": "phase_duration > 1800",
"weight": 40
}
],
"confidenceThreshold": 70,
"explanation": "The ESP DeviceSetup phase took more than 30 minutes. This indicates a blocking app is stuck installing, downloading very slowly, or has entered a retry loop.",
"remediation": [
{
"title": "Investigate blocking app",
"steps": [
"Identify which app is blocking (check ESP events)",
"Verify app content is downloadable",
"Consider reducing the number of blocking apps"
]
}
],
"tags": [
"esp",
"blocking",
"timeout"
]
},
{
"ruleId": "ANALYZE-ESP-002",
"title": "ESP Subcategory Failed (Certificates)",
"description": "Detects when the Certificates subcategory of the Enrollment Status Page reported a failure, even if the enrollment later appears to have succeeded. Users can click 'Continue anyway' on an ESP error, which masks the underlying certificate provisioning failure — this rule surfaces the transition so it stays visible.",
"severity": "high",
"category": "esp",
"version": "1.0.0",
"author": "Autopilot Monitor",
"enabled": true,
"trigger": "single",
"baseConfidence": 80,
"conditions": [
{
"signal": "certificates_subcategory_failed",
"source": "event_data",
"eventType": "esp_provisioning_status",
"dataField": "failedSubcategories",
"operator": "contains",
"value": "Certificates",
"required": true
}
],
"confidenceFactors": [],
"confidenceThreshold": 70,
"explanation": "The ESP Certificates subcategory transitioned to **failed** during enrollment. This is frequently masked when the user clicks 'Continue anyway' on the ESP error screen — the overall enrollment then appears successful while a required certificate (e.g. Wi-Fi, VPN, SCEP/PKCS) was never deployed.\n\nThe subcategory name is read from the registry (`CertificatesSubcategory`) and is language-invariant, so this rule fires regardless of OS display language.",
"remediation": [
{
"title": "Validate certificate delivery on the device",
"steps": [
"Run `certutil -store My` and `certutil -store -user My` on the device to inspect installed certificates",
"Check `Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin` for SCEP/PKCS errors",
"Review the Intune portal for the device's certificate profile assignments and deployment status"
]
},
{
"title": "Fix common certificate provisioning issues",
"steps": [
"Verify the NDES/SCEP connector is online and healthy",
"Confirm the certificate template permissions grant 'Enroll' to the Intune service account / NDES computer account",
"Check that the device has network line-of-sight to the SCEP endpoint at the time of ESP",
"Re-sync the device (Settings → Accounts → Access work or school → Info → Sync) and re-check the Certificates subcategory"
]
}
],
"relatedDocs": [
{
"title": "Microsoft Learn: Troubleshoot certificate profiles in Intune",
"url": "https://learn.microsoft.com/en-us/mem/intune/protect/troubleshoot-certificate-profiles"
},
{
"title": "Microsoft Learn: Enrollment Status Page tracking",
"url": "https://learn.microsoft.com/en-us/autopilot/enrollment-status"
}
],
"markSessionAsFailedDefault": false,
"tags": [
"esp",
"certificates",
"subcategory",
"silent-failure"
]
},
{
"ruleId": "ANALYZE-ESP-003",
"title": "Enrollment Duration Exceeded 60 Minutes",
"description": "Detects when the total Autopilot enrollment takes longer than 60 minutes.",
"severity": "high",
"category": "esp",
"enabled": true,
"baseConfidence": 50,
"conditions": [
{
"signal": "long_enrollment",
"source": "phase_duration",
"eventType": "esp_phase_changed",
"dataField": "espPhase",
"operator": "equals",
"value": "DeviceSetup",
"required": true
}
],
"confidenceFactors": [
{
"signal": "long_esp",
"condition": "phase_duration > 3600",
"weight": 40
}
],
"confidenceThreshold": 70,
"explanation": "The Autopilot enrollment exceeded 60 minutes. This is unusually long and may indicate stuck apps, slow network, or policy conflicts. The default ESP timeout is 60 minutes, after which the enrollment may be marked as failed.",
"remediation": [
{
"title": "Investigate long enrollment",
"steps": [
"Check the app installation timeline - identify which app took the longest",
"Review download speeds in the performance data",
"Consider reducing the number of ESP-blocking apps",
"Check if the ESP timeout policy is configured (default: 60 min)"
]
}
],
"tags": [
"esp",
"timeout",
"duration"
]
},
{
"ruleId": "ANALYZE-ID-001",
"title": "No Machine Certificates Found",
"description": "Detects when no certificates are present in the local machine personal store (LocalMachine\\My). Missing certificates may indicate that MDM enrollment certificate provisioning or SCEP certificate deployment failed.",
"severity": "warning",
"category": "identity",
"isCommunity": true,
"enabled": false,
"version": "1.1.0",
"baseConfidence": 75,
"conditions": [
{
"signal": "cert_store_gathered",
"source": "event_type",
"eventType": "gather_machine_cert_store",
"operator": "exists",
"value": "",
"required": true
},
{
"signal": "cert_subject_missing",
"source": "event_data",
"eventType": "gather_machine_cert_store",
"dataField": "output",
"operator": "not_contains",
"value": "CN=YOUR-CERTIFICATE-SUBJECT",
"required": true
}
],
"confidenceFactors": [
{
"signal": "no_output_at_all",
"condition": "gather_machine_cert_store.output not_exists",
"weight": 20
},
{
"signal": "command_error",
"condition": "gather_machine_cert_store.error_output exists",
"weight": 10
}
],
"confidenceThreshold": 70,
"explanation": "The expected certificate with the configured subject was not found in the local machine certificate store (LocalMachine\\My). Customize the 'value' field in the 'cert_subject_missing' condition to match your expected certificate subject (e.g. 'CN=Contoso Root CA'). The check is case-insensitive (substring match). If the certificate should have been provisioned via SCEP or MDM enrollment, this may indicate a deployment failure.",
"remediation": [
{
"title": "Verify the expected certificate",
"steps": [
"Customize the analyze rule: change 'CN=YOUR-CERTIFICATE-SUBJECT' to your expected certificate subject (case-insensitive substring match)",
"Example subjects: 'CN=Contoso SCEP Cert', 'CN=Contoso Root CA', 'CN=MDM Device Certificate'",
"Check certlm.msc (Certificates - Local Computer > Personal > Certificates) manually to see what's present"
]
},
{
"title": "Troubleshoot missing certificate",
"steps": [
"Check if the device is properly enrolled in Intune (dsregcmd /status)",
"Verify SCEP/PKCS certificate profiles are assigned and targeted correctly",
"Check the NDES/SCEP connector status and reachability",
"Review IntuneManagementExtension logs for certificate enrollment errors",
"Ensure prerequisite certificates (Trusted Root CA) are deployed before the end-entity profile"
]
}
],
"tags": [
"identity",
"certificates",
"machine-store",
"subject-check"
],
"templateVariables": [
{
"name": "cert_subject",
"label": "Certificate Subject",
"description": "The expected certificate subject in your environment (e.g., 'CN=Contoso Root CA'). Case-insensitive substring match against the local machine certificate store.",
"conditionIndex": 1,
"field": "value",
"placeholder": "CN=YOUR-CERTIFICATE-SUBJECT"
}
]
},
{
"ruleId": "ANALYZE-ID-002",
"title": "Unexpected Local Admin Accounts Detected",
"description": "Detects when the LocalAdminAnalyzer flags unexpected local user accounts or profile directories on the device. This is a known Autopilot bypass technique where admin accounts are created before or during enrollment to gain persistent local admin access.",
"severity": "high",
"category": "identity",
"version": "1.0.0",
"author": "Autopilot Monitor",
"enabled": true,
"trigger": "single",
"baseConfidence": 60,
"conditions": [
{
"signal": "unexpected_admins_found",
"source": "event_type",
"eventType": "local_admin_analysis",
"dataField": "finding",
"operator": "equals",
"value": "unexpected_local_admins_detected",
"required": true
},
{
"signal": "high_confidence",
"source": "event_data",
"eventType": "local_admin_analysis",
"dataField": "confidence_score",
"operator": "gte",
"value": "60",
"required": false
},
{
"signal": "error_severity",
"source": "event_data",
"eventType": "local_admin_analysis",
"dataField": "severity",
"operator": "equals",
"value": "error",
"required": false
}
],
"confidenceFactors": [
{
"signal": "high_confidence",
"condition": "exists",
"weight": 15
},
{
"signal": "error_severity",
"condition": "exists",
"weight": 15
}
],
"confidenceThreshold": 50,
"explanation": "The agent detected unexpected local user accounts or profile directories on this device that are not in the built-in or tenant-configured allowed list.\n\nThis is a security-relevant finding. Creating local admin accounts before or during Autopilot enrollment is a known bypass technique (e.g. via BypassNRO or Shift+F10 during OOBE) that grants persistent local administrator access.\n\nClick the event link below to jump to the local_admin_analysis event and check: unexpected_accounts (local user accounts not on the allowed list), unexpected_profiles (C:\\Users profile directories not on the allowed list), bypass_nro (whether the BypassNRO registry flag was set), and confidence_score (the agent's confidence in the finding, 0-100).\n\nIf these accounts are expected for your environment (e.g. a service account or helpdesk account), add them to the allowed list in Tenant Settings.",
"remediation": [
{
"title": "Review the unexpected accounts",
"steps": [
"Open the session timeline and locate the local_admin_analysis event",
"Check the 'unexpected_accounts' and 'unexpected_profiles' lists in the event data",
"Verify whether these accounts are legitimate for your environment"
]
},
{
"title": "Add expected accounts to the allowed list (false positive)",
"steps": [
"Go to Settings → Agent Analyzers section",
"Under 'Allowed Admin Accounts', add the account names that are expected in your environment",
"Save the settings — future enrollments will no longer flag these accounts"
]
},
{
"title": "Investigate a potential security issue",
"steps": [
"Check if the BypassNRO registry flag was set (indicates OOBE was bypassed)",
"Review the enrollment timeline for Shift+F10 or other OOBE escape indicators",
"Check whether the unexpected account has admin group membership",
"Consider re-imaging the device if unauthorized admin access is confirmed"
]
}
],
"relatedDocs": [],
"tags": [
"identity",
"security",
"local-admin",
"bypass-detection"
]
},
{
"ruleId": "ANALYZE-ID-003",
"title": "Critical Vulnerability Detected",
"description": "Fires when the vulnerability correlation finds critical-severity CVEs or CISA KEV entries in installed software. This indicates the device has software with known, actively exploited vulnerabilities.",
"severity": "critical",
"category": "security",
"version": "1.0.0",
"author": "Autopilot Monitor",
"enabled": true,
"trigger": "single",
"baseConfidence": 90,
"conditions": [
{
"signal": "critical_vulnerabilities",
"source": "event_type",
"eventType": "vulnerability_report",
"dataField": "scan_summary.critical_cves",
"operator": "gte",
"value": "1",
"required": true
},
{
"signal": "kev_matches",
"source": "event_type",
"eventType": "vulnerability_report",
"dataField": "scan_summary.kev_matches",
"operator": "gte",
"value": "1",
"required": false
}
],
"confidenceFactors": [
{
"signal": "kev_confirmed",
"condition": "exists",
"weight": 10
}
],
"confidenceThreshold": 80,
"explanation": "The device has installed software with critical vulnerabilities. Software with CVEs rated CRITICAL (CVSS >= 9.0) or listed in the CISA Known Exploited Vulnerabilities catalog was detected. These vulnerabilities are actively targeted by attackers and should be remediated immediately.",
"remediation": [
{
"title": "Review vulnerability findings",
"steps": [
"Open the Vulnerability Report section in the session detail",
"Identify all software with critical or KEV-flagged vulnerabilities",
"Check if newer versions are available that address these CVEs",
"Update the affected software in your Intune app deployment"
]
},
{
"title": "Update deployment packages",
"steps": [
"Check Intune for outdated app package versions",
"Update the deployment package to the latest patched version",
"Re-deploy to affected devices"
]
}
],
"relatedDocs": [
{
"title": "CISA KEV Catalog",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
},
{
"title": "NVD - National Vulnerability Database",
"url": "https://nvd.nist.gov/"
}
],
"tags": [
"vulnerability",
"cve",
"kev",
"critical",
"security"
]
},
{
"ruleId": "ANALYZE-OFFICE-001",
"title": "Microsoft 365 Apps Install Failed",
"description": "Detects when the Microsoft 365 Apps (Office Click-to-Run) background install did not reach completion. The V2 OfficeInstallDetector watches the C2R client directly (registry + process) and emits office_install_failed when the install scenario was abandoned (worker gone and streaming never finished) or a C2R failure code was observed. This catches Office failures that the Intune integrated app type hides, because IME reports the app done within 1-2 minutes while C2R keeps installing in the background.",
"severity": "warning",
"category": "apps",
"version": "1.0.0",
"enabled": true,
"baseConfidence": 75,
"conditions": [
{
"signal": "office_install_failed",
"source": "event_type",
"eventType": "office_install_failed",
"operator": "exists",
"value": "",
"required": true
}
],
"confidenceFactors": [
{
"signal": "error_code_present",
"condition": "exists",
"weight": 15
}
],
"confidenceThreshold": 40,
"explanation": "The Microsoft 365 Apps (Office Click-to-Run) install did not finish.\n\nThe OfficeInstallDetector watches the C2R client directly and reports the real background install lifecycle. The Intune \"integrated\" Microsoft 365 Apps app type only pushes the configuration XML and starts the C2R bootstrapper, so IME marks the app done within 1-2 minutes while C2R keeps streaming and laying down the product for several more minutes. This event means C2R activity ended (the OfficeC2RClient worker exited and the install scenario cleared) without the StreamingFinished flag being set, or a C2R failure code was observed.\n\nReview the office_install_failed event payload: `products`, `channel`, `phase`, `streamingFinished`, `errorCode` (best-effort — may be empty) and `durationSeconds`.",
"remediation": [
{
"title": "Investigate the Office C2R install failure",
"steps": [
"Open the office_install_failed event and review products, channel, phase, streamingFinished and errorCode",
"Check the Click-to-Run logs on the device (%windir%\\Temp and %temp%, files named <MachineName>-yyyymmdd-nnnn.log) for the failing operation",
"Verify the device had network reachability to the Office CDN / Microsoft Connected Cache during the enrollment window",
"Confirm the Intune Microsoft 365 Apps app configuration (products, channel, architecture) matches what the device can install",
"Re-check the session timeline for a reboot or agent shutdown that may have interrupted the background C2R install"
]
}
],
"tags": [
"apps",
"office",
"microsoft-365-apps",
"click-to-run",
"install-failure"
]
},
{
"ruleId": "ANALYZE-SEC-001",
"title": "Secure Boot UEFI CA 2023 certificate not deployed",
"description": "Detects devices where the Windows UEFI CA 2023 certificate has not been deployed to the Secure Boot DB. These devices will lose Secure Boot security update support when the 2011 certificates expire in June 2026.",
"severity": "warning",
"category": "security",
"version": "1.1.0",
"enabled": true,
"baseConfidence": 70,
"preconditions": [
{
"source": "event_data",
"eventType": "hardware_spec",
"dataField": "isVirtualMachine",
"operator": "equals",
"value": "false",
"description": "Skip on virtual machines — Secure Boot DB is host-controlled (Hyper-V/VMware/etc), the inside-the-VM UEFICA2023Status registry value is not the right indicator and not actionable for the VM admin."
}
],
"conditions": [
{
"signal": "ca2023_not_updated",
"source": "event_data",
"eventType": "secureboot_status",
"dataField": "uefiCA2023Status",
"operator": "not_equals",
"value": "Updated",
"required": true
},
{
"signal": "secureboot_enabled",
"source": "event_data",
"eventType": "secureboot_status",
"dataField": "uefiSecureBootEnabled",
"operator": "equals",
"value": "true",
"required": true
}
],
"confidenceFactors": [
{
"signal": "ca2023_notfound",
"condition": "equals:notfound",
"weight": 20
},
{
"signal": "ca2023_error",
"condition": "exists",
"weight": 10
}
],
"explanation": "This device has Secure Boot enabled but the **Windows UEFI CA 2023** certificate has not been deployed to the Secure Boot DB yet.\n\nThe original Windows UEFI CA 2011 certificates expire on **June 27, 2026**. After expiration, devices without the 2023 certificate will no longer receive Secure Boot security updates and may fail to boot with updated boot managers.\n\nCurrent UEFI CA 2023 status: `{{uefiCA2023Status}}`",
"remediation": [
{
"title": "Deploy UEFI CA 2023 certificate",
"steps": [
"Deploy KB5036210 via Windows Update or WSUS",
"Use Intune policy to enable Secure Boot DB update (Windows UEFI CA 2023)",
"Alternatively, use the WinCS CLI tool from Microsoft for manual deployment",
"Verify deployment: check registry HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecureBoot\\Servicing\\UEFICA2023Status = 'Updated'",
"After DB update: ensure the boot manager is updated to a 2023-signed version via monthly cumulative update"
]
}
],
"relatedDocs": [
{
"title": "Microsoft: Secure Boot certificates expire June 2026",
"url": "https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856"
},
{
"title": "KB5036210: Deploying Windows UEFI CA 2023",
"url": "https://support.microsoft.com/en-us/topic/kb5036210"
}
],
"tags": [
"security",
"secureboot",
"certificate",
"ca2023",
"compliance"
]
},
{
"ruleId": "ANALYZE-SEC-003",
"title": "AutoLogon plaintext password stored in registry",
"description": "Fires when the AutoLogon analyzer reports a DefaultPassword value present in Winlogon. A plaintext AutoLogon password stored in the registry is readable by any local administrator and is a credential exposure — more severe than AutoLogon alone (the Sysinternals Autologon tool deliberately avoids this by storing the secret in the LSA instead).",
"severity": "high",
"category": "security",
"version": "1.0.0",
"enabled": true,
"trigger": "single",
"baseConfidence": 90,
"conditions": [
{
"signal": "default_password_present",
"source": "event_type",
"eventType": "autologon_analysis",
"dataField": "checks.default_password_present",
"operator": "equals",
"value": "true",
"required": true
}
],
"confidenceThreshold": 40,
"explanation": "This device has a **plaintext AutoLogon password stored in the registry** (`DefaultPassword` under `HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon`). This value is readable by any local administrator and exposes the AutoLogon account's credentials in clear text.\n\nEven when AutoLogon itself is intended (e.g. a kiosk), the password should never be left as a registry value. The Sysinternals Autologon tool stores the secret as an encrypted LSA secret precisely to avoid this; a plaintext `DefaultPassword` usually means a script or manual edit wrote the credentials directly.\n\nNote: the agent only reports the *presence* of this value — it never reads or transmits the password itself.",
"remediation": [
{
"title": "Remove the plaintext password",
"steps": [
"Delete the DefaultPassword value under HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon",
"If AutoLogon is still required, reconfigure it with the Sysinternals Autologon tool so the secret is stored as an encrypted LSA secret rather than a registry value",
"Rotate the exposed account's password, since it may have been readable on disk"
]
},
{
"title": "Reduce blast radius",
"steps": [
"Verify the AutoLogon account is the least-privileged account that satisfies the use case (not a domain or local admin where avoidable)",
"For kiosk scenarios, prefer Assigned Access / kiosk profiles over a raw AutoLogon credential"
]
}
],
"relatedDocs": [
{
"title": "Sysinternals Autologon (encrypted LSA-secret password storage)",
"url": "https://learn.microsoft.com/en-us/sysinternals/downloads/autologon"
}
],
"tags": [
"security",
"autologon",
"winlogon",
"credentials",
"plaintext-password"
]
},
{
"ruleId": "ANALYZE-SEC-004",
"title": "AutoLogon enabled for an unexpected user",
"description": "Optional kiosk allow-list for AutoLogon. Fires when AutoLogon is enabled for a default user that is NOT on your configured list of approved kiosk / shared-device accounts. Disabled until configured because a normal Autopilot enrollment leaves Windows' own ESP auto-logon for the enrolling user (AutoLogon enabled, a default user, no plaintext password) — so AutoLogon-enabled alone is not graded by default; only a plaintext DefaultPassword on disk (ANALYZE-SEC-003) is. Enable this rule with your expected kiosk account name(s) if you want to surface AutoLogon configured for any other user.",
"severity": "warning",
"category": "security",
"version": "1.0.0",
"enabled": false,
"trigger": "single",
"baseConfidence": 80,
"conditions": [
{
"signal": "autologon_enabled",
"source": "event_type",
"eventType": "autologon_analysis",
"dataField": "checks.autologon_enabled",
"operator": "equals",
"value": "true",
"required": true
},
{
"signal": "unexpected_autologon_user",
"source": "event_data",
"eventType": "autologon_analysis",
"dataField": "checks.default_user_name",
"operator": "not_in",
"value": "EXPECTED-KIOSK-USER-1,EXPECTED-KIOSK-USER-2",
"required": true
}
],
"confidenceThreshold": 40,
"explanation": "AutoLogon is enabled on this device for a user that is **not on your approved kiosk allow-list**. AutoLogon is legitimate for kiosk and shared-device scenarios, so this rule only warns when the configured default user differs from the account(s) you expect.\n\nThis rule is **off by default**. A normal user-driven Autopilot enrollment leaves Windows' own ESP auto-logon for the enrolling user (`AutoAdminLogon=1`, a `DefaultUserName`, an `AutoLogonSID`, and no plaintext password) — registry-indistinguishable from a kiosk AutoLogon — so AutoLogon-enabled alone is not graded. The only AutoLogon state graded by default is a plaintext `DefaultPassword` on disk (**ANALYZE-SEC-003**).\n\nTo use this rule: configure the allow-list with your approved kiosk account name(s) (comma-separated, case-insensitive exact match against the Winlogon `DefaultUserName`) and enable it. AutoLogon for any other user will then warn.\n\nNote: an AutoLogon with no explicit default user (e.g. ForceAutoLogon only) is treated as unexpected and will warn.",
"remediation": [
{
"title": "Confirm the AutoLogon user",
"steps": [
"Open the autologon_analysis event in the session timeline and check the default user/domain",
"If the user is an approved kiosk account, add it to this rule's allow-list",
"If the user is unexpected, treat it as a possible enrollment/OOBE manipulation and investigate what wrote the Winlogon keys"
]
},
{
"title": "Disable AutoLogon if not required",
"steps": [
"Set HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\AutoAdminLogon to 0",
"Remove DefaultPassword (and any Sysinternals LSA secret) if present",
"For kiosk scenarios, prefer Assigned Access / kiosk profiles over raw AutoLogon where possible"
]
}
],
"relatedDocs": [
{
"title": "Microsoft: Configure Windows to automatically sign in (AutoLogon)",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon"
}
],
"tags": [
"security",
"autologon",
"winlogon",
"kiosk",
"allow-list"
],
"templateVariables": [
{
"name": "allowed_autologon_users",
"label": "Allowed AutoLogon users (kiosk accounts)",
"description": "Comma-separated list of approved kiosk / shared-device account names that are expected to use AutoLogon (case-insensitive exact match against the Winlogon DefaultUserName, e.g. 'KioskUser' or 'Reception,LobbyPC'). AutoLogon for any other user raises a warning.",
"conditionIndex": 1,
"field": "value",
"placeholder": "EXPECTED-KIOSK-USER-1,EXPECTED-KIOSK-USER-2"
}
]
},
{
"ruleId": "ANALYZE-SEC-005",
"title": "Unexpected Provisioning Package",
"description": "Detects provisioning packages (PPKG) that are not on the built-in allow-list. The agent emits one or more provisioning_package_scan events whose artifacts[] arrays list every PPKG (registry package, .ppkg file, or Recovery\\Customizations residue; a large set is split across several events). This rule iterates that array across all of them and fires for any artifact whose identity does not match the allow-list regex. The default allow-list covers the Windows OS-inbox packages that ship on every device (Cosa, Power.EnergyEstimationEngine, Power.Settings, SecureStart) so a clean device stays quiet. To allow your own vendor/recovery packages, enable the template rule ANALYZE-SEC-006, extend its allow-list, then disable this rule.",
"severity": "warning",
"category": "security",
"version": "2.0.0",
"enabled": true,
"baseConfidence": 80,
"conditions": [
{
"signal": "ppkg_not_allowlisted",
"source": "event_data_array",
"eventType": "provisioning_package_scan",
"dataField": "artifacts",
"itemField": "identity",
"operator": "not_regex",
"value": "^(?:Microsoft\\.Windows\\.Cosa|Power\\.EnergyEstimationEngine|Power\\.Settings|SecureStart\\.Settings)\\b",
"required": true
}
],
"confidenceThreshold": 40,
"explanation": "A provisioning package (PPKG) was detected that is NOT on the allow-list.\n\n- **Unexpected package:** `{{identity}}`\n\nThe agent reports every PPKG it finds in `provisioning_package_scan` event(s) (see their `artifacts` array(s) for the full list, plus file metadata and best-effort content indicators; large sets span several events). This rule ignores the Windows OS-inbox packages that ship on every device (Cosa, Power.EnergyEstimationEngine, Power.Settings, SecureStart) and only surfaces the rest.\n\nProvisioning packages can apply local accounts, certificates, Wi-Fi/VPN profiles, applications (MSI/EXE) and scripts. They are legitimate in bulk-enrollment and OEM-recovery scenarios, but a PPKG appearing on a device that is expected to be \"pure Autopilot\" can indicate tampering.\n\n**To stop alerting on a known-good package:** enable the template rule **ANALYZE-SEC-006**, add the package to its allow-list regex, then disable this rule. ANALYZE-SEC-006 then only fires for packages outside your extended allow-list.",
"remediation": [
{
"title": "Verify the provisioning package is expected",
"steps": [
"Open the provisioning_package_scan event and review the artifacts array (identity, source, file path, ownerType/installTime for registry packages)",
"Confirm whether the package matches a known source: bulk-enrollment PPKG, OEM recovery package, or an internal provisioning workflow",
"Cross-check the device model/vendor — OEM recovery PPKGs are common and usually benign",
"If the package is unexpected for a pure-Autopilot device, treat it as a potential manipulation and investigate how it was applied (USB, Recovery\\Customizations, image)",
"To allow known-good packages going forward, enable ANALYZE-SEC-006, extend the allow-list, then disable this rule"
]
}
],
"tags": [
"security",
"provisioning-package",
"ppkg",
"allow-list",
"tamper"
]
},
{
"ruleId": "ANALYZE-SEC-006",
"title": "Unexpected Provisioning Package (Custom Allow-List)",
"description": "Template version of ANALYZE-SEC-005 with a customizable allow-list. Iterates the provisioning_package_scan artifacts[] array and fires for any PPKG whose identity is not on YOUR allow-list regex. The placeholder ships with the same OS-inbox defaults as ANALYZE-SEC-005 — extend it with your own vendor/recovery packages. This rule is OFF by default: enable it, set your allow-list, then disable ANALYZE-SEC-005 so only packages outside your list alert.",
"severity": "warning",
"category": "security",
"version": "2.0.0",
"enabled": false,
"baseConfidence": 80,
"conditions": [
{
"signal": "ppkg_not_allowlisted",
"source": "event_data_array",
"eventType": "provisioning_package_scan",
"dataField": "artifacts",
"itemField": "identity",
"operator": "not_regex",
"value": "^(?:Microsoft\\.Windows\\.Cosa|Power\\.EnergyEstimationEngine|Power\\.Settings|SecureStart\\.Settings)\\b",
"required": true
}
],
"confidenceThreshold": 40,
"explanation": "A provisioning package (PPKG) was detected whose identity is NOT on your configured allow-list.\n\n- **Unexpected package:** `{{identity}}`\n\nThe `identity` value combines a package's name, .ppkg file name, ownerType and packageId, so your allow-list regex can match an approved package by any of these. The default allow-list already covers the Windows OS-inbox packages (Cosa, Power.EnergyEstimationEngine, Power.Settings, SecureStart) — extend it with your own vendor/recovery packages.\n\nIf this package should be allowed, add it to the allow-list regex (the 'value' of the 'ppkg_not_allowlisted' condition). If it is genuinely unexpected on a pure-Autopilot device, treat it as a potential manipulation and investigate how it was applied.",
"remediation": [
{
"title": "Triage the unexpected package",
"steps": [
"Open the provisioning_package_scan event and review the artifacts array for this package's identity and source",
"Decide: is this a known-good package that should be allow-listed, or genuinely unexpected?",
"If known-good: the allow-list is anchored (^(?:...)\\b), so insert a new alternative INSIDE the group, before the closing ')' — e.g. ...|SecureStart\\.Settings|Acme\\.Recovery)\\b. Appending after the ) or \\b will not match.",
"If unexpected: investigate the application path (USB media, C:\\Recovery\\Customizations residue, custom image) and the device's chain of custody"
]
},
{
"title": "Activate the custom allow-list workflow (2-step)",
"steps": [
"Enable this rule and extend the allow-list regex by inserting your approved packages as alternatives inside the anchored group (before the closing ')'), case-insensitive",
"Verify it behaves as expected on a known device",
"Disable the built-in rule ANALYZE-SEC-005 so only packages outside your allow-list alert going forward"
]
}
],
"tags": [
"security",
"provisioning-package",
"ppkg",
"allow-list",
"template"
],
"templateVariables": [
{
"name": "allowed_packages",
"label": "Allowed provisioning packages (regex)",
"description": "Case-insensitive regex matched against each package's identity (name | fileName | ownerType | packageId). Packages matching this pattern are treated as approved and do NOT alert. The default is anchored (^...) so it matches only at the START of the identity — extend it by adding an alternative inside the group, e.g. add '|Acme\\.Recovery' before the closing ')'.",
"conditionIndex": 0,
"field": "value",
"placeholder": "^(?:Microsoft\\.Windows\\.Cosa|Power\\.EnergyEstimationEngine|Power\\.Settings|SecureStart\\.Settings)\\b"
}
]
},
{
"ruleId": "ANALYZE-SEC-007",
"title": "Provisioning Package Scan Incomplete",
"description": "Fires when the provisioning-package scan hit a per-source collection cap (too many .ppkg files, registry packages, or Recovery\\Customizations residue files to capture them all). When that happens the allow-list rules (ANALYZE-SEC-005/006) could not evaluate every package, so a non-allow-listed package may have gone unseen. A device with that many provisioning packages is itself unusual and worth a manual look.",
"severity": "warning",
"category": "security",
"version": "1.0.0",
"enabled": true,
"baseConfidence": 80,
"conditions": [
{
"signal": "ppkg_scan_truncated",
"source": "event_data",
"eventType": "provisioning_package_scan",
"dataField": "scanTruncated",
"operator": "equals",
"value": "true",
"required": true
}
],
"confidenceThreshold": 40,
"explanation": "The provisioning-package scan was incomplete: the device had more provisioning packages than the agent captures per source, so a per-source cap was hit (see `ppkgFilesTruncated` / `packagesTruncated` / `recoveryFilesTruncated` on the `provisioning_package_scan` event).\n\nBecause not every package was captured, the allow-list rules (ANALYZE-SEC-005/006) may NOT have evaluated all of them — a non-allow-listed package could be present but unseen. A device carrying this many provisioning packages is also unusual on its own and warrants a manual review.",
"remediation": [
{
"title": "Review the device manually",
"steps": [
"Open the provisioning_package_scan event and check which counts exceeded the cap (ppkgFileCount / packageCount vs the *Truncated flags)",
"Inspect the device directly: C:\\ProgramData\\Microsoft\\Provisioning, C:\\Windows\\Provisioning, C:\\Recovery\\Customizations, and HKLM\\SOFTWARE\\Microsoft\\Provisioning\\Packages",
"Confirm whether the large number of provisioning packages is expected for this device/model (e.g. an OEM image) or anomalous",
"If anomalous, treat it as a potential manipulation and investigate the device's chain of custody"
]
}
],
"tags": [
"security",
"provisioning-package",
"ppkg",
"truncated",
"coverage"
]
}
]
}