Microsoft 365 Sign-In Troubleshooting: From “Access Denied” to Root Cause

“Microsoft 365 is broken” is a starting point, but it gives the next engineer very little to work with.

I would capture:

• The affected account and intended application.
• The exact error, including any request or correlation ID.
• The time of the attempt and its time zone.
• The device and whether the failure happens in a browser, desktop app or both.
• The impact: one user, one device, a department or a wider group.
• What changed before the first failure.

Ask what the user was trying to accomplish. A blocked payroll task needs different coordination from a nonurgent access request, even if both show the same error.

A controlled comparison is useful: repeat the same action on another approved device, or compare browser and desktop behavior. Treat the difference as evidence for the next question, rather than proof of the cause.

In the Microsoft Entra admin center, open Entra ID → Monitoring & health → Sign-in logs. Filter by the account, a narrow time window and the relevant application or resource. Match the event against the details the user captured.

Review the failure reason and the Conditional Access tab. Microsoft documents AADSTS53000 as DeviceNotCompliant and AADSTS53003 as BlockedByConditionalAccess. These codes point the investigation in a direction; the event details tell you which control needs attention.

For escalation, preserve the event time and identifiers. See Microsoft’s Conditional Access troubleshooting guide.

A user completing MFA does not settle every question about the request.

The Authentication details tab helps explain the authentication sequence. Device information and individual Conditional Access policy results provide additional context. Read these together rather than drawing a conclusion from a single status field.

Check both interactive and non-interactive sign-in events when the symptoms involve background application activity. Keep the time zone in mind: the portal localizes event times for the administrator viewing them.

Microsoft explains these fields in its sign-in activity details reference.

The question I want to answer is precise: which requirement prevented this request from succeeding?

If the evidence points to compliance, inspect the matching device in Intune.

Review its overall compliance status and the policy or setting responsible for a failure. A device may satisfy one policy while failing another. Check its recent contact with the service and whether the reported device identity matches the sign-in under investigation.

“Noncompliant” describes an outcome. I still need the failed requirement and a realistic remediation plan.

Use Microsoft’s compliance monitoring guidance to interpret the reports.

From a support perspective, the next step should be clear to the user: what needs fixing, who owns it and when we will verify access again.

Imagine an employee who can access Teams from an approved device but receives an access error on their work laptop.

The key is preserving the chain of evidence. A password reset would not address an unmet device requirement.

I would first remediate the condition that the policy is designed to check. Any exception should have an accountable owner, a defined scope and a review point.

My proposed closure standard is simple: the original task works again, the evidence supports the explanation, and the next engineer can understand the resolution.

When Entra sign-in logs are already routed to an Azure Log Analytics workspace, a focused query can help compare attempts. Access permissions, licensing, diagnostic routing, retention and Azure costs need to be checked in the environment. The portal investigation does not require this optional extension.

Microsoft describes the setup in Analyze activity logs using Log Analytics.

The following is a starter query for interactive user sign-in records in the SigninLogs table. Replace the example account. It has been checked against the documented schema, but has not been executed against a tenant for this article.

SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "user@example.com"
| project TimeGenerated, CreatedDateTime, AppDisplayName,
          ResourceDisplayName, ResultType, ResultDescription,
          ConditionalAccessStatus, CorrelationId, DeviceDetail
| order by CreatedDateTime desc

Use the query to find candidate events and compare success and failure. It does not establish root cause by itself.

The SigninLogs schema reference documents the selected fields. Non-interactive records may require querying their separate table, depending on the configured export.

The Conditional Access What If tool can help explore which policies apply to a defined sign-in scenario.

It is a simulation. It does not perform a real sign-in and does not evaluate Conditional Access service dependencies. Compare its results with the actual incident evidence.

See Microsoft’s What If documentation.

When a policy change is needed, define the expected outcome, a pilot scope and a recovery plan. Verification should include the user’s original workflow.

My preferred knowledge entry would capture:

• Symptom and business impact.
• Relevant event identifiers and device evidence.
• Confirmed cause, with remaining uncertainty stated.
• Remediation and validation.
• A next-investigation step if the issue returns.

For a public example, remove tenant details, account identifiers and other sensitive information.

This is how troubleshooting adds value beyond a closed ticket. The next engineer starts with a better question, the user receives a clearer explanation, and recurring incidents become easier to recognize.

In an isolated test environment with appropriate access, investigate one test account and one test device.

Find a sign-in event, explain the authentication sequence, inspect applicable policy results, and compare the device information with Intune. If Log Analytics is configured, adapt the query and explain each column.

Write a short knowledge entry with evidence and uncertainty. Only record an exercise as completed after you have actually performed it.

Being able to explain why access was denied is a valuable step from support toward administration.

• Microsoft Entra ID Conditional Access: 10 Policies I Would Review First
• The Modern IT Support Engineer: Skills Beyond Technical Fixes

For businesses looking for structured troubleshooting and Microsoft 365 support, see my IT support services in Copenhagen.