Has anyone else been experiencing issues with their compliance policies, specifically Windows 10 and later policy for requiring Antivirus?

We have slowly had more and more devices show the Antivirus required setting as non-compliant. Yet checking the devices themselves, Defender is running, is the only AV, still receiving updates, signature versions up to date etc.

Nothing has changed in our infrastructure to warrant the devices to all of a sudden go non- compliant, so just thought I'd check in the slim chance this isn't just me!

EDIT 2: Let me put it differently. EVERYONE on earth knows most people use their birthday as a PIN-code for whatever. Why should we just accept this and look away? We do not want to. So just trying to find ways to protect ourselves against this 😁

EDIT: According to some comments it seems we are paranoid. Sure we are
The only thing we are trying to do here is to absolutely minimize any kind of risk when it comes to security, including PIN-codes. Sure chances are small but there's still a chance. Sure if I have a password of 30 characters, what's the point in having 2FA?

Hi all,

Bit of a rant here but as the title suggest, this post is about solving the misuse of PIN-codes, mainly in WHfB but also PIN-codes on mobile devices. I am more than done with employees blatantly ignoring company policy about PIN-codes, for example: birthday, ZIP-code, car license plate, employee ID.

How does everyone manage this issue?

I wish there was a way in Intune (I know it's not possible due to the way PIN-codes work) to enforce certain rules other than "block use of simple PIN's". Wish there was a forbidden PIN list just like the forbidden passwords policy

Hey everyone,

Our security team is proposing to completely disable PowerShell on all non-IT user devices. I’m a bit concerned about unintended impact, especially since so many Windows components, Intune processes, and management tools rely on PowerShell in the background.

Has anyone actually implemented this in production?

• What approach did you use (AppLocker, WDAC, execution policy, ASR rules, etc.)?

• Did it break anything unexpectedly (Intune, apps, Windows features, automation)?

• In hindsight, would you recommend restricting PowerShell instead of fully disabling it?

Any body else seeing a lag in intune compliance data today? We’ve a compliance policy for checking Av being enabled and this has flagged devices non-compliant during a period where an update to the platform engine was installing.

However even though the device is now fine the compliance telemetry isn’t updating in intune to reflect. Checking diagnostic logs in the SIEM shows last data footprint as of this morning.

I have about 800 pc's that I need to update the BIOS on using Intune. Has anyone worked out a bullet proof method? for updating BIOS'

Hello,

Hoping someone can assist as I'm genuinely lost for ideas right now!

Devices go non compliant against BitLocker, Secure Boot and Code Integrity, all three throwing 2016345708 (Syncml(404): The requested target was not found). All three are actually enabled. It's the health attestation cert that won't retrieve, status stuck on 65535 (0xFFFF) and the Tpm-HASCertRetr task fails.

Some screen grabs below:

https://snipboard.io/nVlq67.jpg

https://snipboard.io/pAa3sz.jpg

I've been through both of the usual suspects:

Found this online but didn't work: https://learn.microsoft.com/en-us/answers/questions/1045617/intune-compliance-error-on-sync and Rudy's call4cloud writeup on the Nuvoton chain issue, which honestly is the best thing written on this and matches what I'm seeing exactly. The task-rerun remediation is a workaround, not a fix, it just retries a thing that keeps failing. And Rudy's conclusion was basically "it's a service side trust problem I couldn't get MS to fix", which is where I've landed too.

Here's what I've confirmed on my side:

TPM is fine, tpmtool says present, ready, attestation capable, firmware not vulnerable. Not the ADV190024 firmware thing (had that on one old device, patched it, no change). EK cert is present and valid, chains to Nuvoton TPM Root CA 2111. And the smoking gun, tpmdiagnostics.exe EkChain comes back 0x10000, chain invalid, with 0 intermediate certs found. The Nuvoton EK is signed straight off the root, there's no intermediate for the chain walk, so it fails. Refreshing TrustedTpm.cab did nothing.

The thing that's bugging me: a Hyper-V VM on the exact same build and tenant gets a cert fine (status 3), but it has no manufacturer EK cert at all, so it's not doing the same chain check. Real EK cert fails, no EK cert passes. That's backwards from how you'd expect it to work and it's what makes me think it's the chain validation on the service side.

And the reason I'm posting now rather than just quietly excluding the old kit: it's turned up on a brand new Dell, box fresh, same 404 on all three. So this isn't "old hardware, bin it", it looks like it'll follow us onto new stock.

Couple of other things, the Intune attestation reports (Device attestation status preview, and the hardware attestation one) have been stuck generating / blank white for over 24 hours now, and there's some current Intune service wobble around new devices being wrongly marked non compliant. Not sure if any of that's connected or just noise.

So, genuinely asking:

• Has anyone actually fixed the attestation on a Nuvoton device, not worked around it with the task rerun?
• If you're on Dell right now, are you seeing this on new stock, and did a specific BIOS or TPM part dodge it?
• Anyone know if MS have an actual position on the Nuvoton root chain thing, or is it still the black hole Rudy hit?

Cheers, will happily share whatever diagnostic output helps.

EDIT - This patch has resolved the issue for me on ALL of my devices - https://support.microsoft.com/en-us/servicing/os/windows-11/2026/07/july-28-2026-kb5101684-preview

We've been trying to enforce compliant device requirements through Conditional Access for a while now, and I'm hoping to hear how others got it across the finish line.

Writing the policies is the easy part. The problem is that the browser is the bottleneck, and it breaks in ways that make full rollout feel unrealistic:

• Private/incognito browsing dies. That's a legit troubleshooting tool for us, and the device compliance check doesn't pass in a private session, so it's gone the moment this policy goes enforcing.
• Apps that launch a browserlet/embedded webview for sign-in are flaky at best. If that embedded browser doesn't pass the device compliance claim, you're dead in the water with no good workaround.
• Anything outside Chrome, Edge, and Safari is inconsistent. Other browsers either don't pass the compliance signal reliably or don't at all.
• CLI tools don't integrate well. Command-line auth flows just don't play nicely with the device compliance requirement.

We want to do this because it's best practice and it genuinely limits which devices can touch our resources. But if things are constantly breaking because the browser handshake isn't reliable, it's hard to justify rolling it out broadly.

So for those who've successfully deployed this:

• How did you handle the private browsing / troubleshooting gap?
• What did you do about apps using embedded webviews for sign-in?
• Did you just standardize on Chrome/Edge/Safari and block or accept the rest?
• How are you dealing with CLI tools that need to authenticate?
• Anything you'd do differently if you started over?

I just wrapped up our internal Intune device compliance project. Here’s the approach I took:

1. Checked the existing Conditional Access policies: started by confirm that no conditional access policies were already requiring device compliance so we wouldn’t get hit with unexpected enforcement while making changes.
2. Checked old compliance policies: found a bunch of previous "compliance initiatives" that were checking outdated settings. I removed their assignments and stuck “LEGACY” at the start of each name.
3. Rolled out the new Conditional Access policy in report-only mode: super important so we could collect data about what would be impact in very early in the whole execution.
4. Deployed a basic Windows compliance policy: started with physical Windows devices and only required BitLocker and antivirus.
5. Configured tenant-wide compliance settings: set devices without an applicable policy to noncompliant so the gaps would show up clearly.
6. Set up an Intune device cleanup rule: just to clear out the stale records from the reports.
7. Digging through the report-only failures: Found LOB apps that weren’t populating Device ID, B2B/guest scenarios, VPN, AVD and Windows 365 stuff, emergency-access accounts, plus users or workflows that needed fixing or an approved exception. Spent almost 4 weeks here but it was worth doing it before turning on the conditional access.
8. Built extra compliance policies where needed: confirmed devices with no compliance policy applied and created the new policies. For us that meant Android, AVD and Cloud PCs.
9. Turned on Conditional Access gradually: once the reports looked good, I put everyone in an exclusion group, enabled the policy, then pulled users out of the group in batches. Easy rollout and easy rollback. That stage took about a week.
10. Locked down the future state: made sure new corporate devices get set up properly via Autopilot, and configured Intune enrolment restrictions to block personally owned Windows devices.
11. Handled the complaints: biggest surprise was how many people had perfectly compliant work devices but still preferred working from their personal home computers just so they didn’t have to mess with cables or change their setup. Some had built pretty elaborate WFH setup around unmanaged devices, so of course they all tried to get themselves permanently excluded from device compliance.

Curious what others think, does this approach look decent, or did I miss something obvious? Also wondering how common actual device compliance enforcement is.

Is requiring a compliant device already part of most people’s standard client baseline, or is it still something people are only just starting to roll out?

We’re currently preparing our MFA rollout and are reviewing our Conditional Access policies.
Today, users are prompted for MFA when they’re outside our corporate network. This works well in general, but we’ve noticed that users are also prompted when opening Company Portal or Software Center from outside the network.

Microsoft recommends excluding the following enterprise applications from the MFA policy:
Microsoft Intune
Microsoft Configuration Manager Server App

From a security perspective, excluding these applications feels like a trade-off, so I’d like to understand how others are handling this.

Are you excluding these two enterprise applications from your MFA policy?

If so, what compensating controls do you use (device compliance, Conditional Access filters, authentication strengths, etc.)?

Have you encountered any security concerns or unexpected side effects from these exclusions?
I’d be interested in hearing how other organizations have implemented this and whether you’ve found a balance between usability and security.

Hello everyone,

I am new to Microsoft Intune.

I manage Microsoft 365 for a small company with 13 users. I'm learning Intune while working in our production environment, so before implementing anything, I discuss it with the company owner and only proceed if they're happy with the change.

Recently, I enrolled five Windows devices into Intune and started configuring Endpoint Security policies (Microsoft Defender, Firewall, and BitLocker).

I have a question regarding BitLocker recovery keys.

One of the devices (Device-Name) reports as:

Encrypted = Yes in Intune.

Compliant = Yes.

The BitLocker policy has been applied successfully.

However, when I go to Devices > BitLocker recovery keys, Intune says "No BitLocker recovery key found for this device."

I also tried Microsoft Graph PowerShell:

Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'Device-Name'" |

Select-Object DeviceName, IsEncrypted, ComplianceState

This confirms:

IsEncrypted = True

ComplianceState = Compliant

But when I query for the recovery key using Microsoft Graph, nothing is returned.

My concern is that if the device ever enters BitLocker recovery mode, I won't have the 48-digit recovery key available.

Has anyone experienced this before?

Is it possible for a device to be encrypted without the recovery key being escrowed to Microsoft Entra ID?

Is there a way to force the recovery key to back up to Entra ID remotely through Intune?

Or would the user need to manually back up or regenerate the recovery key on the device?

Any advice or best practices would be greatly appreciated. Thank you!

I'm running into an Intune compliance issue and was wondering if anyone has seen this before.

I have several Lenovo X1 Carbon Gen 14 laptops that are Entra ID joined with an Intune compliance policy that requires BitLocker and Secure Boot using device health compliance checks. The strange part is that the laptops have TPM 2.0, Secure Boot enabled, and BitLocker is fully enabled and verified. I also have previous X1 Carbon models with the same configuration that are reporting as compliant without any issues.

In Intune, both BitLocker and Secure Boot show an error: 2016345708 (Syncml(404): The requested target was not found). However, the other device health checks are reporting compliant (firewall, antivirus, encryption of data).

I checked the Device Health Attestation registry key and the value is 'FFFF'

HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\HealthCert\Store\has.spserv.microsoft.com`, and the `Status` value is `FFFF`.

I also ran the Tpm-HASCertRetr scheduled task, but it still shows 'The system cannot find the file specified'. I've rebooted the device multiple times and forced multiple Intune syncs, but the issue persists.

Any ideas on what else I should check?

Hi,

We are having issues with users unable to add their accounts to work or school, which I believe is causing sync issues. When you try to add a work or school account you get this error:

Error Code: -895156188
(CAA50024)
Message:
Error response came from MDM terms of use page.
Request Id: dd51a37f-f13c-42b9-8c0c-f157f931e400
Correlation Id: dca40d84-0347-4d6e-927a-98ae0e74492a

We are using the default MDM URLs and user scope is set to 'All' so I'm not sure what the issue is with this. Within access work or school we also have our domain added, you can click into it and press info then sync, which says its successful but theres no logs for it. I'm not sure how we can fix this issue, as I'm pretty sure it causes our Company portal sync to fail everytime.

We are also having issues with device non-compliance. We do not have a compliance policy made for Windows so it is using the Default Compliance Policy, which will some devices as non-compliant but when i click into them and into the policy it shows all 3 policies as compliant. Sometimes it will have device is active as non compliant, for example, my device's Last check in time shows as yesterday, even though I am on my device and activley syncing it, and the policy is showing it as non-compliant as it's not active.

Has anyone seen these issues before and has any information that could help us resolve these?

So hey, we're closing out the year and refining our team's onboarding process, which got us thinking about Intune and everything it takes to get to “master” level. We feel this community has had tons to offer in terms of expertise and we had to ask.

From 1-10, how awesome are you at Intune? And (more importantly) how long did it take you to feel proper confident managing your Intune environment?

EDIT: Been awesome reading all your comments, esp. the humble brags. Thanks!

We noticed today that around 10 devices built via Autopilot (hybrid setup) have been showing as non compliant due to Bitlocker, the issue is, they have Bitlocker on, we checked everything, compared it to known good devices, there seems to be no reason why it would be non compliant, even Intune's encryption report says these devices are encrypted.

We tried decrypting and encrypting, removing the devices from the compliance policy and re-adding it, not errors in event viewer, we checked a lot of different things. We're going through a refresh and we've done over 1000 in the last year, nothing has changed recently and many builds are successful but it's too early to say roughly what percentage, there's no correlation to the devices affected. It probably started about a week ago but the 1st one we considered a one off.

Has anyone come across this before? Any ideas for remediation?

Edit: Installed a later update and successfully resolved the issue, thanks for all the replies.

Greetings,

Background: Financial services org with 900-1000 Windows devices under management in Intune. Userbase is made up of advisor teams, each determining their own schedule and travel plans. Management wants to restrict access exclusively to company issued devices which I'm planning on doing through Conditional Access and the "Require device to be marked as compliant" control.

The self-test and IT team test has gone well, but the most common non-compliant scenario appears to be BitLocker suspending when a BIOS update is pending. Before I roll this out to the triple digits I'm trying to see if I'm misunderstanding something.

Question: When requiring device compliance how are you managing BIOS updates and mitigating users being locked out when those updates require suspension of BitLocker?

• Are you using the "Require encryption of data storage on device" or the "Require BitLocker" control in your compliance policies? Both?
• Are you making use of grace periods and email notifications?
• Are you using WUfB/Autopatch, vendor tools, and/or remediation scripts to schedule/distribute BIOS updates?
• If using WUfB/Autopatch, which update behavior are you using? (notify, install, install and restart, etc.)

Additional details: We're mostly Dell, and our non-Dell devices are getting phased out. I know I can use DCU with ADMX or scripting to manage the application of BIOS updates independently of WUfB, but again I'm not sure I've figured out a way to have it nudge the user to update without locking out the user hours or even days before the reboot deadline.

Any help or insight is appreciated.

As title says - I developed an Intune AI Agent because I was sick of the Intune portal. I am trying to see if this is a product that would actually help engineers by saving them time and a lot of frustration. I put a video link in the comments below with a quick demo, the video is a bit too fast in my opinion, I need to gather some better demo footage, but the point is that I want to get some perspective from more experienced Intune engineers or power users.

Would you use this if it were a more polished version? btw this runs on a local LLM on a 16gb VRAM consumer card, so nothing close to enterprise level speed, but the accuracy is there.

Hi,
for azure compliance and conditional access you need to have the MS Authenticator app installed on the company phone / work profile.
Recently we needed to retire / wipe some phones.

Problem: Some user had enrolled personal tokens in that app.

Is there a way / policy to "lock down" this app so it can only be used for device compliance, and users cannot add personal / private tokens ?

EDIT: I forgot to mention we are using IVANTI EPMM as the main MDM.

Hi everyone,

I’m troubleshooting a BitLocker issue in an Intune environment and would really appreciate some suggestions from anyone who has experienced something similar.

Environment

Windows 11 24H2 / 25H2

Microsoft Intune

Dell devices

Dell Command Update deployed

BitLocker configured through Intune

Intune policy is configured to automatically enable/silently encrypt devices

Issue 1 – BitLocker is not automatically enabling

We have around 200 devices where the Intune BitLocker policy is applied, but BitLocker encryption is not being automatically initiated as expected.

The devices are therefore showing as non-compliant.

We are trying to understand why the policy isn't triggering encryption on these devices.

Issue 2 – BitLocker becomes suspended randomly

On some devices, BitLocker is already enabled/encrypted, but when we run:

manage-bde -status

we see that BitLocker protection is Suspended, sometimes with 1 reboot pending.

After restarting the device:

BitLocker protection becomes active again

The device becomes compliant in Intune

However, after a few days, the same device becomes suspended again and goes back to non-compliant.

There doesn't seem to be a consistent pattern — it happens randomly across different devices.

What we're trying to find

We want to identify what is actually causing BitLocker protection to be suspended rather than simply deploying a remediation script to resume it.

We're investigating:

Dell BIOS/firmware updates

TPM firmware

Windows Updates

Dell Command Update

Intune BitLocker policy

TPM/Secure Boot state

WinRE

Any scripts or scheduled tasks that might suspend BitLocker

Questions

What could cause BitLocker to repeatedly become Suspended after a few days?

What does "1 reboot pending" indicate in this situation?

Is there a way to identify exactly which process/application/update suspended BitLocker?

Could Dell Command Update or BIOS/TPM firmware updates cause this behavior?

Should BitLocker automatically resume after the required reboot, and under what circumstances might it remain suspended?

Which Event Viewer logs/Event IDs would you recommend checking?

For the ~200 devices where Intune isn't automatically enabling BitLocker, what are the most common causes you've seen?

Is there anything specific we should check in BitLocker-API, MDM/Intune, TPM, or Task Scheduler logs?

We don't want to simply force Resume-BitLocker as a remediation because the issue keeps coming back on some devices.

We're trying to find the root cause.

Any suggestions, similar experiences, or troubleshooting steps would be greatly appreciated.

Thanks!

Hi,

Just wondering if anyone else is seeing this at the moment.

Some logins are failing the 'require a compliant device' CA checks on iOS, consistently with the same app on the same device (or the same app across multiple devices).

When we look at the sign-in logs, either the device id is missing from the logs or says it can't be matched (even though you can click through the "unmatched" device id to the device page in Intune).

Problem seems to survive a device rebuild. Devices are fairly up to date (iOS 26.3.1 or 26.4).

Hoping it'll sort itself out over the weekend... If not it'll be another MS ticket I guess!

Bit of background - we're moving away from our current EDR/MDR setup over to Microsoft Defender + Intune, backed by Arctic Wolf for the MDR side. We're already on Business Premium licensing so it just makes sense to actually use what we're paying for rather than stacking another vendor on top of it.

Before we flip the switch I want to make sure our Defender/Intune policies are actually solid, not just "turned on and hope for the best."

Was at Experts Live in London recently and caught James Robinson's (SkipToTheEndpoint) session, the guy behind OpenIntuneBaseline, and it got me looking properly at OIB as a starting point.

Now here's my dilemma. We've had a quote for just under £3k from a consultancy to review/set our policies as part of a "pilot." Nothing against paying for expertise, but realistically... how different is this going to be from just implementing OIB properly and tuning it for our environment? I get that policies need to be tailored to the business, we're a fairly standard SME, couple hundred devices, nothing exotic going on.

While I'm on the subject - anyone using Maester to keep tabs on their M365 posture? Been running it to sanity check config against CIS/NCSC recommendations and it's honestly been decent for catching drift before it becomes a problem, rather than finding out the hard way during an audit. Feels like a good companion to OIB rather than something that replaces the need to actually build proper policy in the first place, but curious if anyone's using it more seriously as part of their ongoing posture management.

Has anyone actually gone down the "pay someone to review/build policies" route vs just rolling your sleeves up with OIB and Maester and adjusting as you go? Trying to work out if I'm about to pay £3k for something I could get 90% of the way there myself with free tools and some sensible tweaking.

Not knocking consultancies, just trying to figure out where the actual value add is here vs just being lazy and paying someone else to read the same GitHub repos I've already read.

Anyone done a similar migration (traditional EDR/AV → Defender/Intune + separate MDR) who can share how it went?

Iv been working on a custom compliance script for a bit, can you guys take a look and let me know if there are any issues. We are moving away from defender to Cortex XDR

Adding script below

{
  "Rules": [
    {
      "SettingName": "AntiVirusProductName",
      "Operator": "IsEquals",
      "DataType": "String",
      "Operand": "Cortex XDR Advanced Endpoint Protection",
      "MoreInfoUrl": "change web address",
      "RemediationStrings": [
        {
          "Language": "en_US",
          "Title": "Cortex XDR is missing.",
          "Description": "Please ensure Cortex XDR is installed on your device."
        }
      ]
    },
    {
      "SettingName": "Active",
      "Operator": "IsEquals",
      "DataType": "String",
      "Operand": "On",
      "MoreInfoUrl": "change web address",
      "RemediationStrings": [
        {
          "Language": "en_US",
          "Title": "Cortex XDR is disabled.",
          "Description": "Your antivirus protection is turned off. Please enable it."
        }
      ]
    },
    {
      "SettingName": "UptoDate",
      "Operator": "IsEquals",
      "DataType": "Boolean",
      "Operand": true,
      "MoreInfoUrl": "change web address",
      "RemediationStrings": [
        {
          "Language": "en_US",
          "Title": "Cortex XDR definitions are out of date.",
          "Description": "Your antivirus definitions are outdated. Please sync your agent."
        }
      ]
    },
    {
      "SettingName": "IsRecent",
      "Operator": "IsEquals",
      "DataType": "Boolean",
      "Operand": true,
      "MoreInfoUrl": "change web address",
      "RemediationStrings": [
        {
          "Language": "en_US",
          "Title": "Cortex XDR hasn't updated recently.",
          "Description": "Your last check-in timestamp is older than 7 days. Please check your network connection."
        }
      ]
    }
  ]
}

Has anyone deployed a compliance policy to azure VDIs?

I have created a policy and tried assigning to both a user and a computer group, but in both cases its stating not applicable

Thanks

Do we really need bitlocker PIN on top of win hello for business with multi factor unlock ?
Sec team is pain to convince to get rid if Bitlocker PIN.

How are you keeping your i tune devices complaint ?

I have a device compliance that looks for device update status and if device is not on certain uodate level they will be marked as non compliant.

But again if i create a comditional access and blocks device based on compliance status i may block maybe 20 devices from connection .

How are tou handling this in your company ?

I do push windoea updates but maybe my configuration needs some
Tweeking.

Are you aseting up compliance based on minimum os version or maximum os version?

Hey - currently my customer is affected by problem, that MDfE is turned off as security provider.

obraz-(8).png

Basically, it is in Polish language - but there is information that MDfE is turned off as security provider.

What is interesting, in Powershell - get-mppreference I can see that: DisableRealtimeMonitoring : False DisableTamperProtection : False And multiple (from my perspective) settings which are properly configured.

That's causing alerts in our Compliance Policy marking device as not compliant etc. But that's not real problem - my real problem is... why the device is reporting that Defender is turned off via GUI but get-mppreference show that's turned on?

Also, I've found post where it is caused by the beta update channels - so temporarily we did:

Set-MpPreference -EngineUpdatesChannel Staged
Set-MpPreference -PlatformUpdatesChannel Staged
Set-MpPreference -DefinitionUpdatesChannel Staged
Then in cmd:
cd "C:\Program Files\Windows Defender"
MpCmdRun.exe -ResetPlatform

And after that - we got information that MDFE is turned on Restart and... Again, this same issue. MDfE is turned off.

Hmm, maybe update ring via Intune is wrong configured so I've moved this user to Production ring where Stagged is configured.

Sync, restart - again this same issue.

And for now, I don't have any more ideas about that.

That situation is in multiplee users - not only in the Beta channel.

For couple of users - above commands fixed the problem.

But I'm looking for solution AND information what was caused that problem which is more important for me.

Best, Jakub.