Sending each country’s sign-in logs to that country’s SIEM

A multi-country group with one tenant has one stream of sign-in and audit logs, and dozens of security teams that each need their slice of it, and only their slice. Legal wants it that way, the country security leads want it that way, and a single global SIEM that everyone can read is the thing nobody wants.

The catch: an Entra ID sign-in event doesn’t say which country the user belongs to. It says who, from where, to what. Country is a property of the user, and it lives in the directory.

How it routes

Events flow from Entra ID into Stream Analytics, which joins each one against a small reference table, user → country, and forwards it to that country’s SIEM. The table is refreshed on a schedule by an Azure Automation runbook that reads the directory with a managed identity: no stored credentials, no certificate to rotate.

The interesting part is the rule the runbook applies when deciding a country, because the directory is never fully tidy:

1. The business-unit attribute, if set: that’s the organisation’s own answer.
2. Otherwise the usage location: where the licence says the person works.
3. Otherwise nothing. The user is dropped from routing.

Dropping is deliberate. Guessing a country from an email domain or a sign-in IP would put someone’s events in front of the wrong security team, and that is worse than no team seeing them.

The number that matters

Because unmatched users are dropped, the metric to watch isn’t how many events were routed but how many users have no country. That count is reported with every refresh, and it’s the to-do list for the identity team: every name on it is a directory record to fix. Routed events are the outcome; dropped users are the work.

What you could take from this

Two things. Put the lookup next to the stream rather than inside it, so it can be refreshed without touching the pipeline. And when a routing rule can’t decide, make it refuse loudly instead of guessing quietly.