A Dormant Guest Account Is an Unlocked Front Door. Close It in Layers.

The breach that hurts most is the one that signs in with valid credentials. No malware, no exploit, no phishing campaign against your client. Just a guest account from a partner's domain, dormant for months, suddenly active and reading everything it was ever granted.

Businesses want frictionless collaboration with vendors, contractors, and partner companies. Files move through SharePoint, conversations move through Teams, and the security model quietly drifts toward wide open. This post walks through a realistic scenario and the exact Microsoft 365 controls, in layers, that turn guest access from a liability into something you can defend.

How a vendor's breach becomes your client's breach#

Tech Corp is a mid-sized software company, about 300 employees, standardized on Microsoft 365 and heavy on SharePoint and Teams. They work with dozens of contractors, freelancers, and partner organizations. You are their MSP.

The call comes in: "One of our vendors had a breach, and the attackers might have used that access to get into our tenant."

The logs confirm it. A guest account from the vendor's domain, inactive for months, suddenly logging in, downloading files, and viewing customer data. The access was not limited: that one compromised guest could see multiple Teams channels and SharePoint sites holding product roadmaps, customer information, and financial files.

Because guest restrictions were never configured, the external user could also see the employee directory, which let the attacker map the org, identify key teams, and target the most valuable data. There was no MFA requirement for guests, so the compromised partner password worked on the first try. And there were no alerts; Tech Corp learned about the breach when the vendor disclosed it three weeks later.

The damage: stolen intellectual property, a major customer questioning Tech Corp's security, and a painful, expensive incident response.

How did they get here? Months earlier, Tech Corp left external sharing near the defaults, because Microsoft optimizes for productivity out of the box. That effectively meant "we can share documents with anyone." It worked until an executive found a sensitive financial document exposed through a forwarded Anyone link; the recipient never even had to sign in. That is usually the moment leadership asks the right question: how do we lock this down without breaking collaboration?

In layers. Here they are.

Layer 1: kill Anyone links and reset SharePoint sharing defaults#

First stop, the SharePoint admin center. Anyone links are public links: they can be forwarded, copied, pasted, and opened by unintended recipients, often with no authentication and limited accountability.

In SharePoint Admin Center > Policies > Sharing, set this baseline:

1. External sharing: "New and existing guests." Forces external users to authenticate or verify through a secure process, which dramatically reduces anonymous exposure.
2. Default link type: "Specific people." Promotes least privilege by making the sharer name who gets access.
3. Default permission: "View." Many orgs accidentally overshare with edit rights.
4. Enable link expiration. Expiring access is the simplest cure for forever-access drift.

If you do nothing else, moving from Anyone links to New and existing guests plus expiration eliminates the most common data leaks.

Layer 2: know which sharing flow your tenant uses, because it decides whether guests accumulate#

When you share externally under "New and existing guests," the recipient lands in one of two experiences, and tenant configuration (including SharePoint and OneDrive B2B integration) decides which:

Code flow, where the recipient verifies with a one-time passcode emailed to them and no guest user is created in Entra:

Sign-in flow, used when B2B integration is enabled, where the recipient signs in, consents, and is created as a guest user in Entra:

The practical implication for MSPs: some tenants quietly accumulate guest users, others allow access through verification workflows that still need governance. Either way, assume external collaboration creates long-lived access paths unless you deliberately manage the lifecycle. Microsoft documents the sharing behavior in Secure external sharing in SharePoint (opens in new tab) and the PowerShell to change the integration in Microsoft Entra B2B integration for SharePoint and OneDrive (opens in new tab).

Layer 3: shrink what guests can see and who can invite them#

Next stop: Microsoft Entra admin center > External Identities > External collaboration settings. This is where Tech Corp made two critical mistakes: guests had too much directory visibility, and guest invitations were too open.

Restrict guest directory visibility. Limit what guests can see inside the directory so a compromised guest cannot enumerate employee names, group memberships, and organizational structure. Directory visibility is a lateral movement gift in a breach; deny it.

Control who can invite guests, without breaking the business. Defaults often allow broad invitations, including guests inviting other guests. But overcorrecting to admins-only creates a helpdesk nightmare: "I can't share with the client," "our vendor can't open the file," "the Teams invite is blocked." The practical middle ground is allowing member users and specific admin roles, or using the Guest Inviter role in a controlled invitation model, depending on the org's maturity. This is exactly where MSPs earn their keep balancing security against real workflows.

Layer 4: enforce MFA for guests so you stop inheriting vendor weakness#

This is the layer where Tech Corp's incident becomes avoidable. With MFA enforced for guests, a compromised partner password is no longer a key to your tenant. The vendor's security can be weak; your tenant does not have to inherit that weakness.

The clean approach is a dedicated Conditional Access policy for guests.

The friction fix: trust outside MFA with cross-tenant access settings. Guest MFA's main side effect is confused external users being forced to register a second MFA method. For organizations you work with frequently, configure them in cross-tenant access settings (opens in new tab) and use trust settings to accept their MFA instead. We suggest caution here: weigh what data they touch and what factors the outside org actually uses. If they run SMS and your standard is phishing-resistant, do not inherit their MFA.

Layer 5: make unmanaged devices view-only#

In the Tech Corp breach, the guest downloaded data, potentially to an unmanaged device. Conditional Access can cut that exfiltration path: guests reach SharePoint and OneDrive through the browser but cannot download locally unless the device is compliant or managed.

Two common approaches:

• Require a compliant or hybrid-joined device for rich-client access
• Enforce web-only access (the limited browser experience) on unmanaged devices

That turns a compromised guest account from a "download the world" incident into a contained one. One warning: mis-scoping these policies can break legitimate internal workflows, so test and phase the rollout.

Layer 6: put sensitivity labels on the crown jewels#

Even with everything above, the most sensitive content (IP, financials, customer data) deserves protection that travels with the file. That is Microsoft Purview sensitivity labels.

A simple taxonomy works best: Public, Internal, Confidential, Highly Confidential. For the sensitive tiers, configure protections so only internal users can open the file, external guests are blocked, and rights management enforces the controls even after a sharing attempt.

This is belt and suspenders by design: Conditional Access reduces download risk, sensitivity labels reduce access risk on the items that matter most.

Layer 7: review and remove guests on a schedule#

Tech Corp's breach hinged on a guest account inactive for months, which is painfully common. With Entra ID P2 or equivalent governance licensing, Access Reviews (opens in new tab) systematically review and remove guest access on a cadence; quarterly is a great starting point.

Access Reviews can route reviews to the right owners, prompt justification, and automatically apply results by removing access. One nuance worth knowing: reviews remove access to groups, teams, and resources, but may not delete or disable the guest object itself in all cases. Removing access is still the piece that stops data exposure.

Run the breach again with the layers in place#

Same vendor compromise, different tenant:

• The compromised guest hits MFA and is likely stopped at the door
• If they get in, unmanaged-device restrictions block local download and exfiltration
• Limited directory visibility denies the org map for lateral targeting
• Sensitivity labels block the documents that matter most
• Access Reviews already removed the dormant guest months ago
• Anyone links are blocked and every link expires

Same vendor breach. Very different outcome.