Microsoft 365 Copilot Desktop Sign-in Fails with AADSTS53003 Under FIDO2 Conditional Access Policy

Question

Microsoft 365 Copilot Desktop Sign-in Fails with AADSTS53003 Under FIDO2 Conditional Access Policy

MILAN OMIDVAR 0

Hello,

We are experiencing an authentication issue with the Microsoft 365 Copilot desktop application after enforcing FIDO2 authentication for privileged administrator accounts through Microsoft Entra Conditional Access.

Current configuration:

Conditional Access targeting Global Administrators

All cloud resources included, with Office 365 excluded

Custom authentication strength requiring FIDO2 security keys

Approved YubiKey AAGUIDs configured and verified (values masked)

The same registered YubiKeys work correctly when accessing Azure Portal. However, direct sign-in to the Copilot desktop application fails with AADSTS53003:

"Your sign-in was successful but this passkey does not meet the criteria to access this resource."

The issue affects multiple administrator accounts.

Relevant sign-in log details:

Application: M365ChatClient

Application ID: ********-****-****-****-************

Resource: IrisSelectionFrontDoor

Resource ID: ********-****-****-****-************

Error code: 53003

Conditional Access result: Failure

Workaround discovered:

Interestingly, signing in to Microsoft 365 Copilot through a web browser first allows the desktop application to authenticate successfully afterward, without modifying any Conditional Access settings.

This suggests a possible issue with how the desktop client handles FIDO2 authentication or reuses an existing authenticated session.

Questions:

Is this a known issue with the Copilot desktop authentication flow when custom FIDO2 authentication strengths are enforced?

Why does browser authentication resolve the desktop sign-in failure?

Is IrisSelectionFrontDoor intentionally handled separately from the Office 365 Conditional Access resource grouping?

Is there a supported permanent fix without weakening our phishing-resistant MFA requirements?

The browser-first workaround is functional, but we would prefer a proper solution for direct desktop authentication.

Thanks in advance.Hello,

We are experiencing an authentication issue with the Microsoft 365 Copilot desktop application after enforcing FIDO2 authentication for privileged administrator accounts through Microsoft Entra Conditional Access.

Current configuration:

Conditional Access targeting Global Administrators

All cloud resources included, with Office 365 excluded

Custom authentication strength requiring FIDO2 security keys

Approved YubiKey AAGUIDs configured and verified (values masked)

The same registered YubiKeys work correctly when accessing Azure Portal. However, direct sign-in to the Copilot desktop application fails with AADSTS53003:

"Your sign-in was successful but this passkey does not meet the criteria to access this resource."

The issue affects multiple administrator accounts.

Relevant sign-in log details:

Application: M365ChatClient

Application ID: ********-****-****-****-************

Resource: IrisSelectionFrontDoor

Resource ID: ********-****-****-****-************

Error code: 53003

Conditional Access result: Failure

Workaround discovered:

Interestingly, signing in to Microsoft 365 Copilot through a web browser first allows the desktop application to authenticate successfully afterward, without modifying any Conditional Access settings.

This suggests a possible issue with how the desktop client handles FIDO2 authentication or reuses an existing authenticated session.

Questions:

Is this a known issue with the Copilot desktop authentication flow when custom FIDO2 authentication strengths are enforced?

Why does browser authentication resolve the desktop sign-in failure?

Is IrisSelectionFrontDoor intentionally handled separately from the Office 365 Conditional Access resource grouping?

Is there a supported permanent fix without weakening our phishing-resistant MFA requirements?

The browser-first workaround is functional, but we would prefer a proper solution for direct desktop authentication.

Thanks in advance.
Milan Omidvar

MILAN OMIDVAR 0 Reputation points

2026-10-23T10:52:09.68+00:00

Thank you for your AI response.

We have already reviewed the Conditional Access policies, authentication strengths, and sign-in logs. The registered YubiKeys work correctly with Azure, and their AAGUIDs match our custom authentication strength.

The key issue remains unexplained: direct Copilot desktop authentication fails with AADSTS53003, but signing in through the browser first immediately resolves the desktop issue, without any policy changes.

This suggests a possible difference in how the desktop client handles FIDO2 authentication or existing sessions.

Could you please escalate this to the Microsoft Entra Authentication or Microsoft 365 Copilot engineering team for further investigation? We are looking for a permanent fix rather than a workaround.

Thank you.

1 answer

Your answer

MILAN OMIDVAR 0 Reputation points

2026-10-23T10:52:09.68+00:00

Thank you for your AI response.

We have already reviewed the Conditional Access policies, authentication strengths, and sign-in logs. The registered YubiKeys work correctly with Azure, and their AAGUIDs match our custom authentication strength.

The key issue remains unexplained: direct Copilot desktop authentication fails with AADSTS53003, but signing in through the browser first immediately resolves the desktop issue, without any policy changes.

This suggests a possible difference in how the desktop client handles FIDO2 authentication or existing sessions.

Could you please escalate this to the Microsoft Entra Authentication or Microsoft 365 Copilot engineering team for further investigation? We are looking for a permanent fix rather than a workaround.

Thank you.

Answer 1

Hi Milan, :)

Just to be upfront, Im a community member, not Microsoft staff, so I cant escalate this to engineering. The way to get it in front of them is a support request from the Entra admin center. Include the Request ID and Correlation ID from a failed desktop sign-in and from a successful one after the browser workaround. That comparison is the most useful thing you can give them.

On the error itself, the wording matters. "This passkey does not meet the criteria" points to the AAGUID restriction in your custom strength: Entra accepted a passkey, but not one it considers allowed. So I'd compare the Authentication Details of the failed desktop sign-in with the browser one and check which credential was actually used. If the Windows passkey dialog in the desktop flow offers another option (Windows Hello, a phone, Authenticator) and users pick it, that alone would explain it.

If it really is the same YubiKey both times, my guess is that the desktop app reuses an existing Windows session instead of checking the key fresh, and the browser sign-in gives it a session that already passed the AAGUID check. That would be a product issue, which is another reason to open the case.

And yes, your log shows the policy evaluated IrisSelectionFrontDoor, so that resource isnt covered by your Office 365 exclusion.

https://learn.microsoft.com/entra/identity/authentication/concept-authentication-strength-advanced-options

MILAN OMIDVAR 0 Reputation points

2026-10-28T00:45:21.11+00:00

Hi Grant,

Thank you for your input. Your explanation sounds technically reasonable, but it appears to be a troubleshooting approach rather than an actual fix.

Do you know of a tested solution that permanently resolves the issue? I'm specifically looking for a fix, not another workaround.

Thanks again!