Identity controls that move under you

Most of the effort in identity security has gone into the sign-in: stronger factors, phishing-resistant methods, token protection. The attacks now being reported win the account somewhere else, at the moment a new credential is registered. Huntress documents a Windows Hello for Business key, bound by an attacker in the Knight Office intrusion, that let the attacker sign in passwordless after token replays had failed, and warns that such a key survives the revocation of existing tokens. Microsoft says an added MFA method is a durable persistence mechanism when the reset is incomplete, with tokens, sessions or credentials still live. And Microsoft's published enrolment schedule gives the request to register a credential a legitimate-looking reason to arrive. From 1 February 2027, users whose only method is SMS or voice meet a blocking passkey registration prompt, and that is the day to expect the phone calls.

I covered the runbook gap in the passkey migration post and I take it as given here: after a confirmed phish, list the user's registered methods and delete what they cannot account for. This post is about what has happened since, and about the control that sits upstream of that runbook step.

MFA and Conditional Access decide at the sign-in. The tokens that decision produces then carry the identity for between one hour and 28 hours at the resource, with a refresh token behind them that lasts up to 90 days of inactivity and has no maximum age at all. Continuous access evaluation (CAE), token protection and session revocation each narrow that window. None of them covers all of it, and each leaves a different part uncovered.

The rest of this post is the arithmetic behind that, taken from Microsoft's own pages as they stood on 30 October 2026, followed by four changes you can make against your own tenant.

If your last identity project was an MFA rollout, a passkey migration or a Conditional Access baseline such as the one in Conditional Access policies that actually work, this is not an argument that it was wasted. It is an argument that all of it happens at the start of a session, and that the rest of the session is governed by something else.

Which of your Global Administrators did you hire?

On 15 October 2026, from 01:58 UTC, ConnectWise Cloud Management service principals assigned themselves directory roles, mostly Exchange Administrator, in roughly 50 tenants monitored by Huntress. Between 03:44 and 03:49 UTC, in one tenant, the ConnectWise Cloud Management app for Microsoft Teams "added itself to the Global Administrator role". It then added new client secrets to two other applications in the tenant. Huntress later saw the same sequence in a second tenant.

Nobody in that tenant hired a Global Administrator. A vendor's application became one, and the sources do not show who, if anyone, authorised it. Microsoft assesses that Storm-0940, which it describes as China-state aligned, was responsible. ConnectWise says the root cause remains under investigation and reports no indication that its backup archives were compromised. It disabled seven application identities at 07:00 UTC on 17 October, and partners must now re-authorise each tenant under a new application, ConnectWise Cloud Backup for M365, which is a fresh consent worth reviewing.

Later that morning on 15 October, according to SpecterOps, the ConnectWise Cloud Backup application, formerly SkyKick, signed in to customer Microsoft 365 tenants from a hosting provider address between 06:13 and 08:34 UTC. The sign-ins used the application's own credential, so the attacker inherited whatever customers had granted the application.