Identity Compromise Response

Summary

Identity compromise response addresses suspected misuse of a workforce, privileged, service, API, workload, machine, shared, break-glass, federated, or third-party identity. A suspicious login, denied MFA prompt, reputation result, or unfamiliar device is a signal for review, not automatic proof of account takeover. Containment and recovery must account for active sessions, refresh tokens, application tokens, certificates, service credentials, privileges, and dependency impact.

Why it matters

Password reset alone may not invalidate every active session, OAuth grant, API credential, certificate, recovery method, or linked automation. Conversely, broad revocation can disrupt critical services. The response task is to establish evidence-backed scope, choose proportionate controls with accountable approval, and validate the result without claiming complete coverage.

Identity types and scope

Identify the identity type and its dependencies: workforce user, administrator, service account, API or workload identity, application registration, machine identity, shared account, emergency or break-glass account, federated partner, or third-party access. Map privileges, group and role memberships, sensitive applications, mailbox rules, cloud resources, remote access, certificate and key use, automation, and recovery paths. Ownership and risk differ by identity type.

Evidence to review

Review sign-in and MFA events, conditional-access or policy outcomes, active sessions, refresh and access-token issuance where available, device registrations, VPN and endpoint records, privilege and group changes, OAuth consent and application activity, mailbox forwarding or rule changes, recovery-method changes, password reset events, certificate or key use, cloud and SaaS audit records, and identity-provider alerts. Note source coverage, timestamps, and delay. Missing records do not prove the identity or environment is unaffected.

Important distinctions

Suspicious sign-in is not confirmed account compromise.
Password reset is not necessarily session, refresh-token, API-token, certificate, or recovery-method revocation.
MFA success does not by itself prove a legitimate user action.
Denied MFA prompts can be a user report, configuration issue, or attempted abuse; investigate with context.
Token revocation may affect dependent applications and needs validation.
Privileged identity containment often needs a different approval and continuity path than a standard user response.

Containment decision guidance

Choose controls based on evidence, urgency, identity privilege, service dependency, and approval path. Possible actions can include restricting sign-in, revoking active sessions or refresh tokens through approved procedures, resetting credentials, removing unapproved OAuth consent, reviewing roles, rotating scoped secrets or certificates, preserving evidence, and increasing monitoring. Record expected impact, accountable owner, validation evidence, rollback or continuity plan, and reassessment trigger. Do not claim a containment action completed unless its result is confirmed.

Recovery and validation

Recovery may involve restoring access through an approved process, reviewing recovery methods, validating known-good device and network context, confirming essential application access, reviewing privilege changes, and monitoring for recurrence. Validate with source-backed records where available. A clean sign-in after a reset is useful evidence, but not proof that every prior session, token, integration, or endpoint was unaffected.

Privileged and non-human identities

For privileged identities, coordinate with incident, platform, and service owners before action where time permits. For service and workload identities, identify dependent jobs, applications, certificates, secrets, scopes, and owner contacts. A hasty rotation can break production automation; a delayed response can preserve misuse. Document the risk decision, the minimum safe action, and verification steps. Break-glass accounts require especially careful local policy handling.

Worked example

A fictional privileged user has a sign-in from a cloud address, a denied MFA prompt, an active browser session, and a newly granted OAuth consent. Endpoint telemetry is incomplete and there is no confirmed malware. The account also administers an automation workflow that depends on a related service identity. The team preserves sign-in and consent evidence, asks the identity owner to validate the user, obtains approval to revoke browser sessions and remove the unapproved consent, resets credentials through the approved process, reviews roles and recovery methods, and coordinates a separate check of the automation dependency. The conclusion remains "suspected identity compromise under review," not confirmed enterprise compromise.

Common mistakes

Avoid treating geolocation as proof, resetting only a password, ignoring refresh tokens and OAuth grants, disabling a service identity without dependency review, assuming no EDR alert means no misuse, omitting recovery methods, over-broadly removing privileged access without continuity planning, and closing before session, token, role, and application validation are complete.

Reassessment triggers

Reassess when new sign-in or token evidence arrives, the user or owner confirms context, an application dependency fails, privilege changes are found, a new device registers, containment validation fails, or related identities appear. Keep direct observations and analyst inference separate across updates.

Limitations

Identity telemetry differs by provider, licensing, retention, application architecture, and integration. Tokens, sessions, and credentials may have distinct revocation behavior. This guidance does not replace provider documentation, emergency access procedures, incident response, legal review, or local change controls. It does not certify identity safety or complete coverage.