When a Backup Provider's Key Opens Your Microsoft 365 Tenant

A backup service needs permission to copy your mail, files, calendars, and collaboration data. That permission is the point of the product. It is also why a single vendor credential can become much more than a vendor problem.

On 17 October 2026, ConnectWise said it had identified unauthorised access to application identities associated with ConnectWise Cloud Backup, formerly SkyKick. The company suspended Cloud Backup and revoked certificates used by affected application connections. By 19 October, Cloud Backup, SaaS Security, and Cloud Management remained suspended. Scheduled backups, archive access, and restores were unavailable while the investigation and security checks continued (ConnectWise Trust Center advisory).

The stored backup archives are one part of the story. ConnectWise says those archives remain encrypted and isolated, with no evidence that attackers accessed them. The live Microsoft 365 tenants connected to the applications are another part. ConnectWise has told partners to review their own tenant and every customer tenant they manage because switching off a vendor connection does not reverse changes already made inside a customer’s environment.

Huntress, a security provider investigating activity in environments it monitors, reported that a ConnectWise application credential had been used to request Microsoft 365 access tokens. Its 17 October update said it had found sign-in activity from the associated internet address in almost 1,000 Microsoft Entra tenants, with more than 300 successful sign-ins. A successful sign-in does not, on its own, prove that an attacker reached tenant data. In some tenants, the required application was absent, which stopped the next step. Huntress also documented one tenant where an application gave itself the Global Administrator role and added credentials to two other applications (Huntress investigation).

This is a useful incident to study because the mechanics are ordinary. No employee had to hand over a password in every affected organisation. A trusted application already had a doorway. The attacker obtained a way to appear at that doorway as the application.

For a managed service provider, IT administrator, or small business relying on one, the practical question is not “Was the backup archive stolen?” It is “What authority did the connected application have in the live tenant, and what could have been changed while that authority worked?” The answer comes from application records, sign-in logs, role changes, new credentials, mailbox rules, and preserved timestamps. It does not come from the product status page alone.

What ConnectWise confirmed by 19 October

ConnectWise first published an investigation notice on 16 October 2026. The company said it was investigating attempts at unauthorised access associated with its Cloud Backup environment and had started incident-response work. On 17 October, it described the issue more specifically as unauthorised access to application identities and shut off Cloud Backup application access.

At 07:00 UTC on 17 October, ConnectWise disabled seven application identities covering Cloud Backup and Cloud Management connections for services including Microsoft Teams, Exchange Online, Microsoft Graph, Partner Center, and SharePoint Online. It also revoked certificates used for affected Cloud Backup connections. Those measures stopped new authentication through the affected connections. ConnectWise warned that previously issued access tokens could remain usable until they expired or were invalidated, and that separate credentials or permissions created inside a tenant needed their own remediation (ConnectWise: 18 October investigation update).

That distinction deserves a concrete example. Suppose a thief uses a copied building pass to enter an office, then takes a spare key from a drawer. Cancelling the copied pass blocks the original route. It does not pull the spare key from the thief’s pocket. In Microsoft 365, the “spare key” could be a new client secret attached to another application, a newly consented application, an added application owner, a privileged directory role, or a mailbox forwarding rule.

ConnectWise says it has not observed successful threat activity in environments it monitors since applying its mitigations. It also says its design does not give it visibility into every downstream partner and customer environment. Both statements can be true. The vendor can observe its own systems and some connected activity while remaining unable to certify the state of each customer’s tenant.

As of the 01:15 UTC update on 19 October, there was no confirmed restoration time. Existing backup archives remained encrypted, isolated, and preserved. Access to those archives and restoration functions remained unavailable. SaaS Security monitoring and alerting, along with Cloud Management user and licence management, were also unavailable. The outage therefore had an operational effect even where no local compromise was found: new backup jobs were not running and customers could not perform restores through the affected service.

The public facts still have limits. ConnectWise had not attributed the activity to a named actor. It had not published a complete customer impact count. It said the exact credential-exposure mechanism remained under investigation. Reporting should stop at those boundaries. The available evidence supports unauthorised use of application identities and suspicious activity in Microsoft 365 tenants. It does not support a claim that every Cloud Backup customer was breached or that stored backup archives were taken.

A calm response starts with that narrower statement. If the application existed in a tenant, review that tenant. If the relevant records show no successful authentication, no unusual token request, and no subsequent change, document the result. If they show activity, preserve it and expand the investigation. The scope should follow the evidence rather than the size of the headline.

The account that does not look like a person

Microsoft 365 has identities for people and identities for software. A person might sign in with an email address, password, and second factor. An application often authenticates with a certificate or secret and acts through a service principal, which is the local representation of that application inside a tenant.

Cloud backup makes the need easy to see. A service cannot wait for an employee to approve a phone prompt each time it copies a mailbox at 02:00. It needs a durable way to prove which software is calling and a set of permissions that says what the software may read or change. Administrators consent to those permissions when they connect the service.

There are two related records. The application registration describes the software identity and its credentials. The enterprise application, or service principal, describes how that identity exists and is permitted to act in a particular tenant. A multi-tenant vendor application can therefore have one vendor-controlled identity accepted across many customer tenants. Each customer has a local service principal, but the vendor may hold the certificate or secret used to authenticate the application.

That arrangement is convenient. The vendor maintains the service once, while many organisations grant it access. It also concentrates trust. If a credential proving the vendor application’s identity is copied, an attacker may ask Microsoft for tokens in every tenant where that application has been accepted. The attacker does not need each employee’s password. Microsoft sees an application presenting a credential that was valid until the vendor or platform revoked it.

Huntress reported that the suspicious authentication used a client assertion, which points to an application credential rather than a customer user’s password. It observed Microsoft Graph token requests from the internet address 144.172.64[.]128 on 15 October. Huntress said the requests moved through tenants in sorted identifier order, seconds apart, which is consistent with scripted work from a target list. Its original report confirmed unauthorised sign-ins in 162 tenants by 19:00 UTC on 16 October; the later update widened the observed sign-in activity to almost 1,000 tenants and more than 300 successful sign-ins.

Those numbers need careful language. “Successful sign-in” means Microsoft accepted the authentication request. Access to useful data still depends on the application being present, its consented permissions, assigned roles, and the resource requested. Huntress noted that the absence of a service principal stopped access in some tenants even though a sign-in event was recorded. Conversely, a tenant where the application is present and powerful may offer a large working area after authentication.

This is why filtering only for unfamiliar human users misses part of modern identity security. An organisation can have clean employee sign-in records while an application identity obtains tokens. The useful inventory includes enterprise applications, their owners, credentials, permissions, assigned directory roles, consent dates, and recent sign-ins.

It also explains why multifactor authentication is not the central control in this incident. MFA protects interactive human authentication. A scheduled backup process cannot approve a phone notification. Application identities need different controls: short credential lifetimes, certificate protection, restrictions on where workload identities can sign in, narrow permissions, monitored credential changes, and an ability to revoke access quickly.

A successful login is the beginning of the scope check

A sign-in log answers a limited question: did Microsoft accept this identity at this time from this source? It does not list every action that followed. An investigator has to connect that authentication with directory, application, Exchange, SharePoint, Teams, and Azure records to learn what changed.

Start with the application identifiers published by ConnectWise. Search service-principal sign-ins for those identifiers from 13 October onward, using the vendor’s current technical guide rather than copying a partial list from a social post. Include all three internet addresses listed in the 18 October update: 144.172.64[.]128, 144.172.64[.]99, and 144.172.64[.]60. An indicator is a search lead, not a verdict. ConnectWise said the two later addresses came from downstream monitoring, while Huntress documented that some activity also appeared from private Microsoft cloud address space.

The absence of one public address in the logs therefore cannot close the review. Search by application identity, credential type, token target, time, and changes as well as by source address. Huntress found activity involving Microsoft Graph, Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra, and Office 365 management interfaces. The exact set visible in one tenant will depend on its services and audit configuration.

Next, inspect what happened to the application and its neighbours. Look for newly added client secrets or certificates, changed application owners, new service principals, fresh permission grants, and directory-role assignments. The ConnectWise guide specifically warns about persistence through other identities. A new credential on an unrelated trusted application matters because it may remain valid after the original vendor connection is disabled.

Huntress supplied a sharp example. In one partner tenant, it observed a ConnectWise Cloud Management application for Teams assign itself Global Administrator and add new credentials to two other applications. One was a Huntress application specific to that tenant. Huntress later removed the unauthorised credential and reported seven rapid sign-ins using it. That sequence shows why “the vendor revoked its certificate” cannot serve as the tenant’s final incident note.

Then review the services the application could reach. In Exchange, check mailbox forwarding, inbox rules, transport rules, delegated mailbox access, and administrative changes. In Entra, review role assignments, consent grants, conditional-access changes, authentication methods, federation settings, and application ownership. In SharePoint and Teams, inspect audit events around the same identities and times. Preserve the raw records before making broad changes where possible.

A forwarded mailbox provides another useful analogy. If somebody enters a post room and fills in a form telling staff to send future letters elsewhere, changing the outside door lock will not cancel that form. The redirection lives inside. Mail rules and delegated access are digital versions of that lingering instruction.

Log retention can become the quiet constraint. Microsoft 365 licence level, audit settings, and workload determine which records exist and how long they remain searchable. Export relevant sign-in and audit records before routine retention moves the window. Record the query, tenant, timezone, export time, and any gap. A screenshot of a dashboard may help a briefing, but a preserved export is better investigation material.

Revocation stops a route, not the work already done

Revoking the vendor certificates was necessary. Disabling the seven application identities was necessary. Neither action travels backward through time.

Tokens create the first delay. An access token is a short-lived pass issued after successful authentication. Revoking the certificate blocks the application from proving its identity again through that certificate, but a token already issued may continue working until expiry or explicit invalidation. ConnectWise called this out in its public update. The window may be short, yet responders should not assume that certificate revocation and token death occurred in the same second.

Persistent changes create the larger problem. An attacker with suitable rights can create a credential on another application, grant permissions, alter role membership, add an owner, configure forwarding, or change a policy. Those objects have their own lifetimes. They are not children that disappear automatically when the original connection is disabled.

This leads to a useful containment rule: remove the route, then inventory what the route could change. The first task stops more traffic. The second finds what might survive.

The order of operations matters when evidence is fragile. Export sign-in and audit records. Note application identifiers, credential fingerprints, role assignments, and timestamps. Then disable suspicious credentials and sessions, remove unauthorised grants, and correct altered settings. If the threat is active, containment may have to happen before a perfect export. Record what was changed and when so the later timeline can distinguish attacker actions from responder actions.

Do not delete an unfamiliar application credential solely because its display name looks odd. Names are labels, and vendors sometimes rotate credentials or create service objects during legitimate maintenance. Compare creation time, creator, key identifier, expiry, sign-in history, and vendor documentation. Where intent remains unclear, disable the credential or application under an incident process rather than destroying the only local evidence.

The same discipline applies to broad role changes. An emergency removal of Global Administrator from an obviously unauthorised service principal is sensible. A mass removal from every automation account without understanding dependencies can cause a second outage and bury the original incident in recovery noise. Preserve, contain, validate, and then clean.

ConnectWise’s suspension also shows the trade-off on the vendor side. Leaving the service connected could preserve backup availability while the route remained suspect. Suspending it interrupted backups and restores, but reduced the chance of further use through the known connection. That is a defensible containment choice. Customers now have to manage the temporary loss of a control they normally rely on.

The backup outage needs its own response

Security investigations can overshadow an ordinary operational fact: as of early 19 October, affected scheduled backups were not running and customers could not access or restore the relevant archives through Cloud Backup. An organisation may find no evidence of unauthorised activity and still have a recovery gap.

Write down the last confirmed successful backup for each important Microsoft 365 workload. Include mail, OneDrive, SharePoint, and Teams data covered by the service. “The backup platform is healthy” is no longer a usable statement during a published suspension. The useful fact is the timestamp and scope of the last recoverable copy.

Then identify changes occurring during the gap. A week’s worth of static reference documents creates a different exposure from a day of contract edits, mailbox deletions, or a migration. Prioritise data with high change rates and time-sensitive recovery needs. This is continuity work, not proof that the stored archive was compromised.

Avoid connecting a second backup product in a hurry with unrestricted permissions. A rushed replacement can repeat the same trust pattern while administrators are distracted. If an interim tool is justified, review its publisher, requested permissions, credential model, storage location, retention, and restore procedure. Test it with a small scope where the product allows that.

Microsoft’s own retention and recycling features may provide some short-term recovery options, depending on the workload and deletion type. They are not equivalent to an independent backup. Retention configuration can share the same administrative boundary as the live tenant, and some events can affect both the data and its platform controls. Treat native retention as one recovery layer whose exact behaviour needs verification.

Keep the old archives in perspective. ConnectWise says they remain encrypted, isolated, and preserved, with no evidence of access. The service interruption prevents customers from reaching them at present. That is an availability problem. It should not be rewritten as confirmed theft.

A useful continuity note has four lines: last confirmed backup, workloads affected, changes since that backup, and temporary recovery method. Add an owner and a review time. This is enough to guide decisions without creating a parallel crisis document full of speculation.

When ConnectWise restores service, do not treat the first green status light as a completed recovery test. Follow the vendor’s formal reconnection instructions. Confirm which application identities and permissions are being restored. Run a small backup, restore a known item to a safe location, and record the result. A successful backup job proves that data was accepted. A restore test proves that the path back works.

What to ask your managed service provider

Many organisations will not have access to every Microsoft 365 record because a managed service provider runs the tenant. That does not remove the customer’s need for a clear answer. It changes who gathers the evidence.

Ask whether the former SkyKick or ConnectWise Cloud Backup application was present in your tenant on 15 October 2026. The question is specific enough to answer. A general reassurance that “we use enterprise security” is not.

If the application was present, ask whether the provider searched the published application identifiers and indicators across service-principal sign-ins, directory changes, application credentials, role assignments, mailbox changes, and relevant workload audit logs. Ask for the time window and the time the review was completed. ConnectWise recommends reviewing both the provider’s own tenant and every managed customer tenant, including dormant connections.

Dormant matters. A backup relationship can stop producing jobs while its enterprise application remains consented in the customer tenant. An old connection may still have a service principal, permissions, and historical credentials. “We stopped using that product last year” should trigger a check, not an exemption.

Ask what evidence was preserved. A good answer might name Entra sign-in exports, unified audit logs, Exchange changes, application credential records, and a ticket containing timestamps. You do not need a dump of sensitive logs by email. You need confidence that the provider can support its conclusion after the dashboard window moves on.

Ask whether any unauthorised credentials, owners, applications, consent grants, directory roles, forwarding rules, or delegated mailbox permissions were found. If the answer is yes, the next questions are which objects changed, when they were contained, what data or functions those objects could reach, and whether legal, insurance, or notification duties were assessed.

Ask for the last confirmed successful backup and the plan during the suspension. Find out which workloads are currently without new copies and whether restores are unavailable. Request the test result after service resumes.

These questions belong in an ordinary handover with the provider. The vendor sees the vendor environment. The managed service provider sees its management systems and customer fleet. The customer knows which data and business processes matter. No one party holds the whole picture.

A written answer is useful because it separates dates and claims. “No evidence found in logs retained from 13 to 19 October” has a boundary. “No impact” hides one. If some required logs were unavailable, record that limitation and use other evidence rather than turning absence of records into certainty.

Reduce the next application’s blast radius

Once the immediate review is complete, inventory the applications already trusted in Microsoft 365. Start with those holding broad application permissions or privileged directory roles. Record the publisher, business owner, technical owner, purpose, permissions, credential type, credential expiry, last sign-in, and planned review date.

Remove applications with no current owner or purpose after confirming they are unused. For applications that remain, reduce permissions to the operations the service performs. A backup product may need substantial read access, but a reporting tool may not need to write directory objects. A convenience integration should not inherit the authority of a tenant administrator merely because setup was easier that way.

Review who can grant tenant-wide consent and who holds Application Administrator or Cloud Application Administrator. These roles can change the software identities that other controls trust. Keep the group small, protect its human accounts strongly, and alert on role assignment and credential creation.

Prefer certificates or managed workload identities over long-lived shared secrets where the platform supports them, while remembering that a stolen certificate is still a stolen credential. Store private keys in hardware-backed or tightly controlled key services. Rotate them on a schedule and after staff, supplier, or system changes that affect custody.

Microsoft Entra offers conditional access for workload identities under specific licence requirements. It can restrict where service principals sign in from and feed risky service-principal detections into policy. This can make a credential copied to an unrelated hosting provider harder to use. It needs testing because vendor services may legitimately operate from changing cloud infrastructure.

Create alerts for unusual service-principal sign-ins, new application credentials, new owners, new consent grants, and directory-role assignments to applications. Send those records outside the tenant when practical. An attacker with broad tenant authority may be able to interfere with local settings, so a separate security system or logging account gives the evidence another home.

Build offboarding for software, not just people. When a contract ends, remove the enterprise application, revoke its consent, retire credentials you control, and verify that scheduled jobs and support accounts are gone. Record the completion. Disabling billing or deleting a dashboard account does not necessarily withdraw tenant consent.

Finally, practise one vendor-identity incident. Pick a non-critical application and ask: where are its sign-ins, how would we disable it, which tokens or sessions might remain, which changes could persist, who can export the logs, and what business process stops when the connection goes away? The exercise turns a list of console pages into a response path.

This is the broader lesson from the ConnectWise event. SaaS integrations create supply chains of authority. A vendor may have no route into your office network yet still hold a software identity accepted by your cloud tenant. That route deserves the same inventory, narrowing, monitoring, and exit procedure as any other administrator.

A measured checklist for the next 24 hours

If your organisation or provider used ConnectWise Cloud Backup, begin with preservation. Export relevant Entra sign-in and audit records for the window specified in the current ConnectWise guide. Preserve Exchange and Microsoft 365 audit records that cover role, application, consent, mailbox, and forwarding changes. Note the timezone and any retention gap.

Verify the seven application identities listed by ConnectWise and their local enterprise-application state. Keep affected applications disabled until the vendor issues formal restoration guidance. Do not assume that a vendor-side change produced the same visible local state in every customer tenant.

Search for the three published internet addresses, but do not stop there. Review all sign-ins by the affected application identities and inspect changes around those times. Include credentials added to other applications, application owners, new service principals, role assignments, consent grants, federation or access-policy changes, mailbox forwarding, inbox and transport rules, and delegated access.

If suspicious activity appears, involve an incident responder with Microsoft 365 and Entra experience. Preserve evidence before removing objects where the risk allows it. Revoke unauthorised credentials and sessions, remove unauthorised roles and grants, correct mailbox changes, and examine what the affected identities could read or alter. Keep a timestamped responder log.

Separately, record the last confirmed successful backup and the workloads whose new backups or restores are unavailable. Decide whether the current outage exceeds your recovery tolerance. If temporary protection is needed, assess the replacement connection instead of granting broad permissions under pressure.

If no suspicious activity appears, retain the queries and exports that support that result. Recheck the ConnectWise advisory because the investigation is ongoing and indicators may change. A negative finding dated 19 October is useful evidence. It is not a permanent warranty.

For organisations that never used the service, this incident still offers a short task worth doing: list the five most powerful third-party applications in your tenant and name an owner for each. If you cannot name them, start there. You do not need to audit every integration before lunch.

The book The Digital Fortress: Your Everyday Guide to a Safer Digital Life uses the same practical idea for everyday accounts: know which keys matter, keep fewer copies, and have a recovery route you have actually tested. The cloud version has longer labels, but the job is familiar.

One trusted application can serve thousands of tenants. That is how useful cloud services scale. It is also why the credential behind the application must be treated as a keyring rather than a single key. When that keyring is lost, the vendor closes its door and every customer checks what happened inside their own room.

For calm, practical security guidance without a daily alarm bell, join the newsletter. It is one email per month.

Sources

• ConnectWise Trust Center: Cloud Backup service interruption and investigation updates, 16–19 October 2026
• ConnectWise status page: Cloud Backup security issue and service interruption
• ConnectWise: Cloud Backup technical investigation and remediation guide
• Huntress: ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks, updated 17 October 2026
• The Hacker News: ConnectWise Suspends Cloud Backup After Attackers Compromise Microsoft 365 Tenants, 18 October 2026