Improve IAM token session assurance

skills/identity/iam-review/SKILL.md

@@ -156,6 +156,53 @@ IAM-AUTH-10: Composition rules used instead of length-based policy (NIST SP 800-
 
 ---
 
+### Step 2A: Token and Session Assurance
+
+**Objective:** Verify that authentication strength remains enforceable after the initial sign-in by reviewing token issuance, refresh-token revocation, device-code flow controls, MFA fatigue protections, sign-in risk policy, and continuous access evaluation evidence.
+
+**NIST SP 800-63B Reference:** Section 5.2.3 — reauthentication; AAL2/AAL3 phishing-resistant authenticator guidance
+**NIST SP 800-207 Reference:** Tenet 3 — access is granted on a per-session basis; Tenet 6 — authentication and authorization are dynamic and strictly enforced
+**CIS Controls v8 Reference:** Control 6.3 — Require MFA for Externally-Exposed Applications; Control 6.4 — Require MFA for Remote Network Access; Control 6.7 — Centralize Access Control
+
+#### Review Checklist
+
+```
+IAM-TOKEN-01: Device-code flow is enabled without an approved client list, monitoring, or compensating controls
+IAM-TOKEN-02: MFA push approvals lack number matching, phishing-resistant factors, or repeated-denial / fatigue detection
+IAM-TOKEN-03: Sign-in risk and risky-user policies are report-only, partial, or missing enforcement evidence
+IAM-TOKEN-04: Refresh tokens and persistent browser sessions remain valid after user disablement, role removal, password reset, or incident revocation
+IAM-TOKEN-05: Continuous Access Evaluation coverage is assumed but not proven for the resources under review
+IAM-TOKEN-06: Session lifetime, sign-in frequency, or remembered-device settings exceed the data and privilege risk
+IAM-TOKEN-07: Legacy authentication, app passwords, or unmanaged OAuth grants can bypass the reviewed MFA and risk policy
+IAM-TOKEN-08: Post-revocation validation is missing, so the review cannot prove blocked token replay or denied resource access
+```
+
+**Evidence gate:** Treat token and session controls as acceptable only when the review includes policy configuration and recent validation evidence. A tenant-wide claim such as "MFA enabled", "CAE supported", or "tokens revoked" is supporting context; it does not replace proof of enforcement mode, scope denominator, affected resource coverage, and a post-revocation access test.
+
+**Platform-specific checks:**
+
+| Platform | Check | What to verify |
+|---|---|---|
+| **AWS** | IAM Identity Center settings, CloudTrail, and STS session policy | Session duration, MFA context for role assumption, revoked Identity Center sessions, unexpected long-lived access keys, and denied access after permission-set removal |
+| **Azure / Entra ID** | Conditional Access, Authentication methods, Identity Protection, Sign-in logs | Number matching / phishing-resistant MFA, device-code flow restrictions, risk policy enforcement mode, refresh-token revocation, CAE resource coverage, sign-in frequency, and legacy auth blocks |
+| **Azure / Entra ID** | App registrations and Enterprise Apps | OAuth consent scope, app-password exposure, service-principal token lifetime, delegated permission grant revocation, and post-revocation token replay result |
+| **GCP** | Cloud Identity session controls, Admin logs, OAuth app access control | 2-Step Verification enforcement, context-aware access, session length, OAuth app trust level, token revocation evidence, and blocked access after user suspension or group removal |
+| **Okta / IdP** | Risk engine, MFA policy, system log | Device-code or CLI app policy, push fatigue signals, step-up rules, session revocation event, and denied downstream app access |
+
+**Severity Classification:**
+
+| Finding | Severity | Rationale |
+|---|---|---|
+| Refresh tokens remain valid after account disablement or incident revocation | **Critical** | A compromised session can survive the identity or access removal event |
+| Device-code phishing path lacks monitoring or approved-client restriction | **High** | Attackers can obtain valid tokens without the expected interactive sign-in trail |
+| MFA fatigue controls are absent for privileged or externally exposed access | **High** | Repeated push approvals can bypass user intent despite nominal MFA coverage |
+| CAE or risk policy is report-only for sensitive resources | **Medium** | Access may persist after risk changes until token expiry or manual intervention |
+| Post-revocation validation evidence is missing | **Low** | Governance gap that weakens confidence in revocation controls |
+
+**Output requirement:** For every token or session assurance finding, include grant type, affected users or apps, MFA assurance, risk policy mode, refresh-token revocation timestamp, session invalidation timestamp, CAE-covered resources, post-revocation test result, evidence owner, and next validation date.
+
+---
+
 ### Step 3: Least Privilege Audit
 
 **Objective:** Identify over-permissioned accounts and enforce least privilege.
@@ -405,6 +452,7 @@ For each finding, produce a row with:
 
 ### Findings by Category
 - Authentication (Step 2): [count]
+- Token / Session Assurance (Step 2A): [count]
 - Least Privilege (Step 3): [count]
 - Service Accounts (Step 4): [count]
 - Stale Accounts (Step 5): [count]

skills/identity/iam-review/tests/benign/phishing-resistant-token-revocation-assurance.md

@@ -0,0 +1,60 @@
+# Benign: phishing-resistant MFA with token revocation proof
+
+## Scenario
+
+A privileged access workflow uses phishing-resistant MFA, restricts device-code
+flow to approved CLI clients, enforces sign-in risk policy, and records a tested
+token revocation path. The review includes policy configuration and recent audit
+evidence from the IdP and downstream resources.
+
+```yaml
+provider: azure-entra-id
+account_group: privileged-security-operators
+role: security-reader-plus-export
+authentication:
+  mfa_required: true
+  phishing_resistant_methods_required: true
+  allowed_methods:
+    - fido2
+    - certificate_based_authentication
+  number_matching_enabled: true
+  push_fatigue_detection:
+    repeated_denial_alert: enabled
+    threshold: 3_denials_in_15_minutes
+device_code_flow:
+  enabled: true
+  approved_clients:
+    - azure-cli
+    - graph-powershell
+  blocked_unknown_clients: true
+  monitoring_query: last_30_days_reviewed
+risk_policy:
+  user_risk_policy_mode: enforce
+  sign_in_risk_policy_mode: enforce
+  risky_sign_ins_reviewed: true
+token_lifecycle:
+  refresh_token_revoked_at: 2026-06-07T02:04:00Z
+  session_invalidated_at: 2026-06-07T02:05:00Z
+  sign_in_frequency_hours: 8
+  persistent_browser_session_days: 0
+  cae_resource_coverage:
+    graph: enabled
+    sharepoint: enabled
+    custom_admin_api: compensating_short_token_lifetime
+incident_test:
+  user_disabled_at: 2026-06-07T02:03:00Z
+  post_disable_token_replay: denied
+  downstream_app_access_after_revocation: denied
+  validation_window: last_30_days
+review_decision:
+  disposition: acceptable
+  evidence_owner: identity-security@example.com
+  next_validation_date: 2026-07-07
+```
+
+## Expected Assessment
+
+Do not flag `IAM-TOKEN-01` through `IAM-TOKEN-08` when the review proves approved
+device-code clients, phishing-resistant MFA, enforced risk policies, bounded
+session lifetime, refresh-token revocation, CAE or compensating resource coverage,
+and denied post-revocation token replay.

skills/identity/iam-review/tests/vulnerable/device-code-mfa-fatigue-token-persistence.md

@@ -0,0 +1,60 @@
+# Vulnerable: device-code MFA fatigue with persistent tokens
+
+## Scenario
+
+An organization reports that MFA and Conditional Access are enabled for all users.
+A privileged analyst account can still authenticate through device-code flow, approve
+repeated push prompts without number matching, and retain refresh tokens after the
+account is disabled during an incident. The review closes the posture as acceptable
+because the IdP dashboard shows MFA coverage above 95 percent.
+
+```yaml
+provider: azure-entra-id
+account: privileged-analyst@example.com
+role: security-reader-plus-export
+authentication:
+  mfa_required: true
+  phishing_resistant_methods_required: false
+  number_matching_enabled: false
+  mfa_push_denials_last_24h: 14
+  approved_after_denial_burst: true
+device_code_flow:
+  enabled: true
+  approved_clients: []
+  monitoring_query: missing
+risk_policy:
+  user_risk_policy_mode: report_only
+  sign_in_risk_policy_mode: report_only
+  risky_sign_ins_reviewed: false
+token_lifecycle:
+  refresh_token_revoked_at: null
+  session_invalidated_at: null
+  persistent_browser_session_days: 30
+  cae_resource_coverage:
+    graph: enabled
+    legacy_sharepoint: unknown
+    custom_admin_api: not_supported
+incident_test:
+  user_disabled_at: 2026-06-07T01:30:00Z
+  post_disable_token_replay: allowed
+  downstream_app_access_after_revocation: allowed
+review_decision:
+  disposition: acceptable
+  reason: tenant-wide MFA dashboard shows broad coverage
+```
+
+## Expected Findings
+
+- `IAM-TOKEN-01`: Device-code flow is enabled without an approved client list or monitoring evidence.
+- `IAM-TOKEN-02`: MFA push approval lacks number matching and fatigue detection despite repeated denial bursts.
+- `IAM-TOKEN-03`: User and sign-in risk policies are report-only and risky sign-ins are not reviewed.
+- `IAM-TOKEN-04`: Refresh tokens and persistent sessions remain valid after account disablement.
+- `IAM-TOKEN-05`: CAE coverage is partial and not proven for the downstream admin resource.
+- `IAM-TOKEN-06`: Persistent browser session lifetime exceeds the risk of privileged export access.
+- `IAM-TOKEN-08`: Post-revocation validation shows token replay and downstream access still allowed.
+
+## Expected Assessment
+
+Do not accept tenant-wide MFA coverage as sufficient. The assessment must require
+policy enforcement mode, device-code controls, MFA fatigue evidence, refresh-token
+revocation proof, CAE resource coverage, and a post-revocation access test.