You're evaluating a cloud backup vendor for your Microsoft 365 environment. The sales engineer says their tool needs "broad permissions" to protect your data. Your security team flags the permission request: Directory.ReadWrite.All. Your compliance officer wants to know what happens if those credentials leak.
This isn't a hypothetical exercise anymore. ConnectWise suspended its Cloud Backup service after attackers compromised credentials with exactly these permissions, leading to unauthorized sign-ins across 162 customer tenants. You're now facing a decision that every enterprise must make: how much access do you grant third-party applications in your cloud environment?
The Decision You're Facing
When you deploy a cloud backup service, SaaS security tool, or management platform in your Microsoft 365 or Google Workspace environment, you're choosing between three permission models:
- Scoped read-only access with limited data types
- Elevated read permissions across multiple workloads
- Full directory read/write permissions with administrative capabilities
The ConnectWise incident showed the risks of the third option. Attackers didn't just read backup data. They used Directory.ReadWrite.All permissions to assign themselves administrative roles, create new application credentials, and establish persistence mechanisms that survived credential rotation.
Key Factors That Affect Your Choice
Your vendor's technical architecture matters more than their security certifications. ConnectWise Cloud Backup needed broad access to mailboxes, OneDrive, SharePoint, and Teams because of its design. But design choices can change. Ask your vendor: can your tool function with read-only permissions? Can you scope access to specific mailboxes or SharePoint sites instead of the entire tenant?
Your incident response capabilities determine your recovery time. ConnectWise confirmed the compromise on a Saturday. They revoked certificates and invalidated shared credentials. But as Huntress noted, rotating the vendor credential isn't enough when attackers have already assigned themselves Global Administrator roles or added credentials to other applications. If you can't audit every directory role assignment and application permission grant in your tenant within hours, you can't contain this class of attack.
Your managed service provider relationship creates amplification risk. If you're an MSP customer, a compromise at the vendor level doesn't just affect your tenant. Huntress observed attackers using their foothold in one customer to pivot to others. This isn't a vendor problem you can contract away through indemnification clauses. It's an architectural exposure.
Path A: Grant Elevated Permissions (Directory.ReadWrite.All)
Choose this path when:
You've verified the vendor implements credential segmentation. Each customer environment should use unique credentials, not shared secrets. ConnectWise revoked "all shared credentials previously used for Cloud Backup" after the attack, which suggests a shared credential model. If your vendor can't explain how they isolate customer credentials, don't grant write permissions.
You maintain continuous monitoring of directory role assignments. You need automated alerts when any application or user receives elevated roles, especially outside business hours. Huntress saw attackers assign directory roles on October 15. If you're reviewing role assignments weekly or monthly, you're not prepared for this attack pattern.
You've documented every permission the application holds. When ConnectWise suspended service, customers couldn't determine whether their tenants were breached because they lacked visibility into what the application had accessed. Build a permission inventory before you grant access: which mailboxes, which SharePoint sites, which Teams channels. If the vendor's access is compromised, you'll know what to audit.
Your vendor provides real-time access logs. ConnectWise told customers it "does not have visibility into partner and customer environments" and couldn't determine which Microsoft 365 environments were breached. That's unacceptable for any application with write permissions. Require access logs you can correlate with your own Microsoft 365 audit logs.
Path B: Restrict to Read-Only or Scoped Permissions
Choose this path when:
The vendor's core function doesn't require write access. A backup tool needs to read your data and store copies. It doesn't need to modify directory settings, create new users, or assign administrative roles. If the vendor says their product "won't work" without Directory.ReadWrite.All, ask them to explain which specific features break with read-only access. Often, the answer reveals convenience choices, not technical requirements.
You can accept delayed recovery in exchange for reduced blast radius. Read-only permissions mean the vendor can't automatically restore data to your environment. Your team will need to download backups and restore them manually. That's slower, but it also means a compromised vendor credential can't modify your production environment.
You're in a regulated industry with data sovereignty requirements. If you're subject to CIRCIA reporting requirements or operate critical infrastructure under NIS2, you need to explain to regulators how a third-party vendor accessed your systems. "We granted them Global Administrator equivalent permissions because their product required it" won't satisfy an examiner.
Your threat model includes nation-state actors. ConnectWise dealt with a nation-state attack on its remote management software last year. If your organization is a potential target for advanced persistent threats, every third-party application with elevated permissions is a potential supply chain vector. Huntress observed a second wave of attacks targeting systems "in the policy, national security, trade, and critical mineral sectors." These weren't random targets.
Path C: Build Internal Capabilities Instead
Choose this path when:
You have the technical resources to implement your own backup automation. Microsoft 365 provides APIs for backup and recovery. Google Workspace offers similar capabilities. If you can build internal tooling that runs with service accounts you control, you eliminate the third-party risk entirely.
Your compliance requirements prohibit third-party access to certain data types. Some organizations can't grant external applications access to executive mailboxes, legal hold data, or classified information. If your vendor can't provide tenant-level permission scoping, you'll need to build separate solutions for sensitive data.
You've calculated the total cost of vendor risk management. Third-party risk assessments, vendor security questionnaires, contract negotiations, insurance implications, incident response planning. Add up the annual cost of managing a high-risk vendor relationship. Sometimes building internal capabilities is cheaper.
Summary Matrix
| Factor | Elevated Permissions | Read-Only/Scoped | Internal Build |
|---|---|---|---|
| Recovery speed | Fastest (automated) | Moderate (manual) | Moderate (depends on tooling) |
| Blast radius if compromised | Full tenant access | Limited to read operations | Contained to service account scope |
| Vendor risk management overhead | High (continuous monitoring) | Moderate (periodic review) | Low (no vendor) |
| Technical resource requirement | Low (vendor managed) | Low (vendor managed) | High (in-house development) |
| Suitable for MSP environments | No (amplification risk) | Maybe (depends on isolation) | Yes (full control) |
| Regulatory explanation burden | High (justify broad access) | Moderate (justify data egress) | Low (internal controls) |
The ConnectWise incident proved that "we trust our vendor" isn't a risk management strategy. Before you click "Accept" on that permission request, know what you're granting, how you'll monitor it, and what you'll do when it's compromised. Because the question isn't whether your vendor will face an attack. It's whether your architecture can survive it.
