Map each Cedar step to a layer in your tenant

Setup

1. Press Start on this page.

2. Copy the lesson's table into your notes (step, what happened, what was in place) and add three columns: "your tenant's layer", "evidence" (an Audit or Logs record with its request ID, from this or an earlier lab) and "fails for a different reason than the layer before? yes or no".

Walkthrough

1. Day 0, guessing: cite your tenant's sign-in limits. Evidence: the refused attempts in Logs, source Protocol summaries, from the guessing lab, or the limit in Overview > Usage and limits.

Why it matters: this layer held at Cedar and holds in your tenant. It slows guessing without locking the owner out.

2. 09:14, the relayed sign-in: apply the early layer. In Authentication, set Passkey or security key to Required with Replaces password on and Password to Optional, and save. Sign in as Ava with her passkey and regenerate her recovery codes at $ISSUER/account/security: her password is retired.

Why it matters: a phishing-resistant method at the first step would have stopped every later step at Cedar. The policy decides which methods count, and replacing the password removes the fallback a relay would steer her to.

3. 09:20, the new authenticator: cite the recent sign-in check and a reauthentication_required event from the recovery or limiting labs. In the last column, write "no": it counts the age of the session, which a minutes-old stolen session always passes.

Why it matters: layers count only if they fail for different reasons. With passkeys required, a recent session is itself a passkey sign-in, so the earlier layer is what makes this one meaningful.

4. 09:31, the app approval: cite exclusive scopes, administrator assignment and consent from the apps lab (invalid_scope, access_denied, the client updates). Mark "tenant-wide app block" and "administrator approval for sensitive scopes" as missing.

Why it matters: at Cedar any employee could approve any app. In your tenant a client cannot even ask for photos.share until an administrator assigns it, which is a secure default.

5. 09:40 forwarding and 11:30 key in mail: write "no tenant layer". Your tenant has no mailbox. Cite the inventory practice from the rotation lab as the layer that belongs to the people who handle the vendor's keys.

Why it matters: some layers belong to other systems. Naming them stops a table from claiming coverage it does not have.

6. 10:05, the help desk call: cite the lab-support permission gate and the refused reset after removal from the recovery lab, and your written callback procedure.

Why it matters: a process layer held at Cedar. Your tenant adds a technical gate to the same step, which fails for a different reason than the procedure.

7. Day 2, detection: cite your hand-run rules from the detection lab, and mark automated detection as missing.

Why it matters: Cedar's detection held but nearly a day late. A layer that relies on someone reading Audit by hand is real but slow.

8. Review your secure defaults. Open the Lab Mail tenant, which you have barely configured, and list what it does without anyone acting: self-service registration and email changes off, second step required for role holders, browsers not remembered, refresh token reuse grace 0, PKCE required for new public clients, consent remembered rather than skipped, provisioning refuses users whose email already exists, and exclusive scopes need assignment. Then check that Lab Photos still matches each one.

Why it matters: most settings stay at their defaults. Where Lab Photos differs, an exception should have an owner, a reason and an end date, or go back to the default.

9. Write how your tenant fails when a check cannot run: a new password is refused with password_screening_unavailable if the breach lookup is down, and a token request is refused if the token policy script cannot be evaluated or a signing key is unavailable.

Why it matters: the answer when a check cannot decide is a security decision. Each of these refuses rather than allows, so an attacker cannot get through by making the check fail.

Break it

1. In Authentication, turn Replaces password off and set Password back to Required, then save. Open $ISSUER/login: the password path is offered again, and Ava, who has no password now, is asked to set one at her next sign-in. Row 09:14 no longer holds.

Restore: set Passkey or security key to Required with Replaces password on and Password to Optional again, or record in your notes why your tenant's baseline keeps passwords. If you keep passkeys required, Ben and Cora enroll one at their next sign-in.

Check your work

• Check my progress confirms the passkey policy, Ava's retired password and the weakening change.

• Your table has a tenant layer or "no tenant layer" for every row, a cited record for each covered row, and a yes or no in the last column.

• Your defaults list marks where Lab Photos differs from Lab Mail and why.

Cleanup

• Record the authentication policy you chose as the track baseline. The posture review lab checks it.

Missing infrastructure

• G38: the tenant cannot require that a sensitive change, such as adding a method, be confirmed with a phishing-resistant method; it checks recency only. Once it exists, the lab will require a passkey confirmation for new methods and re-run row 09:20.

• G40: there is no tenant-wide app block and no administrator approval policy for sensitive scopes. Once it exists, the lab will set one and cite it in row 09:31.

• G36: there is no automated detection, so row Day 2 relies on reading Audit by hand. Once it exists, the lab will cite a fired alert and its delay.

• G66 Second lab tenant: this lab uses Lab Mail, a second tenant. Additional tenants currently need a paid subscription or a BTL grant, so an ordinary learner can do only the Lab Photos steps until every learner can have a second lab tenant.