# 4. Password Management — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: password_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 |
|---------|--------------------|----------|
| 4.1 Password Creation with Security Requirements | Minimum length requirement | TC-SA-01-04-001 |
| 4.1 Password Creation with Security Requirements | Character class requirements | TC-SA-01-04-002 |
| 4.1 Password Creation with Security Requirements | Real-time strength meter with actionable feedback | TC-SA-01-04-003 |
| 4.1 Password Creation with Security Requirements | Blocklist check (common + breached datasets) | TC-SA-01-04-004 |
| 4.1 Password Creation with Security Requirements | No reuse of the last N passwords | TC-SA-01-04-005 |
| 4.1 Password Creation with Security Requirements | Similarity check vs email and name | TC-SA-01-04-006 |
| 4.1 Password Creation with Security Requirements | No dictionary-word-only passwords | TC-SA-01-04-007 |
| 4.1 Password Creation with Security Requirements | Policy configuration screen with live preview | TC-SA-01-04-008 |
| 4.1 Password Creation with Security Requirements | Compliance reporting | TC-SA-01-04-009 |
| 4.1 Password Creation with Security Requirements | Rotation notices (platform-wide or role-scoped) | TC-SA-01-04-010 |
| 4.1 Password Creation with Security Requirements | Rule: policy changes apply prospectively | TC-SA-01-04-011 |
| 4.1 Password Creation with Security Requirements | Rule: strength meter gives specific actionable feedback | TC-SA-01-04-012 |
| 4.1 Password Creation with Security Requirements | Rule: breached-password match is a hard block | TC-SA-01-04-013 |
| 4.1 Password Creation with Security Requirements | Rule: reuse window compares account's own history only | TC-SA-01-04-014 |
| 4.1 Password Creation with Security Requirements | Rule: salted hashes only; never stored/logged/transmitted in clear | TC-SA-01-04-015 |
| 4.1 Password Creation with Security Requirements | Rule: similarity check blocks trivially derivable passwords | TC-SA-01-04-016 |
| 4.1 Password Creation with Security Requirements | Rule: role-scoped overrides apply the stricter value | TC-SA-01-04-017 |
| 4.2 Forgot Password / Password Reset Flow | "Forgot password" entry on the login screen | TC-SA-01-04-018 |
| 4.2 Forgot Password / Password Reset Flow | Identity confirmation via a registered channel | TC-SA-01-04-019 |
| 4.2 Forgot Password / Password Reset Flow | Reset link: single-use, time-limited, account-bound | TC-SA-01-04-020 |
| 4.2 Forgot Password / Password Reset Flow | Reset OTP alternative | TC-SA-01-04-021 |
| 4.2 Forgot Password / Password Reset Flow | New password with full policy applied | TC-SA-01-04-022 |
| 4.2 Forgot Password / Password Reset Flow | Rate limiting per account and per IP | TC-SA-01-04-023 |
| 4.2 Forgot Password / Password Reset Flow | Lock after multiple failed requests + alert | TC-SA-01-04-024 |
| 4.2 Forgot Password / Password Reset Flow | Support-assisted reset after identity verification | TC-SA-01-04-025 |
| 4.2 Forgot Password / Password Reset Flow | Session invalidation on reset completion | TC-SA-01-04-026 |
| 4.2 Forgot Password / Password Reset Flow | Notification to the account owner | TC-SA-01-04-027 |
| 4.2 Forgot Password / Password Reset Flow | Audit logging of every reset event | TC-SA-01-04-028 |
| 4.2 Forgot Password / Password Reset Flow | Rule: self-service requires control of a registered channel | TC-SA-01-04-029 |
| 4.2 Forgot Password / Password Reset Flow | Rule: used/expired link shows clear message + new-link option | TC-SA-01-04-030 |
| 4.2 Forgot Password / Password Reset Flow | Rule: failed requests trigger lock + security alert | TC-SA-01-04-031 |
| 4.2 Forgot Password / Password Reset Flow | Rule: every reset invalidates all existing sessions | TC-SA-01-04-032 |
| 4.2 Forgot Password / Password Reset Flow | Rule: owner always notified; unexpected-reset report routes to support | TC-SA-01-04-033 |
| 4.2 Forgot Password / Password Reset Flow | Rule: admin-assisted resets require reason, audit-logged | TC-SA-01-04-034 |
| 4.2 Forgot Password / Password Reset Flow | Rule: rate limiting prevents enumeration and abuse | TC-SA-01-04-035 |
| 4.3 Password Change | Change password from profile settings | TC-SA-01-04-036 |
| 4.3 Password Change | Current password verification before change | TC-SA-01-04-037 |
| 4.3 Password Change | New password validated with real-time feedback | TC-SA-01-04-038 |
| 4.3 Password Change | Reuse check against last N passwords | TC-SA-01-04-039 |
| 4.3 Password Change | Optional "sign out all other sessions" checkbox | TC-SA-01-04-040 |
| 4.3 Password Change | Security notice email with device/location context | TC-SA-01-04-041 |
| 4.3 Password Change | Forced-change prompt for flagged accounts | TC-SA-01-04-042 |
| 4.3 Password Change | Audit logging with timestamp and initiating device | TC-SA-01-04-043 |
| 4.3 Password Change | Rule: wrong current password rejects the change | TC-SA-01-04-044 |
| 4.3 Password Change | Rule: new password cannot match last N used | TC-SA-01-04-045 |
| 4.3 Password Change | Rule: change always notifies owner; unexpected-change report routes to support | TC-SA-01-04-046 |
| 4.3 Password Change | Rule: "sign out all other sessions" ends every other session | TC-SA-01-04-047 |
| 4.3 Password Change | Rule: forced-change accounts blocked beyond the change screen | TC-SA-01-04-048 |
| 4.3 Password Change | Rule: change audit-logged with device and (admin-initiated) reason | TC-SA-01-04-049 |

## 4.1 Password Creation with Security Requirements

### TC-SA-01-04-001 — Minimum length requirement enforced
**Type:** Negative
**Covers:** 4.1 → Minimum length requirement (configurable, e.g., 8+)
**Preconditions:** The configured minimum length known (e.g., 8); a registration or change-password screen.
**Steps:**
1. Enter a password of length (minimum − 1) that otherwise satisfies all rules.
2. Observe the validation feedback.
3. Enter a password of exactly the minimum length.
4. Observe the validation.
**Expected Result:** The below-minimum password is rejected with a clear length message; the exactly-minimum password passes the length check; the boundary is exact (no off-by-one); the rejection is shown in real time.
**Priority:** Critical

### TC-SA-01-04-002 — Character class requirements enforced individually
**Type:** Negative
**Covers:** 4.1 → Character class requirements (uppercase, lowercase, number, symbol — each configurable)
**Preconditions:** All four character classes enabled in the policy; a password entry screen.
**Steps:**
1. Enter a password missing each class in turn (no uppercase; no lowercase; no number; no symbol).
2. Observe the specific feedback for each.
3. Enter a password containing all four classes.
**Expected Result:** Each missing class produces its specific feedback (e.g., "Add an uppercase letter"); the all-classes password passes the composition check; disabling a class in the policy removes its requirement (verified via the live preview).
**Priority:** Critical

### TC-SA-01-04-003 — Real-time strength meter with actionable feedback
**Type:** Positive
**Covers:** 4.1 → Real-time strength meter with specific, actionable feedback
**Preconditions:** A password entry screen with the strength meter.
**Steps:**
1. Type a weak password character by character, observing the meter.
2. Read the feedback messages at each stage.
3. Strengthen the password step by step until it passes.
**Expected Result:** The meter updates in real time as the user types; each feedback message is specific and actionable (e.g., "Add a symbol", "Make it longer"); the meter reaches "pass" exactly when all policy rules are satisfied; no vague scores without guidance.
**Priority:** High

### TC-SA-01-04-004 — Blocklist check against common and breached passwords
**Type:** Negative
**Covers:** 4.1 → Blocklist check against common passwords and known breached-password datasets
**Preconditions:** A list of known common passwords (e.g., "password123") and known breached passwords.
**Steps:**
1. Attempt to set a common password that otherwise meets length/composition.
2. Attempt to set a known breached password.
3. Observe the outcome and message for each.
**Expected Result:** Both are hard-blocked (not merely warned) with a clear message that the password is too common/has been compromised; the blocklist check runs against both the common list and the breached datasets; the blocks are logged.
**Priority:** Critical

### TC-SA-01-04-005 — No reuse of the last N passwords
**Type:** Negative
**Covers:** 4.1 → No reuse of the last N passwords (configurable N, e.g., 10)
**Preconditions:** An account with a known password history of N+ entries; the reuse window N known.
**Steps:**
1. Attempt to set the current password as the new password.
2. Attempt to set each of the last N historical passwords in turn.
3. Attempt to set a password older than the N-window.
**Expected Result:** The current and all last-N passwords are rejected with a reuse message; a password older than the window is accepted (if it passes other rules); the window boundary is exact; the comparisons use the account's own hashed history.
**Priority:** High

### TC-SA-01-04-006 — Similarity check vs email address and name
**Type:** Negative
**Covers:** 4.1 → Similarity check: password must differ significantly from email and name
**Preconditions:** An account with a known email and name; a password entry screen.
**Steps:**
1. Attempt a password derived from the email (e.g., "emailaddress1!").
2. Attempt a password derived from the name (e.g., "Firstname1!").
3. Attempt a password unrelated to both.
**Expected Result:** The email-derived and name-derived passwords are rejected with a similarity message; the unrelated password passes the similarity check; the check covers both the email and the name.
**Priority:** High

### TC-SA-01-04-007 — No dictionary-word-only passwords
**Type:** Negative
**Covers:** 4.1 → No dictionary-word-only passwords (configurable enforcement)
**Preconditions:** Dictionary enforcement enabled; a password entry screen.
**Steps:**
1. Attempt a single dictionary word (with length satisfied).
2. Attempt a dictionary word with minimal modification (e.g., "password1").
3. Attempt a non-dictionary passphrase.
**Expected Result:** The dictionary-word-only password is rejected with a clear message; minimally modified dictionary words are rejected per the configured enforcement; the non-dictionary passphrase passes; disabling the enforcement in the policy removes the block (verified via live preview).
**Priority:** Medium

### TC-SA-01-04-008 — Policy configuration screen with live preview
**Type:** Positive
**Covers:** 4.1 → Policy configuration screen in System Settings with live preview
**Preconditions:** Super Admin access to System Settings → Security Policy → Password Policy.
**Steps:**
1. Open the Password Policy screen.
2. Verify all configurable rules are visible (length, character classes, blocklist, reuse N, similarity, dictionary).
3. Use the live preview to test sample passwords against a proposed (unsaved) change.
4. Save the change and verify it applies.
**Expected Result:** All rules are visible and editable; the live preview evaluates sample passwords against the proposed rules before saving and shows the feedback messages; after save the new policy applies to new/changed passwords; the policy change is audit-logged.
**Priority:** High

### TC-SA-01-04-009 — Compliance reporting: weak, aged, reused passwords
**Type:** Positive
**Covers:** 4.1 → Compliance reporting
**Preconditions:** Accounts with weak passwords, aged passwords (beyond maximum age), and reuse violations; Super Admin access to the report.
**Steps:**
1. Open the password compliance report.
2. Verify the list of accounts with passwords older than the maximum age.
3. Verify the list of accounts flagged weak by the strength model.
4. Verify the list of reuse violations.
**Expected Result:** The report lists all three categories with the correct accounts; each entry is actionable (identifies the account and the issue); the data matches the actual account states; the report is refreshable/exportable.
**Priority:** Medium

### TC-SA-01-04-010 — Rotation notices: platform-wide and role-scoped
**Type:** Positive
**Covers:** 4.1 → Platform-wide or role-scoped rotation notices
**Preconditions:** The rotation-notice capability; a target role (e.g., Billing Administrator, Super Admin).
**Steps:**
1. Trigger a role-scoped rotation notice for the target role.
2. Have a target-role user log in.
3. Observe the forced-change prompt and the reason shown.
4. Trigger a platform-wide notice and observe its scope.
**Expected Result:** The role-scoped notice prompts only the target role's users to change their password at next login, with the reason shown; the platform-wide notice applies to all users; the notices are logged; the rotation completion report reflects completions.
**Priority:** High

### TC-SA-01-04-011 — Policy changes apply prospectively only
**Type:** Edge
**Covers:** 4.1 → Rule: existing passwords remain valid until changed unless rotation triggered
**Preconditions:** A policy change to be made (e.g., minimum length raised); existing accounts with passwords valid under the old policy.
**Steps:**
1. Save the stricter policy.
2. Log in with an existing account whose password is valid under the old policy but not the new one.
3. Observe the login outcome.
4. Change that password and verify the new policy applies.
**Expected Result:** The existing password remains valid (login succeeds) — the change is prospective; the new policy applies to the changed password; no existing password is invalidated without an explicit rotation trigger; the policy change is audit-logged.
**Priority:** High

### TC-SA-01-04-012 — Strength meter feedback is specific and actionable
**Type:** Positive
**Covers:** 4.1 → Rule: specific, actionable feedback rather than a vague score
**Preconditions:** A password entry screen; several weak passwords prepared.
**Steps:**
1. Enter each weak password and record the exact feedback text.
2. Verify each message names the specific deficiency and the fix.
3. Verify no message is a bare score without guidance.
**Expected Result:** Every feedback message is specific and actionable (names the exact rule failing and what to do); there is no vague "weak/medium/strong" without an accompanying actionable message; the feedback matches the actual failing rule.
**Priority:** Medium

### TC-SA-01-04-013 — Breached-password match is a hard block
**Type:** Negative
**Covers:** 4.1 → Rule: breached-password match is a hard block, not a warning
**Preconditions:** A known breached password that otherwise satisfies all other rules.
**Steps:**
1. Attempt to set the breached password.
2. Observe whether the submission can proceed (warning vs block).
**Expected Result:** The submission is hard-blocked (the password cannot be set); the message states the password has been compromised; there is no "override" or "use anyway" path; the block is logged.
**Priority:** Critical

### TC-SA-01-04-014 — Reuse window scoped to the account's own history
**Type:** Edge
**Covers:** 4.1 → Rule: reuse compares against the account's own history only (hashed)
**Preconditions:** Two accounts; account B's password equals a password in account A's history.
**Steps:**
1. Set account B's password to a value that appears only in account A's history.
2. Observe the acceptance.
3. Verify the comparison used hashed values (no plaintext history exposed).
**Expected Result:** Account B's password is accepted (the reuse window does not span accounts); the check is per-account; the comparison is performed on hashed values (no plaintext password history is stored or exposed).
**Priority:** Medium

### TC-SA-01-04-015 — Passwords stored only as salted hashes; never in clear
**Type:** Negative
**Covers:** 4.1 → Rule: salted hashes with a strong adaptive algorithm; never stored, logged, or transmitted in clear
**Preconditions:** A password set during the test; access to inspect storage, logs, and network traffic.
**Steps:**
1. Set a known test password.
2. Inspect the stored credential form.
3. Search all logs for the plaintext password.
4. Inspect the network traffic for the password in transit.
**Expected Result:** The stored form is a salted hash (a strong adaptive algorithm — not reversible to the plaintext); no log contains the plaintext password; the password is never transmitted in clear (encrypted in transit); a full review finds zero plaintext occurrences.
**Priority:** Critical

### TC-SA-01-04-016 — Similarity check blocks trivially derivable passwords
**Type:** Negative
**Covers:** 4.1 → Rule: similarity prevents passwords trivially derivable from email or name
**Preconditions:** An account with known email/name; several derivable candidates prepared.
**Steps:**
1. Attempt "emailaddress1!", "emailaddress2024", and a name-based variant.
2. Observe each rejection.
**Expected Result:** All trivially derivable variants are rejected with the similarity message; the check is not bypassable by minor suffix changes; the rejections are logged.
**Priority:** High

### TC-SA-01-04-017 — Role-scoped override applies the stricter value
**Type:** Edge
**Covers:** 4.1 → Rule: role-scoped overrides always apply the stricter of default and override
**Preconditions:** Platform default minimum length 8; a role override of 12 for privileged roles; a user in that role.
**Steps:**
1. As the privileged-role user, attempt a 10-character password (passes default, fails override).
2. Observe the rejection.
3. Attempt a 12-character password.
4. As a standard user, attempt an 8-character password.
**Expected Result:** The privileged user is held to the stricter 12 (the 10-char password is rejected); the 12-char password passes; the standard user is held to the 8 default; the stricter-value rule holds in both directions (an override looser than the default would not lower the bar).
**Priority:** High

## 4.2 Forgot Password / Password Reset Flow

### TC-SA-01-04-018 — "Forgot password" entry on the login screen
**Type:** Positive
**Covers:** 4.2 → "Forgot password" entry on the login screen
**Preconditions:** The login screen; a registered account.
**Steps:**
1. Locate the "Forgot password?" entry on the login screen.
2. Activate it and enter the registered email.
3. Observe the next step.
**Expected Result:** The entry is present and reachable from the login screen; entering the registered email advances to the identity-confirmation step; the flow is self-service (no support needed for the standard path).
**Priority:** High

### TC-SA-01-04-019 — Identity confirmation via a registered channel
**Type:** Positive
**Covers:** 4.2 → Identity confirmation via a registered channel (email and/or phone OTP)
**Preconditions:** An account with a registered email and/or phone; the forgot-password flow started.
**Steps:**
1. Start the flow with the registered email.
2. Complete the identity confirmation (email link or phone OTP).
3. Observe the reset-credential issuance.
**Expected Result:** The system proves control of a registered channel before issuing any reset capability; the confirmation is delivered to the registered channel; only after confirmation is the reset link/OTP issued; the confirmation is logged.
**Priority:** Critical

### TC-SA-01-04-020 — Reset link: single-use, time-limited, account-bound
**Type:** Edge
**Covers:** 4.2 → Reset link issuance: single-use, time-limited (e.g., 30 minutes), bound to the account
**Preconditions:** A fresh reset link; the validity window known (e.g., 30 minutes).
**Steps:**
1. Open the reset link within the window and set a new password.
2. Attempt to reuse the same link.
3. Issue a second link and wait past the window, then open it.
4. Attempt to apply a reset link from account A while acting in account B's context.
**Expected Result:** The link works once within the window; reuse is rejected (single-use); the expired link is rejected with a clear message; the link is bound to its account (cannot be applied to a different account); all outcomes are logged.
**Priority:** Critical

### TC-SA-01-04-021 — Reset OTP alternative for mobile-friendly flows
**Type:** Positive
**Covers:** 4.2 → Reset OTP alternative
**Preconditions:** A mobile client; the forgot-password flow started.
**Steps:**
1. Choose the OTP alternative instead of the link.
2. Receive and enter the reset OTP.
3. Set the new password and complete the reset.
**Expected Result:** The OTP alternative is available on mobile-friendly flows; the OTP verifies and unlocks the new-password screen; the reset completes identically to the link path; the OTP method is logged.
**Priority:** Medium

### TC-SA-01-04-022 — New password validated with the full security policy
**Type:** Negative
**Covers:** 4.2 → New password entry with the full security policy applied
**Preconditions:** A reset in progress at the new-password screen.
**Steps:**
1. Enter a weak password (fails length/composition).
2. Enter a blocklisted password.
3. Enter a reused password (from the account's history).
4. Enter a compliant password.
**Expected Result:** The weak, blocklisted, and reused passwords are all rejected with specific feedback (the full policy applies — strength meter, blocklist, reuse); the compliant password is accepted; the reset completes only with a policy-passing password.
**Priority:** Critical

### TC-SA-01-04-023 — Rate limiting on reset requests per account and per IP
**Type:** Negative
**Covers:** 4.2 → Rate limiting on reset requests per account and per IP
**Preconditions:** The per-account and per-IP reset rate limits known.
**Steps:**
1. From one account, trigger reset requests beyond the per-account limit.
2. From one IP, trigger reset requests for multiple accounts beyond the per-IP limit.
3. Observe enforcement.
**Expected Result:** The per-account limit caps reset requests for a single account; the per-IP limit caps aggregate requests from one IP; excess requests are throttled/blocked; all limit events are logged.
**Priority:** High

### TC-SA-01-04-024 — Lock after multiple failed requests with security alert
**Type:** Negative
**Covers:** 4.2 → Lock on the reset flow after multiple failed requests, with an alert in security monitoring
**Preconditions:** The failed-request threshold known; security monitoring access.
**Steps:**
1. Generate multiple failed reset requests (wrong/expired credentials) for one account.
2. Observe the lock on the reset flow.
3. Check security monitoring for the alert.
**Expected Result:** After the threshold of failed requests the reset flow is locked for the account (temporary); an alert appears in security monitoring (possible account-takeover attempt); the lock and the alert are logged; the lock expires per policy.
**Priority:** Critical

### TC-SA-01-04-025 — Support-assisted reset after identity verification
**Type:** Edge
**Covers:** 4.2 → Support-assisted reset: admin-initiated after identity verification
**Preconditions:** A user with no access to any registered channel; a support request; Super Admin access.
**Steps:**
1. Verify the user's identity through the support process (registered details + OTP to an alternate verified channel or document verification per the standard).
2. Issue the admin-authorized reset with a recorded reason.
3. Have the user set a new password at next login (forced-change prompt).
4. Inspect the audit log and session state.
**Expected Result:** The reset is allowed only after the support identity verification; the user is forced to set a new password at next login; the event is audit-logged as support-assisted with the acting admin and reason; all sessions are invalidated; the user is notified.
**Priority:** Critical

### TC-SA-01-04-026 — Session invalidation on reset completion
**Type:** Positive
**Covers:** 4.2 → Session invalidation: all existing sessions end on reset completion
**Preconditions:** An account with multiple active sessions; a reset in progress.
**Steps:**
1. Complete the password reset.
2. On each pre-existing session, attempt an action.
3. Observe the session outcomes.
**Expected Result:** All pre-existing sessions for the account are invalidated; each fails on its next request (redirected to login); no attacker-held session survives the reset; the invalidation is logged.
**Priority:** Critical

### TC-SA-01-04-027 — Account owner notified of the reset
**Type:** Positive
**Covers:** 4.2 → Notification: the account owner is notified of the reset
**Preconditions:** A reset to complete (self-service and admin-assisted variants).
**Steps:**
1. Complete a self-service reset; observe the notification.
2. Complete an admin-assisted reset; observe the notification.
3. Verify the notification content and delivery.
**Expected Result:** The account owner is notified in both cases (self-initiated and admin-initiated); the notification identifies that a password reset occurred; the notifications are delivered to the registered channels and logged.
**Priority:** High

### TC-SA-01-04-028 — Audit logging of every reset event
**Type:** Positive
**Covers:** 4.2 → Audit logging of every reset event (initiated, link issued, completed, failed, admin-assisted)
**Preconditions:** Scenarios producing each event type; audit log access.
**Steps:**
1. Produce an initiation, a link issuance, a completion, a failure, and an admin-assisted reset.
2. Locate all five events in the audit log.
3. Inspect type, actor, timestamp, and outcome on each.
**Expected Result:** All five event types are present with type (self-service/admin-assisted), actor, timestamp, and outcome; the sequence matches the actual operations; the log is exportable.
**Priority:** High

### TC-SA-01-04-029 — Self-service reset requires control of a registered channel
**Type:** Negative
**Covers:** 4.2 → Rule: self-service reset requires control of at least one registered channel
**Preconditions:** An account whose registered channels are all inaccessible (email/phone lost).
**Steps:**
1. Start the self-service reset flow.
2. Attempt to complete identity confirmation without access to any registered channel.
3. Observe the available path.
**Expected Result:** The self-service flow cannot complete without control of a registered channel; no reset credential is issued; the support-assisted path is the only available option and is presented; the blocked attempts are logged.
**Priority:** Critical

### TC-SA-01-04-030 — Used/expired reset link shows clear message with new-link option
**Type:** Edge
**Covers:** 4.2 → Rule: used or expired link shows a clear message with "request a new link"
**Preconditions:** A used reset link and an expired reset link.
**Steps:**
1. Open the used link; read the message.
2. Open the expired link; read the message.
3. Use the "request a new link" option (within rate limits) and complete the reset.
**Expected Result:** Both show a clear, specific message (used vs expired — not a generic error) with a working "request a new link" option; the new link completes the reset (subject to rate limits); both outcomes are logged.
**Priority:** High

### TC-SA-01-04-031 — Failed reset requests trigger lock and security alert
**Type:** Negative
**Covers:** 4.2 → Rule: multiple failed requests trigger a temporary lock + alert (possible ATO)
**Preconditions:** The failed-request threshold known; security monitoring access.
**Steps:**
1. Generate failed reset requests from one account beyond the threshold.
2. Observe the temporary lock.
3. Verify the security monitoring alert.
4. Repeat from one IP across accounts and verify the per-IP lock.
**Expected Result:** The per-account lock engages after the threshold; the per-IP lock engages for cross-account abuse; both raise alerts in security monitoring flagged as possible account-takeover; the locks are temporary (expire per policy); all events are logged.
**Priority:** Critical

### TC-SA-01-04-032 — Every reset invalidates all existing sessions
**Type:** Negative
**Covers:** 4.2 → Rule: every reset (self-service or admin-assisted) invalidates all existing sessions
**Preconditions:** An account with active sessions; both reset types to execute.
**Steps:**
1. Execute a self-service reset; test all pre-existing sessions.
2. Execute an admin-assisted reset on another account; test all pre-existing sessions.
**Expected Result:** In both cases every pre-existing session is invalidated (fails on next request); no session survives any reset type; the invalidations are logged; this ends any attacker-held sessions.
**Priority:** Critical

### TC-SA-01-04-033 — Owner always notified; unexpected-reset report routes to support
**Type:** Positive
**Covers:** 4.2 → Rule: owner always notified; unexpected-reset report routes to support and security monitoring
**Preconditions:** A completed reset; the user's ability to report an unexpected reset.
**Steps:**
1. Verify the owner notification was delivered.
2. As the user, submit an "unexpected reset" report.
3. Observe the routing of the report.
**Expected Result:** The owner notification is always delivered; the unexpected-reset report is routed to support AND security monitoring as a potential compromise; the report is logged and visible in the security monitoring dashboard.
**Priority:** High

### TC-SA-01-04-034 — Admin-assisted resets require a recorded reason and are audit-logged
**Type:** Negative
**Covers:** 4.2 → Rule: admin-assisted resets require a recorded reason; audit-logged with the acting admin
**Preconditions:** Super Admin access; a support-assisted reset to perform.
**Steps:**
1. Attempt the admin-assisted reset without a reason.
2. Observe the block.
3. Complete it with a reason and inspect the audit entry.
**Expected Result:** The reset cannot complete without a recorded reason; with a reason it completes and the audit entry records the acting admin, target, reason, and timestamp; the entry is visible in the security audit trail; no admin-assisted reset exists without a reason.
**Priority:** Critical

### TC-SA-01-04-035 — Rate limiting prevents enumeration and abuse
**Type:** Negative
**Covers:** 4.2 → Rule: reset requests rate-limited per account and per IP to prevent enumeration and abuse
**Preconditions:** A list of registered and unregistered emails; the rate limits known.
**Steps:**
1. Submit reset requests for many different emails (registered and not) from one IP.
2. Observe the responses for registered vs unregistered addresses.
3. Observe the rate-limit enforcement.
**Expected Result:** The responses do not reveal whether an email is registered (no enumeration — identical generic responses); the per-IP rate limit throttles the burst; the per-account limit caps per-account requests; all limit events are logged.
**Priority:** High

## 4.3 Password Change

### TC-SA-01-04-036 — Change password from profile settings
**Type:** Positive
**Covers:** 4.3 → Change password from profile settings (Security section)
**Preconditions:** An authenticated user; profile settings access.
**Steps:**
1. Open profile settings → Security → Change Password.
2. Complete the current-password verification.
3. Enter and confirm a compliant new password.
4. Submit and verify the change.
**Expected Result:** The change-password screen is reachable from the Security section; the full flow (verify current → new → confirm → submit) works; the new password is effective at the next login; the change is logged.
**Priority:** Critical

### TC-SA-01-04-037 — Current password verification before the change
**Type:** Negative
**Covers:** 4.3 → Current password verification before the change is accepted
**Preconditions:** An authenticated session; the change-password screen.
**Steps:**
1. Enter a wrong current password.
2. Observe the rejection.
3. Enter the correct current password.
4. Observe the new-password fields.
**Expected Result:** The wrong current password rejects the change (the new-password fields are not usable); the correct current password reveals the new-password fields; the verification proves the requester is the account holder; the failed attempt is logged.
**Priority:** Critical

### TC-SA-01-04-038 — New password validated with real-time strength feedback
**Type:** Positive
**Covers:** 4.3 → New password validated against the full security policy with real-time feedback
**Preconditions:** The change-password screen past current-password verification.
**Steps:**
1. Type a weak new password, observing the strength meter.
2. Read the specific feedback at each stage.
3. Strengthen it until it passes and submit.
**Expected Result:** The strength meter validates in real time against the full policy (length, character classes, blocklist, reuse, similarity); the feedback is specific and actionable; the change is accepted only when the password passes; the meter matches the policy exactly.
**Priority:** High

### TC-SA-01-04-039 — Reuse check on the new password
**Type:** Negative
**Covers:** 4.3 → Reuse check: new password cannot match any of the last N used passwords
**Preconditions:** An account with a known password history; the reuse window N known.
**Steps:**
1. Attempt to set the new password to the current password.
2. Attempt to set it to each of the last N historical passwords.
3. Attempt a genuinely new password.
**Expected Result:** The current and last-N passwords are all rejected with a reuse message; the genuinely new password is accepted; the window boundary is exact; the rejections are logged.
**Priority:** High

### TC-SA-01-04-040 — Optional "sign out all other sessions" checkbox
**Type:** Positive
**Covers:** 4.3 → Optional "sign out all other sessions" checkbox (recommended, shown as such)
**Preconditions:** An account with multiple active sessions; the change-password screen.
**Steps:**
1. Observe the checkbox and its "recommended" indication.
2. Complete a change WITH the checkbox ticked; verify the other sessions end.
3. Complete a change on another account WITHOUT the checkbox; verify the other sessions persist.
**Expected Result:** The checkbox is present, optional, and shown as recommended; ticking it ends all other sessions (current one continues); leaving it unticked leaves other sessions active; both outcomes are logged.
**Priority:** High

### TC-SA-01-04-041 — Security notice email with device/location context
**Type:** Positive
**Covers:** 4.3 → Security notice email to the account owner on change (with device/location context)
**Preconditions:** A password change to complete; a monitored inbox.
**Steps:**
1. Complete a password change from a known device/location.
2. Read the security-notice email.
3. Verify the content (date, device/location, "if this wasn't you" guidance).
**Expected Result:** The email is sent on change with the format "Your password was changed on [date] from [device/location]. If this wasn't you, contact support."; the date, device, and location context are accurate; the email is logged.
**Priority:** High

### TC-SA-01-04-042 — Forced-change prompt for flagged accounts
**Type:** Positive
**Covers:** 4.3 → Forced-change prompt: flagged accounts must change at next login
**Preconditions:** An account flagged for rotation (policy, compromise, or admin action).
**Steps:**
1. Log in as the flagged account.
2. Observe the forced-change prompt.
3. Complete the password change.
4. Verify normal access resumes.
**Expected Result:** At next login the account is presented with the forced-change prompt (cannot bypass it); the change must pass the full policy; after the change normal access resumes; the forced change and its trigger are logged.
**Priority:** Critical

### TC-SA-01-04-043 — Audit logging with timestamp and initiating device
**Type:** Positive
**Covers:** 4.3 → Audit logging of every change with timestamp and initiating device
**Preconditions:** Several password changes produced from known devices; audit log access.
**Steps:**
1. Complete changes from two different devices.
2. Locate both in the audit log.
3. Inspect timestamp and initiating device on each.
**Expected Result:** Every change is audit-logged with an accurate timestamp and the initiating device; the device context matches the actual device; the entries are exportable.
**Priority:** High

### TC-SA-01-04-044 — Wrong current password rejects the change
**Type:** Negative
**Covers:** 4.3 → Rule: wrong current password rejects the change (prevents partial-access changes)
**Preconditions:** A session on a shared device where the password is unknown (partial access).
**Steps:**
1. From the shared-device session, attempt a password change with a guessed current password.
2. Observe the rejection.
3. Verify the password is unchanged.
**Expected Result:** The change is rejected (the current password is required and unknown); the password remains unchanged; the attempt is logged; someone with only a session (no password) cannot change it.
**Priority:** Critical

### TC-SA-01-04-045 — New password cannot match any of the last N used
**Type:** Negative
**Covers:** 4.3 → Rule: reuse window enforced on change
**Preconditions:** An account with N+ historical passwords.
**Steps:**
1. Attempt to set each of the last N historical passwords as the new password.
2. Observe each rejection.
3. Set a password outside the window.
**Expected Result:** All last-N passwords are rejected with the reuse message; the outside-window password is accepted; the window is exact; the rejections are logged.
**Priority:** High

### TC-SA-01-04-046 — Change always notifies owner; unexpected-change report routes to support
**Type:** Positive
**Covers:** 4.3 → Rule: change always notifies the owner; unexpected-change report routes to support and security monitoring
**Preconditions:** A completed change; the user's ability to report an unexpected change.
**Steps:**
1. Verify the owner notification was delivered on the change.
2. As the user, submit an "unexpected change" report.
3. Observe the routing.
**Expected Result:** The owner is always notified of a change; the unexpected-change report is routed to support AND security monitoring as a potential compromise; the report is logged and visible on the security monitoring dashboard.
**Priority:** High

### TC-SA-01-04-047 — "Sign out all other sessions" ends every session except the current one
**Type:** Positive
**Covers:** 4.3 → Rule: choosing the option ends every session except the current one immediately
**Preconditions:** An account with 3+ active sessions including the current one; the change screen.
**Steps:**
1. Complete a change with "sign out all other sessions" ticked.
2. On each other session, attempt an action.
3. Verify the current session continues.
**Expected Result:** Every session except the current one is ended (each fails on its next request); the current session continues uninterrupted; the terminations are logged with the trigger (password change).
**Priority:** High

### TC-SA-01-04-048 — Forced-change accounts blocked beyond the change screen
**Type:** Negative
**Covers:** 4.3 → Rule: forced-change accounts cannot access the platform beyond the change screen
**Preconditions:** An account flagged for forced change.
**Steps:**
1. Log in as the flagged account.
2. Attempt to navigate to any panel/page other than the change screen.
3. Complete the change and retry the navigation.
**Expected Result:** Before the change, all navigation beyond the change screen is blocked (the user cannot reach any panel); after the change, normal access is restored; the block and the completion are logged.
**Priority:** Critical

### TC-SA-01-04-049 — Change audit-logged with device and admin-initiated reason
**Type:** Positive
**Covers:** 4.3 → Rule: change audit-logged with timestamp, device, and (admin-initiated) triggering reason
**Preconditions:** A self-initiated change and an admin-initiated forced change; audit log access.
**Steps:**
1. Complete a self-initiated change; inspect its audit entry.
2. Trigger an admin-initiated forced change; inspect its audit entry.
3. Verify the fields on each.
**Expected Result:** The self-initiated entry has timestamp and initiating device; the admin-initiated entry additionally carries the triggering reason and the acting admin; no entry lacks its required fields; the log is exportable.
**Priority:** High