Before we start: whose course this is
This course is independent of Google. Google has not written, reviewed or endorsed it. It uses Google's product names only so that you know which screen we mean, and it doesn't copy Google's documentation. Google's own admin help now lives at knowledge.workspace.google.com. When this course and that site disagree, the site is right.
That matters more than it sounds. Google renames menus, moves settings and changes which editions get which features, often with little warning. Every console path in this course was checked in November 2026. Treat each one like a dated label on a jar in the fridge: check it before you rely on it. If a path doesn't match what you see, search Google's help for the feature name. Don't guess.
The whole journey on one page
When someone says "I can't get into Gmail", they have usually got stuck at one of about six screens. If you can tell which screen, you are already halfway to the cause. Here is the map:
USER SEES WHAT SITS BEHIND IT
---------------------------------------------------------------------------
1. "Sign in" - type email address -> The account itself: does it exist, is it
active or suspended?
2a. "Enter your password" -> Google password (managed in Admin console)
2b. Redirect to Okta/Entra/etc. -> SSO: a third-party identity provider
checks the password instead of Google
2c. "Use your passkey" / screen -> Passkey (phone, security key or the
lock prompt computer's screen lock), if the org allows
users to skip passwords
3. "2-Step Verification" - prompt, -> 2SV: phone prompt, authenticator code,
code or security key security key, backup code
4. "Verify it's you" (unexpected) -> Login challenge: Google's risk check
on an unusual sign-in
5. Signed in, but an app says -> Context-Aware Access: rules on device,
access is blocked IP or location for each app
6. Gmail inbox -> Success
WHEN IT ALL FAILS: "Forgot password?" / recovery
-> Recovery email and phone, or an admin reset
Think of a staffed office building. Screen 1 is the receptionist checking that your name is on the list. Screen 2 is your key card. Screen 3 is the PIN pad. Screen 4 is security stopping you because you came in through an unusual door at 3 a.m. Screen 5 is a locked inner door: you are inside the building but not allowed into this room. How the building decides the order of these checks is the subject of Level 2. For now, just learn the rooms.
Three things on the map that catch people out
SSO changes who owns the password. If your firm uses a third-party identity provider through an SSO profile, the user types their password on that provider's page, not Google's. Resetting the Google password in the Admin console won't help them. One exception to know now: Google's documentation says SSO profiles don't redirect super admins to the identity provider. A super admin still signs in with their Google password even when every other user goes through SSO.
Gotcha: a user says "it's not even asking for my password, it sends me to a Microsoft page". That is SSO doing its job. The fault, if there is one, is probably on the identity provider's side.
Passkeys don't delete the password. When an admin turns on Skip passwords (it sits under Menu > Security > Authentication > Passwordless), users who have added a passkey can sign in with their fingerprint, face or PIN. Their password still exists and still works. Users don't need 2SV turned on to use a passkey this way.
Login challenges and 2SV are different things. 2SV is something the user set up and expects to see. A login challenge is Google spotting something unusual, such as a new device or a new country, and asking for extra proof. Users often call both of them "the code thing". Ask them what the screen actually said.
The one page to open first
For almost any sign-in ticket, start on the same screen:
Admin console (admin.google.com)
Menu > Directory > Users
-> click the user's row (opens their user details page)
-> Security
# Path checked November 2026. What you can see here depends on your admin privileges.
The Security panel brings most of this lesson's map together for one person. Below is an illustrative example of what you might note down from it. It is a support note, not a screenshot:
Ticket 4127 - j.patel@example.co.uk - "can't sign in, new laptop"
Security panel, read-only checks first:
Password : last changed 3 weeks ago # not a fresh reset issue
2-Step Verification : ON (user enrolled) # the user has 2SV
Security keys : none registered
Login challenge : option available # can turn off for 10 min
Recovery information: phone set, email blank # note the gap
Next: ask the user what the screen literally says before changing anything.
From this one panel, an admin with the right privilege can reset a password, view 2SV status, get backup codes, manage security keys, turn off login challenges for 10 minutes and edit recovery information. Each of those gets its own lesson later.
Best practice: look before you click. Every control on this page changes the user's security. Read the panel, write down what you see, and only then act. Later lessons show which roles can see which controls. If a control is missing for you, it's probably a privilege gap, not a bug.
Key takeaways
- A Workspace sign-in passes through several stages: account, then password or SSO or passkey, then 2SV, then possibly a login challenge, then Context-Aware Access, and finally the app. Work out which screen the user is stuck on first.
- With SSO, the password lives at the identity provider. Super admins are not redirected by SSO profiles.
- Passkeys let users skip the password but don't remove it.
- A login challenge ("Verify it's you") is Google's risk check, not the user's 2SV.
- Your first stop for any sign-in ticket: Menu > Directory > Users > the user's row > Security.
- This course is independent of Google and not endorsed by it. Paths are dated (November 2026), so check them against Google's current help.