The following checks confirm whether a device has the wrong enrolment type. This is a common scenario if the device was already Azure AD Joined, and then joined to device management.

This is the definitive check. Look for the MDM certificate in both stores:

# Machine store - where the cert should be for device enrolment
Get-ChildItem Cert:\LocalMachine\My |
    Where-Object { $_.Issuer -like "*Intune*" -or $_.Issuer -like "*MDM*" } |
    Select-Object Subject, Issuer, NotAfter, Thumbprint
 
# User store - where the cert ends up in a user enrolment
Get-ChildItem Cert:\CurrentUser\My |
    Where-Object { $_.Issuer -like "*Intune*" -or $_.Issuer -like "*MDM*" } |
    Select-Object Subject, Issuer, NotAfter, Thumbprint

The certificate is issued by Microsoft Intune MDM Device CA. If it appears in CurrentUser\My instead of LocalMachine\My, the device is enrolled in user context.

This can also be checked via the GUI: certlm.msc for the machine store and certmgr.msc for the user store, under Personal → Certificates.

MDM enrolment configuration is stored under:

HKLM\SOFTWARE\Microsoft\Enrollments\{enrolment-GUID}

Each enrolment has a GUID subfolder containing an EnrollmentType value:

• 6 = device enrolment (AzureDomainJoined)
• 14 = user enrolment (UserEnrollment)

The UPN and AADTenantID values in the same key show which identity was used for the enrolment.

The Intune Management Extension log confirms which certificate store the MDM client is using:

Get-Content "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log" -Tail 200

Important lines to look for:

• Found 1 MDM certificates from Local Computer Store. - confirms machine-level enrolment. If this reads Local User Store, the enrolment is in user context.
• Device join type = DSREG_DEVICE_JOIN - confirms a proper Azure AD device join.
• After impersonation: AzureAD\<username> - IME service impersonating user context for user-targeted policies while the base check-in remains device-level. This is expected behaviour.
• [SendWebRequestInternal] Succeeded - successful check-ins with no authentication errors.

Exporting and importing the certificate from the Local User store as SYSTEM is possible, but it is unclear how Intune will handle renewal of a manually relocated certificate. The certificate may also be marked as non-exportable, making this approach impractical. The recommended fix is to remove the incorrect enrolment and re-enrol the device in the correct machine context.

Disconnect the MDM enrolment by going to Settings → Accounts → Access work or school, selecting the MDM account entry and choosing Disconnect. Ensure the Entra ID account entry is not removed, as this would unjoin the device from Azure AD.

Clean up any stale state left behind:

• Check HKLM\SOFTWARE\Microsoft\Enrollments for leftover enrolment GUID subkeys and remove them.
• Check Task Scheduler → Microsoft → Windows → EnterpriseMgmt for orphaned scheduled tasks.

Stale entries from the old enrolment can interfere with the new one.

Run the following script as SYSTEM (use PsExec and become NT AUTHORITY\SYSTEM):

# Set MDM Enrollment URL's
$key = 'SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo\*'
$keyinfo = Get-Item "HKLM:\$key"
$url = $keyinfo.name
$url = $url.Split("\")[-1]
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo\\$url"
 
New-ItemProperty -LiteralPath $path -Name 'MdmEnrollmentUrl' -Value 'https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath $path -Name 'MdmTermsOfUseUrl' -Value 'https://portal.manage.microsoft.com/TermsofUse.aspx' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath $path -Name 'MdmComplianceUrl' -Value 'https://portal.manage.microsoft.com/?portalAction=Compliance' -PropertyType String -Force -ea SilentlyContinue;
 
# Trigger AutoEnroll
C:\Windows\system32\deviceenroller.exe /c /AutoEnrollMDM

Running this script in a standard or elevated user PowerShell session instead of SYSTEM will enrol the device in user context, placing the certificate in the Current User store and reproducing the original problem.

After re-enrolment on this device, the full policy stack applied successfully: Defender for Endpoint configuration, BitLocker encryption with recovery key escrow to Entra, ASR rules in block and audit mode, firewall policy, and WNS channel registration.

You will also notice your configuration policies now applying under SYSTEM context from Intune.

Wrong enrolment method selected: “Enrol only in device management” in Settings triggers user-level enrolment. “Join this device to Azure Active Directory” triggers device-level enrolment.

• Enroll existing Entra joined devices into Intune - Rudy Ooms, May 14 2020 - detailed write-up on MDM certificate store behaviour during Intune enrolment troubleshooting. This is what originally pointed me towards checking the enrolment type when device-scoped policies were not applying.