New Microsoft 365 User Can't Sign In: Admin Checklist (2026 Updated Guide)

Quick answer

A new Microsoft 365 user who can’t sign in is almost always blocked by one of four things, and they’re not the things the error message points at. In order of likelihood: the license is assigned but the back-end provisioning hasn’t finished propagating; the user’s first MFA registration is being blocked by a Conditional Access policy that wasn’t designed with new users in mind; the UPN they’re typing doesn’t match what was created; or the account is being created without a usage location and silently can’t activate any service. Work the checklist below in order. Don’t reset the password first. That’s the wrong move and you’ll spend an hour finding out why.

Before you start

You need at least the License Administrator or User Administrator role in the Microsoft 365 admin centre. If you only have Global Reader, you can diagnose but not fix. Don’t sign in as the new user on your own machine to “test” — you’ll cache their credentials in Windows Credential Manager and create a different problem to clean up later. Use a private browser window. Have the user available on the phone or in chat. Most of these checks need a sign-in attempt from their actual device to confirm what’s happening, and you can’t fake that from the admin side.

This guide assumes a Microsoft 365 Business or Enterprise tenant with cloud identity. If you’re running a hybrid setup with Entra Connect Sync from on-prem AD, the symptoms are similar but the fix order is different — most of your problems will be sync-related, and you should check the Entra Connect sync state and last sync time first. We flag the hybrid-specific divergences inline below.

What this means

When Microsoft 365 says a new user can’t sign in, the actual error message is usually one of three: “Something went wrong”, “We couldn’t find an account with that username”, or “Your account or password is incorrect”. None of these tell you what’s wrong. Microsoft uses the same generic strings for at least a dozen distinct failure modes, and the real diagnosis lives in two places: the Active users page in the admin centre (for provisioning state) and the Entra ID sign-in logs (for what actually happened on the attempted sign-in).

The honest framing is this: a user account in Microsoft 365 isn’t a single thing. It’s a collection of states — identity created, license assigned, services provisioned, MFA registered, Conditional Access evaluated, mailbox provisioned, OneDrive provisioned — and any one of them being incomplete will produce a sign-in failure that looks identical to all the others. The checklist below works through them in the order most likely to be the cause.

Where this happens

This article covers the admin-side diagnosis for new users failing first sign-in across:

Microsoft 365 web sign-in at office.com or microsoft365.com
Outlook desktop or new Outlook first launch and account add
Teams desktop first sign-in
OneDrive sync client first sign-in
Office app activation (Word, Excel, PowerPoint) on a new install

The checks below diagnose all of them. The endpoint differs but the back-end state is the same.

The decision tree: what to check, in order

This is the sequence that actually works. Skipping ahead because something “looks like” the obvious cause is how IT people lose two hours on a problem they could have fixed in ten minutes.

Step 1 — Confirm the user actually exists, and the UPN matches what they’re typing

In the Microsoft 365 admin centre, go to Users → Active users and search for the new user. Open their record. Look at the Username field — that’s their User Principal Name (UPN). It will be something like jakob@contoso.com.

The single most common cause of “new user can’t sign in” is that the user is typing a different string. They might be typing their email alias (which can differ from the UPN), the company display name with a typo, or — if you have multiple verified domains — the wrong domain. Have the user copy-paste the exact UPN from your message. If sign-in works, you’re done. If it doesn’t, continue.

If the user doesn’t appear in Active users at all, but you remember creating them, check the Deleted users page. Deletion is instant in the UI and recovery is straightforward within 30 days, but a deleted user definitely cannot sign in.

On the user’s record, check three fields in this order:

Sign-in status. Should be Sign-in allowed. If it shows “Sign-in blocked”, that’s your answer — toggle it back. Sign-in blocking sometimes happens accidentally during bulk user creation if you check a tickbox without reading the label.
Licenses and apps. The user must have a license assigned that includes the apps they’re trying to use. Microsoft 365 Business Basic doesn’t include desktop Office; if they’re trying to activate desktop Word, that’s the problem. Microsoft 365 Apps for business includes desktop apps but not Exchange Online — they won’t have email.
Usage location. This is the field that quietly breaks more new-user sign-ins than any other. If usage location is blank, services that depend on regional licensing (Teams, Exchange, OneDrive in some configurations) cannot fully provision, even with a license attached. Set it to the user’s actual country and save.

If you assigned the license via group-based licensing rather than directly, group-based assignment can take longer to propagate — sometimes hours for large groups, though usually under 30 minutes. Check the Errors & issues tab on the Licenses page in the admin centre. If there’s a license assignment error (insufficient licenses, conflicting service plans, missing dependencies), it’ll be listed there with an explanation. Resolve it, then Reprocess the assignment.

Step 3 — If it’s been less than an hour since you assigned the license, wait

This is the advice nobody wants to hear, but it’s correct. Provisioning is not instant. After a license is assigned, Exchange Online needs to provision the mailbox (typically 5–15 minutes, sometimes longer), OneDrive needs to provision the personal site (variable), and Teams needs to provision the user identity. Telling a brand-new user “your account is ready, sign in now” within five minutes of license assignment is a common cause of “I tried and it didn’t work” reports that resolve themselves by lunchtime.

If you’re under time pressure, you can confirm provisioning state from PowerShell (Exchange Online module: Get-Mailbox -Identity user@domain.com should return a mailbox; if it returns “user not found”, the mailbox isn’t provisioned yet). For most cases, just wait 30 minutes after license assignment before declaring an actual problem.

This is the step that turns guessing into diagnosis. After the user has actually tried to sign in (and failed), go to the Microsoft Entra admin centre → Identity → Monitoring → Sign-in logs. Filter by Username = the new user’s UPN, and Status = Failure. Find their attempt.

Open the failed sign-in event. Three tabs matter:

Basic info — gives you the AADSTS error code. Search for it in Microsoft’s authentication and authorization error codes documentation. The error code tells you what actually failed; the user-facing error message does not.
Conditional Access — shows which policies were evaluated and which one (if any) blocked access. This is where you find out that your “Require MFA for all users” policy is preventing the user from registering MFA in the first place — the classic chicken-and-egg new-user problem.
Authentication Details — shows what authentication method was attempted, what factors were prompted for, and what failed.

If you don’t see a failed sign-in event at all, the user isn’t actually reaching Microsoft’s authentication endpoint. That points at the user’s network or the client app, not your tenant configuration. Have them try sign-in via a browser at office.com. If that succeeds, the problem is the desktop client. If it fails the same way, you have a real authentication issue.

Step 5 — The MFA registration trap

By far the most common Conditional Access misconfiguration that breaks new users is this: a policy that requires MFA for all users at all times, with no carve-out for the Microsoft Entra ID security info registration flow. The new user tries to sign in. Your policy says “you must do MFA”. They don’t have MFA registered yet. They can’t register MFA without first authenticating. They can’t authenticate without MFA. They’re stuck.

The fix is a Conditional Access policy that excludes the security info registration user action for users who haven’t yet registered MFA, gated by a trusted network location or a temporary access pass. Microsoft’s own documentation describes this pattern under “secure security info registration”, and if you didn’t set it up when you originally configured Conditional Access, you’ll hit it the first time you onboard a new user. Issue the user a Temporary Access Pass from the admin centre, have them use it to register their authenticator app, and then they’re through the wall.

For a deeper diagnosis of MFA-related sign-in loops once a user does have MFA registered, see MFA prompt loop: admin-side causes.

Step 6 — The CAA50021 device-registration variant

If the sign-in error includes the code CAA50021 specifically, the failure is downstream of the user’s identity entirely. CAA50021 is a device-registration error: the user’s device isn’t joined or compliant in the way your Conditional Access policy demands, and the device is being rejected before the user’s credentials even matter. This is common when a new user is given a brand-new laptop that hasn’t been enrolled in Intune yet, or a personal device on a tenant where Conditional Access requires hybrid join.

The full diagnosis lives in the CAA50021 admin checklist, but the short version is: check the device’s join state with dsregcmd /status from an admin command prompt on the user’s machine, confirm AzureADPrt is YES, and confirm the device shows up as Compliant in your Intune (or equivalent MDM) compliance dashboard.

If the user can sign in to office.com in a browser but Outlook desktop, Word desktop, or Teams desktop won’t activate or won’t sign in, that’s a different problem from the one this checklist diagnoses. The user’s identity is fine; the desktop client is failing to acquire its activation token. The most common cause is a license that was assigned, then unassigned, then reassigned — leaving stale tokens cached. See Microsoft 365 license assigned but won’t activate for the activation-side fixes.

Common causes (ranked by what we actually see)

This is the empirical ranking from the diagnostic logs of small-business tenants. Your mileage will vary, but the order is more useful than a flat list.

The user is typing the wrong UPN. ~25% of “can’t sign in” reports.
License assigned <30 minutes ago, provisioning not complete. ~20%.
Usage location not set. ~15%.
MFA registration blocked by Conditional Access policy. ~15%.
Sign-in blocked toggle accidentally on. ~10%.
CAA50021 / device compliance failing. ~5%.
Group-based licensing assignment error (insufficient seats, conflicting plans). ~5%.
Everything else, including UPN sync issues from on-prem AD, federated identity issues, and obscure Conditional Access policy interactions. ~5%.

Working the checklist in order resolves the first six categories without further investigation, which covers around 90% of cases.

Advanced fixes

These apply if the basic checklist is exhausted and you still have a user who can’t sign in.

Force a license re-evaluation. Remove the license entirely. Wait five minutes. Reassign it. This forces a full provisioning cycle and resolves cases where the back-end state is corrupt without any visible error.

Check the Microsoft Entra sign-in diagnostic tool. From a failed sign-in event in the sign-in logs, click Basic info → Troubleshoot Event. Microsoft’s diagnostic tool will run the same evaluation Microsoft Support would run and surface things like “this policy applied because…” that aren’t visible in the standard logs.

For hybrid identity tenants only: check Entra Connect sync state. If your new user was created in on-prem AD and synced up, but the sync hasn’t run since creation, the user exists in AD but not in Entra ID, and signing in is impossible. Run a delta sync from the Entra Connect server (Start-ADSyncSyncCycle -PolicyType Delta) and confirm the user appears in Entra after sync completes.

Check for guest user collisions. If the user’s email address was previously invited to your tenant as a guest from another organisation, the existing guest record can collide with a new member account. Delete the guest record first.

When to stop

If you’ve worked the full checklist, the sign-in logs show no failed events at all (or events that don’t match any of the patterns above), and the user genuinely cannot sign in from any device or browser, you’re past the point where editorial guidance helps. Open a Microsoft 365 admin support request from the admin centre’s Support → New service request flow. Include the user’s UPN, sign-in date/time in UTC, and the AADSTS error code from any failed events you found. Microsoft’s tier-1 support will run the same diagnostic tool you’ve already run, but tier-2 has access to back-end provisioning logs you don’t.

Don’t, under any circumstances, delete and recreate the user as a first-resort solution. Deleting and recreating wipes their mailbox (which is not recoverable after 30 days), their OneDrive contents, their Teams chat history, and their assigned licenses. It will resolve the sign-in problem because it resolves every problem by erasing the user, but it’s not a fix — it’s a flame.

If your user is on a personal device or BYOD scenario

If the user is signing in from a device they own (rather than a company-managed laptop), and your Conditional Access policy requires either a compliant device or hybrid join, the user will fail every check on this list and the actual fix is one of: (a) enroll the device in Intune, (b) issue them a managed device, or (c) carve out an exception in your Conditional Access policy for this user or scenario. Option (c) is operationally easiest and security-policy-worst; choose accordingly.

CAA50021 admin checklist — when the failure is device-registration rather than identity
Microsoft 365 license assigned but won’t activate — when sign-in works but app activation fails
MFA prompt loop: admin-side causes — when sign-in succeeds initially but loops back to MFA prompts
Microsoft 365 “something went wrong” sign-in — the end-user-facing version of this same family of errors

Official references

Microsoft Learn: Add users and assign licenses in Microsoft 365
Microsoft Learn: Microsoft Entra authentication and authorization error codes
Microsoft Learn: Troubleshooting sign-in problems with Conditional Access
Microsoft Learn: Identify and resolve license assignment problems for a group

FAQ

How long does it take for a new Microsoft 365 user to be able to sign in after I create them?

Identity-only sign-in (to office.com) is usually possible within five minutes of creation if a license is assigned and usage location is set. Full service availability — Outlook mailbox provisioned, OneDrive personal site provisioned, Teams identity active — typically takes 15–30 minutes after license assignment. If it’s been less than 30 minutes, the most likely answer is “wait”.

Why does my new user get “Something went wrong” with no detail?

Microsoft uses generic error messages on the user-facing sign-in screen. The detailed error is in the Entra ID sign-in logs as an AADSTS code. Always start diagnosis there, not from what the user reports seeing.

Can a new user sign in before I assign them a license?

Yes — they can authenticate to Microsoft Entra ID without a license. They just can’t access any licensed services (Exchange, Teams, OneDrive, Office apps). If they can sign in to office.com but see “you don’t have a license to use this product” everywhere, the identity is fine and the license is the issue.

Is it normal for a new user to have to register MFA on first sign-in?

Yes, if your Conditional Access policy requires MFA. If your policy is configured correctly, the first sign-in will direct them to aka.ms/mfasetup to register the Microsoft Authenticator app. If your policy is misconfigured (most common: requiring MFA before MFA can be registered), they’ll get stuck. The fix is a Temporary Access Pass or a Conditional Access exemption for the security info registration flow.

The user can sign in to Outlook on the web but not Outlook desktop. What’s wrong?

Almost always either (a) the desktop Outlook is caching old credentials from a previous user — clear from Windows Credential Manager — or (b) the user’s licensed plan doesn’t include desktop Outlook. Microsoft 365 Business Basic, for example, is web-only. Confirm the licensed plan first.

Can I just delete and recreate the user?

You can, but you shouldn’t. Deletion wipes the mailbox after 30 days, the OneDrive after 30 days, and Teams chat history immediately. Recreate solves nothing that the checklist above doesn’t solve more cheaply.

The user can sign in fine but immediately gets prompted again to sign in. Is that the same problem?

No, that’s an MFA loop or a token-refresh loop, which has different causes. See MFA prompt loop: admin-side causes for that diagnosis.

↑ Back to top