HARBOR-17 / 04 / PRACTICE GUIDE
Identity, session and SaaS incidents
Separate MFA results from session ownership. Review passwords, tokens, application grants, mailbox rules and delegation together.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
EVIDENCE REVIEW DESK
Move from observations to decisions.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
MFA passed / Incomplete decision
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s=>s.mfaPassedMFA success does not prove user intent. Review user confirmation, session and device context separately; the model contacts no identity provider.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
Context behind a successful login
Successful MFA alone does not establish intentional user action. Review session identity, device, application, source and user confirmation together. Location/IP anomalies are leads; retain VPN and shared-egress alternatives. Contact the user through an established organizational channel. Authentication and object/action authorization are different; map the services where the session remains effective.
02 / EXPLANATION
Access beyond password changes
Changing a password may not immediately end every application session or token. Assess existing sessions, refresh/access tokens and delegated authority against provider/application behavior. Do not assume old access ended until authorized test identities show denial. A successful administrative response is not identical to terminated application access; record effective timing and scope.
03 / EXPLANATION
Rules, delegation and application grants
Mail forwarding, mailbox delegation and application grants may affect data flow beyond login blocking. Authorized teams review changes, creation times and business rationale. Distinguish legitimate use from incident-linked changes rather than deleting every rule, preserving evidence and rollback plans. This exercise blocks no account and revokes no token; it models decision/evidence scope.
04 / EXPLANATION
Harbor-17 session gap
The identity record supplies successful sign-in and reserved example IP203.0.113.20, without device or session ID. A post-click sign-in is temporal proximity relevant to a compromise hypothesis, not attribution. Next evidence includes user confirmation, session correlation and application actions. Support closure through scoped old-access testing and rule/grant review, not password-changed status alone.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.