SharePoint Access Denied When You Have Permission: The Four Real Causes (2026 Updated Guide)

Quick answer

If SharePoint says “Access denied” or “You need permission” for a site or file you’ve been granted permission to, you’re almost certainly hitting one of four specific causes: a Limited Access lockdown setting that breaks shared-folder access, a broken permission inheritance on the parent site or library, a user ID mismatch from a deleted-and-recreated account, or a Conditional Access or organizational policy blocking access from your current device or network. The first three are admin fixes. The fourth is sometimes user-fixable. None of them are solved by the SharePoint owner re-granting you permission, which is what most people try first and what almost never works.

Before you start

This is one of the rare error messages where retrying the same thing more aggressively makes the problem worse. SharePoint’s permission system caches user IDs, group memberships, and access tokens at multiple layers. If you keep hammering the page, asking the site owner to re-add you, or signing in and out repeatedly, you can compound a user-ID-mismatch problem to the point where it requires a SharePoint admin (not a site owner) to resolve.

Confirm the basics before diagnosing the four causes. You’re signed in with the correct account — particularly relevant if you have both a personal Microsoft account and a work/school account. The link you’re using is the link the owner actually shared, not a stale one or one for a different file. The site is healthy in general — try a known-working SharePoint site to rule out a broader sign-in problem. If any of those is the issue, the four causes below are not your problem.

If you’re the IT admin investigating this on behalf of a user, skip directly to the SharePoint admin-side access denied diagnosis guide — that has the back-end queries and PowerShell commands. This article is written for the user (or the admin who needs to explain to a user why this happens).

What this means

SharePoint’s permission system has more layers than people realize. When you click a SharePoint link, the platform checks: are you authenticated, do you have a user record on this site collection, do you have an explicit permission or are you in a group that has permission, has the inheritance from the parent given you the permission you need, is there an organizational policy that overrides the explicit grant, and does the underlying file’s permission set match the site’s. Any one of those checks can fail and produce the same “Access denied” message, but the underlying causes are completely different.

The frustrating part is that SharePoint doesn’t tell you which check failed. It shows the same “You need permission to access this item” message regardless. Diagnosing means working through the four common failure modes in order from most-likely-to-least-likely.

The dominant cause when a user has been freshly granted access and immediately can’t use it is the Limited Access lockdown setting interacting with a shared-folder structure. The dominant cause when a user could previously access the site but suddenly can’t is a user ID mismatch caused by an account being deleted and recreated, or a Conditional Access policy change. Knowing which scenario applies cuts the diagnosis time roughly in half.

Where this appears

You’ll see the message in any of several forms:

  • “You need permission to access this site/item.”
  • “Access denied. You don’t have permission to access this resource.”
  • “This link is not available to you. Sorry, you are currently signed in as [account] but that account is not on the list of people this is secured to.”
  • “Due to organizational policies, you can’t access this resource from this network location.”

The third variant — explicitly mentioning the account you’re signed in as — is the easiest to diagnose: it’s almost always either a user ID mismatch or a wrong-account problem. The fourth variant explicitly identifies organizational policy as the cause and routes you straight to the Conditional Access investigation.

Affected surfaces include any SharePoint Online site (modern or classic), OneDrive for Business shared content, Teams files (because Teams files live in SharePoint), and shared links from any of these. The same error patterns apply across all of them.

Common causes

The four real causes, in order of how often each is the actual problem:

Cause 1 — Limited Access lockdown breaks shared-folder permissions. SharePoint has a feature called “Limited-access user permission lockdown mode” that’s designed to make publishing sites more secure. When it’s enabled and someone shares a specific subfolder with a user who doesn’t have access to the parent site, the share appears to succeed but the user gets access denied when trying to open the folder. This is documented Microsoft behavior. It’s surprisingly common in tenants that use SharePoint heavily for both publishing and collaboration.

Cause 2 — Broken permission inheritance on the parent. When permissions are managed at the document library or list level rather than the site level, and inheritance has been broken at some point in the hierarchy, users can be granted access to a specific item but not have the chain of permissions needed to navigate to it. The user has permission on paper, but the path to the resource is blocked at an intermediate level.

Cause 3 — User ID mismatch from deleted-and-recreated account. Every SharePoint user has an internal user ID that’s separate from their UPN (the email-formatted username). When an account is deleted in the Microsoft 365 admin center and then a new account is created with the same UPN, the new account gets a new internal user ID. SharePoint permissions often reference the old user ID, so the new account hits access denied even though the UPN is correct. This is one of the most common causes for users returning from a long absence, name changes, or company restructures.

Cause 4 — Conditional Access or organizational policy blocking access. Modern Microsoft 365 tenants have Conditional Access policies that can block SharePoint access based on device compliance, network location, sign-in risk, or device management state. If you’re on a personal device, on a network outside the corporate VPN, or on a device that’s not compliant with Intune policies, you can hit access denied even with full permissions. The “Due to organizational policies” message is the explicit version; sometimes the same underlying block produces a generic access denied message instead.

Fixes to try first

Most of these require admin help. Don’t waste an hour on user-side fixes that can’t address admin-side causes.

  1. Verify you’re signed in as the right account. Open the link in an InPrivate or Incognito window and sign in fresh. If your work and personal Microsoft accounts are confused, this isolates the problem.

  2. Try the link from a different device or network. This single test rules out or in Cause 4. If the link works from your phone on cellular but not from your laptop on corporate Wi-Fi, the issue is a Conditional Access policy tied to either your device state or your current network location.

  3. Open the link directly in a browser rather than through Teams or Outlook. App-side single sign-on can occasionally fail and produce false access-denied results. Going to the site directly via yourtenant.sharepoint.com and navigating to the file rules out an app-layer auth issue.

  4. Ask the site owner to use the “Check Permissions” feature. Site Settings → Site permissions → Check Permissions, then enter your username. This shows what permission level SharePoint thinks you have. If it shows “No permissions” — even after the owner has just granted you access — you’re almost certainly in Cause 3 (user ID mismatch). If it shows “Limited access only,” you’re likely in Cause 1.

  5. Have the site owner remove and re-add you, then wait 15 minutes. This clears stale group membership caches. It does not fix Cause 1, 3, or 4 — but it does fix some intermittent permission-cache-staleness issues that produce the same symptom.

If steps 1-5 haven’t fixed it, the cause is admin-side. Stop trying user-side fixes and escalate.

Advanced fixes

These are admin-side. If you don’t have admin access, hand this list to your admin along with the diagnostic results from the steps above.

For Cause 1 (Limited Access lockdown): SharePoint admin center → site settings → check whether Limited-access user permission lockdown mode is enabled at the site collection level. If it is, the affected user needs to be granted access to the parent site (typically Read on the root web), not just the subfolder. Either disable the lockdown mode (if the security model permits) or extend the user’s permissions up the hierarchy.

For Cause 2 (broken inheritance): Identify where in the site hierarchy inheritance was broken. Site → Settings → Site permissions → Advanced permissions settings shows the inheritance state. Then walk down the hierarchy until you find the level where the user’s permission stops applying. The fix is usually to either restore inheritance at the broken level or grant explicit permission at every broken level the user needs to traverse.

For Cause 3 (user ID mismatch): This is an admin-only fix. Use the SharePoint Online Management Shell to remove the user from the site collection (Remove-SPOUser), then have them sign in to the site again — this creates a fresh user record with the current internal ID. Alternatively, the Set-SPOUser cmdlet can be used to update the user record. PowerShell is the only reliable way to fix this; the admin center UI doesn’t expose the right controls.

For Cause 4 (Conditional Access / organizational policy): Check the Microsoft Entra sign-in logs for the affected user during the failed access attempt. The sign-in entry will list which Conditional Access policy was applied and whether it was satisfied or not. Common culprits: policies requiring compliant devices (user is on a non-managed device), policies requiring trusted networks (user is off-VPN), policies requiring MFA in specific conditions. The admin can adjust policy scope, exclude the user, or require the user to bring their device into compliance — which is the right answer depends on the security posture.

Use the User Access Diagnostic in Microsoft 365 admin center. Microsoft provides a diagnostic specifically for SharePoint access issues that runs against a tenant and identifies several of these causes automatically. Health → User access in the admin center. Run it for the affected user and the affected URL.

If you are on a work or school device

If you are not the admin: take the time to capture a useful diagnostic before you ask for help. The exact URL you’re trying to access, the exact account you’re signed in with, the exact text of the error message, and the result of trying the link from a different device or network. Send all four along with the request. It saves an admin hours.

If you are the admin: the most efficient diagnostic is “did this user ever have access?” If yes and they don’t now, you’re looking at Cause 3 (user ID mismatch from an account change) or Cause 4 (a recent Conditional Access policy change). If no — the user was just granted access and immediately can’t use it — you’re looking at Cause 1 or Cause 2. The full diagnostic flow with PowerShell commands is in the SharePoint admin-side access denied guide.

For users who are external (B2B guest accounts), Cause 3 is the dominant problem. External users have a particularly fragile user-ID-to-UPN binding because their identity is provisioned in your tenant from their home tenant, and any change on either side can break the link.

When to stop

Stop and escalate to your admin if you’ve confirmed via “Check Permissions” that SharePoint thinks you have no permissions even though you’ve been told you do. That’s a permission-record problem and you cannot fix it from the user side. Stop and escalate if you keep getting the “Due to organizational policies” message — only an admin can change Conditional Access. Stop and escalate if the link worked yesterday and doesn’t work today, especially if your account was recently changed (new email address, name change, recreated account).

Stop and use a workaround if access is urgent and admin response will take time. The site owner can email the file directly, you can request a copy via OneDrive share rather than SharePoint link, or for some content the same file may be accessible via a Teams channel that has different permission inheritance. Workarounds shouldn’t substitute for fixing the root cause, but they shouldn’t keep you blocked all afternoon either.

Stop entirely if you’re considering “creative” fixes — clearing browser caches in unusual ways, registry edits, group policy changes on your local machine. SharePoint permission errors are server-side. Nothing you change on your local machine can override what the server tenant policy says. Time spent on local fixes is time not spent escalating.

  • SharePoint admin-side access denied diagnosis — the admin-side companion guide for the four causes above.
  • Shared mailbox not showing in Outlook — related Microsoft 365 permission-and-license symptom that admins often see alongside SharePoint access issues.
  • “Limited Access” SharePoint behavior — Microsoft documentation reference covering the exact mechanism behind Cause 1.

Official references

FAQ

The owner says they gave me permission but I still can’t access it. What do I tell them? Ask them to use the “Check Permissions” feature in site settings to verify what SharePoint thinks your access is. If it says you have no permissions, the grant didn’t apply — likely Cause 3 (user ID mismatch). If it says “Limited Access only,” it’s Cause 1. Tell them which it is.

Why does the same SharePoint link work for one colleague and not another? Different users hit different causes. Your colleague might be in a security group with site-level permission. You might have file-level permission only and be hitting Limited Access or inheritance. Same link, different per-user state.

I’m an external guest. Why is this so much harder for me? Guest accounts are more fragile because the user-ID-to-UPN binding spans two tenants. Either side changing anything can break the link. The fix is usually for the host admin to remove and re-invite you, which forces a fresh binding.

How long should I wait after being granted permission before trying again? For a normal site permission grant, access is usually live within a minute. Wait fifteen minutes for caches, then try once more. If it still doesn’t work, the grant didn’t apply correctly — diagnose, don’t keep retrying.

Can clearing my browser cache fix this? Almost never. The cause is server-side. The exception is when you’ve recently switched accounts and the browser is sending stale tokens — opening the link in InPrivate / Incognito is faster than clearing cache.

Why does the URL work in one app but not another? Different apps use different sign-in flows. If one works and another doesn’t, the issue is in the failing app’s auth handling, not in SharePoint permissions. Try the link directly in the browser to bypass the app-side problem.

↑ Back to top