Access Manager no longer working with Entra ID? Fleet‑wide 802.1X/EAP‑TLS failures since October15th

[Ruben_S]

Hi Meraki Community,

Since yesterday, we’re seeing 802.1X (EAP‑TLS) auth failures across our fleet (macOS, Windows, and others). Meraki Support told us there were changes on Access Manager yesterday. We suspect the issue is related to how Access Manager now reconciles the user identity between its Meraki user database and the client certificate on the endpoint.

What we see:

• Affects all OS in our environment (not just macOS).
• Server cert validation is OK.
• The failure happens at client certificate verification (EAP‑TLS), consistently across devices.
• This started immediately after the Access Manager changes

Ask : 

• Can you confirm what changed in Access Manager regarding identity mapping/reconciliation between user records and client certs?
• Is there a known issue or a rollback/workaround available?

Errors we have in Session log : 

"Info:

There was an unexpected error.

Suggested action:

Please verify configurations and retry. Please report if this issue is not fixed."

Thanks, Ruben

[alemabrahao]

Meraki updated Access Manager documentation on October 14, 2025, introducing refinements to identity mapping and certificate-based authentication (EAP-TLS) with Entra ID integration. Key changes include:

Stricter identity reconciliation between the client certificate and the user identity stored in Meraki’s local database (synced from Entra ID).

Certificate validation logic now checks for:

Matching identity attributes (e.g., username, UPN, device name).
Valid certificate chain (no duplicates, disabled signers).
Presence of synchronized user attributes from Entra ID.

This means that if the certificate subject or SAN does not match the expected identity format or if there's a mismatch with Entra ID records, authentication may fail, even if the certificate is technically valid.

Access Manager - Cisco Meraki Documentation

[Kine]

Hello alemabrahao,

Thanks for your answer. We had the feeling something changed.

Do you know where we can find detailed documentation about the changes?

What we do not understand is:

UpN in our EntraID are in the format name.surname@company.com

Our SCEP certificate CN is name.surname

The certificate Identity in Meraki is set to CN.

Since yesterday, in the Session logs we started seeing lots of failing clients showing in the "Username" column name.surname@domain.com

A very small percentage of clients instead still connects successfully, and they show as username only name.surname (Which is what we would expect, given our certificate configuration, and what used to work until today).

This sounds like Meraki is not constantly sourcing the CN from the certificates anymore, but rather is often passing the email, which contains the domain too.

Even more strange, the emails should exactly match our UpNs, but the authentication fails (code 23).

We are testing with a new certificate containing more alternate names populated with UpN and email, I will report back if we find a working configuration.

[Kine]

None of our tests succeeded in fixing. We phoned Meraki: known issue, devs are working on it, no solution available at the moment.

I will post when we receive new info.

[Kine · Accepted solution]

Meraki informed us that the issue was fixed on their side.

We are slowing reactivating Access Manager on our networks and the Session Logs looks good.

In the username column we see again the name.surname pattern.

No changes to our certificates, nor to Meraki settings.

[PhilipDAth]

I see it has been updated again.

"Last updatedOct 16, 2025"

[Jeroenvdd]

Our access manager completely stopped working this morning as well,

this irritating thing is I see no errors in any of the logging..

also with this notification:

[alemabrahao]

In this case, I think it would be interesting for you to contact Meraki support.

[Jeroenvdd]

I've done so, ticket created but strangely enough they wanted a har file as if the interface of my browser showing an error could be linked to why the rules stopped being processed for everyone on the network..

We'll see what happens

[PhilipDAth]

I just tried on my test network, authenticating with WiFi using WPA3 using a user certificate, and it is still working ok for me.  I'm using Intune CloudPKI for my CA server.

[Ruben_S]

Can you please confirm which EntraID attribute is used for checking identity please ? (Subject common name, RFC822, DNS ? )

Thank you

[PhilipDAth]

We are using email address for your user certificates.

[Kine]

Yesterday we tested with an Intune certificate built as follows:

Then we tried all available Identity settings in Meraki (Subject common name, RFC822, DNS ), asking each time to a test client to try authenticating.

Outcomes:

• Independently from the identity setting, the Username column in Session Logs always shows the full name.surname@domain.com pattern.
• All attempts lead to the same: "Unexpected error".

The impression is that the Identity selection is not working anymore, or the EntraID lookup is broken.

At the moment Meraki is still investigating the issue and unable to provide any guidance. 

[watdee]

We ran into what looks like the same issue in our environment, except we're using machine certificates instead of user certs.

Our setup:

• Identity is set to SAN:DNS
• Our SCEP profile adds a SAN DNS attribute with the value {{DeviceName}}.mydomain.local
  
  

When the issue started, the username in Access Manager logs changed from COMPUTERNAME.domain.local to host/COMPUTERNAME.domain.local, and authentication started failing. 

The issue lasted about 24 hours, then resolved on its own, host/ disappeared and authentication started working again without any config changes on our end.

I had opened a support case but didn't receive any helpful information, so we were in the dark as to what happened until I found this post. I also haven’t found any documentation confirming whether machine cert-based EAP-TLS is officially supported with Access Manager.  

Glad it’s working again, but wondering:

• Was this caused by a backend change that they rolled back or a bug that they fixed?
• Is our setup (machine certs + SAN:DNS) officially supported?
• Should we deploy a fallback WLAN to our devices in case this happens again or is there another workaround anyone can suggest?

Thanks

[PhilipDAth]

You could configure a fallback SSID, but leave that SSID disabled on your MRs unless you need it.