Microsoft Lists sign in problem and how to fix it fast

Most Microsoft Lists sign-in failures are either a local credential/session or browser problem you can fix in minutes, or an account/tenant policy (license, guest account, conditional access) that needs admin action. Start by signing out and back in, trying a private browser window, clearing cached credentials, or using a different device/network. If those don’t work, collect the exact error text, timestamps and correlation IDs and hand them to your IT admin to check Azure AD sign-in logs and conditional access.

What exactly happens when I try to sign in

Record the visible behavior and the full text of any error, and note when it appears (after entering credentials, after MFA, when opening Lists, etc.). Copy the exact symptom below into your support request.

Example: "You don't have access to this site" error after signing in, AADSTS50020

When it appears:

• Sign-in page never loads (blank page or spinner): often a browser/session issue or network block.
• Page loops back to the sign-in prompt repeatedly: usually cached credentials or cookie/session conflict, or duplicate accounts (MSA vs work account).
• Explicit AAD error code (AADSTSxxxx), 401, 403 or “need permission”: usually authentication or authorization — license missing, guest access blocked, or conditional access.
• Error after MFA step: conditional access or MFA policy failing, browser blocking the MFA prompt, or a device compliance check failing.
• Timeouts or "service unavailable": could be network/DNS or a Microsoft service incident.

Why this matters: an AADSTS error code points IT to a specific policy or step in Azure AD. A browser loop suggests local cleanup will fix it. A tenant-wide error reported by colleagues points to a tenant configuration or service outage.

Am I affected or is it my company’s configuration

Product and versions this applies to:

• Microsoft Lists in web (lists.microsoft.com or Lists via SharePoint), the Microsoft Lists desktop app, and mobile apps on iOS and Android.

Privileges needed: none for the initial checks. Administrator access is only required when asking IT to review Azure AD sign-in logs or tenant settings.

Restart or backup: no restart or backup is required for the checks below.

Safe checks to do first:

• Try another device or browser. If Lists signs in on a colleague’s machine but not yours, it’s local.
• Test another Microsoft 365 web app (Outlook web, OneDrive web). If other apps work, the issue may be Lists-specific or a routing problem.
• Ask one or two coworkers if they can sign in right now. If multiple users in your tenant see the same error, it may be tenant-level.

What tenant-wide indications look like:

• Multiple colleagues report the same error text or AADSTS code.
• Your company’s Microsoft 365 Service Health dashboard shows an incident. (An admin can check the Microsoft 365 admin center.)

If it’s just you, proceed with local fixes. If others are affected, gather error texts and timestamps and contact your admin.

Quick safe fixes to try right now

Start with the least disruptive actions; these fix the majority of sign-in problems.

1. Sign out of all Microsoft accounts in your browser or app.

Browser: Click your profile avatar in the top-right and choose Sign out (repeat for each profile).

Expected result: You get a fresh sign-in prompt. If sign-in succeeds, the problem was a stale session.

2. Open a private or incognito window and sign in there.

Chrome: New Incognito Window
Edge: New InPrivate window
Firefox: New Private Window

Expected result: If this works, the issue is browser cache or cookies. If it fails, move to the next steps.

3. Clear browser cookies and site data for Microsoft domains (lists.microsoft.com, login.microsoftonline.com).

Browser settings > Privacy and security > Cookies and other site data > See all cookies and site data > remove entries for microsoft, login.microsoftonline.com, lists.microsoft.com

Expected result: Sign-in works after a clean session. If it still fails, cached credentials outside the browser may be the cause.

4. Remove old cached credentials from Windows Credential Manager (Windows only).

cmdkey /list
cmdkey /delete:TARGET

Expected result: After deleting credentials for Microsoft or your tenant, signing in will prompt fresh credential entry. If deletion fails or you’re not on Windows, skip to network/device checks.

Do not remove credentials you do not recognize; check with IT if unsure.

5. Try a different browser or the Lists desktop/mobile app.

Expected result: If another browser or the app signs in, the issue is browser-specific. If nothing works, try a different device.

6. Switch networks: disconnect VPN, try your home network or a mobile hotspot.

Expected result: If sign-in works on another network, a corporate firewall or proxy is blocking authentication endpoints. Inform IT with the network difference and timestamps.

How long these steps take: each should take 1–10 minutes. Start with the private window and another browser — they’re fastest.

Account and policy checks that commonly block Lists sign-in

If quick fixes didn’t work, the problem often lies in licensing, account type, or tenant policies. These checks typically require an admin or a ticket to IT.

What to check and where an admin looks:

• Licensing: Lists is available in Microsoft 365 plans that include SharePoint/Lists. Ask IT to confirm the user account has the correct license assigned.
• Guest vs. external accounts: Guest users (accounts invited from another tenant) can be blocked by tenant settings or lack the right permissions. If you’re a guest, ask the resource owner to confirm sharing policies.
• Conditional access and MFA: Conditional access policies can block sign-in based on device compliance, location, client app, or risk. Admins should review:
• Azure AD > Sign-ins: filter by the user, time range, and look for failure reasons.
• Azure AD > Conditional Access > Insights and reporting > What If tool to test a user’s sign-in scenario.

Example of a conditional access block entry (paste into a ticket):

Sign-in blocked by Conditional Access. Resource: Microsoft Lists, Policy: Require compliant device, Result: device_not_compliant, Time: 2026-10-30T14:12:07Z, CorrelationId: 12345678-90ab-cdef-1234-567890abcdef

• Azure AD issues: look for AADSTS error codes in the sign-in log. Common examples:
• AADSTS50020 — user account from a different tenant.
• AADSTS700016 — application not found or not configured for this tenant.

What to ask IT to do:

• Check Azure AD sign-in logs for the user, capture the failure reason, device state, conditional access evaluation and correlation ID.
• Confirm license assignment and that Lists/SharePoint services are enabled for the user.
• If guest access is involved, confirm external collaboration settings and the guest user’s status.

If IT finds a conditional access policy blocking you, request an exception or a path to satisfy the policy (registered device, compliant device, MFA method).

How to verify the problem is fixed and troubleshoot persistent cases

Confirm success with a real Lists operation and collect diagnostics if it still fails.

Verify the fix:

• Sign in to Lists and open or create a list. Create a new item and save it.

List item saved successfully (no authorization errors)

• In the web, refreshing the page should not trigger another sign-in prompt.

If it still fails, gather diagnostic details before escalating:

• Use the browser F12 developer tools > Network tab to capture requests to login.microsoftonline.com and lists.microsoft.com. Save a HAR file.

HAR files may contain personal data. Remove unrelated entries if you’ll share it externally.

• Capture the exact error text, AADSTS code, correlation ID, and timestamp (UTC). Example to give IT:

AADSTS50020: User account 'you@contoso.com' from identity provider 'live.com' does not exist in tenant 'Contoso' and cannot access the application 'Lists'. CorrelationId: 1234abcd-... Timestamp: 2026-10-30T14:12:07Z

• Test with a new temporary user (admin can create) or a different tenant to determine whether the issue is tenant-specific.
• Check Microsoft 365 Service Health and Known Issues pages (admin access required) for any ongoing incidents affecting Lists or Azure AD authentication.

When these steps don’t resolve it, include the HAR file, sign-in log entries, and timestamps in your IT ticket or Microsoft Support case.

Prevent this happening again and when to escalate

Practical steps to reduce repeat sign-in failures:

• Keep your browser updated and avoid mixing multiple personal Microsoft accounts with your work account in the same browser profile. Use separate profiles for personal MSAs and work Azure AD accounts.
• If your organization uses conditional access, document any device enrollment or compliance steps you follow. Keep device certificates and OS updates current.
• When admins change conditional access or external collaboration settings, ask them to communicate scope and exceptions clearly.

When to escalate to IT or Microsoft Support:

• Escalate to your IT admin when: multiple users are affected, the error shows a conditional access or license issue, or you need admin access to Azure AD sign-in logs.
• Escalate to Microsoft Support when your admin confirms tenant settings are correct but Microsoft infrastructure or an internal error appears in logs, or when Microsoft 365 Service Health indicates a platform issue.

Checklist of information to include in your escalation (copy into the ticket):

• Exact error message and AADSTS code (if present).
• Full timestamp(s) in UTC and correlation ID(s).
• Steps you tried (private window, cleared cookies, removed cached credentials, different network/device).
• HAR file or F12 network capture (if available).
• Whether other Microsoft 365 apps sign in successfully and whether colleagues are affected.

Give that information to IT or Microsoft Support so they can find the sign-in attempt in Azure AD logs quickly and resolve the root cause.

Conclusion

If a private browser window or clearing cached credentials fixes it, you should be back in Lists within minutes. If the error includes an `AADSTS` code or several people are affected, collect the exact error text, correlation IDs and timestamps and hand them to your IT admin so they can check Azure AD sign-in logs and conditional access. If tenant settings look correct but the issue persists, open a Microsoft Support case with the diagnostics you collected.

Frequently Asked Questions

Can I fix a conditional access block myself?

No. Conditional access policies are enforced at the tenant level and require admin changes or an exception. You can satisfy the policy if it allows that (for example, register your device or complete required MFA). Provide the error details to your admin if you think the policy is blocking you incorrectly.

Is the Lists desktop app different from the web for sign-in?

The desktop app still authenticates against Azure AD and can be affected by the same policies, but it may use the system credential store rather than browser cookies. Trying the desktop or mobile app helps determine whether the issue is browser-specific.