# How to Investigate a Suspicious Login Alert

A location alert is the starting point\. Identity events, session use and application actions tell you what to contain\.

<https://rdpcore.blog/en/articles/investigate-a-suspicious-login>

![Access badge, laptop and time markers on an incident\-response desk\.](<https://rdpcore.blog/media/055bf4b9d83424c5453509c77126d70e/1600.jpg>)

Correlated events support a stronger conclusion than location alone\.

A login arrives from an unfamiliar country five minutes after a normal session\. That deserves investigation, but a country label alone cannot distinguish theft from a corporate VPN or a mobile carrier's routing\. The first useful output is a timeline, not a verdict\.

## Preserve the facts you have

Record the event time and timezone, account, authentication method, session identifier or safe correlation ID, and the detecting rule\. Check whether the event was a failed attempt, a completed sign\-in or the reuse of an existing token\. Those cases imply different containment actions\.

Correlate identity\-provider events with application activity\. Look for credential enrollment, recovery changes, privilege elevation, exports and unusual API calls\. Avoid copying raw session cookies or tokens into an incident ticket\.

## Test competing explanations

Was the source an expected VPN exit? Did a device change coincide with a legitimate enrollment? Is the reported travel impossible only because two systems use different timezones? Ask the user through a trusted channel independent of the questionable session\. A reply inside that session cannot establish control of the account\.

If evidence suggests an active compromise, contain according to the organization's incident procedure\. Revoking sessions may be necessary even after a password reset\. Review API keys, app passwords and newly enrolled authenticators separately\.

## Verify containment and recovery

Confirm that the suspicious session can no longer access protected resources\. Preserve the evidence needed to understand the entry point and check for actions taken before revocation\. Record uncertainties alongside conclusions\. A defensible incident record states what happened, what remains unknown and which observable condition would trigger escalation\.

## Further reading

[NIST SP 800\-61 Rev\. 3: Incident Response](<https://csrc.nist.gov/pubs/sp/800/61/r3/final>)

Related guide: [Plan Account Recovery Before Rolling Out Passkeys](<https://rdpcore.blog/en/articles/passkeys-account-recovery>)\.
