Lesson 2: How a Sign-in Gets Decided, Step by Step

Why the order matters

When a user rings and says "I can't get in", you're really asking one question: which gate stopped them? A Google Workspace sign-in isn't one check. It's a set of gates that always come in the same order, and each one looks different on the user's screen. If you know the order, you can usually name the gate from the user's own words before you open the Admin console.

Think of a corporate building. Reception decides which entrance you use (identity source). You show your badge (first factor). Security might ask for a PIN or call your manager (2SV or a login challenge). Once you're inside, some rooms have their own card readers (Context-Aware Access). A locked meeting room doesn't mean you failed at reception.

Admin screens and defaults below were checked against Google's documentation in November 2026. Google changes them often, so check again before you quote one to a customer.

The five gates, in order

User types alice@example.com at accounts.google.com
│
├─ GATE 1  Identity source: who checks the password?
│          Google itself, OR an SSO profile sends the user to a
│          third-party IdP (Entra ID, Okta, ...) - "our company page"
│
├─ GATE 2  First factor: password (at Google or at the IdP)
│          OR a passkey, if the admin allows skipping the password
│
├─ GATE 3  Second factor / risk check:
│          2SV, if the user is enrolled  -> "it asks for a code / tap my phone"
│          otherwise a risk-based LOGIN CHALLENGE, only if Google thinks
│          the sign-in looks unusual     -> "it asked for my employee ID"
│
├─ ✔ SIGNED IN: the Google session exists now
│
└─ GATE 4  Context-Aware Access, checked when an APP is opened
           Drive / Gmail / ... checks device, IP, location
           -> "Your organization isn't allowing access."

That's four numbered gates plus the moment the session gets created. The session sits between gate 3 and gate 4, and it's the key to the whole lesson.

Gate 1: where the identity lives

If the user's organisational unit or group has an SSO profile assigned, Google never asks for their password. It sends the browser to the third-party identity provider (IdP). The user sees their company's own sign-in page. If they're stuck there, the problem is at the IdP: a wrong password, a lockout or MFA on the IdP's side. You can't reset their Google password to fix it, because Google never checks it.

Gotcha: after the IdP says yes, Google may still add its own checks. Under Security → Authentication → Login challenges → Post-SSO verification, the default for the organisation's legacy SSO profile is to skip Google's extra challenges and 2SV. For other SSO profiles, the default is to apply them. So an SSO user who gets asked for a Google code isn't necessarily seeing a fault. It may be the setting.

Gate 2: password or passkey

For Google-managed identities, the first factor is the password. If an admin has ticked Allow users to skip their password and authenticate with a passkey (Security → Authentication → Passwordless, off by default), a passkey can replace the password. A passkey covers both the first and second factor in one step. Turning the option on doesn't delete the user's password.

Gate 3: 2SV or a login challenge

These two get mixed up all the time:

So a user without 2SV who suddenly gets asked for an employee ID after a trip abroad has hit a login challenge, not a broken 2SV setup. Later levels show how to clear each one. For now, you only need to name the gate.

Gate 4: Context-Aware Access comes after the sign-in

Context-Aware Access (CAA) policies are assigned to apps, not to the sign-in page. They decide whether this user, on this device, from this IP or location, can use Drive or Gmail. So the user gets through gates 1–3, is properly signed in, then opens Drive and gets a block page. With no custom text configured, that page says "Your organization isn't allowing access."

That's why CAA blocks feel strange to users: "I'm signed in, Calendar works, but Drive says no." That's exactly what you'd expect, because each app has its own access level. A few useful facts:

• CAA doesn't apply to the Admin console or to the user's own account pages (myaccount.google.com). The user can still reach their account settings while Drive is blocked.
• An admin can run an access level in Monitor mode, which logs what would be blocked without blocking it.
• For third-party apps that use "Sign in with Google", CAA is checked when the user signs in to that app. After that, the app controls its own session.

Worked triage: from the user's words to the gate

"It sent me to our company page and says my password is wrong"
    -> Gate 1/2 at the IdP. Google never saw the password.
"It keeps asking for a code from my phone, and I've got a new phone"
    -> Gate 3, 2SV. The first factor was accepted.
"It asked for my employee ID. It's never done that before"
    -> Gate 3, risk-based login challenge (unusual sign-in).
"Wrong password" on the Google page itself (no redirect)
    -> Gate 2, Google-managed password.
"I signed in fine but Drive says my organisation isn't allowing access"
    -> Gate 4, Context-Aware Access. Sign-in worked.

Best practice: ask "what's the last screen you saw, and what did it say, word for word?" before you touch anything. A screenshot of that screen is often the whole diagnosis, and it tells you which log to read later.

Key takeaways

• Every sign-in hits the gates in this order: identity source → first factor (password or passkey) → 2SV or login challenge → session created → Context-Aware Access at each app.
• Being redirected to a company page means an SSO profile applies. The password is checked at the IdP, not by Google.
• 2SV happens routinely. Login challenges appear only when risk is detected, and a user with 2SV on doesn't get an extra login challenge.
• A passkey can cover both factors, but only if the admin allows skipping the password.
• CAA blocks happen after a successful sign-in because they're attached to apps. One app can be blocked while another works.