AADSTS165000: User session context is missing (fix)

What does AADSTS165000 mean?

Microsoft’s error code reference doesn’t list AADSTS165000 (checked 30 October 2026).

We found no Microsoft documentation page for it. The wording comes from user reports on Microsoft Q&A. The common part of the message is:

AADSTS165000: Invalid Request: … One or more of the user context values (cookies; form fields; headers) were not supplied, every request must include these values and maintain them across a complete single user flow.

The first part and the ending vary. Three threads show three versions:

Thread	Text after “Invalid Request:” and at the end
iPads, school tenant	“The user session context is missing.”
Mac, Microsoft 365 Home	“The user session context is missing.” … “Failure Reasons:[Missing session context cookie;]”
Edge, Azure Site Recovery appliance	“The request did not include the required tokens for the user context.” … “The request did not return all of the form fields. Failure Reasons:[Token was not provided;]”

Our reading of the message: the Microsoft sign-in page tracks one sign-in across several requests with cookies and hidden form fields. When a request in the middle arrives without them, the page can’t tie it to the sign-in that started it, and it stops with 165000. The Failure Reasons part says which piece was missing. Microsoft hasn’t documented this.

What users report as the cause:

• Wrong device clock. In the iPad thread, a community member writes that the iPads that failed had the wrong date and time: “Fixed time zone and set time to automatic, problem solved.” A second user reports the same fix on an iPad.
• iPad browsers. The iPad thread saw it in Safari-based and Chrome browsers, after cache clears and even a full wipe.
• One browser only. In the Edge thread it happened only in Edge, not in Chrome with the same user, and started after the May 2024 Windows Server updates.

Is it an attack?

No, as far as any report we found shows. Every case users describe is a browser or device problem.

Pattern	Likely meaning
One or two users, always on the same iPad	The device clock or cookie settings. Check the date and time first.
Many users on managed iPads at the same site	A content filter or proxy that changes the sign-in traffic, or a device profile that blocks cookies. The iPad thread used a filtering browser. Our interpretation.
One browser on one server fails, another works	A browser issue, as in the Edge thread. Use the other browser or the device code workaround below.
A spike for every user at once	Not seen in any report we found. Check for a network change; this is a guess, not a reported cause.

We found no source that links 165000 to an attack.

How do I find it in my logs (KQL)?

Microsoft doesn’t document whether or where 165000 is logged. The admin in the iPad thread writes that the sign-in logs showed error code “399218”. Our reading: the sign-in log may record these failures under a different code than the one on the user’s screen. Search for both:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType in ("165000", "399218")
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable, ResultType, ResultDescription

If rows show up, see which devices and browsers they come from. Concentration on one operating system points at the device, not the tenant:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType in ("165000", "399218")
| extend OS = tostring(DeviceDetail.operatingSystem), Browser = tostring(DeviceDetail.browser)
| summarize Attempts = count(), Users = dcount(UserPrincipalName), LastSeen = max(TimeGenerated)
          by OS, Browser, AppDisplayName
| sort by Attempts desc

If neither query returns anything, look up the user’s failed sign-ins at the time of the error and read ResultType and ResultDescription from there.

How do I fix AADSTS165000?

For the user:

1. Set the device’s date and time to automatic, with the right time zone. Two users report this fixed it on iPads.
2. Allow cookies in the browser and don’t use private browsing for the sign-in. On Safari, a Q&A answer suggests turning off Prevent Cross-Site Tracking and Block All Cookies.
3. Try another browser. In the Edge thread, Chrome worked with the same account.
4. On a Mac with Microsoft 365 Home, an Independent Advisor on Q&A suggests that a work or school account used on the device before can get in the way, and points to Microsoft’s license removal tool for Office on Mac. This one is a single suggestion, not a confirmed fix.

For admins:

1. Ask which device and browser, and check the clock first. It is the only fix that more than one user reports as working.
2. If a content filter sits in front of the devices, a Q&A answer suggests excluding Microsoft sign-in addresses from it, such as login.microsoftonline.com, login.live.com and *.office.com. Users have not confirmed that this fixed it.
3. The same answer suggests checking Conditional Access sign-in frequency and persistent browser session settings for the affected users. Nobody in the thread reports this as the cause.

For apps that open a browser sign-in (appliances, tools): the accepted answer in the Edge thread is a workaround: when the error shows, refresh the sign-in tab, or open https://microsoft.com/devicelogin in a new tab and enter the device code the app showed. The moderator who posted it said no root cause had been shared yet.