With the July 2026 service release (2607), Microsoft Intune now includes native Windows Registry inventory, giving administrators a built-in way to confirm that critical settings are actually in place on managed PCs—no PowerShell scripting required. The feature surfaces collected registry data directly in the Device Inventory page, bridging a long-standing gap between policy assignment and on-device reality.

What’s New in the Registry Inventory Feature

Administrators can now define a set of registry keys and values to collect from Windows devices managed by Intune. This is configured through a Properties Catalog profile, where you specify exactly which registry paths to inspect. Once assigned, devices check in and report the key path, value name, value type, and the actual data stored.

Microsoft supports three flexible collection patterns:
- A single named value under a specified key.
- All values directly under a key (non-recursive, excluding subkeys).
- The same named value across immediate subkeys of a given key.

That last option is particularly practical for settings spread across multiple adapter or component subkeys—for example, DHCP configuration under network interface keys. The collected data appears under Device Inventory, with the caveat that initial collection can take up to 24 hours. This is inventory telemetry, not real-time remote registry access; it’s designed for periodic sampling and validation, not active troubleshooting where you need instant feedback.

Microsoft has built in sensible guardrails: only the HKLM hive is supported, each device is limited to 100 collected keys, and individual values are capped at 6 KB. The system also attempts to detect and exclude potentially sensitive or confidential values, though admins should still apply data-minimization principles when selecting keys.

What This Means for IT Admins

For years, verifying that a configuration profile actually applied a setting—or that a third-party app registered itself correctly—often meant writing a detection script, deploying it via Remediations, and then figuring out how to store and review the output. That maintenance overhead scaled poorly across large estates. Now, you can ask a simple question like “Is this BitLocker key protector set to TPM+PIN?” or “Is our LOB app reporting version 4.2?” and get an answer directly in the admin console.

The feature shines in co-managed environments transitioning from Configuration Manager. Because it supports both Entra-joined and hybrid-joined devices, you get a unified view of inventory across machines still under mixed management. And since it’s included in Intune Plan 1, it’s available to the broad base of organizations without an extra license fee.

Security teams will find immediate value: registry keys often hold the ground truth for controls like Secure Boot status, firewall settings, or exploit mitigations. Instead of guessing whether a security baseline landed, you can inventory the relevant keys and spot drift early. A device-level record inside the management platform makes it far easier to resolve discrepancies between policy status and lived reality.

How We Got Here

Endpoint management has always struggled with the “last mile” of configuration—knowing that a policy was sent is not the same as knowing it was received and enforced. Intune’s existing reporting could show assignment status, but not the actual configuration state written to disk. The registry, despite being a decades-old technology, remains the substrate for countless Windows and application settings.

Without native inventory, admins resorted to creative workarounds: custom scripts, Log Analytics ingestion, even exporting registry files manually. The community reaction on forums like Reddit—calling this a “game-changer”—reflects years of frustration finally addressed. Microsoft’s documentation frames this as a way to validate a machine’s actual configuration rather than just the policy targeted at it. That shift in mindset, from “did I deploy it?” to “is it really there?” is what makes this release notable.

What to Do Now

If you’re an Intune admin, start by identifying the high-value registry checks that currently require scripts. Common candidates: security hardening settings, application version stamps, or driver configurations. Then, follow these steps:

  1. Build a small Properties Catalog profile targeting a pilot group. Add a few registry paths you understand well—for example, HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to check UAC status.
  2. Wait the 24-hour collection window and compare the inventory results against a local reg query. Ensure the data matches; this will surface any issues with key paths, access permissions, or value size limits.
  3. Retire only discovery scripts that this feature fully replaces. If a script also remediates a problem, keep it; Registry Inventory is read-only and won’t fix drift.
  4. Be mindful of the limits: 100 keys per device, 6 KB per value, HKLM only. For user-based settings (HKCU) or very large binary values, you’ll still need supplementary methods.
  5. Watch for portal availability: Early reports suggest that some tenants see the Registry category but not the configuration controls, likely due to staged rollout. Verify in your own tenant before changing existing workflows.

Don’t expect instant answers during an incident; this is designed for ongoing visibility, not firefighting. But once your profiles are in place, you’ll have a consistent, low-overhead record of what’s happening across your fleet.

Looking Ahead

Microsoft has hinted that registry inventory data will eventually feed into more parts of Intune—dynamic device filters, assignment rules, and Graph API queries. That evolution could make registry-based conditions a first-class citizen in policy targeting. For now, treat the Device Inventory view as a solid foundation, and keep an eye on the Intune release notes for expansion beyond HKLM and into richer reporting experiences. The hard part—getting the data out of the registry and into Intune without scripting—has finally been solved.