Identity and Sign-In Investigation

What you will be able to do

• Distinguish stable identity from authentication event in a realistic identity and sign-in investigation case.
• Interpret the evidence and boundary associated with device context.
• Choose an appropriate action involving network and location without exceeding the stated authority.
• Verify session response through an observable result and a documented handoff.

01

Frame Identity and Sign-In Investigation

Investigate sign-in activity by connecting stable identity, authenticator method, device and network context, session behavior, and proportionate account response.

A user receives an MFA prompt at night and the account later downloads files from a new device. The analyst must determine whether the events share a session and what access to revoke.

Keep observed facts, working assumptions, authorized actions, safety boundaries, and expected evidence separate. Begin with read-only inspection and preserve the context another analyst needs to reproduce the decision.

02

Stable Identity

A sign-in investigation needs a stable account or subject identifier across aliases, tenants, and display-name changes. Within identity and sign-in investigation, this concept answers a separate question and should retain its own evidence.

Confirm account state, owner, role, provider, creation, and recent recovery actions. Apply that action to the named case before expanding the investigation or changing protected state.

Respect this boundary: do not merge users who share the same visible name. The required result is specific: all reviewed events map to the intended digital identity.

03

Authentication Event

Authentication records can show method, factor, verifier, challenge, failure reason, and assurance context. Within identity and sign-in investigation, this concept answers a separate question and should retain its own evidence.

Compare successful and failed events with enrollment and recovery changes. Apply that action to the named case before expanding the investigation or changing protected state.

Respect this boundary: do not assume an mfa success means the user intended the request. The required result is specific: the analyst can explain how the session was authenticated.

04

Device Context

Device context may include identifier, platform, management, health, browser, application, and prior trust relationship. Within identity and sign-in investigation, this concept answers a separate question and should retain its own evidence.

Compare the observed device with enrollment, normal use, and endpoint telemetry. Apply that action to the named case before expanding the investigation or changing protected state.

Respect this boundary: do not identify a physical device from user-agent text alone. The required result is specific: device confidence is supported by more than one relevant attribute.

05

Network and Location

Addresses and geolocation can support context but may reflect proxies, mobile networks, shared gateways, or privacy services. Within identity and sign-in investigation, this concept answers a separate question and should retain its own evidence.

Compare provider, autonomous network, proxy state, travel, and known work patterns. Apply that action to the named case before expanding the investigation or changing protected state.

Respect this boundary: do not declare impossible travel from geolocation labels alone. The required result is specific: location evidence is weighted with its uncertainty and other events.

06

Session Response

Account response may revoke sessions, reset exposed authenticators, restrict access, preserve evidence, and monitor recovery. Within identity and sign-in investigation, this concept answers a separate question and should retain its own evidence.

Choose actions based on confidence, privilege, data access, and business continuity. Apply that action to the named case before expanding the investigation or changing protected state.

Respect this boundary: do not change only the password while stolen sessions remain valid. The required result is specific: unauthorized access stops and the legitimate user regains controlled access.

07

Apply Identity and Sign-In Investigation to One Case

Use the case as a bounded investigation: A user receives an MFA prompt at night and the account later downloads files from a new device. The analyst must determine whether the events share a session and what access to revoke.

First, confirm account state, owner, role, provider, creation, and recent recovery actions. Then, compare successful and failed events with enrollment and recovery changes. Keep both observations in the case record before choosing the next step.

Next, compare the observed device with enrollment, normal use, and endpoint telemetry. After that, compare provider, autonomous network, proxy state, travel, and known work patterns. Finish only after you choose actions based on confidence, privilege, data access, and business continuity.

08

Recap Before Practice and Prove

Stable Identity: A sign-in investigation needs a stable account or subject identifier across aliases, tenants, and display-name changes. In practice, confirm account state, owner, role, provider, creation, and recent recovery actions. Preserve the boundary: do not merge users who share the same visible name.

Authentication Event: Authentication records can show method, factor, verifier, challenge, failure reason, and assurance context. In practice, compare successful and failed events with enrollment and recovery changes. Preserve the boundary: do not assume an mfa success means the user intended the request.

Device Context: Device context may include identifier, platform, management, health, browser, application, and prior trust relationship. In practice, compare the observed device with enrollment, normal use, and endpoint telemetry. Preserve the boundary: do not identify a physical device from user-agent text alone.

Network and Location: Addresses and geolocation can support context but may reflect proxies, mobile networks, shared gateways, or privacy services. In practice, compare provider, autonomous network, proxy state, travel, and known work patterns. Preserve the boundary: do not declare impossible travel from geolocation labels alone.

Session Response: Account response may revoke sessions, reset exposed authenticators, restrict access, preserve evidence, and monitor recovery. In practice, choose actions based on confidence, privilege, data access, and business continuity. Preserve the boundary: do not change only the password while stolen sessions remain valid.