Auditable External Sharing Without a SharePoint Migration: Mary Kay’s Path Away From Microsoft 365 Guest Access

Mary Kay Inc. is a privately held, direct-selling skin care and cosmetics manufacturer headquartered in Addison, Texas, operating across about 35 markets with a global network of independent beauty consultants. The company is fully integrated. It runs its own research, its own manufacturing, and its own global distribution, which means a steady stream of files has to cross the company boundary: to raw-material vendors, contract partners, and the auditors who arrive every year.

Inside that boundary, everything lives in Microsoft 365. SharePoint Online and Teams are the backbone for user content and personal productivity, and Mary Kay had no intention of changing that. The problem was the edge. Microsoft 365 is built for collaboration inside a tenant, and every time a file had to reach someone outside it, the tools got worse.

External Sharing Was the Gap in the Microsoft 365 Backbone

Kevin Percival, Mary Kay's Director of End User Computing and Supporting Platforms, described the situation plainly:

“We have found its external sharing capabilities to be difficult to use, unreliable, and very difficult to audit.”

The standing answer for outside access was Microsoft Remote Guest Access: create a guest account, grant it into the shared content, and hope somebody remembers to take it away. In practice, every vendor, auditor, or contract partner who needed files meant either a share that was nearly impossible to audit or a guest account nobody wanted to own. The team that administered guest access deflected the requests when it could. IT could not confidently answer who outside the company could see what. And the need recurred on a schedule: each tax season brought a fresh wave of auditors who needed access for a few months and then, in theory, needed it revoked.

Mike Minor, the senior technical consultant who now runs Mary Kay's file transfer platform, gave his own verdict on guest access:

“It’s insecure, and the administration on it is a real pain.”

The diagnosis was simple: Mary Kay was running its external file exchange on mechanisms built for internal collaboration, and the cost landed on the people accountable for security and administration.

The Fix Had to Complement Microsoft 365, Not Compete With It

The problem persisted because the obvious fixes were all wrong. Moving content off Microsoft 365 was never on the table. SharePoint and Teams are where the business actually works, and Percival's stated requirement was a platform that complements Microsoft 365 rather than competing with it. So external sharing had to be carved off the estate without forcing a single business user to change where they keep their files. And the change could not be a big-bang migration of every external relationship at once; it had to absorb requests as they came.

Meanwhile, the case for acting grew. The requests kept recurring, the administration burden kept climbing, and the company had decided for security reasons to move away from guest access as much as possible. What it needed was a layer where access for an outside party is easy to grant, easy for them to use, recorded every time, and gone when the engagement ends, while internal content stays in SharePoint. Mary Kay selected Files.com to be that layer.

An External-Facing Layer Kept in Sync With SharePoint

Files.com became Mary Kay's external-facing file platform, sitting beside Microsoft 365 rather than in place of it.

Mary Kay connected SharePoint Online to Files.com, with one-way and two-way Syncs keeping designated folders matched. Internal teams now keep working in SharePoint, while external parties work on Files.com. Internal staff sign in to Files.com through single sign-on against Azure Active Directory, so their access follows corporate identity.

External relationships moved to Files.com followed one pattern. Each engagement received a shared folder holding internal staff and external users side by side, typically a handful of each. Accounts for short engagements carried access-expiration dates, so an auditor's credentials could be set to end with the audit. A 90-day inactivity rule disables any external account nobody is using, with re-enable on request. Dormant access shuts itself off by default instead of lingering until someone notices.

Mary Kay also built a Microsoft Form intake that used Power Automate and the Files.com API to create the folder, user, and permissions. Instead of beginning with a guest account someone had to babysit, an external-sharing request could become a repeatable form submission. For one-off exchanges, Files.com Share Links send files out and Inboxes collect them in, with access recorded on the same platform.

Demand Moved Off Guest Access Without a Mandate

With the layer in production, Mary Kay began moving external-sharing requests away from guest accounts and hard-to-audit shares. Each relationship could now be scoped to the right folders, logged in one place, and designed to expire instead of remaining open indefinitely.

The more telling result was behavioral. Named users grew from 250 at go-live to more than 300, driven by staff who had used guest access asking to be moved onto Files.com. The administrators who once handled guest access now route those requests to the Files.com team. Adoption came from pull, not mandate.

Fixing the Boundary Without Touching the Backbone

Today, when someone at Mary Kay needs to exchange files with an outside party, the answer is increasingly a governed grant instead of a guest account: a folder, a credential with an end date, and a record of every access. That request used to be the one the guest-access administrators dreaded, and the account it produced was the one nobody could confidently audit later.

Microsoft 365 never moved. Nobody was retrained, no SharePoint content was migrated, and no SharePoint cutover was ever scheduled. Files.com carved the external-facing workload off the estate, kept it synced with SharePoint, and let demand do the retiring, one request at a time. Fixing external sharing did not require replacing the platform the company works in. It required giving the boundary a platform of its own.