Review your tenant's security posture from its real settings

Setup

1. Press Start on this page.

2. Create a findings table in your notes: check, what you found, impact, reachability, existing coverage, priority, owner, date, and how you will confirm the fix.

3. Take the intended configuration from the baseline you recorded in the Layered defenses lab. That is what this review compares against.

Walkthrough

1. Accounts without a strong method. In Users and Administrators, list every account that holds a role. For each role holder, check at $ISSUER/account/security (signed in as them) or from their recent sign-ins which methods they use. Ben uses an authenticator app, which a relay can pass along.

Why it matters: high-value accounts first. The lesson's "92 percent use passkeys" hides who is in the remaining gap; look at names, not totals.

2. Weaker fallbacks. In Authentication, read every method's mode, whether anything replaces passwords, the remember-browser days and the recovery codes setting. Compare with your recorded baseline.

Why it matters: an account is only as strong as the weakest way in. A single setting changed during a lab, and never changed back, is drift.

3. Read the records, not only the settings. In Audit, source Protocol activity, page through recent account.sign_in and account.second_step events and note which kind of sign-in each role holder actually completed.

Why it matters: a policy states intent, and the records show what happened. A role holder still completing authenticator codes every day is a finding even if the policy looks right.

4. Dormant accounts and leftovers. In Users, sort by last sign-in and look for accounts nobody uses, plus anything named lab-tmp- that a cleanup missed. Do the same in OAuth > Clients and Roles.

Why it matters: nobody notices when an unused account or client is taken over. Temporary resources are the lab's version of the pilot that was never switched off.

5. Standing administrators and grants. Count BTL Tenant Admins in Administrators and note that a single one leaves no second person to recover the tenant. In OAuth > Clients, list each client's scopes, consent mode and grant types; flag any with more than its job needs, such as SCIM write scopes on a reader or consent set to skip.

Why it matters: every administrator is a target that can change everything, and grants keep working without anyone signing in.

6. Lifetimes, secrets and keys. In OAuth > Flow policy and Access Token Management, read the session, access token and refresh lifetimes and the reuse grace. In Key Management, note each key's status and age, and any retiring key that was never disabled.

Why it matters: the older and longer-lived a credential, the more places it may have been copied and the longer a stolen copy works.

7. Trust and records. In Provisioning, confirm users with an existing email are refused. In the token managers, review claim mappings. In Audit, open Collection and retention and note the retention period and any dropped records.

Why it matters: trust configuration decides who can sign in as whom, and records decide whether anyone would notice.

8. Prioritize. Rate each finding by what an attacker could do with it, how reachable it is, and what already covers it. Confirm anything that might be intended (an integration that never signs in is not a dormant person) and record accepted risks with who accepted them and until when.

Why it matters: the first review produces a long list. Sorting by impact and reachability keeps the important items from waiting behind the easy ones.

9. Fix two findings. First, remove a standing role: unless Ben has help desk work this week, remove lab-support from him. Second, narrow a client that holds more than it needs, for example remove a scope lab-printer-app no longer uses. Give each fix an owner and a date in the table.

Why it matters: every fixed finding needs an owner and a date, or the next review finds the same list.

Break it

1. Confirm each fix by trying the path it closed. Sign Ben in and open $ISSUER/manage: he is sent back to his account page. Request the removed scope for lab-printer-app: the authorization request returns invalid_scope. If either still works, the fix did not take effect, and the finding stays open.

Check your work

• Check my progress confirms your review of the sign-in records, the removed role, the narrowed client and Ben's sign-in after the change.

• Your findings table covers every check in the lesson's table, with a priority for each finding, an owner and date for each fix, and a recorded owner and revisit date for each accepted risk.

Cleanup

1. Delete any lab-tmp- resources you found.

2. Add the checks you want to repeat to a schedule: which ones should be alerts (a new administrator, a new client with broad scopes) and which ones quarterly.

Missing infrastructure

• G52: there is no filterable last sign-in report, no per-client last use and no report-only mode for a new rule, so dormant clients and the effect of a change are judged by hand. Once it exists, the lab will list clients unused for 30 days and preview a passkey requirement in report-only mode before enforcing it.

• G40: there is no inventory of each user's app grants, so the grants check reads client settings instead of what people actually approved. Once it exists, the lab will review grants per user with their last use.