Your Microsoft 365 backup signs in with a key you do not hold

On Thursday 15 October, in the small hours, a Microsoft 365 backup tool signed in to the tenants of companies that had not called it. No stolen password, no tricked user, no session token hijacked off a laptop. The application authenticated with its own credential and asked for its tokens, which is exactly what it does every night when it copies your mail. The only difference was who was holding the credential.

The headline this week is "backup tool hacked". The reading that matters is a different one, and it applies to you even if you do not use that tool: the key that opens your Microsoft 365 does not live in your Microsoft 365. It lives in the vendor's tenant. You cannot see it, you cannot rotate it, you do not know when it was last rotated. And — this is the part almost nobody has looked at this week — the control Microsoft sells to fence off that kind of identity says in writing, in its own documentation, that it does not apply to it.

What happened, with the timestamps attached

It is worth reading in order, because the order is the argument. All times are UTC and come from Huntress's public analysis and from the vendor's own notice:

• 13 and 14 October. Password-spraying sign-in attempts against four law firm tenants, from a single IP: 144.172.64.128. Nobody got in — smart lockout locked two accounts and no successful user sign-ins were observed. At the time it did not look related to what came next.
• 15 October, 01:58. Service principals assign themselves directory roles — mostly Exchange Administrator. In around fifty tenants at once, out of those monitored by Huntress; nobody knows the real total.
• 15 October, 03:44–03:49. In one specific tenant, a Teams application grants itself Global Administrator and adds a new secret to two other applications: an MSP management one and Huntress's own — the security company that would later publish the analysis. That credential was used to sign in seven times in quick succession; Huntress spotted it and removed it on the 16th. Worth holding on to that: the one who told the story was inside it too.
• 15 October, 06:13–08:34. The application authenticates from that same IP in 17 of the first 290 tenants checked, spread across 17 different partner accounts. The denominator matters: this is a sample, not a census.
• 16 October, 19:00. 162 tenants with confirmed unauthorised sign-ins. In the same analysis: close to a thousand Entra tenants with sign-in activity from that IP, of which more than three hundred succeeded.
• 17 October, 05:01. ConnectWise announces the service interruption: "we recently identified unauthorized access to application identities within the ConnectWise Cloud Backup environment". It adds that it has no indicators to date that partner backup data has been compromised.

The main application is 506e08f9-6e9a-4da4-942b-a099a03644ae, ConnectWise Cloud Backup, formerly SkyKick Backup. It was not the only one: the ConnectWise Cloud Management applications for Teams, Exchange Online and SharePoint Online were abused too. If you manage third-party tenants, those identifiers are literal and searchable in your own console — you do not have to take anyone's word for it.

MFA did not fail. Nobody asked for it.

This is where most conversations this week go sideways. The question that comes up in the meeting is "but didn't we have MFA?". You did. And it was irrelevant, because MFA is evaluated when there is a person to ask. In this flow there is no person: the application presents its own credential and requests a token. There is no second factor to demand, no device to evaluate, no user sign-in risk to look at.

You do not have to deduce it: Microsoft writes it on the first screen of its own documentation about workload identities. It says these identities cannot perform multifactor authentication, often have no formal lifecycle process, and need to store their credentials or secrets somewhere. All three sentences are the vendor's. The third is the one that hurts here: in this case, that "somewhere" was the provider's tenant. The credential was used via client assertion, which means, in Huntress's analysis, that the credential lives in the software vendor's own tenant.

Put shortly: somebody cut a copy of the key to your house and keeps it in theirs. You cannot change that lock.

The control you would reach for says in writing that it does not apply here

If this is your job, the first thing you think is: fine, I will put Conditional Access on the service principal and block sign-ins coming from outside my known IP ranges. That is exactly the policy that would have stopped the access from 144.172.64.128. It exists, it is called Conditional Access for workload identities, and Microsoft documents it step by step.

On the same page, inside a grey note you can read in four seconds, is the sentence that dismantles the plan: "Policy can be applied to single tenant service principals that are registered in your tenant. Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies."

A Microsoft 365 backup tool that a provider deploys into its customers' tenants is, by definition, a third-party multitenant application. The technical reason is coherent even if it is uncomfortable: your policy cannot govern the authentication behaviour of an identity whose home and authority sit in another tenant. That identity's credentials are managed by its home tenant, not yours. It is the same sentence as before, seen from the other side.

And so nobody leaves thinking it is just a matter of buying the licence: that Conditional Access for workload identities requires Workload Identities Premium licences, which are a separate SKU; the only grant control available is block access (you cannot require MFA from an application, because it cannot do it); and if you put the service principal in a group and apply the policy to the group, it is not enforced — it has to be assigned directly. Three details that turn a whiteboard idea into a project. We already wrote about another situation with the same shape, where the official remedy for an incident collided with the customer's own policy: the advice your own policy blocks.

So what is left (which is more than it looks)

This is not one of those stories where nothing can be done. It is one of those where what works is cheap and boring, and that is precisely why it has not been done. Four things, cheapest first:

1. The inventory, which is free and sitting right there. In Entra ID, Enterprise applications: that is the full list of applications that can enter your tenant, with the permissions you granted them, who consented and when. You do not have to take a salesperson's word about their product's permissions: they are written in your own directory. In most companies we look at, nobody has read that list end to end since the tenant was built. If you only do one thing after reading this, open it.

2. The log that did see this. Under Monitoring & health > Sign-in logs there is a separate tab: service principal sign-ins. It is a different tab from the user one, which is why it almost never gets looked at. The whole timeline above — the times, the IP, the 17 tenants — came from there. It is not a control, it is visibility, and it was the only thing that let this be seen from your side of the glass. It did not cost money: it cost remembering that the tab exists. (Smart lockout did its job too on the 13th and 14th, while the attempt was still aimed at user accounts; the moment the attack became an application, it had nothing left to lock.)

3. Consent, which is a decision and not a button. If any user in your organisation can approve an application reading their mail, the inventory in point 1 grows without anyone deciding. Requiring admin consent and setting up the approval workflow turns "someone clicked Accept" into "someone signed". That is an hour of configuration and an internal agreement about who signs.

4. The procedure, written before you need it. And here is the least intuitive detail of the whole week, taken word for word from the published response guidance: disable the application, do not delete it. The reason they give is operational: deleting it removes the consent, and to get the service back you will have to re-consent from scratch. We add a second reason, which worries us more: the consent record takes with it the trace of what the application had been granted and since when — exactly what you will be asked for if anyone comes knocking, be it a customer, an insurer or a regulator. The rest of the procedure is just as dry: disable even if you see nothing unusual, review the secrets and certificates on all of your enterprise applications and app registrations (starting with the management and security ones, which hold the most permissions), and re-enable nothing until the vendor confirms it has rotated its credentials.

Failure is inevitable; an outage is a design decision

A vendor having a credential compromised is a failure. At sufficient scale, credentials leak: that is statistics, not incompetence. What decides whether that failure becomes an outage inside your company is not luck, it is what you had ready the previous Tuesday. Did you have the application list? Does anyone look at the service principal tab? Does the disable-but-do-not-delete procedure exist, or is it improvised at six in the morning?

And something should be said in the vendor's favour, because it changes the diagnosis: according to its own statement, it has no indicators to date that partner backup data has been compromised, and existing archives will remain accessible once service is restored. If that holds — and it is a «to date», not a closing statement — then the backup worked. What broke was the identity the backup used to get in. Those are two different products travelling inside the same contract, and they are bought together because nobody tells you there are two.

The four questions you should be asking us

We sell Microsoft 365 backup. So what follows plays against us, and we are writing it anyway. One thing is being told badly this week and is worth getting right: Exchange Web Services has not gone away. Microsoft began blocking it in phases on 1 October 2026, with an allow-list by application identifier for those who need it, and shuts it down completely on 1 April 2027. For as long as that window lasts, widely used backup products — Veeam among them — are still pulling Exchange Online mailboxes over EWS, because Graph does not yet cover incremental backup properly. It makes no difference: over EWS or over Graph, the tool enters your directory as an application with granted permissions, and upgrading to the version that moves to Graph consists, literally, of granting it more. There is no 365 backup without a privileged identity inside your tenant. Not ours either.

What you can demand is that whoever operates it answers four things without getting nervous. You can ask us, and you should ask anyone with an application inside your directory.

The first is exactly which permissions their application holds in your tenant and which of them are write. You do not need them to answer this one, because the answer is in your Enterprise applications and you can look yourself; what you are measuring by asking is whether they tell you the same thing you can see. The interesting part comes after: why it needs the write permissions and what stops working if you take them away. The second is where the credential that opens your tenant lives, and when it was last rotated. If the answer is "in our environment", do not be alarmed: that is normal and it is how the model works. Be alarmed if they cannot tell you how often it is rotated or who checks.

The third is whether, if that credential is compromised, you hear it from them or from the press — and here the answer is only worth anything with a number of hours attached: "we will notify you" is not a commitment, it is an intention. And the fourth is the one that really separates whoever has a procedure from whoever only has a product: if you disable their application tomorrow, what stops working and how do you come back. If nobody in the chain can answer it, what you call an emergency disable is in fact an experiment, and you will run it on the worst day of the year. We would rather you asked us in the cold.

None of this is an argument for not backing up Microsoft 365. The opposite: Microsoft does not do your backups for you, and that contract has small print we have already picked apart elsewhere — your Exchange Online backup hangs on a text field. The argument is a different one: a 365 backup is, as well as a backup, a privileged identity in your directory, and until this week it was not governed as one. The identity part is governed with the same least-privilege principles you apply to people, even though there is no person here to authenticate.

What we would do this week, starting with half an hour

No project, no new licences, no meeting. Six steps, in order:

1. Open Entra ID > Enterprise applications and sort by creation date. Read the whole list, however long. Flag the ones you cannot explain in one sentence.
2. For the flagged ones, look at the permissions. Separate read from write and note which ones touch mail, files or the directory itself.
3. Open Sign-in logs > service principal sign-ins and filter the last 30 days. Look at which IP and which country each application comes in from. If something comes in from somewhere you did not expect, your morning is now booked.
4. Check whether user consent is open. If it is, decide today who signs from now on and switch it on.
5. Write the disable procedure in five lines, in the same place you keep the rest: disable without deleting, who authorises it out of hours, who gets told, what breaks, how you come back.
6. Email the four questions above to every provider with an application in your tenant. The email is worth as much as the answer: it leaves a date.

Half an hour well spent has a rare property in security: it still works when the next incident comes from a different vendor under a different name. The list, the log and the procedure do not expire with the news cycle.

Sources (checked 18 Oct 2026): the timeline with UTC times, the application identifier 506e08f9-6e9a-4da4-942b-a099a03644ae, the secondary ConnectWise Cloud Management applications that were abused, the IP 144.172.64.128, the password spraying against four law firm tenants (with no successful user sign-ins and two accounts locked by smart lockout), the fifty monitored tenants where service principals assigned themselves roles, the 17 out of the first 290 tenants checked, the secret added to Huntress's own application and used seven times until its removal on the 16th, the 162 confirmed tenants as of 19:00 UTC on 16 October, the close to a thousand tenants with activity from that IP and the more than three hundred that succeeded, the use of client assertion ("the credential lives in the vendor's own tenant") and the disable-do-not-delete guidance — together with its stated reason, which is operational: "deleting it removes the consent, and you will need to re-consent to restore service" — all come from the public analysis by Huntress. ConnectWise's statement — "unauthorized access to application identities" and "we have no indicators to date that Cloud Backup partner backup data has been compromised" — and the time of the service interruption notice are reported by BleepingComputer. The quotes about workload identities, the literal exclusion of third-party multitenant applications, the Workload Identities Premium licence requirement, the single available grant control and the non-enforcement of the policy via group membership are in the Microsoft Entra documentation. The Exchange Web Services retirement schedule (phased blocking from 1 October 2026 with an allow-list by application identifier, full shutdown on 1 April 2027) and the fact that Exchange Online mailboxes are still being backed up over EWS while Graph catches up on incremental backup are in Veeam KB4820. Ours, and we mark it as such: the reading that the applicable Conditional Access control does not cover this class of application, the second reason not to delete the application (losing the consent record, which is not the reason the source gives), the ordering of the four measures by cost, the four questions for a provider, the six-step list and the distinction between the backup and the backup's identity. We have not independently verified the tenant counts: they are the ones published by the researcher, they come from its own telemetry and we cite them as such.