An employee reports an authentication prompt they did not initiate. An administrator notices an unfamiliar application grant, or a service credential appears in a public repository. Each situation needs investigation, but the affected identity, its permissions, and the available evidence determine the appropriate response. A useful identity incident procedure connects containment, investigation, recovery, and verification. The objective is to stop unauthorized access while preserving enough information to understand the event and identify remaining exposure. Follow the organization's incident process and involve the people authorized to make consequential changes to the affected systems.

Establish the Scope and Responsible Team

Record the reported activity, relevant identities, affected systems, and known timing. Distinguish confirmed observations from assumptions. Identify the incident owner and the administrators able to restrict access, collect evidence, and assess the operational effect of changes. The practical role of identity and access management cyber security is to connect those facts with the actual account and permission model. Determine whether the incident involves a human account, privileged identity, workload credential, or a combination. A compromised deployment service may require a different containment plan from an employee account used only for routine collaboration.

Restrict Access Through Supported Controls

Use the appropriate account, credential, permission, and session controls to contain the observed exposure. Depending on the environment, actions may include disabling an account, revoking supported sessions, restricting a role, or replacing a compromised secret. Coordinate urgent changes with the incident owner and affected service teams. Do not assume that a password reset ends every authenticated session. Identity provider tokens and application sessions can behave differently. Microsoft documents that applications control their own session tokens. Check the relevant platform procedures and verify the result at important destinations instead of relying only on a completed central reset action.

Preserve Relevant Evidence

Collect authentication records, administrative changes, application activity, and other available evidence needed to understand the event. Preserve useful identifiers and time information. Record the response actions too, so investigators can distinguish an attacker's changes from containment performed by the authorized team. Protect the collected material and avoid placing exposed credentials into ordinary tickets or messages. Evidence can contain personal information and sensitive infrastructure details. Follow the organization's handling procedures and retain the information needed for investigation without spreading the secret or unnecessarily expanding access to the affected data.

Look for Additional Access and Persistence

Investigate changes made through the compromised identity, including new accounts, role assignments, authentication methods, application permissions, and other relevant configuration. The attacker may have created another route that remains usable after the original credential is replaced. Check the scope carefully before drawing conclusions. Available logs may be incomplete or retained for a limited period. Record what has been verified and which questions remain unresolved. Coordinate removal of unauthorized changes with resource owners so recovery addresses the actual affected systems rather than stopping at the first visible account problem.

Recover From a Trusted Position

Restore access using the approved process after the team has addressed the relevant cause and remaining exposure. A replacement password or key entered on a still compromised device can become exposed again. Include the appropriate endpoint or workload investigation in the recovery plan. For services, identify dependencies and test the new authentication mechanism before returning the workload to normal operation where practical. Confirm that obsolete credentials are no longer accepted. For human users, review registered methods and recovery settings, then give clear instructions about the restored login route and any further checks required.

Evaluate Response Capabilities Before the Next Incident

When comparing the best iam vendors, ask vendors to demonstrate containment and verification across representative applications. Check which sessions can be revoked, which require application action, and how quickly changes are expected to take effect under supported conditions. Include a failed connector or unavailable application in the exercise. The team should know who owns the unresolved step and what alternative control is available. A response plan becomes more useful when it describes product limitations and manual dependencies before responders need to navigate them during an urgent event.

Keep the affected business owner informed through the agreed incident communication channel as recovery progresses.

Learn From the Confirmed Findings

After recovery, review the cause, permissions involved, detection path, and response delays. Improve the controls supported by the evidence, whether that means stronger authentication, narrower authority, better secret handling, clearer ownership, or more complete logging. Avoid claiming a root cause that the investigation has not established. Identity incident response ends with verified restoration and an understood plan for remaining work. Stopping unauthorized access is the immediate priority, but the organization also needs confidence that alternative routes were investigated and recovery did not recreate the same exposure. A practiced process gives responders the information, authority, and coordination needed to reach that outcome.