Microsoft 365 Sign-in on One Page

When a user says "I can't get into Outlook", the cause is almost always somewhere along one short path. It runs from the first sign-in box to the moment their inbox loads. Each screen on that path comes from a different part of Microsoft Entra ID. Learn the path once and you can ask the right first question on every ticket: which screen did they stop on?

Before we start: who wrote this course

LevelUpWith is independent of Microsoft. Microsoft has not written, endorsed or reviewed this course. Microsoft's own documentation on Microsoft Learn (learn.microsoft.com) is the authority. Admin screens, menu paths, role names and licence limits change often. Every path in this course was checked against Microsoft Learn in November 2026. If what you see in your tenant differs from this course, believe the tenant and the current documentation.

The journey, screen by screen

Think of the path as airport checkpoints. Each one is staffed by a different team, and each team can turn the passenger back for its own reason.

User opens outlook.office.com
   |
   v
[1] "Sign in" (email address)       -> Entra works out which tenant owns the account
   |                                    and how the account signs in (cloud password,
   |                                    or sent on to another identity provider)
   v
[2] "Enter password"                -> First factor checked: password, or a
   |  (or a passkey / Authenticator)    passwordless method instead
   v
[3] (invisible) Conditional Access  -> Tenant policies evaluated AFTER the first factor:
   |                                    allow, require MFA, require a compliant device, or block
   v
[4] "Approve sign-in request" /     -> MFA, using a method the user registered under
   "More information required"         Security info (or asked to register one now)
   |
   v
[5] "Stay signed in?"               -> Keep me signed in (KMSI): Yes sets a persistent
   |                                    browser cookie
   v
[6] Inbox loads                     -> Access granted. The whole attempt, success or
                                       failure, is written to the sign-in logs

Some points the diagram hides:

• Screen 1 has no security check yet. It only finds the account's home. That is why a typo in the domain fails here, before any password is asked for.
• Conditional Access has no screen of its own. Users only see its effects: an MFA prompt they didn't expect, or a "You cannot access this right now" page. Microsoft's documentation says plainly that Conditional Access is enforced after first-factor authentication finishes. So a user blocked by policy has usually typed the correct password. Don't reset it.
• "More information required" is the combined registration interrupt. The user has not yet set up the security info their organisation requires. They are not locked out. They are being asked to register a method, for example the Authenticator app. Later, users manage their methods at https://aka.ms/mysecurityinfo.
• "Stay signed in?" does not appear for everyone. Microsoft hides it for guests, for high-risk sign-ins, and when a Conditional Access persistent browser session control applies.

Where each piece lives for support

The last row matters. If the sign-in log shows a success and Outlook still misbehaves, the fault is probably not in Entra ID.

Walkthrough: reading one failed sign-in

Every attempt lands in the sign-in logs, and you can't edit or delete the entries. Open them read-only:

1. Go to https://entra.microsoft.com
   (sign in with at least the Reports Reader role; roles are covered in Level 3)
2. Entra ID > Monitoring & health > Sign-in logs
3. Filter: User = the caller's address, Date = when it happened
4. Open the failed row and look at Basic info

Here is an example of what you might see for Priya, who rang to say "it won't let me in":

Date:               02/11/2026 09:14
User:               priya.shah@contoso.co.uk
Application:        Office 365 Exchange Online   # which app she was opening
Status:             Failure
Sign-in error code: 53003                        # blocked by Conditional Access
Failure reason:     Access has been blocked by Conditional Access policies...

Compare this with the path diagram. Error 53003 belongs to the invisible step 3, so her password worked. Codes you will meet early on:

50126   Invalid username or password        -> step 2 (first factor)
50076   MFA required by policy or location  -> steps 3-4 (an MFA challenge was needed)
53003   Blocked by Conditional Access       -> step 3 (policy said no)
50140   "Keep me signed in" interrupt       -> step 5 (user stopped at the prompt)

If you find a code you don't recognise, paste it into Microsoft's lookup page at https://login.microsoftonline.com/error.

Gotcha: the logs don't keep forever. Microsoft states that sign-in logs are kept for 7 days on Entra ID Free and 30 days on P1 or P2. A user who reports "it failed two weeks ago" in a Free tenant has no record left to read. Take a screenshot of the entry, or note its details, while you still have the ticket open.

Best practice: read before you act. Find the failed row first, then match the code to a step in the path. Only then reset, unblock or escalate. Resetting a password for a Conditional Access block only adds a second problem.

Key takeaways

• A Microsoft 365 sign-in goes in this order: account lookup → first factor → Conditional Access → MFA or registration → "Stay signed in?" → app. Each step can fail on its own.
• Conditional Access runs after the first factor and has no screen of its own. A user blocked by policy usually has the right password.
• "More information required" means the user still has to register security info. It is not a lockout.
• The sign-in logs are at Entra ID > Monitoring & health > Sign-in logs. Match the error code to the step where the sign-in stopped. They are kept 7 days on Free and 30 days on P1/P2.
• This course is independent of Microsoft. Microsoft's current documentation is the authority, and screens change, so check them.