Explore / Suite Support Pro: Configure and Fix
Google Workspace Support Pro: Sign-in, 2SV and Lockouts

Fix Google Workspace sign-in problems the way a senior support engineer does: reset passwords, sort out 2-Step Verification, backup codes, security keys and passkeys, recover suspended or challenged accounts, read User log events and Context-Aware Access logs to find out why someone was blocked, spo
Expert · 30 levels · 2 free · Created Nov 2026 · Professionally curated by levelupwith.com
What's inside
- Level 1: Workspace Sign-in on One PageFree
You get a one-page map of a Google Workspace sign-in: the screens the user sees and the parts behind them (password, 2-Step Verification, passkeys, SSO, login challenges, Context-Aware Access and recovery details), with a clear statement that this course is independent of Google and not endorsed by it. - Level 2: How a Sign-in Gets Decided, Step by StepFree
You learn the order of decisions in a sign-in, from where the identity lives (Google or a third-party SSO provider) through first factor, second factor and risk-based login challenge to Context-Aware Access at the app, so you can tell which step a user is stuck at from what they describe. - Level 3: Editions, Licences and What They Unlock
You learn how the Workspace edition and the user's licence change which sign-in controls and logs exist (for example Context-Aware Access, the security investigation tool and how far back logs go), and you check each one against Google's current edition comparison and record the date you checked. - Level 4: Prebuilt Admin Roles: The Smallest One for Each Job
You compare Google's prebuilt admin roles, such as Help Desk Admin, User Management Admin and Super Admin, and pick the smallest one that covers each sign-in support job, including the limit that a User Management Admin can't reset an administrator's password. - Level 5: Custom Roles and Scoping Support to an OU
You read and test a custom support role that has only the user-security and reporting privileges a help desk needs, scoped to particular organisational units, and you confirm in a test tenant what it can and can't do before anyone relies on it. - Level 6: The User's Security Panel: Read-Only First Look
Before changing anything, you learn to read a user's Security panel and the settings their organisational unit inherits. That shows you their 2SV status, enrolled methods, passkeys and security keys, recovery details and any login challenge state. - Level 7: Password Resets and Forcing a Change
You reset a user's password from the Admin console, decide whether to make them change it at next sign-in, and get the new password to them safely. You also learn the password policy limits and the knock-on effects on sessions and devices. - Level 8: Enrolling 2SV and the Enforcement Grace Period
You walk a user through 2-Step Verification enrolment, read whether their OU allows or enforces 2SV, which methods it accepts and what new-user enrolment period applies, and explain what happens on the day enforcement starts. - Level 9: Generating and Handing Over Backup Codes
You generate backup verification codes for a user from the Admin console, check who is asking before you hand them over, and explain to the user how codes are used up and replaced. - Level 10: Registering Security Keys
You help a user register a hardware security key and a spare, read whether their OU requires security keys only, and know the browser and device requirements that commonly trip up registration. - Level 11: Setting Up Passkeys and Skip Passwords
You read the Passwordless settings at Security > Authentication > Passwordless (skip passwords and any restriction to passkeys on hardware security keys only), then help a user create a passkey on their device and turn on skipping passwords. - Level 12: Keeping Recovery Details Up to Date
You check and update a user's recovery phone and email, read whether the tenant lets users recover their own password, and understand why stale recovery details turn a five-minute fix into a lockout. - Level 13: Moving Users Between OUs and Policy Effects
You move a user to another organisational unit and predict the sign-in effects first: 2SV enforcement, allowed methods, passwordless and password policy can all change at once. - Level 14: Fault: Lost or Replaced Phone
For a user whose phone was lost, wiped or replaced, you work through the usual causes in order, check what methods they still have, restore access with backup codes or a short login-challenge bypass, and help them re-enrol on the new phone. - Level 15: Fault: No Backup Codes, No Second Step
For a user who is stuck at 2SV with no working method and no backup codes, you check who they are, generate fresh codes or turn off 2SV temporarily where the OU policy allows, and get them re-enrolled properly. - Level 16: Fault: Security Key or Passkey Won't Work
When a security key or passkey is rejected or never prompts, you check in order: browser support, the key's PIN or lockout, a passkey on another device or phone, the OU's restriction to hardware security keys, and a revoked key. - Level 17: Fault: Suspended Accounts
You tell apart an account an admin suspended from one Google suspended automatically for suspicious activity. You read the reason on the user page and restore only once you know why it happened. - Level 18: Fault: Login Challenges Blocking a Real User
For a real user who is blocked by a risk-based login challenge they can't pass (no phone signal, no employee ID on record), you check who they are and use Login challenge > Turn off for 10 minutes. Afterwards you check why the challenge fired. - Level 19: Fault: The Wrong-Password Loop
Work through a user who says the password is right but sign-in keeps rejecting it, or who goes straight back to the password prompt. Check the causes in order: an old saved password, the wrong account in the browser, a forced password change they haven't finished, sync from an external directory, and a recent admin reset. - Level 20: Fault: SSO Redirect Failures
Diagnose a user who is sent to a third-party identity provider and then gets an error, a loop or a block. Decide whether the fault sits with the user, the SSO profile assigned to their organisational unit or group, or the identity provider itself. - Level 21: Reading the Login Audit Log
Open the Login audit log under Reporting > Audit and investigation in the Admin console (path checked against Google's documentation in November 2026, so recheck it). Filter by user, event and time, then read success, failure, challenge and suspicious-login events to rebuild what happened on one sign-in. - Level 22: User Log Events in the Investigation Tool
Know when the security investigation tool and its User log events data source are in your edition and your admin role. Use the tool to look across users and events for patterns that the per-user view hides. - Level 23: Tracing SSO Failures in the Logs
Use the SAML-related audit events and the Login audit log together to show whether a failed SSO sign-in broke in Google or at the identity provider. Collect the evidence the identity provider team will need. - Level 24: Reading Context-Aware Access Denials
Read Context-Aware Access log events, found under Reporting > Audit and investigation in the Admin console (checked November 2026), to explain why a user was blocked from an app on a particular device or network. Entries can take around an hour to appear. - Level 25: Explaining Tenant Policy Without Changing It
Read tenant-wide sign-in policy, including 2SV enforcement and allowed methods, password rules, session length, the login challenge setting, SSO assignment and Context-Aware Access, as it applies to one organisational unit or group. Explain what it does to a user, and escalate design questions instead of editing the policy. - Level 26: Recognising Account Takeover
Spot the warning signs that a sign-in problem may be a takeover. These include suspicious-login and unknown-location events, recovery details changed without the user knowing, new 2SV methods, unexpected mail forwarding or delegation, and reports from colleagues of odd messages. - Level 27: First Response to a Suspected Takeover
Take the first steps that contain a suspected takeover, in a set order, recording each one with a timestamp. Steps include resetting the password, signing the user out of all sessions, removing unknown 2SV methods and recovery details, and reviewing app access and forwarding. Do not destroy evidence. - Level 28: Super Admin Recovery as an Escalation
Understand how a super admin who is locked out gets back in: their own recovery details, another super admin, and then Google's recovery process using proof of domain ownership. Learn why support routes this upward instead of trying it themselves. - Level 29: Where Support Stops: The Evidence Packet
Draw the line between first and second line, third line, the identity provider team and Google support. Put together a standard evidence packet so the next person never has to ask the user again. - Level 30: Final Challenge: The Sign-in Ticket Queue Exam
Work a queue of realistic sign-in tickets that covers the whole course: resets, 2SV, a lost phone, keys and passkeys, suspensions, challenges, SSO, Context-Aware Access and takeover. Triage, resolve or escalate each one with a written note.
Access
The first 2 levels are free with a free account. Every level, the podcast edition and the AI tutor come with All Access at £4.99/month or any Creator plan — see pricing.