Security playbook · AI Employee: Sig

Anomalous Login

True positive detection reduces breach dwell time

Install this playbookBack to marketplace
The problem

Anomalous logins are drowning in noise. Impossible-travel alerts fire whenever a VPN reconnects, new-device alerts fire on every phone upgrade, off-hours-login alerts fire on the same three people every week. Security teams silence the alerts, and then the one real account compromise arrives dressed as another false positive. Detection without response is theatre.

At a glance
Trigger
Monitor event
Approvals
User confirms; security on repeated denial
What it does
Writes to your systems
Systems
Okta · GeoIP · EDR
How it feels in production

An hour-by-hour walkthrough.

02:14. Sig receives an Okta signal: a login from Kyiv on Priya's account. Priya's last known location was Bangalore, four hours ago. Impossible travel. Before opening a ticket, Sig checks the context. Priya's calendar has no travel booked. Her Slack status is "working" from her Bangalore office an hour ago. The Kyiv login was from a device fingerprint never seen on her account, a residential VPN endpoint frequently associated with credential-stuffing. The user-agent claimed macOS Chrome but the TLS fingerprint said Windows. Signal-fusion score: 0.94. Action tier: high. Sig: 1. Suspends Priya's session on every IdP-connected app (Okta forced logout). 2. Locks the account pending MFA re-enrolment. 3. DMs Priya via her verified phone number (SMS out-of-band) with a passphrase-verified callback link. 4. Files a P1 incident with the full timeline and evidence bundle in Jira Service Management. 5. Pages the on-call security engineer with the packaged context. Compare that to the 20 other anomalous-login signals Sig received the same hour: 17 were VPN reconnects with same device + expected location; 2 were confirmed travel from the calendar; 1 was a new-device login preceded by an in-app device-enrolment step. All 20 were auto-closed with a note. No ticket, no page, no false-positive drain. The security engineer arrives at their desk to one real incident and 20 lines of "closed, here's why" — not 21 alerts to triage.
How it works

Step by step.

  1. 01

    Ingest login signals from every IdP + endpoint

    Read Okta / Azure AD / Google Workspace login events, EDR endpoint events, VPN connection logs. Normalise to a common login record with location, device fingerprint, network context, user-agent, TLS fingerprint.

    Okta · Azure AD · Google Workspace · CrowdStrike · SentinelOne
  2. 02

    Fuse signals before scoring

    Cross-check the login against: user's calendar, Slack status, recent travel-request tickets, recent device-enrolment steps, VPN reconnect history. A signal in isolation is noise; the fusion is the signal.

    Google Calendar · Slack · IT ticketing · VPN logs
  3. 03

    Score + tier the response

    Multi-factor score (0-1) drives tier. Under 0.3: auto-close with note. 0.3-0.7: notify user + require in-app confirmation. Over 0.7: session revoke + account lock + P1 incident + page security.

    Scoring engine · Policy config
  4. 04

    Execute the response

    For high-tier: force logout on every SSO-connected app, lock the account, contact the user out-of-band (SMS to verified phone), file P1 incident with evidence bundle, page on-call security.

    Okta · Twilio · Jira Service Management · PagerDuty
  5. 05

    Close the loop + write the audit trail

    Auto-closed low-tier events get a one-line audit entry with the reason. High-tier events stay open until the security engineer resolves them. Weekly digest surfaces patterns (repeat offenders, geographies, times).

    SIEM · Audit log · Security digest
Systems and wiring

What you connect to make this run.

Okta · Azure AD · Google Workspace

read+write

Consume login events via System Log API (Okta) / Sign-In Logs (Azure) / Reports API (Google). Write: force-logout, session-revoke, account-lock via admin APIs.

Calendar · Slack · IT ticketing

read

Fusion context. Calendar tells us if the user is travelling; Slack presence tells us if they're active elsewhere; ticket search tells us if they filed a laptop-swap request yesterday.

Twilio · SMS gateway

write

Out-of-band contact for high-tier events. Never rely on email or Slack alone — those are the exact channels an attacker just gained access to.

Jira Service Management · PagerDuty

write

P1 incident with the full evidence bundle: timeline, signal fusion detail, action taken, user contact status. On-call security engineer paged with the incident link.

What changes

Before and after, honestly.

False-positive rate on impossible-travel alerts
Before
70-90% (VPNs + calendars ignored)
After
Under 8% (signal fusion filters obvious explanations)
Time from anomalous login to session revoke (real threat)
Before
20-90 minutes (analyst investigates + acts)
After
Under 60 seconds (auto-executed at high tier)
Security alerts per week reaching a human
Before
300-800 (drowning)
After
10-40 (only real signal + policy-tuning exceptions)
User complaints about account lockouts
Before
5-10 per week (over-aggressive rules)
After
Under 1 per week (tier + out-of-band verification)
Related

Playbooks that pair with this one.

Security

Compromised Credential Response

The full response playbook when the credential is confirmed compromised.

Frequently asked

Answers about this playbook.

What if the user is legitimately travelling but forgot to book it?

Mid-tier response (0.3-0.7 score) — user gets an in-app confirmation prompt, not a hard lock. If they confirm from a trusted device, the login proceeds and the trip auto-registers. Hard lock is only for high-fusion-score events where the evidence is overwhelming.

Can we exclude executives or on-call staff from auto-actions?

Yes but reluctantly. Exec bypass is a well-known attacker target; better to keep the flow with a shorter response tier (notify security immediately, don't hard-lock without human confirmation). Every bypass is a signed exception in policy config with an owner and expiry.

How does it handle service accounts + automation?

Service accounts have their own baseline (fixed set of IPs, no user-context). Any deviation is high-tier by default, since a service account rarely legitimately drifts. Separate policy config from human accounts.

What about M365 / Google alerts we already get?

Sig subscribes to those alerts as one of many signals — never as the sole trigger. The vendor alerts alone are noisy; the fusion + action layer sits on top and translates them into decisions.

Is the SMS out-of-band step a security risk (SIM swap)?

SMS is the tie-breaker, not the auth. The auth is: user confirms via a device we already trust (their laptop, their phone's authenticator app). SMS is the notification that says "we've locked your account, use your trusted device to verify." Attacker with a SIM swap sees a notification for an account already locked.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Security playbooks