The first 30 minutes after a suspicious login

A sign-in alert can mean a stolen password, a traveler on hotel Wi-Fi, a misconfigured integration, or just a false positive. The alert deserves attention; it does not yet tell you which story is true.

Start by slowing the situation down. A measured first response helps protect the account without destroying the evidence you need to understand what happened.

First five minutes: verify and scope

Use a trusted admin session and the identity provider’s own audit logs. Don’t follow links in an alert email or ask the possibly affected user to click a “verify” link. Confirm the account, timestamp, source IP, device, application, and authentication method. Compare the event with the person’s usual pattern and any travel, VPN, or maintenance window you already know about.

Contact the user through a separate, known-good channel. Ask whether the activity was theirs; do not send passwords, reset links, or sensitive incident details over a channel you have not verified.

Next: contain access proportionately

If the user does not recognize the sign-in, or you have corroborating indicators, use your identity platform’s incident procedure. Depending on your environment, that may include:

• Revoking active sessions and refresh tokens.
• Resetting the password from a trusted device and checking that recovery details were not changed.
• Reviewing and removing unexpected MFA methods, app passwords, OAuth grants, or registered devices.
• Temporarily restricting access while keeping a safe recovery path available.

Changing a password alone may not end existing sessions or remove a malicious consent grant. Check the controls your identity provider actually applies, and confirm the user can recover access safely.

Contain what you can verify. Preserve enough context to understand what happened.

Preserve the useful evidence

Record the alert ID, timestamps (including timezone), account, source IP, device identifiers, application, authentication results, and the actions taken. Export relevant audit events using your normal process before short retention windows expire. Keep original timestamps and note who collected the records.

A single unfamiliar IP address is not proof of compromise. VPNs, mobile carriers, and shared egress can make geolocation noisy. Look for a chain of activity: unfamiliar authentication followed by a mailbox rule, a new credential, unusual data access, or a changed recovery method.

Check for persistence and impact

Review activity from shortly before and after the sign-in. Prioritize changes that can preserve access or redirect information:

• New MFA factors, passkeys, devices, recovery contacts, or API credentials.
• Mail forwarding, inbox rules, delegates, or suspicious OAuth application consent.
• Unexpected privilege changes, cloud sessions, file sharing, and access to sensitive services.

Follow your incident-response plan if you find evidence of broader access, regulated data exposure, or a privileged account compromise. Bring in the appropriate security, privacy, legal, and service owners early; notification duties depend on your organization and jurisdiction.

What not to do

• Don’t delete the account or wipe a device before preserving relevant evidence.
• Don’t assume a forced password change alone has evicted an attacker.
• Don’t forward suspicious messages around as attachments without following your safe handling procedure.
• Don’t promise that data was or was not accessed until you have checked.

After the immediate response

Once access is contained, close the loop: confirm the user is safely back in, document the timeline, identify the likely entry point, and address the cause. That might mean better phishing-resistant authentication, conditional access, reduced standing privileges, or a clearer way for staff to report unusual prompts.

Keep the playbook short enough to use under pressure. Name the person who can revoke sessions, where to find sign-in logs, how to reach the user out-of-band, and when to escalate. Test it before the next alert arrives.