Official documentation checked October 14, 2026.
AADSTS50097 means device authentication is required. It does not establish that your Windows registration is corrupt, and it is not a reason to disconnect a work-managed computer or exclude Copilot from Conditional Access. The sign-in client must provide the device identity required by the resource’s policy.
1. Identify the device requirement and failing sign-in
Capture the exact error, account, time, correlation ID, client, and requested resource. Ask an authorized administrator to review the corresponding Entra sign-in event and its Conditional Access details. Determine whether the device identity is absent, the device is not compliant, or the sign-in flow cannot present the required evidence. These are different problems.
Microsoft’s AADSTS50097 guidance explains that applications may need Windows Web Account Manager (WAM), a suitable system browser, or a mobile authentication broker to satisfy device authentication. This is an identity-flow requirement, not proof that every Copilot user must join a personal device to an organization.
Do not infer the cause from a generic Copilot message alone. Use the sign-in troubleshooting workflow to identify the actual resource and policy before changing anything.
2. Check the browser and device state safely
Use the organization’s supported browser and work profile in a normal window. Private browsing is not a reliable test for device-based Conditional Access: Microsoft documents that device checks can fail in private mode or with cookies disabled. On Windows, Edge needs the appropriate signed-in profile; Chrome supports Microsoft’s Single Sign On extension or the documented CloudAP configuration; Firefox has its own Windows single-sign-on setting. Do not try to install a Chrome extension into Firefox. See the current supported-browser requirements.
On Windows, support can collect the following read-only diagnostic from the affected user’s normal session:
dsregcmd /statusReview the device join state and user state with IT. AzureAdJoined, DomainJoined, and WorkplaceJoined describe different relationships. Where present, DeviceAuthStatus checks whether the device exists and is enabled; an MDM URL alone does not prove enrollment. Microsoft’s dsregcmd reference explains these fields and the importance of user context.
Sanitize device and tenant identifiers before sharing output outside support. Do not run leave/rejoin commands, delete device certificates, clear token-broker folders, or disconnect the account as a general reset. Those operations can disrupt management and access beyond Copilot.
3. Repair the confirmed client or management issue
- Supported device, unsuitable browser/session: correct the managed browser sign-in or supported authentication configuration, then retry.
- Compliance requirement not met: follow the device-management team’s remediation instructions and verify the updated compliance result. Repeatedly clearing cookies cannot make a noncompliant device compliant.
- Missing or disabled device identity: have the administrator verify the intended registration and enrollment state, ownership, and recovery options before an approved repair.
- Mobile client: use the organization’s required broker and enrollment or app-protection workflow. Do not assume a universal “Device registration” switch in Authenticator applies to every platform.
- Custom application: its developer should implement the supported WAM/system-browser/broker flow; users should not weaken tenant policy to compensate.
After the approved correction, reproduce the original action and review the new sign-in event. Success should include the expected device and policy results, not just a disappearing popup. If the error remains, escalate with the client version, device-state findings, policy requirement, and event identifiers. Do not remove the security requirement or promise that registration will finish within an arbitrary two-minute period.