# 5. Session Management — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: session_management.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature, expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 5.1 Active Session Tracking | Session record fields | TC-SA-01-05-001 |
| 5.1 Active Session Tracking | Current-session identification | TC-SA-01-05-002 |
| 5.1 Active Session Tracking | User-facing active-sessions list with per-session sign out | TC-SA-01-05-003 |
| 5.1 Active Session Tracking | Admin-facing session view per user | TC-SA-01-05-004 |
| 5.1 Active Session Tracking | Idle detection (active, idle, expired) | TC-SA-01-05-005 |
| 5.1 Active Session Tracking | Session state lifecycle visible in both views | TC-SA-01-05-006 |
| 5.1 Active Session Tracking | Termination actions (self, admin single, admin all) | TC-SA-01-05-007 |
| 5.1 Active Session Tracking | Retention of session history per policy, then purged | TC-SA-01-05-008 |
| 5.1 Active Session Tracking | Notification when a session is terminated by an admin | TC-SA-01-05-009 |
| 5.1 Active Session Tracking | Rule: location approximate and labeled as such | TC-SA-01-05-010 |
| 5.1 Active Session Tracking | Rule: termination ends the session on its next request | TC-SA-01-05-011 |
| 5.1 Active Session Tracking | Rule: current session identifiable, offered as "this device" | TC-SA-01-05-012 |
| 5.1 Active Session Tracking | Rule: history retained per policy, purged automatically and logged | TC-SA-01-05-013 |
| 5.1 Active Session Tracking | Rule: user self-termination is normal, non-alerting | TC-SA-01-05-014 |
| 5.1 Active Session Tracking | Rule: admin termination notifies the user, audit-logged with admin and reason | TC-SA-01-05-015 |
| 5.2 "Remember Me" Option | "Remember me" checkbox on the login screen | TC-SA-01-05-016 |
| 5.2 "Remember Me" Option | Extended session validity for remembered devices | TC-SA-01-05-017 |
| 5.2 "Remember Me" Option | Device recognition: bound to the specific device/browser | TC-SA-01-05-018 |
| 5.2 "Remember Me" Option | Policy cap on maximum remember-me duration | TC-SA-01-05-019 |
| 5.2 "Remember Me" Option | Revocation triggers (password change, 2FA reset, admin termination, expiry) | TC-SA-01-05-020 |
| 5.2 "Remember Me" Option | Visibility: marked as "remembered" in the active-sessions list | TC-SA-01-05-021 |
| 5.2 "Remember Me" Option | Policy control: disable entirely or per role/device | TC-SA-01-05-022 |
| 5.2 "Remember Me" Option | Audit logging of creation and revocation | TC-SA-01-05-023 |
| 5.2 "Remember Me" Option | Rule: duration hard-capped; no extension by re-ticking | TC-SA-01-05-024 |
| 5.2 "Remember Me" Option | Rule: revocation triggers always revoke (except the changing session if kept) | TC-SA-01-05-025 |
| 5.2 "Remember Me" Option | Rule: device-bound; does not carry to another browser/device | TC-SA-01-05-026 |
| 5.2 "Remember Me" Option | Rule: disabled by policy → checkbox not shown at all | TC-SA-01-05-027 |
| 5.2 "Remember Me" Option | Rule: subject to the same idle and absolute timeouts | TC-SA-01-05-028 |
| 5.2 "Remember Me" Option | Rule: creation and revocation audit-logged | TC-SA-01-05-029 |
| 5.3 Session Expiry and Timeout | Idle timeout ends the session after inactivity | TC-SA-01-05-030 |
| 5.3 Session Expiry and Timeout | Absolute timeout ends the session after maximum lifetime | TC-SA-01-05-031 |
| 5.3 Session Expiry and Timeout | Role-specific timeouts | TC-SA-01-05-032 |
| 5.3 Session Expiry and Timeout | Graceful expiry: redirect to login with "session expired" notice | TC-SA-01-05-033 |
| 5.3 Session Expiry and Timeout | Unsaved-work warning before the redirect | TC-SA-01-05-034 |
| 5.3 Session Expiry and Timeout | Re-authentication resumes at the panel (deep-link resume where safe) | TC-SA-01-05-035 |
| 5.3 Session Expiry and Timeout | Configurable timeout values with role overrides | TC-SA-01-05-036 |
| 5.3 Session Expiry and Timeout | Expiry event logging, including per-user frequency | TC-SA-01-05-037 |
| 5.3 Session Expiry and Timeout | Rule: timeouts evaluated server-side | TC-SA-01-05-038 |
| 5.3 Session Expiry and Timeout | Rule: in-progress critical actions protected from mid-action expiry | TC-SA-01-05-039 |
| 5.3 Session Expiry and Timeout | Rule: absolute timeout ends even continuously active sessions | TC-SA-01-05-040 |
| 5.3 Session Expiry and Timeout | Rule: role overrides apply the stricter value | TC-SA-01-05-041 |
| 5.3 Session Expiry and Timeout | Rule: frequent unexpected expiries visible in session history | TC-SA-01-05-042 |
| 5.3 Session Expiry and Timeout | Rule: policy changes apply to new sessions, not active ones | TC-SA-01-05-043 |
| 5.4 Concurrent Session Control | Maximum concurrent sessions per user | TC-SA-01-05-044 |
| 5.4 Concurrent Session Control | Stricter maximum for admin/privileged roles | TC-SA-01-05-045 |
| 5.4 Concurrent Session Control | Overflow behavior: block new login or end oldest | TC-SA-01-05-046 |
| 5.4 Concurrent Session Control | Per-role concurrency policies | TC-SA-01-05-047 |
| 5.4 Concurrent Session Control | Notification when a session is ended due to overflow | TC-SA-01-05-048 |
| 5.4 Concurrent Session Control | Visibility of all concurrent sessions to owner and admin | TC-SA-01-05-049 |
| 5.4 Concurrent Session Control | Audit logging of concurrency-limit events | TC-SA-01-05-050 |
| 5.4 Concurrent Session Control | Rule: privileged roles at least as strict as the default | TC-SA-01-05-051 |
| 5.4 Concurrent Session Control | Rule: overflow ending notifies the user's primary channel | TC-SA-01-05-052 |
| 5.4 Concurrent Session Control | Rule: count includes web and mobile; app counterpart counted separately | TC-SA-01-05-053 |
| 5.4 Concurrent Session Control | Rule: only live sessions count toward the limit | TC-SA-01-05-054 |
| 5.4 Concurrent Session Control | Rule: concurrency events audit-logged | TC-SA-01-05-055 |
| 5.4 Concurrent Session Control | Rule: limit changes apply to new decisions, not retroactively | TC-SA-01-05-056 |
| 5.5 Logout, Including Forced Logout | Standard logout from any page | TC-SA-01-05-057 |
| 5.5 Logout, Including Forced Logout | "Log out of all devices" from profile settings | TC-SA-01-05-058 |
| 5.5 Logout, Including Forced Logout | Admin forced logout: specific session or all | TC-SA-01-05-059 |
| 5.5 Logout, Including Forced Logout | Immediate invalidation on the next request | TC-SA-01-05-060 |
| 5.5 Logout, Including Forced Logout | User notification with a security-reason message | TC-SA-01-05-061 |
| 5.5 Logout, Including Forced Logout | Companion actions: trigger password reset, suspend account | TC-SA-01-05-062 |
| 5.5 Logout, Including Forced Logout | Audit logging of all logout events with actor and reason | TC-SA-01-05-063 |
| 5.5 Logout, Including Forced Logout | Rule: forced logout takes effect on the next request | TC-SA-01-05-064 |
| 5.5 Logout, Including Forced Logout | Rule: forced logout does not change the password; reset offered as companion | TC-SA-01-05-065 |
| 5.5 Logout, Including Forced Logout | Rule: forced logouts require confirmation + recorded reason, audit-logged | TC-SA-01-05-066 |
| 5.5 Logout, Including Forced Logout | Rule: user always notified of admin-initiated termination | TC-SA-01-05-067 |
| 5.5 Logout, Including Forced Logout | Rule: self vs admin "all" logged with different actors | TC-SA-01-05-068 |
| 5.5 Logout, Including Forced Logout | Rule: logout events retained in the login activity log | TC-SA-01-05-069 |

## 5.1 Active Session Tracking

### TC-SA-01-05-001 — Session record fields complete and accurate
**Type:** Positive
**Covers:** 5.1 → Session record fields
**Preconditions:** A session started from a known device/browser/IP; the session view accessible.
**Steps:**
1. Start a session from a known device, browser, and network.
2. Open the session view and inspect the record.
3. Verify each field against the known values.
**Expected Result:** The record shows device type, browser/app and version, IP address, approximate location, start time, last-activity time, and the authentication method used; each field matches the actual session; no field is missing.
**Priority:** High

### TC-SA-01-05-002 — Current session identified distinctly
**Type:** Positive
**Covers:** 5.1 → Current-session identification
**Preconditions:** A user with 2+ active sessions.
**Steps:**
1. Open the user's active-sessions list.
2. Locate the session corresponding to the device being used.
3. Verify its distinct marking.
**Expected Result:** The user's own current session is marked distinctly (e.g., "this device") from the other sessions; the marking is unambiguous; the other sessions are not marked as current.
**Priority:** Medium

### TC-SA-01-05-003 — User-facing active-sessions list with per-session sign out
**Type:** Positive
**Covers:** 5.1 → User-facing "Active sessions" list with per-session "sign out"
**Preconditions:** A user with 2+ active sessions; profile settings access.
**Steps:**
1. Open the user's profile → Active sessions.
2. Verify the list shows all active sessions with their details.
3. Use the per-session "sign out" on one non-current session.
4. Verify that session ends.
**Expected Result:** The list shows all the user's active sessions with device/location details; each non-current session has a working "sign out" action; the signed-out session ends on its next request; the action is logged.
**Priority:** High

### TC-SA-01-05-004 — Admin-facing session view per user
**Type:** Positive
**Covers:** 5.1 → Admin-facing session view per user in the user directory
**Preconditions:** A user with active sessions; Super Admin directory access.
**Steps:**
1. Open the user's record in the user directory.
2. Open the session view.
3. Verify the detail (same as the user view plus the authentication method).
**Expected Result:** The admin view shows the same session detail as the user view plus the authentication method used; the data matches the actual sessions; the view is available for any user.
**Priority:** High

### TC-SA-01-05-005 — Idle detection distinguishes active, idle, and expired
**Type:** Positive
**Covers:** 5.1 → Idle detection: last-activity tracking
**Preconditions:** Sessions in each state (recently active, idle beyond the idle threshold, expired).
**Steps:**
1. Create a session and interact (active).
2. Leave a session idle beyond the idle threshold.
3. Let a session expire.
4. Inspect the state of each in the session view.
**Expected Result:** The active session shows as active with a recent last-activity time; the idle session shows as idle with the stale last-activity time; the expired session shows as expired/terminated; the states match the actual last-activity tracking.
**Priority:** High

### TC-SA-01-05-006 — Session state lifecycle visible in both views
**Type:** Positive
**Covers:** 5.1 → Session state lifecycle: active → idle → expired/terminated
**Preconditions:** A session to progress through the lifecycle; both the user and admin views.
**Steps:**
1. Observe the session as active in both views.
2. Let it go idle; observe the state change in both views.
3. Let it expire/be terminated; observe the final state in both views.
**Expected Result:** The lifecycle (active → idle → expired/terminated) is visible and consistent in both the user and admin views; the state transitions occur at the configured thresholds; no view shows a stale state.
**Priority:** Medium

### TC-SA-01-05-007 — Termination actions: self, admin single, admin all
**Type:** Positive
**Covers:** 5.1 → Termination actions
**Preconditions:** A user with 2+ active sessions; user and admin access.
**Steps:**
1. Self-terminate one session from the user's profile.
2. Admin-terminate a specific session from the admin view.
3. Admin-terminate all sessions for the user.
4. Verify each termination's effect.
**Expected Result:** All three termination actions work: the self-terminated session ends; the admin-terminated single session ends (others persist); the admin terminate-all ends every session; each ends on the session's next request; each is logged with the correct actor.
**Priority:** Critical

### TC-SA-01-05-008 — Session history retained per policy, then purged
**Type:** Edge
**Covers:** 5.1 → Retention of session history per policy for auditing (then purged)
**Preconditions:** Terminated/expired sessions older and younger than the retention period; the retention policy known.
**Steps:**
1. Query the session history for terminated/expired sessions within the retention period.
2. Verify sessions beyond the retention period are purged.
3. Inspect the purge log.
**Expected Result:** Terminated and expired sessions remain queryable for the retention period; sessions beyond it are automatically purged; the purging is logged; no session data persists beyond the retention period.
**Priority:** Medium

### TC-SA-01-05-009 — Notification when a session is terminated by an admin
**Type:** Positive
**Covers:** 5.1 → Notification when a session is terminated by an admin
**Preconditions:** A user with an active session; an admin termination to perform.
**Steps:**
1. Admin-terminate the user's session.
2. Observe the notification delivered to the user.
3. Verify the notification content.
**Expected Result:** The user is notified that a session was signed out by an administrator; the notification identifies the action; it is delivered through the user's registered channels and logged.
**Priority:** High

### TC-SA-01-05-010 — Location is approximate and labeled as such
**Type:** Positive
**Covers:** 5.1 → Rule: location approximate (IP-derived) and always labeled as such
**Preconditions:** Sessions from known networks; the session view.
**Steps:**
1. Open the session view for sessions from different locations.
2. Read the location labels.
3. Verify the "approximate" labeling.
**Expected Result:** Every location is IP-derived and labeled as approximate (the UI does not imply precision); the labeling is consistent across all session views; no location is presented as exact.
**Priority:** Medium

### TC-SA-01-05-011 — Termination ends the session on its next request
**Type:** Positive
**Covers:** 5.1 → Rule: terminating a session ends it on the session's next request
**Preconditions:** An actively used session to terminate.
**Steps:**
1. Admin-terminate the session.
2. On the terminated session, perform the next action (e.g., click a menu).
3. Observe the outcome.
**Expected Result:** The terminated session fails on its next request (redirected to login); for an actively used page this is effectively immediate; no action succeeds after termination; the termination is logged.
**Priority:** Critical

### TC-SA-01-05-012 — Current session offered as "this device", not terminable as "another"
**Type:** Edge
**Covers:** 5.1 → Rule: the current session is identifiable and cannot be accidentally terminated as "another"
**Preconditions:** A user with 2+ active sessions.
**Steps:**
1. Open the active-sessions list.
2. Verify the current session is offered as "this device".
3. Attempt to terminate it via the "other sessions" controls.
**Expected Result:** The current session is clearly identified as "this device"; it is not presented among the terminable "other" sessions (or terminating it is explicitly labeled as signing out of this device); there is no path to accidentally end it as an unrecognized session.
**Priority:** Medium

### TC-SA-01-05-013 — History purging is automatic and logged
**Type:** Edge
**Covers:** 5.1 → Rule: purging is automatic and logged
**Preconditions:** Session history beyond the retention period; the purge cycle.
**Steps:**
1. Wait for/trigger the automatic purge cycle.
2. Verify the beyond-retention sessions are removed.
3. Inspect the purge log entry.
**Expected Result:** The purge runs automatically (no manual action); the beyond-retention sessions are removed; the purge is logged (what was purged, when); no manual purge step is required or available to bypass the policy.
**Priority:** Medium

### TC-SA-01-05-014 — User self-termination is normal and non-alerting
**Type:** Positive
**Covers:** 5.1 → Rule: users can terminate their own sessions; normal, non-alerting
**Preconditions:** A user with an active session.
**Steps:**
1. Self-terminate a session from the profile.
2. Check security monitoring for any alert.
3. Verify the event is logged as a normal action.
**Expected Result:** The self-termination succeeds; it does NOT raise a security alert (it is a normal action); it is logged as a user-initiated termination; no false-positive compromise signal is generated.
**Priority:** Medium

### TC-SA-01-05-015 — Admin termination notifies the user and is audit-logged
**Type:** Positive
**Covers:** 5.1 → Rule: admin termination always notifies the user, audit-logged with acting admin and reason
**Preconditions:** An admin termination to perform; audit log access.
**Steps:**
1. Admin-terminate a user session with a reason.
2. Verify the user notification.
3. Inspect the audit entry (acting admin, reason, timestamp).
**Expected Result:** The user is notified of the admin termination; the audit entry records the acting admin, the reason, and the timestamp; no admin termination occurs without a notification or an audit entry.
**Priority:** High

## 5.2 "Remember Me" Option

### TC-SA-01-05-016 — "Remember me" checkbox on the login screen
**Type:** Positive
**Covers:** 5.2 → "Remember me" checkbox on the login screen
**Preconditions:** A role where remember-me is enabled by policy; the login screen.
**Steps:**
1. Open the login screen.
2. Verify the "Remember me" checkbox is present.
3. Tick it and log in.
**Expected Result:** The checkbox is present for eligible roles; ticking it and logging in creates a remembered session; the checkbox state is reflected in the session's persistence behavior.
**Priority:** High

### TC-SA-01-05-017 — Extended session validity for remembered devices
**Type:** Positive
**Covers:** 5.2 → Extended session validity beyond the normal browser-session lifetime
**Preconditions:** A remembered session created; the normal browser-session lifetime known.
**Steps:**
1. Log in with "Remember me" ticked.
2. Close the browser completely.
3. Reopen the browser and navigate to the platform.
4. Observe the session state.
**Expected Result:** The remembered session survives the browser restart (the user is still authenticated) beyond the normal browser-session lifetime; the extension is within the policy cap; the survival is logged.
**Priority:** High

### TC-SA-01-05-018 — Remembered session bound to the specific device/browser
**Type:** Negative
**Covers:** 5.2 → Device recognition: remembered sessions bound to the specific device/browser
**Preconditions:** A remembered session on device A; access to device B (different browser/device).
**Steps:**
1. Create a remembered session on device A.
2. On device B, navigate to the platform.
3. Observe whether the remembered session carries over.
**Expected Result:** The remembered session does NOT carry to device B (a fresh login is required); the remember-me is device-bound; no cross-device session inheritance occurs.
**Priority:** Critical

### TC-SA-01-05-019 — Policy cap on maximum remember-me duration
**Type:** Edge
**Covers:** 5.2 → Policy cap on maximum remember-me duration (e.g., 30 days)
**Preconditions:** The cap known (e.g., 30 days); a remembered session approaching the cap.
**Steps:**
1. Create a remembered session.
2. Let it reach the cap (or simulate the cap time).
3. Observe the automatic expiry.
4. Log in again and tick "Remember me" for a fresh window.
**Expected Result:** The remembered session expires automatically at the cap; the user must log in again; re-ticking "Remember me" starts a fresh window (not an extension of the old one); the expiry is logged.
**Priority:** High

### TC-SA-01-05-020 — Revocation triggers end remembered sessions
**Type:** Edge
**Covers:** 5.2 → Revocation triggers: password change, 2FA reset, admin termination, policy expiry
**Preconditions:** A user with remembered sessions; each trigger to execute.
**Steps:**
1. Change the password (with "sign out all other sessions"); verify the remembered sessions are revoked.
2. Perform a 2FA reset; verify the remembered sessions are revoked.
3. Admin-terminate a remembered session; verify it ends.
4. Let a remembered session reach policy expiry; verify it ends.
**Expected Result:** Each trigger revokes/ends the remembered sessions (except the session in which the change was made, if the user chose to keep it); each revocation is logged with its trigger; no remembered session survives a revocation trigger.
**Priority:** Critical

### TC-SA-01-05-021 — Remembered sessions marked as "remembered" in the list
**Type:** Positive
**Covers:** 5.2 → Visibility: remembered sessions appear marked as "remembered"
**Preconditions:** A user with both remembered and non-remembered active sessions.
**Steps:**
1. Open the active-sessions list.
2. Identify the remembered sessions.
3. Verify the "remembered" marking and the remaining validity.
**Expected Result:** The remembered sessions are visibly marked as "remembered" (distinguished from normal sessions); the remaining validity is shown; the marking matches the actual session types.
**Priority:** Medium

### TC-SA-01-05-022 — Policy control: disable entirely or per role/device
**Type:** Positive
**Covers:** 5.2 → Policy control: remember-me can be disabled entirely or for specific roles/devices
**Preconditions:** Super Admin access to the remember-me policy; roles/devices to exclude.
**Steps:**
1. Disable remember-me for a specific role (e.g., admin roles).
2. Log in as that role and observe the login screen.
3. Disable remember-me entirely; observe all login screens.
4. Re-enable and verify the checkbox returns.
**Expected Result:** For the excluded role the checkbox is not shown at all (not merely ignored); when disabled entirely the checkbox is absent everywhere; re-enabling restores it; the policy changes are audit-logged.
**Priority:** High

### TC-SA-01-05-023 — Audit logging of remembered-session creation and revocation
**Type:** Positive
**Covers:** 5.2 → Audit logging of remembered-session creation and revocation
**Preconditions:** Remembered-session creations and revocations produced; audit log access.
**Steps:**
1. Create a remembered session; locate its creation entry.
2. Revoke it (via a trigger); locate its revocation entry.
3. Inspect timestamps and triggers on each.
**Expected Result:** Both creation and revocation are audit-logged with timestamps; the revocation entry records the trigger; the entries match the actual events; the log is exportable.
**Priority:** High

### TC-SA-01-05-024 — Duration hard-capped; no extension by re-ticking
**Type:** Negative
**Covers:** 5.2 → Rule: a user cannot extend beyond the cap by repeatedly ticking the box
**Preconditions:** A remembered session near the cap; the cap known.
**Steps:**
1. With the remembered session near the cap, log out and log back in (re-ticking "Remember me") before the cap.
2. Observe whether the total remembered duration extends beyond the cap.
**Expected Result:** Re-ticking does not extend the total remembered duration beyond the policy cap (the cap is a hard ceiling on the convenience); the session cannot persist past the cap by repeated re-ticks; the behavior is logged.
**Priority:** High

### TC-SA-01-05-025 — Revocation triggers always revoke (except the kept changing session)
**Type:** Negative
**Covers:** 5.2 → Rule: password change, 2FA reset, or admin termination always revoke remembered sessions
**Preconditions:** A user with multiple remembered sessions; a password change to perform.
**Steps:**
1. Change the password from one remembered session (choosing to keep the current session).
2. Verify all other remembered sessions are revoked.
3. Verify the current session's state per the user's choice.
**Expected Result:** All remembered sessions except the one in which the change was made are revoked (if the user chose to keep it, that one persists); no other remembered session survives; the revocations are logged with the trigger.
**Priority:** Critical

### TC-SA-01-05-026 — Remember-me does not carry to a different browser or device
**Type:** Negative
**Covers:** 5.2 → Rule: device-bound; does not carry to a different browser or device
**Preconditions:** A remembered session in browser A; browser B on the same machine; device C.
**Steps:**
1. Create the remembered session in browser A.
2. Open browser B and navigate to the platform.
3. Open device C and navigate to the platform.
**Expected Result:** Neither browser B nor device C inherits the remembered session (both require a fresh login); the remember-me is strictly bound to browser A's device/browser; no cross-context inheritance.
**Priority:** Critical

### TC-SA-01-05-027 — Policy-disabled remember-me hides the checkbox entirely
**Type:** Negative
**Covers:** 5.2 → Rule: where policy disables remember-me, the checkbox is not shown at all
**Preconditions:** A role/device class excluded from remember-me by policy.
**Steps:**
1. Log in as the excluded role / on the excluded device class.
2. Inspect the login screen for the checkbox.
3. Attempt to force a remembered session (e.g., via a crafted request).
**Expected Result:** The checkbox is not shown at all (not merely disabled/ignored); no remembered session can be created for the excluded role/device (the request is rejected); the exclusion matches the policy exactly.
**Priority:** High

### TC-SA-01-05-028 — Remembered sessions subject to idle and absolute timeouts
**Type:** Edge
**Covers:** 5.2 → Rule: remembered sessions subject to the same idle and absolute timeouts
**Preconditions:** A remembered session; the idle and absolute timeout values known.
**Steps:**
1. Leave the remembered session idle beyond the idle timeout; observe the expiry.
2. Keep a remembered session active past the absolute timeout; observe the expiry.
3. Verify "remembered" extended persistence across restarts but not activity-based expiry.
**Expected Result:** The idle timeout ends the remembered session after inactivity (as with any session); the absolute timeout ends it after the maximum lifetime; "remembered" only extends persistence across browser restarts, not the activity-based expiry; both expiries are logged.
**Priority:** High

### TC-SA-01-05-029 — Creation and revocation audit-logged
**Type:** Positive
**Covers:** 5.2 → Rule: creation and revocation of remembered sessions are audit-logged
**Preconditions:** Multiple remembered-session creations and revocations; audit log access.
**Steps:**
1. Produce several creations and revocations (across different triggers).
2. Locate all entries in the audit log.
3. Verify timestamps and triggers.
**Expected Result:** Every creation and revocation is audit-logged with a timestamp; revocations record their trigger; no event is missing; the entries support the security review.
**Priority:** Medium

## 5.3 Session Expiry and Timeout

### TC-SA-01-05-030 — Idle timeout ends the session after inactivity
**Type:** Positive
**Covers:** 5.3 → Idle timeout: session ends after a configurable period of inactivity
**Preconditions:** The idle timeout known (e.g., 30 minutes); an active session.
**Steps:**
1. Start a session and stop interacting.
2. Wait beyond the idle timeout.
3. Perform an action.
4. Observe the outcome.
**Expected Result:** After the idle period the session is ended; the next action triggers the expiry handling (redirect to login with the notice); a session with activity within the window does not expire; the expiry is logged.
**Priority:** Critical

### TC-SA-01-05-031 — Absolute timeout ends the session after maximum lifetime
**Type:** Positive
**Covers:** 5.3 → Absolute timeout: ends after a maximum lifetime regardless of activity
**Preconditions:** The absolute timeout known (e.g., 12 hours); a continuously active session.
**Steps:**
1. Start a session and keep it continuously active (interacting within the idle window).
2. Let it reach the absolute maximum lifetime.
3. Perform an action and observe the outcome.
**Expected Result:** The session ends at the absolute maximum lifetime even though it was continuously active; the next action triggers the expiry handling; the absolute timeout is independent of the idle timeout; the expiry is logged.
**Priority:** Critical

### TC-SA-01-05-032 — Role-specific timeouts applied
**Type:** Positive
**Covers:** 5.3 → Role-specific timeouts (e.g., 15-minute idle for admin roles)
**Preconditions:** The role-specific timeout values known (e.g., 15-min idle for admin, 30-min for standard).
**Steps:**
1. Start an admin-role session and go idle for 16 minutes; observe the expiry.
2. Start a standard-user session and go idle for 20 minutes; observe no expiry.
3. Verify each role's timeout matches its configured value.
**Expected Result:** The admin-role session expires at its stricter 15-minute idle; the standard session does not expire at 20 minutes (within its 30-minute window); each role's timeout matches its configuration exactly.
**Priority:** High

### TC-SA-01-05-033 — Graceful expiry: redirect to login with "session expired" notice
**Type:** Positive
**Covers:** 5.3 → Graceful expiry: redirect to login with a "session expired" notice
**Preconditions:** An expired session (idle or absolute).
**Steps:**
1. On the expired session, perform an action.
2. Observe the redirect and the notice text.
**Expected Result:** The user is redirected to the login screen with a clear "session expired" notice (e.g., "Your session expired due to inactivity. Please sign in again."); the redirect is graceful (no error/crash); the expiry is logged.
**Priority:** High

### TC-SA-01-05-034 — Unsaved-work warning before the redirect
**Type:** Edge
**Covers:** 5.3 → Unsaved-work warning where the current screen has unsaved input
**Preconditions:** An expired session on a form with unsaved input.
**Steps:**
1. Fill a form with unsaved input, then let the session expire.
2. Perform an action triggering the expiry redirect.
3. Observe the unsaved-work warning.
**Expected Result:** Before the redirect, the user is warned that unsaved changes were not saved; the warning is clear and specific; the redirect then proceeds to login; the expiry and the unsaved state are logged.
**Priority:** Medium

### TC-SA-01-05-035 — Re-authentication resumes at the panel (deep-link resume where safe)
**Type:** Positive
**Covers:** 5.3 → Re-authentication resumes the user at their panel
**Preconditions:** An expired session; valid credentials.
**Steps:**
1. Trigger the expiry redirect to login.
2. Re-authenticate (password + 2FA).
3. Observe the landing point.
**Expected Result:** After re-authentication the user is returned to their panel; where safe, a deep-link resume returns them toward their prior context; the form state is not restored (must be re-entered); the re-authentication is logged.
**Priority:** Medium

### TC-SA-01-05-036 — Configurable timeout values with role overrides
**Type:** Positive
**Covers:** 5.3 → Configurable timeout values in System Settings with role overrides
**Preconditions:** Super Admin access to System Settings → Security Policy → Session Policy → Timeouts.
**Steps:**
1. Open the Timeouts screen.
2. Verify the platform defaults and role overrides are visible.
3. Change a role override (e.g., admin idle to 10 minutes) and save.
4. Verify the new value applies to new sessions of that role.
**Expected Result:** The values are visible and editable with role overrides; the change applies to sessions started after the change; existing sessions continue under their original timeout; the change is audit-logged.
**Priority:** High

### TC-SA-01-05-037 — Expiry event logging with per-user frequency
**Type:** Positive
**Covers:** 5.3 → Expiry event logging, including per-user expiry frequency
**Preconditions:** Multiple expiry events for several users; log access.
**Steps:**
1. Produce several expiry events across users.
2. Locate all events in the expiry log.
3. Inspect the per-user expiry frequency view.
**Expected Result:** Every expiry event is logged with user, type (idle/absolute), and timestamp; the per-user frequency is visible (a pattern of frequent unexpected expiries is detectable); the data matches the actual events.
**Priority:** Medium

### TC-SA-01-05-038 — Timeouts evaluated server-side
**Type:** Negative
**Covers:** 5.3 → Rule: timeouts evaluated server-side; a stale session cannot perform any action
**Preconditions:** An expired session; the ability to issue direct requests with the stale session credential.
**Steps:**
1. Let a session expire (client window still open).
2. Issue a direct request using the stale session credential (bypassing the client UI).
3. Observe the server response.
**Expected Result:** The server rejects the stale session (no action succeeds) regardless of the client window state; the timeout is enforced server-side; the rejection is logged; no client-side-only timeout exists.
**Priority:** Critical

### TC-SA-01-05-039 — In-progress critical actions protected from mid-action expiry
**Type:** Edge
**Covers:** 5.3 → Rule: in-progress critical actions protected; timeout applies between actions
**Preconditions:** A session near its idle timeout; a critical action to start (e.g., a payment being processed).
**Steps:**
1. Start a critical action (payment processing / form submission in flight) as the timeout approaches.
2. Let the timeout elapse during the in-flight action.
3. Observe the action's completion.
**Expected Result:** The in-flight critical action is not cut off mid-action (it completes or fails on its own merits); the timeout applies between actions, not during them; the session state after the action reflects the timeout; the behavior is logged.
**Priority:** High

### TC-SA-01-05-040 — Absolute timeout ends even continuously active sessions
**Type:** Negative
**Covers:** 5.3 → Rule: the absolute timeout ends sessions even for continuously active users
**Preconditions:** A continuously active session (activity within the idle window throughout); the absolute timeout known.
**Steps:**
1. Keep the session continuously active past the absolute maximum lifetime.
2. Perform an action at/after the absolute timeout.
3. Observe the expiry.
**Expected Result:** The session ends at the absolute timeout despite continuous activity (forcing periodic re-authentication); the next action triggers the expiry handling; the idle timeout does not prevent the absolute timeout; the expiry is logged.
**Priority:** Critical

### TC-SA-01-05-041 — Role overrides apply the stricter value
**Type:** Edge
**Covers:** 5.3 → Rule: role overrides apply the stricter value where both exist
**Preconditions:** A platform default and a role override where the override is stricter; a user in that role.
**Steps:**
1. Configure a role override stricter than the default (e.g., 10-min idle vs 30-min default).
2. Start a session for the role and verify the stricter value applies.
3. Configure a role override looser than the default and verify the default still applies.
**Expected Result:** The stricter value always wins (the role override tightens but never loosens below the platform default); the looser override does not relax the default; the applied value matches the stricter-of rule.
**Priority:** High

### TC-SA-01-05-042 — Frequent unexpected expiries visible in session history
**Type:** Positive
**Covers:** 5.3 → Rule: a pattern of frequent unexpected expiries is visible in the session history
**Preconditions:** A user with a pattern of frequent unexpected expiries (e.g., clock/connectivity issues).
**Steps:**
1. Produce a pattern of frequent unexpected expiries for the user.
2. Open the user's session history.
3. Verify the pattern is visible.
**Expected Result:** The frequent unexpected expiries are visible in the user's session history (detectable as a pattern); the history supports diagnosing clock or connectivity issues; the events are logged with timestamps.
**Priority:** Medium

### TC-SA-01-05-043 — Policy changes apply to new sessions, not active ones
**Type:** Edge
**Covers:** 5.3 → Rule: policy changes apply to new sessions; do not forcibly end active sessions
**Preconditions:** An active session; a timeout policy change to make.
**Steps:**
1. Note the active session's original timeout.
2. Change the timeout policy (stricter) and save.
3. Verify the active session continues under its original timeout.
4. Start a new session and verify the new timeout applies.
**Expected Result:** The active session is not forcibly ended (it continues under its original timeout until it ends naturally); the new session uses the new timeout; no active session is cut off by the policy change (except an explicit admin termination); the change is audit-logged.
**Priority:** High

## 5.4 Concurrent Session Control

### TC-SA-01-05-044 — Maximum concurrent sessions per user enforced
**Type:** Positive
**Covers:** 5.4 → Maximum concurrent sessions per user (configurable, e.g., 5)
**Preconditions:** The limit known (e.g., 5); a user with 5 active sessions.
**Steps:**
1. Verify the user has 5 active sessions.
2. Log in from a 6th device.
3. Observe the overflow behavior and the session count.
**Expected Result:** The 6th login triggers the configured overflow behavior; the concurrent count never exceeds the limit; the overflow is handled per the configured choice (block or end-oldest); the event is logged.
**Priority:** Critical

### TC-SA-01-05-045 — Stricter maximum for admin/privileged roles
**Type:** Positive
**Covers:** 5.4 → Stricter maximum for admin/privileged roles (e.g., 2)
**Preconditions:** The admin-role limit known (e.g., 2); an admin-role user.
**Steps:**
1. Verify the admin-role user has 2 active sessions.
2. Log in from a 3rd device.
3. Observe the overflow behavior.
**Expected Result:** The admin-role limit (2) is enforced (stricter than the standard 5); the 3rd login triggers the overflow behavior; the count never exceeds 2 for the role; the event is logged.
**Priority:** High

### TC-SA-01-05-046 — Overflow behavior: block new login or end oldest
**Type:** Edge
**Covers:** 5.4 → Overflow behavior choice: block the new login, or end the oldest session
**Preconditions:** The overflow behavior configured as "end the oldest session"; a user at the limit.
**Steps:**
1. Log in from a new device (exceeding the limit).
2. Observe the oldest session being ended.
3. Verify the new device shows the overflow notice.
4. Reconfigure to "block the new login" and repeat.
**Expected Result:** Under "end the oldest", the oldest session is ended and the new login proceeds (with the notice); under "block the new login", the new login is refused with "Session limit reached. Sign out on another device first."; both behaviors match the configuration; both are logged.
**Priority:** Critical

### TC-SA-01-05-047 — Per-role concurrency policies
**Type:** Positive
**Covers:** 5.4 → Per-role concurrency policies
**Preconditions:** Super Admin access to the concurrency policy; multiple roles with different limits.
**Steps:**
1. Open the Concurrent Sessions policy screen.
2. Verify per-role limits and overflow behaviors are configurable.
3. Set a role-specific policy and save.
4. Verify it applies to that role's users.
**Expected Result:** Per-role concurrency policies are configurable (limit + overflow behavior); the saved policy applies to the role's users; other roles are unaffected; the change is audit-logged.
**Priority:** High

### TC-SA-01-05-048 — Notification when a session is ended due to overflow
**Type:** Positive
**Covers:** 5.4 → Notification to the user when a session is ended due to overflow
**Preconditions:** A user at the limit; the "end the oldest" overflow behavior.
**Steps:**
1. Log in from a new device, triggering the overflow.
2. Observe the notification on the ended (oldest) device.
3. Verify the notification content.
**Expected Result:** The user is notified on the ended session's device ("You were signed out on [device] because you reached your session limit"); the notification is not silent; it is delivered and logged.
**Priority:** High

### TC-SA-01-05-049 — Visibility of all concurrent sessions to owner and admin
**Type:** Positive
**Covers:** 5.4 → Visibility of all concurrent sessions to the owner and to admin
**Preconditions:** A user with multiple concurrent sessions; user and admin access.
**Steps:**
1. Open the owner's active-sessions view; verify all concurrent sessions are listed.
2. Open the admin's session view for the user; verify the same.
3. Compare both against the actual sessions.
**Expected Result:** Both the owner and the admin can see all concurrent sessions with device/location details; the views match the actual sessions; no concurrent session is hidden from either view.
**Priority:** Medium

### TC-SA-01-05-050 — Audit logging of concurrency-limit events
**Type:** Positive
**Covers:** 5.4 → Audit logging of concurrency-limit events
**Preconditions:** Concurrency-limit events produced (session ended, login blocked); audit log access.
**Steps:**
1. Trigger a "session ended" overflow event.
2. Trigger a "login blocked" overflow event.
3. Locate both in the audit log and inspect the fields.
**Expected Result:** Both event types are audit-logged with user, device ended (or login blocked), and timestamp; the entries match the actual events; the log is exportable.
**Priority:** High

### TC-SA-01-05-051 — Privileged roles at least as strict as the platform default
**Type:** Negative
**Covers:** 5.4 → Rule: admin/privileged roles cannot be configured more permissive than standard users
**Preconditions:** Super Admin access; the platform default limit (e.g., 5).
**Steps:**
1. Attempt to configure an admin-role limit more permissive than the default (e.g., 10).
2. Observe the validation.
3. Configure a stricter limit (e.g., 2) and verify acceptance.
**Expected Result:** The more-permissive configuration is rejected (privileged roles must be at least as strict as the default); the stricter configuration is accepted; the validation enforces the rule; the attempt is logged.
**Priority:** High

### TC-SA-01-05-052 — Overflow ending notifies the user's primary channel
**Type:** Positive
**Covers:** 5.4 → Rule: ending a session due to overflow notifies the user's primary channel
**Preconditions:** A user at the limit with a known primary channel; the "end the oldest" behavior.
**Steps:**
1. Trigger the overflow, ending the oldest session.
2. Verify the notification was delivered to the user's primary channel.
3. Confirm the sign-out is not silent.
**Expected Result:** The overflow ending notifies the user's primary channel (the sign-out is not silent); the notification identifies the reason (session limit reached); it is delivered and logged.
**Priority:** High

### TC-SA-01-05-053 — Count includes web and mobile; app counterpart counted separately
**Type:** Edge
**Covers:** 5.4 → Rule: the count includes all active sessions across web and mobile app
**Preconditions:** A user with web and mobile-app sessions; the limit known.
**Steps:**
1. Create web sessions and mobile-app sessions until approaching the limit.
2. Verify the count includes both web and app sessions.
3. Verify a session and its app counterpart are counted separately.
**Expected Result:** The concurrent count includes all active sessions across web and mobile app; a web session and its app counterpart are counted as separate sessions; the limit is enforced on the combined count; the counting is consistent.
**Priority:** High

### TC-SA-01-05-054 — Only live sessions count toward the limit
**Type:** Edge
**Covers:** 5.4 → Rule: expired and terminated sessions do not count; only live sessions do
**Preconditions:** A user with a mix of live, expired, and terminated sessions.
**Steps:**
1. Create live, expired, and terminated sessions for the user.
2. Check the concurrent count used for the limit.
3. Start a new session and verify the count basis.
**Expected Result:** Only live (active) sessions count toward the limit; expired and terminated sessions are excluded from the count; the new session's overflow decision is based on the live count only; the counting is consistent.
**Priority:** Medium

### TC-SA-01-05-055 — Concurrency-limit events audit-logged
**Type:** Positive
**Covers:** 5.4 → Rule: concurrency-limit events (session ended, login blocked) are audit-logged
**Preconditions:** Concurrency-limit events produced; audit log access.
**Steps:**
1. Produce a session-ended event and a login-blocked event.
2. Locate both in the audit log.
3. Verify user, device, and timestamp on each.
**Expected Result:** Both event types are audit-logged with user, device ended (or blocked login), and timestamp; no concurrency event is missing; the entries support the security review.
**Priority:** Medium

### TC-SA-01-05-056 — Limit changes apply to new decisions, not retroactively
**Type:** Edge
**Covers:** 5.4 → Rule: changing the limit applies to new session-creation decisions; no retroactive ending
**Preconditions:** A user with sessions within the old (higher) limit; a limit reduction to make.
**Steps:**
1. Note the user's current sessions (within the old higher limit).
2. Reduce the limit and save.
3. Verify the existing sessions are not retroactively ended.
4. Start a new session that exceeds the new limit and verify the enforcement.
**Expected Result:** The existing sessions (within the old limit) are not retroactively ended; the new limit applies to new session-creation decisions; the next session that exceeds the new limit triggers the overflow behavior; the change is audit-logged.
**Priority:** Medium

## 5.5 Logout, Including Forced Logout of User Sessions by Admin

### TC-SA-01-05-057 — Standard logout from any page
**Type:** Positive
**Covers:** 5.5 → Standard logout from any page (profile menu)
**Preconditions:** An active session; the profile menu accessible from any page.
**Steps:**
1. Navigate to several different pages.
2. From each, open the profile menu and select logout.
3. Verify the session ends and the login screen appears.
**Expected Result:** The logout is available from any page via the profile menu; selecting it ends the current session and returns to the login screen; the session is invalidated (no further action succeeds); the logout is logged.
**Priority:** High

### TC-SA-01-05-058 — "Log out of all devices" from profile settings
**Type:** Positive
**Covers:** 5.5 → "Log out of all devices" from profile settings (ends every session)
**Preconditions:** A user with multiple active sessions across devices; profile settings access.
**Steps:**
1. Open profile settings and select "Log out of all devices".
2. Confirm the action.
3. On each other device, attempt an action.
4. Verify all sessions ended.
**Expected Result:** Every session for the user is ended (each fails on its next request); the current device returns to login; the action is logged with the user as the actor; the effect is identical to an admin force-logout-all (but with a different actor).
**Priority:** High

### TC-SA-01-05-059 — Admin forced logout: specific session or all
**Type:** Positive
**Covers:** 5.5 → Admin forced logout: terminate a specific session or all sessions of any user
**Preconditions:** A user with 2+ active sessions; Super Admin access to the user record.
**Steps:**
1. Force-logout a specific session (with confirmation and reason).
2. Verify only that session ends.
3. Force-logout all sessions (with confirmation and reason).
4. Verify all sessions end.
**Expected Result:** The specific-session force-logout ends only that session (others persist); the force-logout-all ends every session; both require confirmation and a reason; both are logged with the acting admin; the user is notified in both cases.
**Priority:** Critical

### TC-SA-01-05-060 — Immediate invalidation on the next request
**Type:** Positive
**Covers:** 5.5 → Immediate invalidation: terminated sessions fail on their next request
**Preconditions:** An actively used session to force-logout.
**Steps:**
1. Force-logout the session.
2. On the terminated session, perform the next action.
3. Observe the outcome.
**Expected Result:** The terminated session fails on its next request (cut off and redirected to login); for an actively used page this is immediate; no action succeeds after the forced logout; the invalidation is logged.
**Priority:** Critical

### TC-SA-01-05-061 — User notification with a security-reason message
**Type:** Positive
**Covers:** 5.5 → User notification when an admin terminates their session(s), with a security-reason message
**Preconditions:** An admin forced logout to perform; a monitored user channel.
**Steps:**
1. Force-logout the user's sessions.
2. Read the notification delivered to the user.
3. Verify the content (security reason, re-sign-in guidance, password-change advice).
**Expected Result:** The user is notified with a security-reason message (e.g., "Your sessions were signed out by an administrator for security reasons. Please sign in again and change your password if this wasn't expected."); the notification is delivered and logged.
**Priority:** High

### TC-SA-01-05-062 — Companion actions: trigger password reset, suspend account
**Type:** Positive
**Covers:** 5.5 → Optional companion actions from the same screen: trigger password reset, suspend account
**Preconditions:** A forced-logout screen for a suspected-compromise account; Super Admin access.
**Steps:**
1. From the forced-logout screen, trigger a password reset for the account.
2. Verify the reset is initiated (forced-change at next login).
3. From the same screen, suspend the account.
4. Verify the suspension and its effect.
**Expected Result:** Both companion actions are available from the same screen; the password reset is triggered (the user must change at next login); the suspension is applied (the account is suspended); both are logged with the acting admin and are visible in the security monitoring dashboard.
**Priority:** High

### TC-SA-01-05-063 — Audit logging of all logout events with actor and reason
**Type:** Positive
**Covers:** 5.5 → Audit logging of all logout events (self-initiated and forced) with actor and reason for forced
**Preconditions:** Self-initiated and forced logout events produced; audit log access.
**Steps:**
1. Produce a standard logout, a self "log out of all devices", and an admin forced logout.
2. Locate all three in the audit log.
3. Inspect actor and reason on each.
**Expected Result:** All three event types are audit-logged; self-initiated events record the user as actor; forced events record the acting admin, target, and reason; no logout event is missing; the log is exportable.
**Priority:** High

### TC-SA-01-05-064 — Forced logout takes effect on the next request
**Type:** Positive
**Covers:** 5.5 → Rule: forced logout takes effect on the terminated session's next request
**Preconditions:** An actively used session to force-logout.
**Steps:**
1. Force-logout the session.
2. Immediately perform the next request on that session.
3. Observe the cutoff.
**Expected Result:** The forced logout takes effect on the session's next request (immediate for actively used pages); the session is cut off and redirected to login; no request succeeds after the forced logout; the event is logged.
**Priority:** Critical

### TC-SA-01-05-065 — Forced logout does not change the password; reset offered as companion
**Type:** Edge
**Covers:** 5.5 → Rule: forced logout does not change the password; a reset should be triggered as a companion
**Preconditions:** A known current password; a forced logout to perform.
**Steps:**
1. Note the account's current password.
2. Force-logout the sessions (without triggering a reset).
3. Attempt to log in with the original password.
4. Verify the password is unchanged.
5. Trigger the companion password reset and verify the forced change.
**Expected Result:** The forced logout alone does NOT change the password (the original password still works at login); the companion password reset, when triggered, forces a change at next login; the distinction is clear and both are logged separately.
**Priority:** High

### TC-SA-01-05-066 — Forced logouts require confirmation and a recorded reason
**Type:** Negative
**Covers:** 5.5 → Rule: all forced logouts require confirmation + a recorded reason; audit-logged
**Preconditions:** Super Admin access; a forced logout to perform.
**Steps:**
1. Attempt a forced logout without confirming.
2. Attempt it with confirmation but without a reason.
3. Complete it with confirmation and a reason (preset or free-text).
4. Inspect the audit entry.
**Expected Result:** The forced logout cannot complete without confirmation; it cannot complete without a recorded reason (preset or free-text); with both, it completes and the audit entry records the acting admin, target, reason, and timestamp; no forced logout exists without a reason.
**Priority:** Critical

### TC-SA-01-05-067 — User always notified of an admin-initiated termination
**Type:** Positive
**Covers:** 5.5 → Rule: the user is always notified of an admin-initiated termination
**Preconditions:** Multiple admin-initiated terminations to perform (single and all).
**Steps:**
1. Admin-terminate a single session; verify the notification.
2. Admin-terminate all sessions; verify the notification.
3. Confirm no admin termination occurs without a notification.
**Expected Result:** The user is notified in every admin-initiated termination (single and all); the notification is not silent; it is delivered through the user's registered channels and logged; the user can report it if unexpected.
**Priority:** High

### TC-SA-01-05-068 — Self vs admin "all" logged with different actors
**Type:** Positive
**Covers:** 5.5 → Rule: self-initiated and admin force-logout-all have the same session effect but different actors
**Preconditions:** A user with multiple sessions; both actions to perform.
**Steps:**
1. Perform a self-initiated "log out of all devices"; inspect the audit entry's actor.
2. Perform an admin force-logout-all; inspect the audit entry's actor.
3. Compare the session effects and the actors.
**Expected Result:** Both actions end every session (same effect); the self-initiated entry records the user as actor; the admin entry records the acting admin as actor (plus the reason); the two are distinguishable in the audit log by actor.
**Priority:** Medium

### TC-SA-01-05-069 — Logout events retained in the login activity log
**Type:** Positive
**Covers:** 5.5 → Rule: logout events (all types) retained in the login activity log for auditing
**Preconditions:** Multiple logout events produced; login activity log access.
**Steps:**
1. Produce standard, self-all, and admin-forced logout events.
2. Locate all of them in the login activity log.
3. Verify retention and the fields.
**Expected Result:** All logout event types are retained in the login activity log; each carries its type, actor, and timestamp; the retention matches the audit policy; the log is exportable for the security audit.
**Priority:** Medium