Your Intune Compliance Is Moving to Azure Attestation… and Your Firewall Might Break it

Your Intune Compliance Is Moving to Azure Attestation… and Your Firewall Might Break it

Hey you…

Microsoft did it again…

Seems like I’m starting every blog like this huh?

I was casually browsing through the Windows Message Center… you know… because apparently that is what I do for fun nowadays… when I saw this:

Intune: Windows Health Attestation Migration to Microsoft Azure Attestion

Okay… Health Attestation… Azure Attestation…

Sounds like one of those backend changes where Microsoft moves something from Sevice A to Service B… changes a few URLS… and expects us to pretend we noticed.

Cool… moving on…

EXCEPT!!!

This one can actually make your Windows devices NON-COMPLIANT

… oh.. shit…

So… now you have my attestation… I mean ATTENTION…

Microsoft announced on September 17th 2026 that Windows Health Attestation compliance evaluation for Windows 11 devices managed through Intune will automatically migrate from the current Device Health Attestion service…

DHA

… to Microsoft Azure Attestation…

MAA

… during the first half of 2027.

And… before you think

Engin… come on… that’s 2027… why the hell are we talking about this now?

Well… Because I would rather check a firewall rule today… than troubleshoot 3000 suddenly non-compliant laptops on a Monday Morning… Ain’t nobody got time for that.

So… What the hell is Health Attestation?

Before we start opening firewall ports like it’s 2003 let’s first understand what we are actually talking about. If you have a Windows compliance policy in Intune you probably have seen these settings before:

  • Require BitLocker
  • Require Secure Boot
  • Require Code Integrity

Pretty straightforward. BitLocker Enabled? Good. Secure Boot enabled? Nice… Code Integrity working? WONDERFUL!. Device compliant.

Right?

Well… Not exactly. Intune isn’t simply asking Windows:

Yo… is Secure Boot enabled?

… and Windows replies:

Trust me bro…

That would be… slightly problematic. Windows Health Attestation uses hardware backed information (including TPM protected boot information) to verify the security state of the device. Very simplified it looks like this:

Windows boots
↓
TPM + Boot measurements
↓
Health Attestation
↓
Intune evaluates the result
↓
Compliant / Non-Compliant
↓
Conditional Access potentially ruins someone's morning

The important part here is that the attestation service is used to validate that the security state being reported can actually be trusted. Microsoft describes this as a validating boot-time security properties of the device. So… this isn’t just another registry key somewhere.

DHA… MAA… WTF?

Up until now Intune has used the Device Health Attestation service (DHA) for this compliance evaluation. Microsoft is moving Windows 11 over to Microsoft Azure Attestation (MAA). Windows 11 already contains the Health Attestation CSP functionality required to communicate with Microsoft Azure Attestation.

The device collects attestation evidence such as:

  • Boot information
  • TPM audit information
  • TPM certificate information

That evidence can be sent to Microsoft Azure Attestation. MAA validates it and returns a signed attestation result which can be used by Intune to determine the health of the device…

In other words…

OLD:

Windows 11 -> DHA -> Intune -> Compliance

NEW:

Windows 11 -> MAA -> Intune -> Compliance

From the user’s perspective? Nothing… from your perspective? Hopefly also nothing…

Hopefully…

So… what can actually break?

And here we arrive at the fun part… your firewall… because OF COURSE IT’S THE FIREWALL!!!

Microsoft specifically warns that if your firewall configuration prevents Windows 11 devices from reaching the new Microsoft Azure Attestation endpoints… devices using Device Health compliance settings can fall out compliance…

uhm… let me repeat that for you… Your laptop can have:

  • Bitlocker enabled
  • Secure boot enabled
  • code integrity enabled
  • TPM working perfectly
  • ABSOLUTELY NOTHING WRONG WITH IT…

And Intune can still report it as non-compliant because the device cannot reach the attestation service… The laptop is healthy… Intune just can’t prove it…

Perfect… Love it…

And then… Conditional Access enters the room…

This is where a boring network change can suddenly become a VERY visible user problem. A lot of organizations have Conditional Access policies using:

Require device to be marked as compliant

Which makes perfect sense… but… imagine this:

Firewall blocks MAA
↓
Health Attestation fails
↓
Device falls out of compliance
↓
Conditional Access sees non-compliant devices
↓
User can't access corporate resources
↓
Service Desk ticket
↓
Another Service Desk ticket
↓
327 Service Desk tickets
↓
Someone blames Intune
↓
Someone blames Microsoft
↓
Someone restarts the laptop 14 times
↓
Someone eventually checks the firewall

I may have seen similar movies before

Are YOU affected?

Before we panic… and start changing firewalls everywhere… Check whether this actually applies to you… This is mainly something you should investigate if you have:

  • Windows 11 devices (check)
  • Managed through Microsoft Intune (check)
  • Windows compliance policies (check)
  • Device Health settings enabled (check)
  • Restrictive outbound firewall rules (check)
  • Proxy filtering (check)
  • SSL/TLS inspection (check)

Especially the last one deserves some attestation… I MEAN ATTENTION… damn… did it again…

Microsoft explicitly says that SSL traffic inspection should NOT be used for the required attestation endpoints. So… if your security team decrypts and inspects every HTTPS connection because…

SECURITY!!!

… you probably want to have a conversation with them… bring coffee… maybe cookies…

Which Compliance settings are involved?

The 3 important Device Health settings mentioned by Microsoft are:

Bitlocker

This verifies the BitLocker state reported during boot. Small reminder: Health Attestation evaluates this at boot time. So if you just enabled BitLocker and the device is still showing non-compliant…

REBOOT THE DAMN DEVICE.

Sometimes IT really is that easy.

Secure Boot

Secure Boot makes sure the system starts using trusted boot components with valid cryptographic signatures. If somebody tampers with the boot process Secure Boot is supposed to notice. If somebody tampers with the boot process, Secure Boot is supposed to notice.

Code Integrity

Code Integrity verifies the integrity of drivers and system files being loaded into Windows. Unsigned or modified kernel components? Not exactly something we want on our corporate endpoints right? All three can depend on Health Attestation when used as a Device Health compliance requirements.

What do I need to allow?

The new Azure Attestation endpoints depend on the location of your Intune tenant. You can find you your tenant location here:

Intune Admin Center

Tenant administration
↓
Tenant status
↓
Tenant details
↓
Tenant location

For European tenants Microsoft currently lists these MAA endpoitns:

intunemaape7.neu.attest.azure.net
intunemaape8.neu.attest.azure.net
intunemaape9.neu.attest.azure.net
intunemaape10.weu.attest.azure.net
intunemaape11.weu.attest.azure.net
intunemaape12.weu.attest.azure.net

Required traffic:

Outbound HTTPS
TCP 443

and again… NO SSL INSPECTION

Don’t just copy my European list because you happen to be reading this article while sitting somewhere in Europe. Your physical location does NOT determine the Intune tenant location.

Check your tenant… Check Microsoft Learn… Then configure your firewall…

For the love of Cthulhu… don’t create random firewall rules because some guy called ENGIN THE MAGNIFICENT put 6 URLs on his blog…

What about Windows 10?

Interesting detail… According to Microsoft’s current documentation Windows 10 devices continue using the existing DHA endpoint. The same applies to GCCH and DoD environments. So this migration is specifically something Windows 11 Intune administrators should pay attention to.

Although if you are still designing a brand new Windows 10 deployment strategy… in late 2026… We probably need to have a completely different conversation.

Do I need to change anything in Intune?

As far as the announced migration goes… no giant migration project… no new compliance policies… no “Migrate to Azure Attestation” button that you need to press while sacrificing a Surface Laptop to the Microsoft gods. Microsoft says the compliance evaluation will automatically migrate during the first half of 2027.

Your preparation is mainly around connectivity. That means I would check:

  1. Which Windows compliance policies use Device Health settings?
  2. Which Windows 11 devices receive those policies?
  3. What is my Intune tenant location?
  4. Can those devices reach the correct MAA endpoints?
  5. Is outbound TCP 443 allowed?
  6. Are those endpoints excluded from SSL inspection?
  7. Do we use Conditional Access policies that require compliant devices?

Number 7 is important… because a compliance problem is annoying. A compliance problem combined with Conditional Access can become an outage.

Can I test this?

This is the part where I would NOT wait until Microsoft starts migrating productiond evices.

Take a few Windows 11 test devices… Look at your current compliance configuration… check your network path, the proxy logs, the firewall logs… Check whether the required Azure Attestation endpoints are reachable… and most importantly:

TALK TO YOUR NETWORK/SECURITY TEAM BEFORE THE CHANGE HAPPENS… not during… not after… BEFORE…

I know… REvolutionary concept.

One more thing

Microsoft maintains the official Intune network endpoint documentation and those endpoints can change. So please don’t create a firewall rule today… print this article… put it inside your change documentation… lock it in a cabinet… and assume those 6 endpoints will remain identical until the end of civilization.

Always validate against the current Microsoft documentation before implementing the change. Microsoft changes things… this is basically the reason this blog exists.

TLDR

Microsoft is moving Windows 11 Health Attestation compliance evaluation in Intune from Device Health Attestation (DHA) to Microsoft Azure Attestation (MAA) during the first half or 2027.

IF you use Device Health compliance settings such as:

  • BitLocker
  • Secure Boot
  • Code Integrity

… your Windows 11 devices need connectivity to the appropriate Azure Attestation endpoints for your Intune tenant region.

If your firewall or proxy blocks those endpoints Microsoft says affected devices can fall out of compliance. You need:

  • Outbound HTTPS / TCP 443
  • Correct regional MAA endpoints
  • No SSL inspection on those endpoints

And if you combine Intune compliance with Conditional Access… A firewall configuration problem can suddenly become a user access problem.

So… no panic… no emergency change… no weekend migration…

Just check it now… Future you will appreciate it.

Final Thoughts

I actually like this change. Azure Attestation is the logical place for this functionality and from an administrator perspective Microsoft is making the migration pretty painless.

There is no massive Intune redesign needed (let’s hope they won’t do that)… no new agent (please for the love of Cthulhu no agents)… no application deployment (we’re not in the SCCM era right?)… No 600MB MSI that needs 3 reboots and a virgin sacrifice (maybe the last one..)

Just… connectivity…

But those are also the changes I don’t like ignoring. Because when a huge feature migration requires almost no administrator interaction it becomes VERY easy to forget about it… until something breaks… So check your compliance policies… talk to your firewall guys… test your Windows 11 devices… and then go back to ignoring it until 2027.

Thanks for reading.

Cheers,

Engin

Leave a Reply