The Inventory Blind Spot Nobody Talked About Honestly

The conventional wisdom was that MDM-enrolled devices were "managed" devices. Policy applied, compliance checked, done. But MDM compliance checks validate policy assignment, not configuration state. There's a meaningful difference between "this device has the BitLocker policy assigned" and "this device has BitLocker configured with the correct cipher strength, recovery key escrow, and pre-boot PIN requirement as reflected in the registry."

That distinction matters enormously in regulated environments. SOC 2 Type II auditors don't accept policy assignment screenshots as evidence of control effectiveness. ISO 27001 assessors want configuration state. And your incident response team, when investigating a compromised endpoint, needs to know whether LSA protection was actually enabled at the time of the incident — not whether a policy intended to enable it.

The registry is where Windows records what is actually true about a device. Group Policy writes to it. Intune CSPs write to it. Local administrators write to it. Malware writes to it. Until now, Intune couldn't tell you which of those writes had won.

---

How Registry Visibility Works Inside Intune's Architecture

The implementation sits inside the Intune Management Extension (IME) pipeline, which already handles PowerShell scripts, Win32 app deployments, and proactive remediations. Registry collection is surfaced through the Device Inventory feature, which Microsoft has been expanding incrementally — hardware inventory, software inventory, and now configuration state via registry keys.

Admins configure custom inventory rules that specify:

• The registry hive (HKLM, HKCU, etc.)
• The key path
• The value name
• The data type expected

The IME agent collects these values on a configurable schedule and reports them back to the Intune service. Data lands in the Microsoft Endpoint Analytics data store and is queryable through the Intune portal and, critically, through Log Analytics and Microsoft Sentinel via the Intune Data Export connector.

This architecture matters for two reasons. First, it means registry data flows into the same pipeline as your other endpoint telemetry — you're not creating a new silo. Second, it means you can write KQL queries against registry state alongside device compliance data, Defender signals, and Entra ID identity context. That's a fundamentally different capability than running a PowerShell script and exporting a CSV.

The collection agent runs under the SYSTEM context, which means it can read protected registry paths that user-context scripts cannot — including HKLM\SYSTEM\CurrentControlSet\Control\Lsa for LSA protection state and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System for UAC configuration.

---

Security-Critical Registry Paths Worth Collecting First

Not every registry key deserves inventory collection. The operational value comes from targeting keys that represent security control state — values where drift between intended and actual configuration creates measurable risk.

Here are the paths that should be in your initial collection ruleset:

LSA Protection (Credential Guard prerequisite)

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: RunAsPPL
Expected: DWORD 1 or 2

UAC Configuration

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Value: EnableLUA
Expected: DWORD 1

Value: ConsentPromptBehaviorAdmin
Expected: DWORD 2 (prompt for credentials)

Windows Firewall — Domain Profile

HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile
Value: EnableFirewall
Expected: DWORD 1

PowerShell Script Block Logging

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
Value: EnableScriptBlockLogging
Expected: DWORD 1

SMBv1 Disabled State

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value: SMB1
Expected: DWORD 0

Each of these represents a control that Intune policy should be enforcing — but that local administrators, software installers, or configuration drift can silently override. Collecting them gives you ground truth.

---

Querying Registry State at Scale with KQL

Once registry inventory data flows into Log Analytics, you can operationalize it through scheduled queries and alerts. The following examples assume you've configured the Intune Data Export to a Log Analytics workspace and that registry inventory data is landing in the IntuneDevices or custom inventory table (table names may vary based on your export configuration — validate against your workspace schema).

Query 1: Find devices where LSA protection is not enabled

IntuneDeviceInventory
| where RegistryKeyPath == "HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa"
| where RegistryValueName == "RunAsPPL"
| where RegistryValueData != "1" and RegistryValueData != "2"
| project DeviceName, DeviceId, RegistryValueData, LastSyncDateTime
| order by LastSyncDateTime desc

Query 2: Detect UAC disabled across the fleet

IntuneDeviceInventory
| where RegistryKeyPath == "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System"
| where RegistryValueName == "EnableLUA"
| where RegistryValueData == "0"
| join kind=leftouter (
    IntuneDevices
    | project DeviceId, UserPrincipalName, ComplianceState, EntraDeviceId
) on DeviceId
| project DeviceName, UserPrincipalName, ComplianceState, LastSyncDateTime
| order by LastSyncDateTime desc

Query 3: Cross-reference registry drift with Defender risk score

let RegistryDrift = IntuneDeviceInventory
| where RegistryValueName in ("RunAsPPL", "EnableLUA", "EnableFirewall")
| where RegistryValueData == "0"
| summarize DriftCount = count() by DeviceId, DeviceName;
DeviceInfo
| where isnotempty(MachineId)
| join kind=inner RegistryDrift on $left.DeviceId == $right.DeviceId
| project DeviceName, RiskScore, DriftCount, LastSeen
| where RiskScore in ("High", "Medium")
| order by DriftCount desc

This third query is where the architecture pays off. You're correlating registry configuration drift with Defender for Endpoint risk scores — surfacing devices that are both misconfigured and under active threat. That's the kind of signal that drives prioritized remediation rather than bulk policy reapplication.

---

Operationalizing Drift Detection Without Adding Tooling

The traditional response to registry drift was to deploy a configuration management tool — SCCM compliance baselines, a third-party CSPM agent, or a custom PowerShell compliance framework. Each of those approaches adds operational overhead: another agent to manage, another console to check, another data pipeline to maintain.

The Intune registry inventory approach eliminates that overhead for the Windows endpoint use case. The IME agent is already deployed on every Intune-managed device. The data pipeline to Log Analytics is already available if you're running Microsoft Sentinel or Azure Monitor. The KQL query language is already in use if your SOC is running Defender for Endpoint.

What changes is the scope of what that existing infrastructure can see.

To operationalize drift detection without new tooling, the workflow looks like this:

Step one — Define your security baseline registry keys. Work from CIS Benchmark Level 1 for Windows 11 Enterprise or your internal security baseline document. Map each control to its registry path and expected value. Aim for 15–25 keys initially; you can expand after validating collection reliability.

Step two — Configure custom inventory rules in Intune. Navigate to the Intune admin center, create a custom inventory profile, and add each registry key as a collection target. Assign to a pilot group first — 50–100 devices — and validate that data appears in the portal before fleet-wide rollout.

Step three — Export to Log Analytics. Configure the Intune Diagnostic Settings to export device inventory data to your Log Analytics workspace. This is a one-time configuration step that unlocks all subsequent KQL-based analysis.

Step four — Write baseline KQL queries. Start with the five security-critical paths listed above. Save them as functions in Log Analytics so they're reusable across workbooks and alert rules.

Step five — Create alert rules for critical drift. LSA protection disabled and UAC disabled should trigger near-real-time alerts. Set these as Sentinel analytics rules with Medium or High severity. Wire them to your incident response playbook.

Step six — Build a compliance workbook. An Azure Monitor Workbook that visualizes registry compliance state across your fleet gives you the audit evidence that SOC 2 and ISO 27001 assessors actually want to see — timestamped, queryable, exportable.

---

Governance Outcomes: What This Actually Closes for Auditors

Compliance frameworks don't care about your policy assignment screenshots. They care about evidence of control effectiveness — proof that the control was actually operating at the time being assessed.

Registry inventory data provides that evidence in a form that auditors can validate. A Log Analytics query showing that EnableLUA = 1 across the vast majority of your fleet over the past 90 days, with timestamps and device identifiers, is audit evidence. A screenshot of an Intune policy assignment is not.

For SOC 2 Type II, the relevant controls are in the CC6 series (Logical and Physical Access Controls) and CC7 (System Operations). Registry state for UAC, LSA protection, and firewall configuration maps directly to CC6.1 and CC6.6. With registry inventory, you can produce continuous evidence of control state rather than point-in-time screenshots.

For ISO 27001:2022, Annex A Control 8.9 (Configuration Management) explicitly requires evidence that security configurations are maintained. Registry inventory data, exported to Log Analytics with retention policies set, satisfies this requirement in a way that MDM policy assignment records do not.

For insider risk programs, the value is different but equally significant. An employee with local admin rights who disables UAC or LSA protection on their device is either misconfigured or deliberately reducing security controls. Registry inventory, combined with Entra ID identity context and Defender behavioral signals, gives your insider risk team a configuration-layer signal they previously had no visibility into.

---

PowerShell Validation Before You Commit to Fleet Rollout

Before deploying registry inventory collection at scale, validate that the values you expect to collect are actually present and readable on representative device types. This PowerShell script runs locally or via Intune remediation to pre-validate your target keys:

$TargetKeys = @(
    @{ Path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa";                                          Name = "RunAsPPL";                   Expected = "1" },
    @{ Path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System";                     Name = "EnableLUA";                  Expected = "1" },
    @{ Path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System";                     Name = "ConsentPromptBehaviorAdmin"; Expected = "2" },
    @{ Path = "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile"; Name = "EnableFirewall";    Expected = "1" },
    @{ Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging";             Name = "EnableScriptBlockLogging";   Expected = "1" },
    @{ Path = "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters";                     Name = "SMB1";                       Expected = "0" }
)

$Results = foreach ($Key in $TargetKeys) {
    $Exists   = Test-Path $Key.Path
    $Actual   = if ($Exists) {
                    try { (Get-ItemProperty -Path $Key.Path -Name $Key.Name -ErrorAction Stop).$($Key.Name) }
                    catch { "VALUE_NOT_FOUND" }
                } else { "KEY_NOT_FOUND" }

    [PSCustomObject]@{
        KeyPath       = $Key.Path
        ValueName     = $Key.Name
        ExpectedValue = $Key.Expected
        ActualValue   = $Actual
        Status        = if ($Actual -eq $Key.Expected) { "PASS" } else { "DRIFT_DETECTED" }
    }
}

$Results | Format-Table -AutoSize

$DriftCount = ($Results | Where-Object { $_.Status -eq "DRIFT_DETECTED" }).Count
Write-Host "`nDrift detected on $DriftCount of $($Results.Count) keys." -ForegroundColor $(if ($DriftCount -gt 0) { "Red" } else { "Green" })

Run this against 10–15 devices across your hardware and OS build spectrum before committing to inventory rule configuration. It surfaces keys that may not exist on older builds (Script Block Logging policy key, for example, only exists if the policy has been applied), which prevents false negatives in your inventory data.

---