A foreign sign-in warning from work SSO is a request to investigate, not proof that an attacker used your account. Preserve the original alert, verify it through an independent company channel, and compare the event with your actual travel, device, application, and activity before anyone labels it safe or compromised.

Key Takeaways:

Save the time, application, device, location, IP address, error, request ID, and correlation ID before retrying.

Open the identity portal from a trusted bookmark or contact IT through a verified channel instead of following an unexpected message link.

A foreign IP can reflect legitimate travel, carrier routing, or an approved corporate path; it is not a verdict by itself.

If you do not recognize the event, contain it through the employer's incident process rather than improvising account changes.

Only the authorized identity or security team should close the alert as safe, compromised, or dismissed.

This checklist handles one triggered identity event. Use the broader work-account protection guide for preparation before a trip and the international travel planning guide for the wider travel sequence.

1. Preserve foreign sign-in and risky sign-in evidence

Record the exact local time, displayed time zone, account, application, device name, browser, operating system, country or region, IP address, and risk wording. Copy any error code, request ID, correlation ID, ticket number, or notification ID. Microsoft notes that sign-in details use identifiers to connect one attempt with related activity, and its portal may display time in the administrator's time zone rather than the traveler's time zone.［1］

Capture only what policy permits. A screenshot may expose a username, tenant name, customer name, internal application, IP address, QR code, or token. Redact it before sending through an approved support system, and do not paste corporate logs into a public chat, personal email, or consumer troubleshooting forum.

Write a short timeline while it is fresh: when you last signed in successfully, when you traveled, which device and network you used, whether you changed SIMs, and whether you initiated the flagged application. Note whether the attempt succeeded, failed, or stopped at MFA. Avoid rapid retries because they can create more events, trigger lockout, or hide the first useful error among repeated entries.

Do not delete the notice merely because the city looks plausible. Also do not reset everything immediately if your organization requires evidence preservation or a specific response order. Save the original facts, then move to a verified channel.

2. Verify the alert and the support route independently

Treat an unexpected security message as untrusted until you confirm it. Do not use its sign-in button, telephone number, QR code, attachment, or reply address. Open the official SSO or security portal from a managed bookmark, company launcher, password manager entry, or a URL supplied in established policy.

If you cannot reach the portal, contact the service desk through a number or application you already know. A caller who asks for your password, one-time code, recovery code, push approval, or screen-control session is not following a safe verification process. End the contact and start again through the published channel.

Compare the independent portal with the message. Check whether both show the same account, application, time, device, and event identifier. A real alert can still describe benign travel, and a convincing message can still be phishing. Authenticity and event interpretation are two separate questions.

If email or company chat might be compromised, use a second approved route such as a service-desk number, managed mobile application, or manager escalation path. Microsoft specifically cautions administrators that confirming an event with the user over email or Teams may be unreliable when those channels are part of the suspected compromise.［2］

3. Compare SSO sign-in logs with what you actually did

Start with who, how, and what: which identity signed in, which client or authentication method was used, and which resource was requested. Then compare application, device registration or compliance state, browser, operating system, IP address, broad location, authentication method, and Conditional Access result. SSO sign-in logs can also show whether the event was interactive or a background token use.［1］

Ask yourself concrete questions: Did you open that application at that time, and was it the same managed device and browser? Did you approve an MFA prompt or see the same error on screen? Was there a second event for a resource you never use? A matching country alone is weak evidence; a matching time, device, application, and user action is stronger.

Remember that IP geolocation is approximate. Microsoft states that mobile providers and VPNs can issue addresses from centralized pools far from the device's physical location.［1］ Hotel gateways, corporate egress, roaming carriers, security proxies, and cloud-hosted applications can also make the displayed place differ from your hotel or office.

Do not publish the IP or use a public lookup as the final answer. Give IT the observed address and context. The security team can compare it with corporate egress ranges, other tenant events, threat intelligence, device records, and your normal history without disclosing sensitive infrastructure.

4. Decide whether the event is expected, uncertain, or unauthorized

Use three working states rather than forcing an early yes-or-no answer. Expected means you recognize the exact action and the surrounding signals fit. Unauthorized means you did not initiate it or there is corroborating evidence such as an unknown device, impossible application, unsolicited MFA approval, mailbox change, or data access. Uncertain means the evidence is incomplete or contradictory.

For an expected event, tell IT the country, dates, approved device, application, network type, and the action you performed. Do not personally dismiss the alert if the system reserves that action for an administrator. Microsoft recommends that administrators validate application, device, location, IP address, and user context before marking a risky sign-in safe.［2］

For an unauthorized or uncertain event, stop signing in through the suspect path. Disconnect only if company policy directs you to do so, and use a separate trusted device to contact the incident team. Report any MFA prompt you denied or accidentally approved, any password entered into an unexpected page, and any sensitive action performed after the alert.

A VPN cannot classify an employer's SSO event, approve a foreign location, revoke corporate sessions, or override identity policy. A consumer VPN must not be used to disguise your location or work around a risk decision.

5. Contain a suspected compromise through the employer

Follow the organization's order because identity systems are interconnected. The response may include blocking the account, resetting the password, requiring MFA re-registration, revoking refresh and access tokens, removing an unknown authentication method, or preserving logs. Microsoft places those actions with administrators or configured self-remediation flows, not with an unauthenticated helper.［2］

Tell the incident owner what you know and what you do not. Include the event identifiers, whether the password was entered, whether MFA was approved, the last known good session, devices currently under your control, and high-value resources the identity can reach. Do not claim that changing a password automatically closed every session unless the identity team confirms it.

If you used the same password elsewhere, disclose that fact through the incident channel and change affected independent accounts from a trusted device. Do not reuse the new work password. Check for unexpected recovery-method changes, mailbox rules, app consents, forwarding, privilege changes, downloads, or financial actions only where your role and policy allow.

Preserve suspicious messages and headers without forwarding active links broadly. If the alert followed questionable public Wi-Fi, use the separate post-Wi-Fi response guide to document the network exposure, but do not assume the network caused the identity event.

6. Confirm recovery with the sign-in correlation ID and final decision

Access is not restored merely because one application opens. Ask the authorized team to confirm the event disposition, account risk state, session revocation, required credential changes, device trust, and whether any applications remain blocked. Retest only the minimum approved resources from the approved device and network.

Record the ticket number, actions taken, decision owner, restoration time, and any monitoring window. If the event was legitimate travel, ask whether the employer needs travel dates, approved egress ranges, or another documented control for future trips. Do not ask for a blanket exception that weakens policy for every location.

If the event was malicious, confirm what other identities or data were reviewed and what follow-up is assigned. If it was a benign alert, retain enough evidence to explain the decision without copying sensitive logs into personal storage. The goal is an auditable result, not simply making the warning disappear.

Before the next trip, verify your approved work location, backup authentication method, service-desk route, and managed-device status. That preparation reduces pressure to accept an unsafe prompt when the same alert appears under travel conditions.

Summary

Preserve the first alert and its identifiers before retries change the evidence.
Verify both the notice and the support contact through independent trusted routes.
Compare the full event context; a foreign IP or city alone does not prove compromise.
Let the authorized identity team classify and remediate the event.
Confirm sessions, device trust, access, and the written incident outcome before closing the case.

FAQ

Does a foreign sign-in alert mean my work account was hacked?

No. It means the identity system observed a signal worth evaluating. Legitimate travel, carrier routing, or an approved corporate route can affect location, while an unknown device or unrecognized activity raises concern. Use the complete event context and the employer's investigation process.

Can IP geolocation show my exact hotel or office?

No. IP location is an estimate and may reflect a carrier gateway, VPN egress, proxy, or registration record. Do not use the displayed city as precise physical-location evidence.

Should I click the alert link to confirm the sign-in?

Open the official portal independently instead. A genuine-looking alert can be copied by a phisher, and a real alert does not make every embedded link safe.

What is a sign-in correlation ID for?

It helps support and administrators group or locate related sign-in activity. Preserve it with the request ID, timestamp, application, and error, but do not treat it as proof that the attempt was yours.

Should I keep retrying while the alert is active?

No. Repeated attempts can add noise or trigger lockout. Preserve the first event, make at most the bounded checks your employer permits, and contact IT.

Can I mark the event safe because I am traveling in that country?

Not by location alone. Confirm the application, device, time, authentication action, and other activity, then let the authorized team apply the tenant's decision.

Can a personal VPN clear the SSO risk state?

No. It may change the visible network path, but it cannot establish that an event is legitimate or change corporate identity policy. Do not use it to conceal location or bypass a block.

Disclaimer: This article is for general informational purposes only and does not constitute legal, technical, or other professional advice. We make no guarantees regarding the accuracy, completeness, or timeliness of the content.

Sources

Microsoft Learn, Learn about the sign-in log activity details — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-in-log-activity-details
Microsoft Learn, Investigate risk with Microsoft Entra ID Protection — https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-investigate-risk

Sources checked 12 September 2026.

Related Articles:

Work SSO Flags a Foreign Sign-In: What to Check