New starter cannot sign in on first day: diagnosis and fixes

TL;DR — When a new starter cannot sign in on their first day, the most common cause is simple: they are using the wrong sign-in method or they were never fully invited/provisioned (created in the identity system). Start by checking the exact error message, then confirm in your identity provider or app admin area that the user exists, has the right email address, and has an active invitation. Reading time: ~6 min

The scenario

It is 9:17 on a Tuesday. Your new starter is on their first onboarding call, screen-sharing from a fresh laptop, and every login attempt is failing. They can open the sign-in page, but after entering their work email they either get "No account found", "Ask your admin for access", or they loop back to the login screen after entering a password. HR says the account was requested last week, your IT checklist says "done", and now everyone is waiting for you to sort out what should have been the easiest part of day one.

Symptoms

• The user sees one of these messages after entering their work email:
  • "No account found for this email"
  • "User does not exist"
  • "Ask your administrator for access"
  • "Your account is disabled"
  • "We couldn't sign you in"
  • "Invalid email or password"
• The sign-in page offers multiple methods and the user is unsure which one to pick:
  • "Continue with Google"
  • "Continue with Microsoft"
  • "Sign in with SSO" (single sign-on)
  • Email/password form
• The user receives no invitation email, or says "I never got the setup email".
• The user gets stuck in MFA (multi-factor authentication) setup:
  • "Invalid verification code"
  • "This code has expired"
  • "Authenticator app not enrolled"
• The admin area shows the user as one of:
  • Pending invitation
  • Not found
  • Suspended / Disabled
  • Unlicensed / No access assigned
• If your app uses SSO, the identity provider sign-in logs may show messages like:
  • "application not assigned"
  • "user not provisioned"
  • "domain not verified"
  • "login denied by policy"

Likely causes

Step-by-step diagnosis

1. Start with the exact error on screen
   Ask the user to read the message word-for-word or send a screenshot. If the page says "Continue with Google", "Continue with Microsoft", or redirects to your company login page after entering their email, this is likely the wrong sign-in method. Jump to Fixes → Wrong sign-in method used.

2. Confirm the exact work email address
   Use the email from your HR system, directory, or the original onboarding request. Compare it to what the user is typing, character-for-character, including dots, hyphens, and the domain.

   • If you find a typo such as jane.smyth@company.com instead of jane.smith@company.com, this is your problem. Jump to Fixes → Email address mismatch or typo in the account.
   • If the email matches exactly, continue.

3. Check whether the user exists in the app admin area
   In your provider's dashboard, open the app admin area and go to the user list (for example: Admin/Settings → Users/People → Search). Search for the exact email.

   • If the user is Pending invitation, Invited, or similar, this is your problem. Jump to Fixes → User was invited but the invitation was never accepted or expired.
   • If the user is not found, continue to the next step.
   • If the user is Disabled, Suspended, or No access assigned, jump to Fixes → Account is blocked by policy, disabled, or missing app assignment.

4. Check the identity provider (if you use company SSO)
   In your identity provider dashboard (for example: your Microsoft Entra, Google Workspace, Okta, or similar admin console), go to Users → Search and look up the exact email.

   • If the user is not found, this is your problem. Jump to Fixes → User was never provisioned in the identity provider or app.
   • If the user exists, open their profile and check assigned apps/groups and recent sign-in logs.
   • If the logs show application not assigned, login denied by policy, or the app is missing from assigned apps, jump to Fixes → Account is blocked by policy, disabled, or missing app assignment.

5. Check whether the invite/setup email can actually be received
   In the app admin area, click Resend invite. Then ask the user to check Inbox, Spam/Junk, and the mail quarantine area if your mail system has one.

   • If the resend action reports a bounce, or nothing arrives anywhere, this is likely an email delivery/domain issue. Jump to Fixes → Email domain not verified or mail delivery blocked.
   • If the invite arrives, have the user open it in a private/incognito window and continue.

6. Test MFA enrollment only after the account is confirmed to exist
   If the user can reach the password step or SSO step but fails on the code/app approval screen, open the user in the admin area and look for Reset MFA, Clear enrolled factors, or similar.

   • If resetting MFA lets them enroll again and sign in, this is your problem. Jump to Fixes → MFA enrollment/setup failed on the new device.
   • If not, continue.

7. Use a controlled password reset only for password-based accounts
   If your app uses email/password rather than Google/Microsoft/SSO, trigger Forgot password from the login page or Send password reset from the admin area.

   • If the reset email arrives and the user can sign in after setting a password, the issue was an incomplete invite or stale password setup. Use the fix in User was invited but the invitation was never accepted or expired.
   • If the reset email does not arrive, return to Email domain not verified or mail delivery blocked.

Fixes

Wrong sign-in method used

Tell the user to start from the main sign-in page and enter only their work email first. Then follow the method indicated by the page:

• If it says Continue with Google, click that button.
• If it says Continue with Microsoft, click that button.
• If it says Sign in with SSO, enter your company domain if prompted.
• Do not use email/password if your organization uses Google, Microsoft, or SSO for that app.

If you publish internal docs, send a direct link with one sentence such as: Use "Continue with Microsoft" for all @company.com accounts.

Verify it worked: the user reaches the app home page without seeing the password form again.

User was invited but the invitation was never accepted or expired

In the app admin area, open Users/People, select the user, and click Resend invitation. If there is an option to revoke and re-invite, use it if the original invite is older than a few days.

If your app supports a direct reset link instead of an invite, use Send password reset for password-based accounts.

Ask the user to open the new invite in a private/incognito browser window to avoid stale cookies (saved browser sign-in state).

Verify it worked: the user status changes from Pending invitation to Active after they complete setup.

User was never provisioned in the identity provider or app

Create the user in your identity provider or app admin using the exact work email. If your process is group-based, add them to the onboarding or app-access group.

Typical admin path:

• Identity provider: Admin console → Users → Add user
• Then: Applications/Apps → [Your app] → Assign users/groups
• Or in the app itself: Admin → Users → Add user

If you sync users from a directory, trigger a sync from your directory tool instead of creating a duplicate local account.

Verify it worked: searching the email in the identity provider and app now shows an active user with the app assigned.

Email address mismatch or typo in the account

Edit the user record so the login email exactly matches the employee's real work email from your directory. Common mistakes are swapped letters, missing dots, old surnames, and the wrong domain.

If the wrong email already received an invite, revoke that invite first, then save the corrected email and resend the invite.

⚠️ If your app treats email as the unique identifier, changing it can affect audit history or linked records. Check the user profile screen for warnings before saving.

Verify it worked: the user can enter the corrected email on the login page and receives the expected invite/reset flow.

MFA enrollment/setup failed on the new device

In the admin area, open the user and choose Reset MFA, Clear enrolled factors, or the equivalent option. Then ask the user to sign in again and re-enroll using their authenticator app or security key.

If your policy allows it, issue a one-time backup code or temporary bypass for the first login, then require MFA enrollment immediately after.

Tell the user to check the device time if codes are rejected; authenticator codes fail when the phone clock is far off.

Verify it worked: the user completes MFA enrollment and the next sign-in accepts the code or push approval.

Account is blocked by policy, disabled, or missing app assignment

Open the user in your identity provider and check:

• Status: change from Disabled/Suspended to Active if appropriate.
• Assigned applications: add the app if it is missing.
• Groups: add the user to the access group used for that app.
• Conditional access / sign-in policy: if the sign-in log says login denied by policy, review whether the user's device, location, or MFA state is being blocked.

A common fix is simply assigning the app to the user or to the correct onboarding group.

Verify it worked: the next sign-in log shows success instead of application not assigned or login denied by policy.

Email domain not verified or mail delivery blocked

First, resend the invite and check whether your mail system shows a bounce or quarantine. In your mail admin area, search message trace/logs for the recipient address and the app's sender address.

If your app requires domain verification for self-serve invites, complete that in the app admin area using the DNS (domain name system) record it provides. In your DNS provider dashboard (for example: DNS → Records), add the TXT record exactly as shown by the app.

Example TXT record format:

Type: TXT
Name/Host: @
Value: verification=abc123example
TTL: 3600

If your mail gateway is blocking the invite, allowlist the sender domain or sender address in your mail security tool, then resend.

Verify it worked: the resent invite appears in the user's inbox or quarantine within a few minutes and can be opened successfully.

Prevention

• Standardize the login method in onboarding docs
  Put one line in the welcome email and IT checklist: For all @company.com accounts, use "Continue with Microsoft" on first login. This prevents users from setting a password on an account that should use SSO.

• Create a pre-day-one access checklist with explicit checks
  Before the start date, confirm these four items in writing: user exists, exact email matches HR, app is assigned, invite accepted or reset link delivered. A simple checklist works:

[ ] Email matches HR record exactly
[ ] User exists in identity provider
[ ] Required apps/groups assigned
[ ] Invite accepted or password set
[ ] MFA enrolled or temporary backup code issued

• Use group-based app assignment instead of manual per-user access
  Add all new starters to one onboarding group, then assign the app to that group. This reduces missed app assignments when someone is created but not granted access.

• Add invite delivery monitoring in your mail admin
  Create a saved search or alert for bounced/quarantined onboarding emails from your app sender domains. Look specifically for repeated failures to new starter addresses.

• Pin one source of truth for email addresses
  Sync the employee's primary work email from HR/directory into your identity provider and apps. Do not hand-type emails into multiple systems if you can avoid it.

• Test the first-login path monthly with a dummy account
  Create a test user, send the invite, complete MFA, and confirm access to the standard apps. Record the exact path that works so support and HR use the same steps every time.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.