ConnectWise Cloud Backup's app credential, not a person's: Huntress says 162 tenants, a headline says 173

Huntress's page says 162 tenants. The headline that cites Huntress says 173.

Huntress published its account on 16 October 2026 and says that as of 19:00 UTC that day (20:00 BST) it had confirmed unauthorised sign-ins in 162 tenants, made with a credential belonging to the ConnectWise Cloud Backup application, formerly SkyKick. The Hacker News reported on 17 October that Huntress had observed confirmed unauthorised sign-ins in 173 partner and customer tenants. The two figures differ by 11, which is 6.8 per cent of 162 (derived). The Huntress page, read at 11:47 BST and again at 11:54 BST on Saturday 17 October, says 162 and does not contain 173. Todyl's post and ConnectWise's advisory give no tenant count, and the two other write-ups read either give none or repeat 162. So 173 is either a later Huntress update that had not reached the page read here, or it comes from somewhere that could not be read. This briefing says 162 where it quotes Huntress and 173 only where it quotes the headline.

The second computed fact is about time. Huntress puts the Cloud Backup sign-ins between 06:13 and 08:34 UTC on 15 October, a window of 141 minutes (derived). If all 162 tenants fell inside it, which the page does not say, that is one tenant every 52 seconds on average (derived). Huntress also says the actor moved through tenants "a few seconds apart". Both statements can be true only if the script touched many tenants that Huntress cannot see, or if the 162 were not all reached in that window. The page does not say which. Todyl, watching its own tenants, saw the same application and the same source address in a different window, 07:11 to 08:47 UTC, so the two vendors' windows together span 154 minutes (derived). The counts describe what two security companies could see in the tenants they watch. They do not describe how far the credential went.

The headline says a ConnectWise credential was used to sign in. Read against the primary sources, that sentence leaves a lot open. It does not say the credential was a person's: Huntress describes an application's credential, held in the vendor's own tenant. It does not say how many of the tenants had mail, files or Teams data read: no source confirms any. It does not say how the credential left the vendor's hands, why ConnectWise's first advisory came 35 h 34 min after the first sign-in Huntress saw (derived), who the tenants belong to, or whether any are in the UK or the EU. It does not say whether other vendors' application credentials are affected. No source read cites a CVE, and the CISA Known Exploited Vulnerabilities catalogue, dated 16 October 2026 at 17:15 UTC, has no Cloud Backup or SkyKick entry.

Interests, in one sentence: Huntress and Todyl sell managed detection and response to MSPs, ConnectWise sells the product and is the party whose application credential was used, and Microsoft sells the Entra licences that carry the logging and controls discussed here, so every claim below is attributed to the party that made it.

What was read, and how

The news article is the secondary source here, and the primary sources are the security companies' own posts, the vendor's own advisory and Microsoft's documentation. All were read in full on Saturday 17 October 2026 between 11:47 and 12:10 BST. This is a developing story, so any figure below can be overtaken: ConnectWise's advisory has already carried two entries 11 hours apart (derived), and Huntress says it will keep updating its post.

• The Hacker News, 17 October: the article that carries the 173. Secondary. It also covers an unrelated update-server compromise of a backup product, which is not used here.
• Huntress blog post, 16 October: read in full twice. Primary for the sign-in window, the 162, the other ConnectWise applications and the mitigation steps.
• ConnectWise Trust Center advisory page and its status page entry: both entries of each, the first published at 17:47 UTC on 16 October and the update of 05:01 UTC on 17 October (the status page stamps them one and ten minutes later). Primary for what the vendor says.
• Todyl blog post, 16 October: its own tenants' view. It answered a plain request with a bot check, which was not completed; it was read later in a browser tab where the article had loaded.
• Microsoft Learn, NCSC, the ICO, Cyber Essentials and the Bill text: read as cited below.
• Not read: two community threads linked by the news article (scripted pages that returned no text), a post by one security vendor seen only as a search-result snippet, an advisory by another that an aggregator write-up cites, and any ConnectWise partner-only page.

Who counted what, and over what

Every number in this story is a count of something different. Setting them side by side shows how little the largest of them covers.

Counts in the sources, with their basis. Read 17 October 2026. Percentages are derived.

Source and date	What it counts	Limits
Huntress blog, 16 October	162 tenants with confirmed unauthorised sign-ins, as of 19:00 UTC on 16 October	Tenants Huntress can see. It says it cannot check tenants without the Entra licensing, and that the actor is "not limited to the tenants we have confirmed so far"
Huntress blog, same post	The application authenticated from the hosting address in 17 of the first 290 or so tenants checked, across 17 partner accounts (5.9 per cent, derived)	An earlier, smaller sample from 06:13 to 08:34 UTC on 15 October. The 5.9 per cent cannot be projected onto tenants not checked
The Hacker News, 17 October	173 partner and customer tenants, attributed to Huntress	Not on the Huntress page read at 11:47 and 11:54 BST. No time, window or method is given
Todyl blog, 16 October	No tenant count. Nine tenants had no active backup subscription, and a token was still issued in them	Tenants Todyl monitors. Sign-ins 07:11 to 08:47 UTC on 15 October, one per tenant
ConnectWise advisory, 16 and 17 October	No count of tenants, partners or customers	Says it identified "unauthorized access to application identities" in its Cloud Backup environment
Huntress blog	About 50 tenants where ConnectWise Cloud Management applications assigned themselves directory roles, mostly Exchange Administrator, from 01:58 UTC on 15 October	Huntress says the pattern points to vendor automation but has not confirmed that with ConnectWise
Huntress blog	One tenant where a Cloud Management application made itself Global Administrator and changed two other applications	The one tenant audit log Huntress reviewed in detail. The page does not say how many others were reviewed

The sequence, in UTC, and the gaps worked out

What each source states, in order. Times are UTC unless a date alone is given. BST is one hour ahead.

When (UTC)	What the source states	Source
13 to 14 October, times not given	Password spraying from one hosting address against four tenants of law firms. Two accounts were locked out. Huntress saw no successful user sign-in from that address	Huntress
15 October, from 01:58	In about 50 Huntress-monitored tenants, ConnectWise Cloud Management applications assigned themselves directory roles	Huntress
15 October, 03:44 to 03:49	In one tenant, a Cloud Management application added itself to Global Administrator and made nine changes to two other applications. Six succeeded, three failed	Huntress
15 October, 06:13 to 08:34	The Cloud Backup application authenticated from the hosting address in tenants Huntress checked, in sorted order, a few seconds apart	Huntress
15 October, 07:11 to 08:47	Sign-ins as the Cloud Backup application in tenants Todyl monitors, one per tenant, 1 to 6 minutes apart in sorted order	Todyl
16 October, 17:47 (18:47 BST)	ConnectWise: investigating "recent attempts of unauthorized access"; containment in place; no indication partner backup data has been accessed	ConnectWise
16 October, 19:00	Huntress: unauthorised sign-ins confirmed in 162 tenants	Huntress
17 October, 05:01 (06:01 BST)	ConnectWise: "unauthorized access to application identities"; shutting off Cloud Backup application access until further notice; no indicators that partner backup data has been compromised	ConnectWise
17 October, time not given	The Hacker News: 173 tenants, attributed to Huntress	The Hacker News

ConnectWise says it "recently identified" the access and that it started incident response on detecting it. It does not say when it detected anything. So the intervals below run between what Huntress observed and when ConnectWise published. They are not detection times, and the window Huntress saw is the span of what it could see, not the span of the compromise.

Intervals between printed times (derived by subtraction; see calc-output.txt).

Interval	Length (derived)
First role self-assignments Huntress saw (15 October, 01:58) to its first Cloud Backup sign-in (06:13)	4 h 15 min
Global Administrator change in one tenant (03:44) to the first Cloud Backup sign-in (06:13); Huntress says about two and a half hours	2 h 29 min
First Cloud Backup sign-in Huntress saw (06:13, 15 October) to ConnectWise's first advisory (17:47, 16 October)	35 h 34 min
Last sign-in Huntress saw (08:34) to ConnectWise's first advisory	33 h 13 min
ConnectWise's first advisory to Huntress's 162 count (19:00)	1 h 13 min
ConnectWise's first advisory to its update shutting off access (05:01, 17 October)	11 h 14 min
First sign-in Huntress saw to the shut-off update	46 h 48 min

The earliest dated event tied to the same source address is the spraying on 13 and 14 October, three days before ConnectWise's advisory date (derived). Spraying user accounts is a different act from using an application credential, and Huntress saw no successful user sign-in from it. Whether the credential was held earlier than 15 October is not stated.

An application's credential, not a person's: what Microsoft documents

Microsoft's overview of permissions and consent describes two ways an application reaches data. In delegated access it acts for a signed-in user. In app-only access it acts "only as the application's own identity", which Microsoft says is used in scenarios such as automation and backup. App-only access uses application permissions, which only an administrator can consent to, and an application holding a file permission of that kind can read any file in the tenant.

A multitenant application, in Microsoft's description of application objects, has one application object in the vendor's own tenant, and a service principal in each tenant where it has been consented to. The service principal defines what the application can do in that tenant. That is the shape the reports describe. Huntress says the credential type was a client assertion, so that "the credential lives in the vendor's own tenant", and that nothing a customer did could have produced it. Todyl says the application held tenant-wide read and write access to mail and attachments, OneDrive and SharePoint files and Teams chats in each consenting tenant, and the ability to restore data, and that the actor's activity was limited to signing in with the already-approved application. The customer's administrator gave that consent earlier, to a legitimate product. Microsoft's own page on admin consent calls granting it "a sensitive operation" that can give a publisher access to "significant portions of your organization's data".

Huntress says app-only sign-ins involve "no user, no device, and no MFA prompt". Microsoft's page on Conditional Access for workload identities, last updated 24 March 2026, says workload identities cannot perform multifactor authentication and that the policies apply to single-tenant service principals registered in the customer's own tenant: "Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies." Todyl's account agrees: Conditional Access was not applied to the sign-ins, and it says least-privilege consent and removing unused applications are the main controls left to a customer. Huntress lists Conditional Access for workload identities, Identity Protection and application management policies among controls that make a planted secret harder to use or easier to spot. On Microsoft's wording those help for applications in the customer's own tenant, such as the single-tenant Huntress application that received a new secret, and not for the vendor's multitenant backup application.

None of the sources reports that granular delegated admin privileges (GDAP) or any partner staff account was involved. Microsoft's GDAP introduction describes "least-privileged access" for partners to customers' workloads, granular and time-bound, and Conditional Access has a separate service provider user target for partner staff. Both govern people who sign in as partners. An application signing in as itself is outside both, so a customer who reviewed its partner relationships this week would have found nothing about this event.

What a customer can do is specific and limited. Disabling the application in its own tenant, which Microsoft says prevents all tokens being issued for it there, stops new tokens. Tokens already issued last up to 90 minutes (Todyl), which fits Microsoft's default access-token lifetime of 60 to 90 minutes. Only the vendor can rotate its own credential (Todyl). The sign-ins sit in the Service principal sign-ins tab, not the default user tab (Huntress), one of the four log types Microsoft lists in its sign-in log overview. Per Microsoft's retention table, sign-in and audit logs are kept for seven days on Entra ID Free and 30 days on P1 and P2, so a free-tier tenant starts losing 13 October entries on 20 October, three days from now (derived). Graph activity logs, which record each request, need a P1 or P2 licence, are not kept unless sent somewhere, and start only when switched on. Todyl says they were not being collected in the tenants where it could not tell the actor's reads from the backup service's.

What the record states, and what it does not

Stated and not stated, from the Huntress post, the Todyl post and the ConnectWise advisory page as read on 17 October 2026.

Question	Stated	Not stated
Whose credential?	An application's: Cloud Backup, formerly SkyKick, held by the vendor. Huntress: a client assertion, living in the vendor's own tenant; no user involved	Whether it was a secret or a certificate. Huntress's summary says "API secret" and its body says client assertion; Todyl's prose says client secret and its log field says client assertion
How was it obtained?	Nothing. Huntress says it is "in hostile hands"; ConnectWise gives no cause	The method, the date it was lost, and whether it left a vendor system, a repository or a person's device
What happened after sign-in?	Graph tokens obtained, one per tenant, in sorted order (Todyl). In the one audit log Huntress reviewed in detail, no mail or file access. Todyl found no directory changes by the backup application	Whether any mail, file, Teams or directory data was read or copied. Huntress: directory reads leave no audit trail. Todyl cannot separate the actor's reads from the backup service's
How many tenants?	162 (Huntress, 19:00 UTC, 16 October). 173 (The Hacker News, 17 October). 17 partner accounts in an earlier sample	The source of 173, the total number of tenants where the application is consented, and any UK or EU count
Who are they?	"Partner/customer" tenants (The Hacker News); tenants Huntress and Todyl can see, including Huntress partners' tenants	How many are ConnectWise's partners and how many are those partners' clients. Four tenants of law firms were sprayed on 13 and 14 October; no sector is stated for the rest. ConnectWise's status page lists the affected location as "All Regions" and gives no country count
Why was detection not faster?	ConnectWise says it "recently identified" the access	When ConnectWise detected anything, who saw it first, and why its first advisory came 35 h 34 min after the first sign-in Huntress saw (derived)
What has ConnectWise done?	Shut off Cloud Backup application access until further notice (update of 05:01 UTC, 17 October); published a source address and client identifiers; "no indicators to date" that partner backup data is compromised	Whether the credential has been rotated (neither ConnectWise entry says so; Todyl notes the same of the first), when service returns, and how many partners it has told
Other applications?	Huntress: a second ConnectWise application gave itself Global Administrator in one tenant and added secrets to two other applications; it cannot verify the remaining ConnectWise applications are secure	Whether that and the Cloud Backup sign-ins were one operator (Huntress has not tied them), and whether other vendors' applications are affected
CVE or alert?	None cited. The CISA catalogue of 16 October (17:15 UTC) lists ConnectWise ScreenConnect entries and none for Cloud Backup	Any CISA or NCSC alert. None was found; both sites' search pages are scripted and could not be searched conclusively

ConnectWise's own advisory has moved between the two entries. The first, at 17:47 UTC on 16 October, speaks of "recent attempts of unauthorized access". The second, at 05:01 UTC on 17 October, speaks of "unauthorized access to application identities" and tells customers where in the Entra sign-in log to look. Todyl, whose post is dated 16 October, noted that the first entry did not mention Microsoft 365, the application or its credential. Todyl's own caution on the data question is worth keeping next to the vendor's: "The absence of confirmed exfiltration is partly a visibility limit rather than a clean result."

Friendly names: eight words that carry more than they show

Words in the headline and the reports, and what the sources show behind each.

Word	What it suggests	What the sources show
Credential	A person's username and password, protected by MFA	An application's proof of identity, held by the vendor. The sources call it an API secret, a client assertion and a client secret. Huntress says there is no MFA prompt for it
Compromised	Known theft and known damage	Huntress: the credential is in "hostile hands" and was used. Huntress says any organisation with the app installed is affected; Todyl says to assume every tenant with it enabled is compromised. Neither states data was taken
Sign in	A person typed a password	An application asked Entra for a token as itself, once per tenant, from a script. Success means a token was issued, not that anything was read
Tenant	An organisation	A Microsoft Entra directory. The sources count tenants only, which is not a count of organisations, users or mailboxes
Partner	A trusted reseller	Three meanings in one story: ConnectWise's partners, who buy Cloud Backup; Huntress's partners, whose tenants it watches; and Microsoft's partner relationships such as GDAP. Only the first two appear in the reports
Delegated	Someone acts for you, with limits	ConnectWise's product page advertises "delegated authentication for a seamless zero trust approach". In Microsoft's terms delegated access acts for a signed-in user. The reports describe app-only access. The sources do not say how the two relate
Supply chain	A distant, rare risk	Three parties, three different things held: the vendor holds the credential, the MSP chose the product and holds the contract, and the customer's administrator gave the consent
MSP	A security specialist	NCSC calls an MSP's own systems "a juicy target". Here the route in was the MSP's supplier's credential, not an MSP account

The same trust-in-a-trusted-tool pattern appeared in an earlier briefing on this site, where a genuine, signed remote-management installer put a second remote tool on devices. The mechanism differs, because that case ran on endpoints and this one runs on a cloud identity, but in both the property that made the tool trusted was the property that made it useful to an attacker.

Rotating the vendor's credential is necessary, and not enough

In one Huntress partner tenant, Huntress reports that a second ConnectWise application, Cloud Management for Microsoft Teams, added itself to the Global Administrator role at 03:44 UTC on 15 October, then made nine changes to two other applications in about five minutes (03:44 to 03:49, derived). The two were an MSP management application and Huntress's own application. Six changes succeeded and three failed (66.7 per cent succeeded, derived). The successful ones added new client secrets, set to expire in 2028, which is between 443 and 808 days after 15 October 2026 (derived).

Huntress's reading is that a credential on an MSP management application can extend access beyond one tenant, because such applications are often consented in the MSP's customers' tenants, and it says it has not seen that happen. Three points follow from the page. First, Huntress says disabling the ConnectWise applications "will not remove credentials that were already added", so a customer has to review credentials on all of its applications, not only ConnectWise's. Second, a secret planted in a customer's own tenant is a customer-side artefact, and ConnectWise rotating its own credential does not touch it. Third, the relationship between this earlier activity and the later Cloud Backup sign-ins is not settled. Huntress has no source address for the earlier events and has not tied the two phases to one operator; the sign-ins began 2 h 29 min after the Global Administrator change (derived); and Todyl found no directory changes by the backup application in its own tenants. The record describes two phases of unclear relationship, not one proven campaign.

UK: what applies today, and where each piece stops

No source read says that any UK organisation is among the tenants, and none says that none is. That is a gap in itself. A UK customer of an MSP that uses Cloud Backup can check its own tenant whether or not it was among the 162, and the guidance below applies either way.

UK guidance and law as read from the pages cited, on 17 October 2026, and where each stops.

Instrument	What it says, as read	Where it stops
NCSC, [Choosing a managed service provider](https://www.ncsc.gov.uk/guidance/choosing-a-managed-service-provider-msp) (SME guide, 24 November 2025)	Apply least privilege to the MSP, require 2-step verification on the MSP's own access, ask how long logs are kept and whether you can see them, fix incident-notification times in the contract, and ask whether you have assessed the MSP's supply chain risks	Written around the MSP's people and access. It does not mention applications consented in your tenant or credentials a vendor holds
NCSC, [Using MSPs to administer your cloud services](https://ncsc.gov.uk/blog-post/using-msps-to-administer-your-cloud-services) (blog, 10 January 2023)	An MSP's own systems can be "a juicy target". The contract should oblige the MSP to tell you of breaches, including "any breaches that happened in the MSP's own supply chain"	Speaks of accounts, devices and administrator access. It does not mention consent or application permissions, and it predates this event by three years and nine months (derived)
NCSC, [supply chain security guidance](https://www.ncsc.gov.uk/collection/supply-chain/guidance/12-principles)	Twelve principles in four stages: understand the risks, establish control, check your arrangements, continuous improvement	Only the landing page was read for this briefing, not the principles themselves. It is written for large organisations and the public sector
Cyber Essentials, [Requirements for IT Infrastructure v3.3](https://www.ncsc.gov.uk/files/cyber-essentials-requirements-for-it-infrastructure-v3-3.pdf) (April 2026)	Accounts used by third parties such as an MSP are in scope. Authentication to cloud services must always use MFA. User accounts are removed or disabled when no longer required	The wording is about user accounts. A search found nothing on service accounts, machine accounts or application permissions, and Huntress says app-only sign-ins have no MFA prompt
UK GDPR, ICO [guide to personal data breaches](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/)	A controller reports a notifiable breach within 72 hours of becoming aware, where feasible, and may give details in phases. A processor must tell the controller "without undue delay". Breaches include access by an unauthorised third party	Whether any personal data was accessed is the open question: the reports establish tokens issued, not reads. Awareness and risk are judgements the controller must record
Cyber Security and Resilience Bill, [HL Bill 49](https://bills-api.parliament.uk/api/v1/Publications/67673/Documents/8744/Download) as amended in Grand Committee	A managed service is ongoing IT management under contract, delivered by connecting to or obtaining access to the customer's systems. A relevant managed service provider that is not micro or small would notify the Information Commission within 24 hours (initial) and 72 hours (full) of becoming aware of a significant incident, then tell the UK customers likely to be affected	Not law. Lords report stage is listed for 26 October, nine days from today (derived), and these duties start on a day set by regulations. The text does not say whether a vendor of an automated backup application that connects by consent provides a managed service, or whether a stolen vendor credential is an incident in the systems an MSP relies on

The Bill is read in detail in an earlier briefing on this site, on its AI gap and its report-stage amendments. For this story the point is narrow: the Bill would put 24-hour and 72-hour duties on larger managed service providers, with customer notification after them, but the text read does not decide whether the product vendor in a case like this is inside it. Stage dates can move; the 26 October date is provisional.

The 72 hours, as arithmetic. Counting from ConnectWise's first advisory, published at 17:47 UTC (18:47 BST) on Friday 16 October, 72 hours ends at 18:47 BST on Monday 19 October (derived), and a weekend sits inside it. That is an illustration and not a legal view. The ICO says the clock runs from becoming aware and points to the Article 29 Working Party guidelines for when a controller is aware, and whether a personal data breach occurred is the very thing the record does not establish. A customer whose tenant had the application consented should record, today, when it became aware, what it checked, and why it did or did not report. The ICO guide says a processor must tell its controller without undue delay, so the question to put to an MSP is when it became aware, not only what it knows.

What to do, in order

Three lists, because the three readers hold different things. Each is ordered by what is cheapest and most time-limited first. They draw on Huntress's and Todyl's recommendations and on Microsoft's documentation, and they stop where the sources stop: none of this can confirm that data was not taken.

The question that exposes the gap

Which of the third-party applications consented in your tenant could read every mailbox without a person signing in, who holds the credential that proves each one is genuine, and who would tell you within hours, rather than days, if that holder lost it?

In this case the accounts of what happened inside customer tenants come from two security companies watching their own customers, and the vendor's first advisory came 35 h 34 min after the first sign-in Huntress saw (derived). Who detected it first is not stated, and neither is how a customer that was not being watched could have known earlier.

Key facts