Entra under pressure

In August 2026 a criminal seller advertised around 3.6 million employee records taken from corporate Entra ID tenants, across nine large organisations. The datasets are reported to hold names, corporate email addresses, phone numbers, employee IDs, job titles and department information, which is to say the ordinary contents of a directory.

What makes it worth your attention is what it was not. No Azure vulnerability and no zero day have been found. Researchers attribute the access to stolen credentials and infostealer infections, which means ordinary valid logins reading exactly what those logins were always permitted to read. The claims come from a criminal seller, and the scale may not survive scrutiny. The mechanism will, because it needs nothing your tenant does not already allow.

Earlier this year I published a post about the Graph API endpoints that matter to architects. It walks through tenant discovery, identity and access auditing, privileged role review and licensing analysis. It is, read uncharitably, a reconnaissance guide. The same calls I use to produce a tenant assessment for a client produce a complete map of that client's directory for anyone else who can make them.

That is the point I want to make here, not a problem with the post. The difference between an architect running an assessment and an attacker running reconnaissance is who is holding the credential, and whether anyone is looking, not the API, the permissions, or the tooling.

Here is the procedure. A user reports a phish, or your tooling catches one. You reset the password, revoke the sessions, and close the ticket. It has been the correct sequence for a decade, and it is what almost every account-compromise runbook still says.

There is now a credible technique it does not cover, and on 1 September Microsoft made the conditions for it a great deal more common across every tenant still using SMS or voice. The technique is claimed rather than captured, and I will be precise at the end about how much weight that supports. What matters more is what your own tenant would do about it, because that part is documented and has a date attached.

You disable a leaver's account in Active Directory, reset the password, and move on. Within half an hour Microsoft Entra Connect Sync has carried the change to Entra ID, and the cloud side of that person's access starts to close. From 7 April 2027 that stops happening on a class of server that looks fully patched, and under password hash synchronisation the failure is quiet: sign-in keeps working, and the leaver keeps their access.

When I checked Microsoft's documentation on 17 September, it said Connect Sync servers below version 2.5.79.0 would stop synchronising on 30 September 2026. The pages now carry update dates between 29 September and 1 October, and they say something different. The deadline is 7 April 2027. The minimum version is 2.6.84.0, a build Microsoft released on 7 July, ten weeks before I read the page that still named 2.5.79.0. And a third condition appeared: the server must use application-based authentication, which replaces the Sync_ service account that Connect Sync uses to sign in to Entra ID with an app registration and a certificate.

That third condition is the one that will catch people. Auto-upgrade, which most organisations rely on to keep Connect Sync current, has never delivered a build that meets the version floor, and since July background sync no longer switches the credential either. So the version number alone no longer tells you whether a server survives April.