Skip to content

How pages are verified

Every page shows one of two states under its title:

  • Checked against Microsoft documentation; lab test pending. The page quotes and links Microsoft’s documentation, and has been reviewed for accuracy and consistency, but I haven’t reproduced it in my lab yet. Treat queries and thresholds as starting points and test them in your own workspace.
  • Lab-verified (date). I have triggered the error in my own test tenant, captured the sign-in log row and run every query on the page against it.

Pages move from the first state to the second as I work through them. The changelog shows what changed and when.

The description is quoted word for word from Microsoft’s error code reference and linked. It is never paraphrased into something it doesn’t say.

Statements about attacks are backed by Microsoft’s security documentation (smart lockout, the password spray playbook, ID Protection, illicit consent grants) or by a lab reproduction. Where a statement is my own reasoning rather than documented behaviour, the page says so.

I trigger the error in my own test tenant, capture the sign-in log row, and run every KQL query on the page against it. No production or employer data is used.

Queries run against the real SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs or AuditLogs schema in Log Analytics. Thresholds in queries are starting points and are labelled as such.

A monthly check compares each quoted description with Microsoft’s live error lookup and the Entra release notes. Changed pages are re-verified and their date is updated.

I use AI tools to help draft pages and to track changes in Microsoft’s documentation. Nothing is marked as verified until I have checked it against the sources and reproduced it in the lab. If you find an error, it’s mine. Please tell me.