Impossible Travel and Anomalous Sign-In Detection: Building Login Analytics That Survive VPN Noise

Impossible travel alerts are among the first identity detections most teams switch on, and among the first they learn to ignore, because VPNs, mobile carriers and cloud egress make honest users look like they teleport. The signal is still valuable: stolen passwords and session cookies get used from somewhere the real user is not. This guide covers the detection logic behind impossible travel, atypical travel and other anomalous sign-in analytics, how the main identity providers implement them, where false positives come from and how to tune them without blinding the rule. It is written for detection engineers, SOC analysts and identity administrators. Prevention and response for account takeover as a whole are covered in the Account Takeover Prevention Guide; this page goes deeper on the analytics.

Key takeaways

• Velocity alone is not a detection. A speed calculation between two IP geolocations produces mostly VPN and carrier noise. Combine it with a change in device, user agent or ASN to get alerts worth an analyst's time.
• Interactive and non-interactive sign-ins need different rules. Token refreshes egress from cloud regions unrelated to the user, so most velocity rules exclude them; separate token-anomaly detections cover replay.
• Know your egress. Corporate VPN, secure web gateway, VDI and zero trust proxy ranges must be modelled as named locations or exceptions by ASN, not by blanket country exclusion.
• Baselines need history. Entra's unfamiliar sign-in properties detection runs a learning period of at least five days per new user; Okta evaluates the last 10 to 50 successful sign-ins depending on the condition. New and dormant accounts are blind spots.
• Response matters more than the alert. Revoke sessions and refresh tokens, not just the password, and check for new MFA methods, OAuth consents and inbox rules created in the same window.

What anomalous sign-in detection actually measures

Every sign-in event carries a set of properties: source IP, the ASN that owns it, a geolocation derived from the IP (or from device GPS in some apps), device and browser fingerprint, client application, authentication method and outcome. Anomaly detections compare those properties with either physics (could one person be in both places?) or history (has this user ever looked like this?).

MITRE ATT&CK tracks the behaviour these rules hunt as T1078 Valid Accounts and T1078.004 Cloud Accounts, with session theft as T1539 Steal Web Session Cookie and replay as T1550.004 Web Session Cookie. In MITRE D3FEND the matching defensive technique is D3-UGLPA User Geolocation Logon Pattern Analysis.

How the main identity providers implement it

Platforms are listed alphabetically. Both platforms ship built-in detections; most teams also write their own rules in a SIEM for consistency across providers.

Microsoft Entra ID Protection

• Atypical travel (riskEventType unlikelyTravel): two sign-ins from geographically distant locations where at least one location may be atypical for the user; the algorithm weighs time between sign-ins against travel time and uses adaptive learning for new users. Calculated in real time.
• Impossible travel (mcasImpossibleTravel): supplied by Microsoft Defender for Cloud Apps; activities from distant locations within a period shorter than travel time. Calculated offline.
• Unfamiliar sign-in properties (unfamiliarFeatures): compares IP, ASN, location, device, browser and tenant IP subnet with history. New users are in a learning mode with this detection off; the minimum is five days, and long inactivity can return a user to learning mode. Microsoft notes that on non-interactive sign-ins it deserves increased scrutiny because of token replay risk.
• Related detections: New country (newCountry), Anonymous IP address (anonymizedIPAddress), Malicious IP address, Anomalous Token (anomalousToken, historically noisier at low and medium risk), Password spray, Verified threat actor IP.
• Risk levels: low, medium and high. Low-risk detections age out after six months; medium and high persist until remediated or dismissed.

Availability: atypical travel and unfamiliar sign-in properties require Microsoft Entra ID P2. Impossible travel and new country require Entra ID P2 plus a Defender for Cloud Apps licence, or Microsoft 365 E5 with EMS E5. See the Entra ID Sign-In and Audit Log Detection Guide for the log fields.

Okta behavior detection

• Location conditions: New city (last 20 successful sign-ins by default), New state (15), New country (10) and New geo-location (20, outside a 20 km radius of prior sign-ins; radius and count configurable).
• Device and network: New device (20; a browser change counts as a new device), New IP address (50), New ASN (50).
• Velocity: evaluates two successive sign-in attempts against a default threshold of 805 km/h (500 mph).
• Use: behaviours are referenced in sign-on and authentication policies to step up or deny, and are recorded in the System Log for SIEM rules.

Availability: check your Okta edition and engine (Classic or Identity Engine) for which behaviours and policy actions apply. See the Okta System Log Detection Guide.

Building your own impossible travel rule

Built-in detections are opaque and licence-dependent. A SIEM rule gives you control of thresholds and exceptions, and lets you apply one logic across Entra, Okta, Google Workspace and SaaS apps. Elastic's published Entra ID rule is a useful worked reference: it looks at successful interactive sign-ins within a 90-minute window and alerts when implied speed is at least 800 km/h and separation at least 500 km, excluding non-interactive sign-ins because token refresh traffic egresses through unrelated cloud regions.

1. Select events: successful, interactive sign-ins only for the velocity rule. Failed attempts belong in spray and brute-force rules.
2. Pair consecutive sign-ins per user: sort by user and time and compare each sign-in with the previous one, rather than counting distinct countries per hour, which misses pairs that straddle the window.
3. Compute distance and speed: great-circle distance between geolocations divided by elapsed time. Set a minimum distance (several hundred kilometres) so that city-level geolocation error does not fire alerts.
4. Enrich: add ASN and organisation name, whether the IP is in a named or trusted location, device and user-agent fingerprint, authentication method and application.
5. Suppress known egress: drop pairs where either IP belongs to corporate VPN, secure web gateway, zero trust proxy or VDI ranges. Do the exclusion at the exception layer by ASN or CIDR, not by country.
6. Score, do not just threshold: raise priority when the second sign-in also has a new device, a different browser family, a hosting-provider ASN, an anonymiser flag, or touches admin portals and Graph or API endpoints.
7. Correlate follow-on activity: look for MFA method registration, OAuth consent, inbox rule creation or recovery detail changes by the same user within an hour or so.

VPN noise and other false positives

Microsoft's own investigation guidance for atypical travel says that if the IP range belongs to a sanctioned VPN, confirm the sign-in as safe and add the range to named locations in Entra ID and Defender for Cloud Apps. The SigmaHQ rule for the Entra impossible travel risk event lists the classic false positive: connecting to a VPN, doing some work, dropping the VPN and continuing.

The reverse problem is attackers who deliberately look local. Residential proxy networks let an attacker sign in from an IP in the victim's own city and ISP range, which defeats any purely geographic rule. Device, user-agent and authentication method changes are then the only signals left. See the Residential Proxy Networks and Abuse Guide. MITRE ATT&CK lists proxy chains as T1090.003 Multi-hop Proxy.

Decision guidance: built-in, SIEM or both

• Small organisations on one identity provider: use the built-in detections and wire them to risk-based access policies (step up to phishing-resistant MFA for medium sign-in risk, block or force reset for high). Writing custom velocity rules rarely pays off at this size.
• Multiple identity providers or many SaaS apps with local logins: build a SIEM rule set on normalised sign-in events so one exception list covers every source. Keep the built-in detections as an extra input to the score.
• Large enterprises with global staff: invest in egress modelling and per-user baselines; consider suppressing pure velocity alerts entirely and alerting only on composite scores.
• Enforce or alert: enforcement in the sign-in flow (step-up or block) stops the attacker before access but costs user friction; offline detections reach the SOC after the fact. Use real-time detections for enforcement and offline ones for investigation.

Implementing and tuning: a phased approach

1. Collect: stream interactive and non-interactive sign-in logs, risk detections and audit logs to the SIEM with at least 90 days retention so baselines and investigations have history.
2. Model egress: inventory VPN, SWG, proxy, VDI and office ranges; register them as named or trusted locations and in a SIEM lookup.
3. Run in alert-only mode for two to four weeks: record every alert with its disposition (true positive, VPN, travel, carrier, other). Tune exceptions from the dispositions, not from guesses.
4. Add composite scoring: promote alerts with device, ASN or method changes; demote pure velocity pairs between known egress points.
5. Connect to enforcement: link risk levels to access policies for a pilot group, then widen. Keep a rollback: switch the policy to report-only if lockouts spike.
6. Write the response runbook: revoke sessions and refresh tokens, reset credentials, remove attacker-added MFA methods, OAuth grants and device registrations, and confirm with the user through an out-of-band channel. See the Account Takeover Response Playbook.
7. Review quarterly: new VPN providers, office moves and IP database changes erode tuning over time.

Where identity fits: service accounts and workload sign-ins

Velocity and "new location" logic assumes a human who travels. Service accounts, service principals and API keys do not travel: they should sign in from a small, stable set of IPs or workloads. That makes location a stronger signal for non-human identities, not a weaker one.

• Allow-list, do not baseline: for service principals and workload identities, define expected source ranges and alert on any sign-in outside them. Entra workload identity risk and Conditional Access for workload identities exist for this purpose.
• Do not exempt service accounts from detection: teams often exclude them from user-risk rules because they generate noise, which leaves the most privileged credentials unmonitored.
• Watch human accounts used as service accounts: a shared mailbox or integration user signing in from many IPs looks like impossible travel all day. Convert it to a proper workload identity. See the ITDR Guide.

Detection and measurement

• True positive rate: share of anomalous sign-in alerts confirmed as compromise or policy violation. Track per rule; a velocity rule below a few per cent needs composite scoring.
• Alert volume per 1,000 users per week: trend after each tuning change, alongside true positives, to prove tuning reduced noise rather than coverage.
• Egress coverage: percentage of interactive sign-ins from known named or trusted locations versus unknown. A falling figure means new egress paths exist.
• Time to session revocation: median time from a confirmed alert to revoked refresh tokens.
• Self-remediation rate: share of risky sign-ins resolved by a successful step-up by the real user, which reduces analyst load.
• Service identity coverage: percentage of service principals and service accounts with location allow-lists or detections.

Framework mapping

Common failure patterns

• Country exclusions instead of egress exceptions: excluding a whole country because the VPN egresses there also excludes every attacker using that country.
• Excluding all cloud ASNs: silences VDI noise and, with it, attackers on rented cloud servers, the highest-fidelity signal available.
• Password reset without session revocation: stolen refresh tokens and cookies keep working after the reset, so the attacker stays in.
• Velocity on non-interactive events: floods the queue with token refreshes from cloud regions and trains analysts to close alerts unread.
• No coverage for new and dormant accounts: learning periods mean freshly created or reactivated accounts, a favourite attacker target, have no baseline.
• Treating location as identity proof: trusted locations that skip MFA turn a compromised VPN account or residential proxy into a bypass.

Practitioner checklist

• Interactive and non-interactive sign-ins, risk detections and audit logs reach the SIEM with at least 90 days retention.
• All corporate egress ranges (VPN, SWG, proxy, VDI, offices) are registered as named locations and in a SIEM lookup, reviewed quarterly.
• Velocity rules use successful interactive sign-ins, a speed threshold around 800 km/h and a minimum distance.
• Alerts are scored with device, user agent, ASN and authentication method changes, not velocity alone.
• Exceptions are by ASN or CIDR, never by whole country or all cloud providers.
• Risk-based access policies step up or block on medium and high sign-in risk, piloted in report-only mode first.
• The response runbook revokes sessions and refresh tokens and removes attacker-added MFA methods, OAuth grants and devices.
• Service principals and service accounts have location allow-lists and are not excluded from detection.
• True positive rate and alert volume are tracked per rule after every tuning change.

Standards and references

• Microsoft Learn: What are risk detections? (Microsoft Entra ID Protection)
• Microsoft Learn: Risk detection types and levels
• Microsoft Learn: Investigate risk with Microsoft Entra ID Protection
• Okta Help: About behavior detection
• Elastic detection-rules: Microsoft Entra ID Impossible Travel Sign-in
• SigmaHQ: Impossible Travel (Azure Identity Protection)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: Valid Accounts: Cloud Accounts (T1078.004)

Related NHI Mgmt Group resources: Account Takeover Prevention Guide · Entra ID Sign-In and Audit Log Detection Guide · Okta System Log Detection Guide · Residential Proxy Networks and Abuse Guide · ITDR Guide