Is this alert real? Service account authenticating from a new ASN at 02:40

Overnight alert: a service account used by a batch job authenticated successfully from an ASN we have never seen, at 02:40, then performed a normal-looking sequence of API calls and stopped. No failed attempts before it. MFA is not enabled on the account because it is non-interactive.

My instinct says look at it hard rather than close it. Talking myself through it here because the shift handover disagreed with me.

Look at it hard. The absence of failed attempts is the part that should worry you, not reassure you. A successful first attempt from a new location means either a legitimate infrastructure change nobody told you about, or someone with a working credential.

First question: did anything change in the batch job's hosting? Cloud provider region moves and NAT changes produce exactly this signature and are the most common benign explanation.

Agreed. Check whether the ASN belongs to a cloud provider and whether your own workload could have moved there. Then check what the credential can reach, because the calls being 'normal-looking' is only comforting if you know what normal is for that account.

Also worth pulling: was the same credential used from the old ASN in the same window. Two sources at once is a different conversation.

This is why we moved service accounts to workload identity where we could. A non-interactive account with a long-lived secret and no MFA is a permanent exception, and 'it is a batch job' is how it stays one for four years.

Resolved: it was a genuine infrastructure move, the batch job was migrated to a different region and the change record went to the platform team's board, not ours. Both sources appearing in the same window was the clincher for the timeline.

Action taken anyway: the credential is now rotated and scoped down, and platform changes that alter egress addresses will notify us. Thanks both, the two-source check is going in the runbook.