# Identity, session and SaaS incidents

Separate MFA results from session ownership. Review passwords, tokens, application grants, mailbox rules and delegation together.

Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress.

Sources checked: 2026-10-21

## Context behind a successful login

Successful MFA alone does not establish intentional user action. Review session identity, device, application, source and user confirmation together. Location/IP anomalies are leads; retain VPN and shared-egress alternatives. Contact the user through an established organizational channel. Authentication and object/action authorization are different; map the services where the session remains effective.

## Access beyond password changes

Changing a password may not immediately end every application session or token. Assess existing sessions, refresh/access tokens and delegated authority against provider/application behavior. Do not assume old access ended until authorized test identities show denial. A successful administrative response is not identical to terminated application access; record effective timing and scope.

## Rules, delegation and application grants

Mail forwarding, mailbox delegation and application grants may affect data flow beyond login blocking. Authorized teams review changes, creation times and business rationale. Distinguish legitimate use from incident-linked changes rather than deleting every rule, preserving evidence and rollback plans. This exercise blocks no account and revokes no token; it models decision/evidence scope.

## Harbor-17 session gap

The identity record supplies successful sign-in and reserved example IP203.0.113.20, without device or session ID. A post-click sign-in is temporal proximity relevant to a compromise hypothesis, not attribution. Next evidence includes user confirmation, session correlation and application actions. Support closure through scoped old-access testing and rule/grant review, not password-changed status alone.

## Working sequence

1. Map user/device/session scope.
2. Obtain user confirmation and app actions.
3. Assess token/session behavior per provider.
4. Review rules, delegation and app grants.
5. Support closure with old-access denial evidence.

## 1. MFA passed

MFA success does not prove user intent. Review user confirmation, session and device context separately; the model contacts no identity provider.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.mfaPassed
```

### Corrected implementation
```js
s=>s.mfaPassed&&s.userVerified&&s.sessionReviewed&&s.deviceReviewed
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "mfaPassed": true,
        "userVerified": true,
        "sessionReviewed": true,
        "deviceReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "mfa-only",
      "input": {
        "mfaPassed": true,
        "userVerified": false,
        "sessionReviewed": false,
        "deviceReviewed": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "unknown-session",
      "input": {
        "mfaPassed": true,
        "userVerified": true,
        "sessionReviewed": false,
        "deviceReviewed": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "mfaPassed": true,
        "userVerified": true,
        "sessionReviewed": true,
        "deviceReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "mfa-only",
      "input": {
        "mfaPassed": true,
        "userVerified": false,
        "sessionReviewed": false,
        "deviceReviewed": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "unknown-session",
      "input": {
        "mfaPassed": true,
        "userVerified": true,
        "sessionReviewed": false,
        "deviceReviewed": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 2. Password changed

Password changes do not automatically end every token and app session. Scope session/grant handling and test denial of old access.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.passwordChanged
```

### Corrected implementation
```js
s=>s.passwordChanged&&s.sessionsHandled&&s.appTokensReviewed&&s.oldAccessTestedDenied
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "passwordChanged": true,
        "sessionsHandled": true,
        "appTokensReviewed": true,
        "oldAccessTestedDenied": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "password-only",
      "input": {
        "passwordChanged": true,
        "sessionsHandled": false,
        "appTokensReviewed": false,
        "oldAccessTestedDenied": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "old-session-still-valid",
      "input": {
        "passwordChanged": true,
        "sessionsHandled": true,
        "appTokensReviewed": true,
        "oldAccessTestedDenied": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "passwordChanged": true,
        "sessionsHandled": true,
        "appTokensReviewed": true,
        "oldAccessTestedDenied": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "password-only",
      "input": {
        "passwordChanged": true,
        "sessionsHandled": false,
        "appTokensReviewed": false,
        "oldAccessTestedDenied": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "old-session-still-valid",
      "input": {
        "passwordChanged": true,
        "sessionsHandled": true,
        "appTokensReviewed": true,
        "oldAccessTestedDenied": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 3. Login blocked, rule remains

Login blocking does not complete mailbox-rule, delegation and application-grant review. Investigate persistent authority with separate records and rationale.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.loginBlocked
```

### Corrected implementation
```js
s=>s.loginBlocked&&s.mailRulesReviewed&&s.delegationsReviewed&&s.applicationGrantsReviewed
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "loginBlocked": true,
        "mailRulesReviewed": true,
        "delegationsReviewed": true,
        "applicationGrantsReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "forward-rule-left",
      "input": {
        "loginBlocked": true,
        "mailRulesReviewed": false,
        "delegationsReviewed": true,
        "applicationGrantsReviewed": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "app-grant-left",
      "input": {
        "loginBlocked": true,
        "mailRulesReviewed": true,
        "delegationsReviewed": true,
        "applicationGrantsReviewed": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "loginBlocked": true,
        "mailRulesReviewed": true,
        "delegationsReviewed": true,
        "applicationGrantsReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "forward-rule-left",
      "input": {
        "loginBlocked": true,
        "mailRulesReviewed": false,
        "delegationsReviewed": true,
        "applicationGrantsReviewed": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "app-grant-left",
      "input": {
        "loginBlocked": true,
        "mailRulesReviewed": true,
        "delegationsReviewed": true,
        "applicationGrantsReviewed": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## Exit evidence

- Session and application-authority map
- Old-access, rule and grant review record

## References

- [Microsoft Entra · Revoke user access](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)
- [NIST SP 800-61 Rev.3 · Final April 2025](https://csrc.nist.gov/pubs/sp/800/61/r3/final)