Most coverage of the ConnectWise supply chain breach answers the vendor's question: what was taken, who took it, how many tenants were touched. Useful context, but it is not the question sitting in your inbox. The question you actually have is narrower and harder: who holds standing access into my environment that I never inventoried, and can I see any of it from the outside?
That is a vendor access audit, not an incident summary. Below is how to run one, starting from your external attack surface rather than your tenant logs, because most organisations cannot see what their MSP's platform exposes on their behalf.
What actually happened in the ConnectWise Cloud Backup compromise
The reported sequence is short, which is part of what makes it awkward. A ConnectWise Cloud Backup credential or key was obtained by an attacker and used to reach customer Microsoft 365 environments through the access the backup platform already held. No exploit chain against your tenant. No brute force. Legitimate access, used by the wrong party.
Microsoft has linked the activity to the China-aligned actor it tracks as Storm-0940, the same cluster associated with large-scale password spraying from compromised network edge devices. Reporting at the time indicated a large number of Microsoft 365 tenants were affected, with the figure still subject to revision.
Confirmed, reported and still uncertain
Brief your board carefully here. The volume figure, the attribution and the initial access route all come from vendor statements and researcher analysis rather than from anything you can independently verify. Attribution in particular is a judgement, not a fact, and figures of this kind tend to move as investigation continues. Check the vendor's current advisories before you repeat any number in writing.
There is a structural reason the true scope stays blurred. When access rides on a valid credential inside a trusted integration, the activity looks like normal platform behaviour. A tenant that was accessed and a tenant that was merely reachable can be difficult to separate after the fact, and the difference matters a great deal to anyone weighing up a notification decision.
A pattern around internet-facing management tooling
This is not the vendor's first appearance in incident write-ups. In February 2024, CVE-2024-1709, an authentication bypass in ScreenConnect rated CVSS 10.0, was exploited at scale, including by Black Basta affiliates, against on-premises instances exposed to the internet. In 2025 the company disclosed a suspected nation-state incident affecting a limited number of ScreenConnect customers.
Same product family, three different access routes. Stolen key, unauthenticated bypass, suspected state actor. The common factor is not the vendor. It is that remote management and backup platforms hold privileged access into many estates at once, which makes them worth months of attacker effort.
Why a backup platform breach becomes your Microsoft 365 problem
Delegated access is the mechanism nobody revisits after onboarding. A partner holds a GDAP relationship with defined roles and an expiry date, or an older delegated admin arrangement that was migrated rather than retired. Alongside it sit service principals, app registrations and OAuth consents granted by someone with Global Admin during a migration project, each carrying scopes like Mail.Read or Files.Read.All that never expire on their own.
Backup and RMM agents work the same way. An agent installed to protect mailboxes can, by design, read mailboxes. When an attacker inherits that access, your sign-in logs show a service principal doing exactly what it has always done. No failed logins. No impossible travel. Nothing an identity protection rule was built to catch.
Which brings the position this article is built on: tenant sign-in logs are the wrong first place to look when access arrives through a legitimate delegated relationship or a valid API key. The faster signal is almost always external. An exposed management console on a subdomain nobody remembers. Technician credentials appearing in stealer log data that nobody connected to your supplier. Those are visible from the attacker's side of the fence, which is where you should be standing.
The notification clock runs on facts you do not hold
Your supplier's breach is your personal data incident. Under UK GDPR Article 33 you have 72 hours from becoming aware of a personal data breach to report it to the ICO where the threshold is met, and awareness starts when your supplier tells you, not when the supplier was compromised. You are then expected to characterise the scope of a system you do not administer, using evidence held by a third party, inside three days. The organisations that handle this well are the ones that already knew which access paths existed before the email arrived. The pattern is familiar from the exposure gaps behind the Capita ICO fine: the regulator's interest lands on what you could reasonably have known about your own estate.
Build the vendor access inventory you are missing
Most organisations can list their suppliers. Very few can list their supplier access paths. The gap between "we use an MSP"and "that MSP holds Global Admin via GDAP, plus three OAuth consents and a backup agent with mailbox scope"is precisely where supply chain incidents land, and a procurement spreadsheet does not close it.
Build the map per vendor, against real assets:
- Every party with standing access, not just contracted suppliers: MSPs, backup and archiving providers, reseller tenants, marketing agencies with CMS admin, contractors holding guest accounts from a project that ended two years ago.
- The access type each one holds: admin delegation, API key, OAuth scope, agent install, VPN account, SSH key, jump host.
- The data each access path can reach, written plainly. "Can read all mailboxes"is a sentence a board understands. "Graph application permissions"is not.
- The owner and the review date. Access without a named internal owner is the first thing to remove.
Then cross-check the map against your external footprint. A typical mid-market picture looks like this: one MSP with delegated admin across 40 tenants, two backup agents at mailbox-level scope, and three OAuth consents granted during a 2019 migration that no current member of staff recognises. Somewhere alongside that sits a remote access console on a forgotten subdomain, still resolving, still authenticating. External asset discovery and shadow IT identification exist to find those management interfaces, because the internal inventory was never told they were deployed.
Six exposure checks to run this week
- Audit enterprise application consents and partner relationships. Pull every service principal, app registration and GDAP relationship. Remove anything without a current contract and a named owner. Cut role assignments back to what the supplier actually needs, and set expiry rather than leaving standing admin in place.
- Test internet-facing remote management instances. Any self-hosted ScreenConnect, RMM or backup portal needs its own inventory line, with version, exposure, MFA status and patch state recorded. Dual scanning matters here: an infrastructure scan finds the open port and the outdated build, a web application scan finds the login flow that accepts credentials without a second factor.
- Search leaked credential sources and stealer logs. Query your own domains and your suppliers' domains. Technician accounts, service accounts and shared admin mailboxes are the ones that matter, and a structured triage of stealer log data beats scrolling a feed. An infostealer on a technician's laptop hands over session cookies as well as passwords, which is why a password reset alone does not close it.
- Hunt lookalike and newly registered domains. Public supply chain incidents reliably produce a second wave of domains impersonating the vendor, your brand or your helpdesk, aimed at users who are expecting remediation emails. DNS surveillance, lookalike domain detection and then takedown with evidence collection and registrar contact matter more in the fortnight after disclosure than at any other point in the year.
- Watch leak sites and criminal channels for your own name. Ransomware leak sites and hacker Telegram channels list downstream victims before any of them have issued a statement. Seeing your organisation, or your MSP, named there changes your response timeline immediately.
- Validate the fix. Revoked tokens get reissued at the next onboarding. An agent gets reinstalled by the next engineer. A console comes back on a different subdomain. Re-test the asset and confirm the state holds, rather than closing the ticket on a supplier's assurance.
Watching the aftermath on the dark web and Telegram
Stolen access is frequently sold before it is exploited. Initial access brokers monetise the credential, and weeks can pass before an affiliate uses it to deploy ransomware. Your useful monitoring window sits in that gap, which is the one part of supply chain response that rewards patience and continuous watching rather than a 48-hour incident sprint.
Signal quality is the hard part. Stealer log dumps and reposted combo lists recycle the same records endlessly, and volume alone tells you nothing. Automated filtering narrows the field; human research into criminal chatter is what confirms whether a credential set is live, historic or simply recycled from a 2021 breach that has already been remediated. Treating every alert as equally urgent is one of the common Telegram monitoring mistakes, and it burns analyst time you need elsewhere.
Be honest about the limits. Dark web and Telegram monitoring will not confirm whether your specific tenant was accessed. It tells you whether credentials tied to your domains are circulating, whether your name appears in victim lists, and whether anyone is advertising access to an environment that looks like yours. That is intelligence to act on, not proof, and anyone selling it as proof is overstating the capability.
One more thing happens after a vendor breach becomes public: the phishing turns personal. Finance and IT leadership accounts take the follow-on pressure, because attackers know who authorises payments and account changes, and a "your backup provider was breached, please verify these details"email lands credibly for a fortnight. Per-person risk scoring and executive identity monitoring are a different control from tenant hardening. You need both.
Turn the response into a standing supplier risk programme
An annual questionnaire completed before the incident tells you nothing about the incident. Continuous supplier threat intelligence does: monitoring your key suppliers' external footprints, credential exposure and public incident signals, and scoring them on what changes rather than on what they claimed in a PDF.
Use accreditation as evidence, not reassurance. ISO 27001 certification status is a starting point, and the Annex A supplier controls (A.5.19 through A.5.22, covering supplier relationships, security within agreements, ICT supply chain and monitoring of supplier service delivery) give you a defensible framework for access review cadence and the evidence you can demand. Ask for the statement of applicability and the scope certificate. A logo on a website is not a control.
Change the contract while the incident is fresh and the supplier is motivated: a defined notification window, a committed access review cadence, named technical contacts rather than a shared support address, and an obligation to provide breach evidence in a usable form. Then report on it in a way that survives scrutiny, with a weekly "what has changed"view of your external footprint and a management summary showing which vendor access paths closed and when. If you are weighing up whether to run that in-house, our guidance on what a managed threat intelligence provider should do sets out the baseline to expect.
Frequently Asked Questions
What happened in the ConnectWise supply chain breach?
As reported, an attacker obtained a ConnectWise Cloud Backup credential or key and used that legitimate access to reach customer Microsoft 365 environments, with Microsoft linking the activity to the China-aligned actor it tracks as Storm-0940. Reporting indicated a large number of tenants were affected, with the figure still subject to revision. Treat the attribution and the volume figure as vendor and researcher claims rather than independently confirmed facts, and check current advisories before quoting either.
How do I know if my Microsoft 365 tenant was affected?
Start with the access paths, not the logs. Enumerate every service principal, app registration, OAuth consent and partner delegation tied to the supplier, check what data each can reach, and ask the supplier in writing whether your tenant appears in their affected list. Sign-in logs are worth reviewing for unfamiliar service principal activity and unusual mailbox or SharePoint access patterns, but an attacker using valid delegated access will not generate the failed logins those logs are designed to surface.
Does a supplier breach like this trigger an ICO notification?
It can. If personal data you control was affected and the breach is likely to risk individuals' rights and freedoms, UK GDPR Article 33 requires reporting to the ICO within 72 hours of becoming aware, and awareness begins when your processor informs you. Document your assessment either way, including why you concluded the threshold was or was not met, because the reasoning is as scrutinised as the decision.
What should we ask our MSP after the ConnectWise Cloud Backup incident?
Ask for a written list of every access path they hold into your estate, the dates and roles of any GDAP relationships, which of their technician accounts had access, whether those accounts were subject to MFA, and what evidence they hold that your tenant was or was not accessed. Then ask when tokens were revoked and how they will confirm those revocations persist. Vague reassurance is not an answer you can report to a regulator.
How can we spot the next supply chain compromise earlier?
Watch the outside continuously and watch for change. Continuous asset monitoring with change detection catches a management console reappearing on a new subdomain or an agent being reinstalled; credential and criminal-channel monitoring catches technician logins circulating before they are used. One-off checklists do not survive the next onboarding project, which is why external attack surface management works as a standing programme rather than an incident response task. If you want to see what your own footprint looks like from an attacker's perspective, start with DarkInvader's external attack surface platform.
