SharePoint: User Has Permission But Gets “Access Denied” — The Admin Diagnosis (2026 Updated Guide)

Quick answer

When a user genuinely has SharePoint permission but is getting “Access Denied”, the cause is almost never the permission. It’s almost always either a Conditional Access policy blocking the sign-in to SharePoint Online (which manifests as “Access Denied” rather than as a clear policy block message), or the SharePoint Admin Centre’s unmanaged-device or network-location restrictions doing exactly what they were configured to do. The diagnosis isn’t in the SharePoint permissions UI; it’s in the Entra ID sign-in logs filtered for SharePoint Online. Stop checking permissions. Start checking policies.

Before you start

You’ll need at least the SharePoint Administrator role for the SharePoint Admin Centre changes, and at least Conditional Access Administrator or Reports Reader for the Entra side. You’ll also need to know where the affected file or site lives, the affected user’s UPN, and ideally a recent timestamp of when they tried (and failed) to access it.

If you’re a SharePoint Site Owner without tenant-level admin access, this guide isn’t fully actionable for you. The site-level permissions you can see don’t include the tenant-level access controls that produce most of these failures. You’ll need to work with whoever has SharePoint Admin or Conditional Access Admin access.

Why this is so confusingly common

SharePoint’s “Access Denied” message is one of the worst error messages in Microsoft 365, because it’s used as a fallback for at least eight different distinct underlying failures. The user sees the same red banner whether the cause is a missing permission, a broken sharing link, a Conditional Access policy block, an unmanaged-device restriction, an IP address restriction, an expired sharing token, a checked-out file they don’t own, or a corrupted folder inheritance.

The standard troubleshooting workflow most IT people learn — check permissions, check sharing settings, check site collection administrators — solves only the first two of those eight causes. For the rest, you’re looking in the wrong place. The diagnosis pattern that actually works is: start with the Entra sign-in logs, not the SharePoint permissions UI.

The five-minute diagnosis

Go to Microsoft Entra admin centre → Identity → Monitoring & health → Sign-in logs. Filter:

  • Username = the affected user
  • Application = SharePoint Online (or Office 365 SharePoint Online)
  • Status = Failure
  • Time range covering when the user tried to access the file

If you see a failed sign-in event for SharePoint Online at the relevant time, the cause is one of the policy or device scenarios in the next sections — and the failed event’s Conditional Access tab will tell you exactly which policy.

If you see a successful sign-in event but the user still saw Access Denied, the failure is downstream of authentication — meaning permissions, sharing tokens, or app-enforced restrictions on the SharePoint side. Check the SharePoint side next.

If you see no sign-in events at all, the user isn’t reaching SharePoint Online. That points at a network problem, the user using a wrong URL, or a token already cached on the device that’s blocking re-auth.

This is the fork in the road. Don’t try to diagnose both branches at once.

Branch A: Conditional Access is blocking, but the message says “Access Denied”

This is the most common cause we see. The user has SharePoint permissions in the normal sense — they’re a member of the right group, the document library has them on the access list, the file isn’t restricted at the item level. But a Conditional Access policy is blocking their authentication to SharePoint Online entirely, and SharePoint is rendering the result as “Access Denied” rather than as a Conditional Access block.

The signature scenarios:

Scenario A1: New device that isn’t compliant or hybrid-joined

User got a new laptop. They can sign in to office.com fine. Outlook works. Teams works. But SharePoint sites give Access Denied. The cause is a Conditional Access policy that requires compliant or hybrid-joined devices for SharePoint Online specifically (or for All Cloud Apps, which catches SharePoint), and the new laptop hasn’t completed Intune enrolment yet.

Fix: Complete the device enrolment, or grant a Temporary Access Pass with appropriate scope, or add a time-limited exclusion to the policy for this user. The structural fix is to ensure new-device provisioning includes Intune enrolment before the user is asked to access tenant data.

Scenario A2: Personal device under “block unmanaged devices”

The user is signing in from a home computer or personal laptop. You have a policy in the SharePoint Admin Centre under Policies → Access control → Unmanaged devices set to Block access. SharePoint is doing exactly what you told it to. The end-user experience is Access Denied with no clear indication that the device state is the cause.

Fix: Decide whether the policy is correct. If it is, the user must use a managed device. If you want to allow web-only access from unmanaged devices but block the desktop sync client, change the policy to Allow limited, web-only access instead of Block access. If the user genuinely needs full access from a personal device, that device needs to be enrolled in Intune.

Scenario A3: Network location restriction

You have a Conditional Access policy that requires sign-in from a trusted Named Location, or you have SharePoint Admin Centre → Policies → Access control → Network location set to allow access only from specific IP ranges. The user is travelling, working from home, on a phone hotspot — anywhere outside the trusted ranges — and is being blocked. SharePoint says Access Denied.

Fix: If the user is legitimately working from outside the allowed locations, either temporarily exclude them from the policy, expand the trusted locations to include their current network, or make a permanent decision about whether your policy is correctly scoped. Network-location restrictions are a strong control but they break travelling users in exactly this way.

Scenario A4: SharePoint authentication context blocking

If your SharePoint site has been configured with an Entra Authentication Context for elevated trust requirements (terms of use acceptance, session controls, additional MFA), and the user hasn’t satisfied that context yet, they’ll be blocked at SharePoint with Access Denied while still being able to access other Microsoft 365 services normally.

Fix: Check SharePoint Admin Centre → Sites → Active sites, find the site, and check whether an Authentication Context is applied. If it is, confirm the corresponding Conditional Access policy is correctly scoped to include the user, and that the user has satisfied whatever the context requires (typically: re-authenticate, accept a terms of use, complete elevated MFA).

Branch B: Authentication succeeded but SharePoint still says Access Denied

If the Entra sign-in log shows the user authenticated to SharePoint Online successfully but they’re still seeing Access Denied on the file or site, the cause is on the SharePoint side. Check in this order:

Check 1: License is assigned and provisioned

The user must have a license that includes SharePoint. Microsoft 365 Apps for business doesn’t. Microsoft 365 Business Basic, Standard, and Premium all do. Office 365 E1, E3, E5 all do. If the user was migrated from a different plan or had their license changed recently, double-check.

Check 2: Their personal site is provisioned

The first time a user accesses any SharePoint resource, their OneDrive personal site must provision. This usually happens automatically on first access. If it failed (rare but possible), they’ll get Access Denied across the board until provisioning completes. Force a refresh by having them visit https://[tenant]-my.sharepoint.com directly. Wait two minutes. Try the original site again.

Check 3: Inheritance is broken on a parent folder

This is the SharePoint-specific trap. When you grant a user permission directly on a single file deep in a folder structure, SharePoint normally grants Limited Access on each parent folder so the user can navigate to it. But if any parent folder has had its permission inheritance broken (someone clicked “Stop inheriting permissions” on it), the chain breaks, and the user can’t reach the file even though they’re explicitly granted on it.

Fix: Navigate to the parent folder and check Settings → Permissions for this list / folder. If inheritance is broken, either re-establish it (caution: this overrides any custom permissions on the folder) or explicitly grant the user Limited Access on the broken folder.

If the file was shared with the user via a sharing link rather than direct permission grant, check the link’s audience setting. If the link was set to “Specific people” and the user’s email isn’t on the list, they’ll get Access Denied even if you remember sending them the link. The link audience is the gate.

Fix: Open Manage Access on the file. Confirm the user is in the audience list for whichever link they’re using. If they’re not, add them or generate a new link with the correct audience.

Check 5: External user account state

If the user is an external (guest) user on your tenant — common for contractors, partners, or merged-org collaboration — check that their guest account isn’t disabled, their invitation hasn’t expired, and they’re not blocked by a separate Conditional Access policy that targets external users specifically.

The Conditional Access vs SharePoint policy overlap problem

A specific category of misconfiguration worth calling out. The SharePoint Admin Centre has its own access controls (under Policies → Access control) for unmanaged devices, network location, and sign-in via legacy clients. Microsoft’s current recommendation is to migrate these to Conditional Access policies, but most tenants have both configured at once, and the two policy stacks can disagree.

If you’ve configured “Block access from unmanaged devices” in the SharePoint Admin Centre AND a Conditional Access policy that allows access from unmanaged devices for SharePoint, the SharePoint-side policy wins because it evaluates after Conditional Access has granted the token. The user authenticates fine but is then denied by SharePoint, which renders as Access Denied.

The architecturally correct answer is to use Conditional Access for these decisions and leave the SharePoint Admin Centre access control settings disabled or unconfigured. Microsoft has been pushing this migration for several release cycles. If your tenant has both layers active, audit both.

What not to do

  • Don’t grant the user Site Collection Administrator as a “test”. It bypasses every legitimate access control, including the Conditional Access policy you’re trying to diagnose. You’ll resolve the symptom and never find the cause.
  • Don’t disable Conditional Access for SharePoint Online “just to check”. This is a security regression that survives a real audit poorly.
  • Don’t tell the user to clear browser cookies. It does almost nothing for the cases above. The state lives in tenant policy, not in browser cookies.
  • Don’t reset their permissions and re-grant. Permission state is fine in 95% of these cases. Re-granting solves nothing.

When to escalate

If the sign-in logs show successful authentication, the user has confirmed permission, the license is assigned, the personal site is provisioned, inheritance is intact, and the sharing link audience is correct — and the user is still hitting Access Denied — open a Microsoft 365 admin support request. SharePoint has back-end metadata that you cannot inspect from the admin UI, and there’s a small but real category of state corruption that requires Microsoft to repair.

  • CAA50021 admin checklist — when device state is the underlying cause
  • Conditional Access blocked sign-in — when CA blocks more visibly
  • SharePoint access denied (when you have permission) — the end-user-facing version

Official references

FAQ

Why does SharePoint say “Access Denied” when the actual cause is Conditional Access?

Microsoft’s design choice. SharePoint receives the access decision as a binary “yes/no” from the authentication layer; it doesn’t know the reason for “no”, and it presents a generic Access Denied. There’s been industry pressure to expose the underlying reason in the user-facing message, but as of 2026 Microsoft hasn’t done so.

Is there a way to confirm a CA policy is the cause without asking the user to fail again?

Yes. The sign-in logs retain a few weeks of history. Filter by the affected user, application = SharePoint Online, status = Failure, and you’ll see prior failed events with the Conditional Access tab populated. You don’t need a fresh failure if a recent one exists.

My user can see the file in the Teams chat preview but gets Access Denied when they click in. Why?

Teams uses a different authentication flow than direct SharePoint navigation. The Teams web client may render a SharePoint preview using a different scope or token than the desktop client uses for the click-through. Check whether the Conditional Access policy has different requirements for the SharePoint Online cloud app versus the Office 365 SharePoint Online cloud app — yes, those can be configured separately, and yes, that’s a confusing trap.

Does the SharePoint sync client (OneDrive for Business) hit the same Access Denied issues?

Often yes. The OneDrive sync client authenticates as a desktop app and is subject to the same Conditional Access policies as a browser. If a CA policy blocks unmanaged devices for SharePoint, the sync client will silently fail to sync — which presents as files-not-syncing rather than Access Denied, but it’s the same root cause.

Can I see all SharePoint Access Denied events across my tenant?

Yes, partially. The Entra sign-in logs show every authentication attempt and result for SharePoint Online. The SharePoint Audit log (in Microsoft Purview Compliance Portal → Audit) records access attempts at the SharePoint level. Cross-referencing the two gives you a comprehensive view, though it requires a search and isn’t a single dashboard.

Will external (guest) users hit different Access Denied causes than internal users?

Yes. Guests are subject to additional controls: external sharing settings at the tenant level, site-level external sharing settings, guest-specific Conditional Access policies, and the B2B collaboration settings in Entra. If only your guests are being denied, audit those layers specifically rather than the internal-user policies.

What’s the right way to test whether Conditional Access is the cause without affecting other users?

Add the affected user to the policy’s exclusion list temporarily, have them retry, and confirm the loop or block stops. Then remove them from the exclusion. This isolates the policy as the variable. Don’t disable the policy globally — that affects everyone.

↑ Back to top