Restricted Content Discovery: the Copilot safety switch you shouldn't flip everywhere

You’re about to turn on Microsoft 365 Copilot. You’ve read enough to know it surfaces oversharing: the salary sheet someone shared org-wide in 2019, the board deck nobody locked down. So you go looking for a switch that hides the scary sites, and you find one: Restricted Content Discovery.

It works. RCD keeps a SharePoint site’s files out of Copilot and org-wide search. And here’s where it goes wrong. It works so cleanly that teams start flipping it on everywhere “just to be safe.” A few weeks later Copilot is noticeably worse at answering questions, and nobody connects the two. They did it to themselves.

RCD is a real tool. It’s also one Microsoft explicitly tells you not to overuse. Both of those are true at once, and the gap between them is where this post lives.

What RCD actually does

Restricted Content Discovery stops a SharePoint site’s files from showing up in organization-wide search and Microsoft 365 Copilot, unless the asking user owns that content or recently interacted with it. It’s a per-site flag (RestrictContentOrgWideSearch), and you can turn it on for any number of sites.

What it does not do matters just as much. Straight from Microsoft Learn:

So RCD is a discoverability control, not a security boundary. It changes who can find a site through search and Copilot, not who can open it. Anyone who already had access still does. It also leaves site-context search, the Microsoft 365 Feed, and Recommendations untouched. And it cannot be applied to OneDrive.

When it’s on, a “Restricted” tag appears on the site’s Home tab, and every on, off, and justification event is written to the audit log. One practical note: turning RCD on isn’t instant. It re-indexes every file in the site, so a large site can take days to fully reflect the change.

Click to zoom

RCD vs RSS vs RAC, three controls people keep confusing

This is the part worth getting exactly right, because the three controls sound alike and do very different things.

RCD and RSS are opposite logic. RCD is a deny-list applied site by site: “hide this one.” RSS is a single tenant-wide allow-list: “show only these 100.” Microsoft frames RSS as a short-term measure while you clean up permissions, not a long-term architecture. Neither RCD nor RSS is a security boundary. They only affect discoverability.

RAC is the different animal. Microsoft’s own wording: “Users not in the specified group can’t access the site or its content, even if they had prior permissions or a shared link.” That’s a real deny.

The asymmetry between RAC and RCD is the thing to hold onto:

• RAC blocks the open, but a user with direct permissions can still see the search hit.
• RCD blocks the search hit, but anyone with access can still open the file.

They’re complementary, not interchangeable. RCD hides. RAC locks.

Why you shouldn’t flip it on everywhere

Here’s the part the “turn it on for safety” instinct skips. Microsoft puts a Caution box around RCD for a reason:

Copilot is only as good as the content it can reach. Every site you hide is a site Copilot can’t use to answer a question, so the more you restrict, the more you get vague, incomplete, or just wrong answers. Blanket RCD doesn’t make Copilot safe. It makes Copilot useless slowly, in a way that’s hard to trace back to the cause.

There’s a latency cost too. RCD re-indexes every file in a site when it’s toggled. Mass-apply it across dozens of sites and you flood the indexing pipeline, which slows index updates for everyone in the tenant, not just the restricted sites.

So RCD has a genuine tradeoff. It’s not free, and it’s not “the more the better.”

The site-selection rule

The fix is to be deliberate. Microsoft’s guidance is the rule of thumb worth memorizing:

“Highest risk,” not “anything that makes you nervous.” Build the list deliberately:

• Run the Data Access Governance reports in the SharePoint admin center and review the Active Sites tab.
• Shortlist the sites that are genuinely high-sensitivity: HR, legal, M&A, exec and board, payroll.
• Keep the list short. If it’s growing past a dozen-ish sites, you’re probably hiding things that should be remediated instead.

Because here’s the distinction that keeps RCD honest: a site that’s high-sensitivity is an RCD candidate. A site that’s merely over-permissioned is not. That’s a cleanup job. If a site has an “Everyone except external users” grant it shouldn’t, the answer is to remove that grant, not to paper over it with RCD. If the site genuinely needs to be group-restricted, hard-lock it with RAC. RCD is the wrong tool for “this site is shared too widely.”

You can delegate RCD now, carefully

Until recently, RCD lived only with tenant admins. That’s changing: Microsoft is rolling out site-owner delegation for RCD, available and rolling out through 2026.

A tenant admin enables it tenant-wide:

Set-SPOTenant -DelegateRestrictedContentDiscoverabilityManagement $true

Once that’s on, site admins can toggle RCD for their own sites, and they must supply a justification on every change, which lands in the audit log. The per-site cmdlet itself is:

Set-SPOSite -Identity <site-url> -RestrictContentOrgWideSearch $true

Delegation is off by default, and the obvious caveat: it delegates to all site admins, not a hand-picked set. That’s convenient (the people closest to a sensitive site can protect it without a ticket) but it also means the overuse risk from the section above now sits with every site owner in your tenant. If you turn delegation on, pair it with a written rule about when RCD is appropriate, or you’ll end up exactly where this post started: RCD everywhere, Copilot degraded, nobody sure why.

Licensing, briefly

RCD is part of SharePoint Advanced Management (SAM). The good news for most tenants planning Copilot: SAM is effectively bundled with Microsoft 365 Copilot. If at least one user in the tenant has a Copilot license, SharePoint admins automatically get SAM, and RCD specifically just needs that one Copilot license present somewhere in the tenant. Organizations without Copilot can buy SAM separately as the “SharePoint Advanced Management Plan 1” add-on. Either way, if you’re planning a Copilot rollout, you almost certainly already have RCD available.

The honest framing

RCD is worth using. It’s also worth being clear-eyed about what it is.

When you turn RCD on, the oversharing is still there. Every wrong permission still works. Anyone with access (including the people who were granted access by mistake) can still open everything on that site. What you’ve changed is that Copilot and org-wide search will no longer hand that content to people who go looking. That’s real value: it shrinks the blast radius of Copilot. But it does nothing to shrink the blast radius of a wrong permission.

So treat RCD as a holding measure, not a fix. Turn it on to stop the bleeding on your genuinely sensitive sites while you do the actual work: tightening permissions, removing stray org-wide grants, locking the must-be-restricted sites with RAC, classifying content with Purview. RCD stops the bleeding. Permissions close the wound. You need both, and only one of them is a real fix.

Picked right, RCD is a clean, low-effort safety switch for the handful of sites that truly warrant it. Picked badly (flipped on everywhere out of caution) it’s a slow, invisible tax on the Copilot you just paid for. The whole skill is in the shortlist.