TL;DR: ConnectWise is investigating unauthorized access tied to its Cloud Backup for Microsoft 365 service, with early community reports describing possible tenant access through the backup application's Microsoft Entra permissions, according to Coalition. The issue underscores how third-party backup access can create broad tenant-wide exposure when application credentials are abused.
At a glance
What this is: This is an investigation into unauthorized access tied to a Microsoft 365 backup application, with community reports suggesting tenant-level data access through Microsoft Entra permissions.
Why it matters: It matters because backup applications often hold broad, unattended access across many tenants, so one compromised app identity can turn a routine resilience control into a multi-tenant exposure path.
Context
Cloud backup for Microsoft 365 depends on application-level access that runs without a user sign-in, password prompt, or MFA challenge. That model is normal for unattended backup, but it creates a governance gap when the application itself becomes the trust boundary.
The security problem is not the presence of a backup app in the tenant. The problem is that tenant-wide permissions and shared provider credentials can create a single point of compromise across many customers, especially where MSP-managed access is involved.
Key questions
Q: What should teams do first when a third-party backup app shows suspicious Microsoft Entra activity?
A: First, suspend the application if the activity matches known indicators, then preserve sign-in and audit logs before the retention window closes. After that, validate whether any bulk mailbox, SharePoint, or Teams access aligns with the backup schedule. The priority is containment and evidence preservation before you assume the service is benign.
Q: Why do Microsoft 365 backup applications create elevated access risk?
A: They operate with tenant-wide application permissions and no human sign-in, which means the app itself becomes the trust boundary. If its credentials are compromised, the attacker can inherit the backup service's own access scope across every approved tenant. That makes the application identity a privileged control point, not a passive integration.
Q: What are the signs that backup application access may be abnormal?
A: Look for access outside the normal backup schedule, unusual source IPs, unfamiliar user agents, and bulk reads that do not match the provider's expected operating pattern. In isolation those signals are not proof of compromise, but together they justify treating the application as a potentially abused non-human identity.
Q: Who is accountable for third-party application access in Microsoft 365 tenants?
A: The customer remains accountable for what external applications can reach its tenant, even when an MSP or vendor operates the service. That means approval, review, suspension, and revocation need an explicit owner and a documented lifecycle. Shared operation does not remove the need for clear governance over the application identity.
Technical breakdown
Why Microsoft Entra application sign-ins expand tenant blast radius
Microsoft Entra applications authenticate as the app, not as an interactive user. That means the backup service can act across a tenant with the permissions already granted at approval time, usually to read mailbox, SharePoint, and Teams content. If an attacker obtains the application's credentials or abuses its sign-in path, the activity can look like normal service traffic because bulk reads are expected for backup operations. The control challenge is that the identity is non-interactive, so standard user-centric defenses such as MFA and conditional access for humans do not meaningfully constrain this access path. See the Microsoft 365 Security Guide. See the Microsoft 365 Security Guide.
Practical implication: Model backup apps as privileged non-human identities with tenant-wide blast radius, not as ordinary SaaS integrations.
Why backup activity is hard to distinguish from compromise
Backup services generate exactly the kind of access patterns that security teams are trained to ignore at scale: repetitive reads, broad data traversal, and activity outside a human session. That makes audit logic and alerting dependent on context such as the app ID, source IP, user agent, and scheduling window rather than on the volume of access alone. In practice, the risk sits in the mismatch between expected service behavior and abnormal operational provenance. When those signals are missing, an attacker can blend into legitimate backup flows long enough to reach large data sets without triggering user-focused detections. See the IAM and IGA Basics. See the IAM and IGA Basics.
Practical implication: Correlate app identity, source provenance, and schedule context before treating bulk access as normal backup behaviour.
How partner-managed backup access changes the governance problem
When an MSP deploys the same backup application across many clients, the tenant owner does not fully control the full lifecycle of that access path. Approval, revocation, monitoring, and incident response may be split between the customer, the service provider, and the vendor, which makes accountability and offboarding harder to execute cleanly. The result is a third-party non-human identity problem, not just a tenant misconfiguration problem. The governance question becomes who owns ongoing review of the application, its permissions, and its evidence trail after initial approval. See the Authorisation Models Guide. See the Authorisation Models Guide.
Practical implication: Assign explicit ownership for third-party app approvals, monitoring, and revocation before the service is deployed.
Threat narrative
Attacker objective: The objective is to use a trusted backup application's tenant-wide permissions to read and exfiltrate Microsoft 365 data at scale.
- Entry occurs through the backup application's Microsoft Entra identity, which can access tenant data without a human sign-in or MFA prompt.
- Credential abuse would let an attacker operate as the application itself, turning approved tenant-wide permissions into direct access to mailbox, SharePoint, and Teams data.
- Impact would be broad data exposure across every tenant that approved the application, with suspicious activity hiding inside normal backup-style access patterns.
Breaches seen in the wild
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Third-party backup applications are privileged non-human identities, not routine SaaS add-ons. The important governance fact is that they authenticate at the application layer and often hold tenant-wide read scope by design. That means their security posture belongs in NHI governance, not in a general procurement checklist. Practitioners should treat them as privileged identities with explicit ownership, review, and revocation paths.
Backup services create a standing-trust problem because their normal behaviour resembles malicious bulk access. A service that reads mail, SharePoint, and Teams at scale will naturally generate activity patterns that human-centric monitoring can misread or ignore. The practical consequence is that detection must key off app identity, provenance, and schedule, not access volume alone. This is a governance gap, not a logging nuisance.
Vendor-managed access does not remove customer accountability for the application lifecycle. In MSP deployments, the customer may approve the app while the provider operates it, which fragments monitoring and offboarding responsibility. That split makes third-party NHI governance a shared-control problem rather than a simple tenant-admin task. Organisations need a named owner for every external application identity that can reach production data.
Bulk backup access should be governed as identity blast radius, not as benign throughput. The same permissions that make unattended backup work also define how far compromise can travel if the application's credentials are exposed. Identity and access basics matters here because entitlement scope, lifecycle control, and review cadence determine whether a backup app remains a resilience control or becomes an enterprise-wide exposure path.
Policy and evidence controls matter more than the application label. 'Backup' does not automatically mean low risk, just as 'approved' does not mean continuously safe. The field needs to stop assuming that service intent explains service risk; the real question is whether the application's identity, permissions, and observability are governed like any other privileged access path.
What this signals
Backup applications should be governed as production identities, not as convenience integrations. The access they hold is often broader than the average business app, and the operational model makes compromise harder to detect than a user-account incident. That shifts the control objective from simple enablement to continuous lifecycle governance and evidence-based review.
Third-party app governance is now a Microsoft 365 resilience issue. If one external application can read mail, SharePoint, and Teams across multiple tenants, then backup availability and identity risk are tightly coupled. Practitioners should prepare to review external application inventories, not just user access, as part of their cloud governance baseline.
Identity blast radius is the right lens for backup services. When a service account or app identity is allowed broad tenant access, the question is not whether it is expected to be busy. The question is how far a compromise can move before detection, and whether the organisation can revoke that path quickly enough to matter.
For practitioners
- Disable the backup application until remediation is confirmed In Microsoft Entra, suspend the enterprise application if suspicious activity matches the known indicators, then restore only after the provider confirms remediation and you have revalidated the tenant's access posture.
- Search for the published indicators across sign-in and audit logs Review Entra sign-in logs and the Microsoft 365 unified audit log for the listed app ID, source IP, and user agents, then preserve the evidence before retention expires. See the Cloud Incident Response Guide.
- Validate unusual bulk access against the backup schedule Compare mailbox, SharePoint, and Teams access patterns with the service's normal backup windows so you can distinguish expected reads from out-of-pattern activity.
- Assign a named owner for third-party application approvals Record who can approve, review, suspend, and revoke each external Microsoft 365 application so the customer, MSP, and vendor do not leave ownership ambiguous.
- Review tenant-wide app access quarterly Inventory every external application with production access in Microsoft 365, then recertify the scope and necessity of each app identity on a fixed cadence.
Key takeaways
- The incident shows how a cloud backup application can become a high-value non-human identity when it holds tenant-wide Microsoft 365 permissions.
- The key risk is not ordinary app usage, but the possibility that compromised application credentials can mimic normal backup traffic while reaching mail, SharePoint, and Teams data.
- Customer-owned governance over approval, monitoring, and revocation is essential when third-party applications are allowed to operate across production tenants.
Related NHI Mgmt Group resources: Microsoft 365 Security Guide · Authorisation Models Guide · IAM and IGA Basics · Cloud Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on a third-party backup application whose compromise could affect many tenants. |
| NHI-05 — Overprivileged NHI | The backup app's tenant-wide permissions define the blast radius if the identity is abused. | |
| NHI-10 — Human Use of NHI | MSP and customer workflows can blur accountability for non-human identities in production tenants. | |
| Recommendation — Inventory and continuously review third-party NHI approvals, ownership, and revocation paths before they become shared exposures. Reduce app permissions to the minimum viable scope and recertify high-risk access on a fixed cadence. Separate human administration from application identity use and document who may operate each production NHI. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article describes suspicious authentication activity followed by possible data theft through the app identity. |
| Recommendation — Map app-account abuse to credential access and exfiltration techniques so detections focus on identity misuse, not only users. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The compromise path depends on managing the application's authenticators and their lifecycle. |
| Recommendation — Apply authenticator lifecycle controls to service identities and revoke exposed application secrets immediately. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The risk comes from broad application entitlements granted to a backup service. |
| Recommendation — Review and limit third-party application entitlements so tenant-wide access is justified, documented, and monitored. | ||
Key terms
- Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
- Application Identity: Application identity is the distinct identity assigned to an application, service, or workload so it can authenticate and be authorised to access other resources. If unmanaged, it becomes a target for credential theft and overprivilege. Defenders should inventory these identities, restrict secrets, rotate credentials, and monitor service-to-service use.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Tenant-Wide Application Permission: An application permission that applies across an entire tenant instead of a bounded set of users, mailboxes, or sites. In practice, it can give an app far more access than it needs. That increases blast radius, complicates governance, and makes least privilege harder to enforce.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org