Restricted SharePoint Search Is Retiring, and Its Replacement Is Not a Replacement

What Restricted SharePoint Search was for

It bought time.

Organizations switching on Copilot discovered a problem latent for a decade: SharePoint permissions nobody had audited were suddenly load-bearing. A budget site with sloppy access control was harmless while nobody knew it existed. Ask Copilot about budgets and it stops being harmless.

RSS was the answer to "we need to turn this on before the permissions review is finished." An admin kept an allow list of up to 100 sites that could appear in organization-wide search and, temporarily, in Copilot chat and agentic experiences. Off by default, empty by default, enabled through PowerShell, effective within an hour.

Microsoft was unusually candid about what it was not. From the Learn page: "It's a short-term solution that gives your organization's administrators time to review and audit site and file permissions. It's not intended or scalable for long-term use." And elsewhere on the same page: it "isn't a security boundary and doesn't change any permissions on SharePoint sites."

It also leaked by design: content a user owns, recently accessed, or that was shared with them in Teams or Outlook surfaces regardless of the allow list, capped at the most recent 2,000 entities. A search-scope filter with deliberate holes, not a wall.

So the retirement is not Microsoft withdrawing a security control. It is withdrawing a deadline extension.

Starting July 31, 2026, new enablement is blocked. If Restricted SharePoint Search is off in your tenant today, you cannot turn it on. Microsoft has not published a full-retirement date on the Learn page — dates in third-party roundups are not sourced to one — and for planning it does not matter much. A control you cannot enable is already not part of your plan.

---

The replacement is an inversion, not a replacement

Microsoft names three replacements: Restricted Content Discovery, SharePoint Advanced Management and Microsoft Purview. Most coverage presents RCD as the drop-in successor. It is not, and the difference is structural rather than cosmetic.

| | Restricted SharePoint Search | Restricted Content Discovery |

|---|---|---|

| Shape of the control | Tenant-wide allow list: these sites *may* be found | Per-site restriction: this site *may not* be found |

| Default | Off, list empty | Off per site |

| Scale limit | 100 sites | No list; applied per site |

| Licensing | SharePoint Online PowerShell module | Copilot license + SharePoint Advanced Management available |

| AI entry points in the UI | Unchanged | Removed — no Copilot button, AI actions menus, or Create pages with AI |

| Covers OneDrive | — | No. SharePoint sites only |

| Propagation | Within an hour | Site-size dependent; over a week above 500,000 items |

Read the first row again. One enumerates what is permitted; the other enumerates what is forbidden. A 100-site allow list and a per-site deny flag are not two versions of one policy — they are opposites, and no transformation between them preserves your intent.

If your tenant has 4,000 sites and an allow list of 90, your policy today is "3,910 sites are not discoverable." Expressing that in RCD means flagging 3,910 sites. Nobody will, and Microsoft warns against trying: "Use Restricted Content Discovery selectively. Excessive use can reduce the amount of content available to organization-wide search and Microsoft Copilot experiences, which can affect the completeness and relevance of search results and AI-generated responses."

So the honest statement of the change is this. Restricted SharePoint Search let you default to closed. Restricted Content Discovery requires you to default to open and name the exceptions. Everything in the plan below follows from that, because the permissions review RSS was buying time for is now the deliverable rather than a thing you would get to.

Two further asymmetries. RCD is more aggressive in the interface: it removes AI entry points from restricted sites — the Copilot button, the AI actions menus including agent creation, and Create pages with AI. RSS filtered results; RCD removes the affordances too. Better governance, more visible to users — so communicate it.

RCD does not cover OneDrive at all. Microsoft: "You can only apply this feature to SharePoint sites. It's not supported for OneDrive sites." Given how much casually overshared content lives in OneDrive, that gap belongs in your risk register, not a footnote.

---

The licensing gate nobody is pricing in

Restricted SharePoint Search needed the SharePoint Online Management Shell. That is all — free, in the sense that PowerShell against a licence you own is free.

Restricted Content Discovery requires, in Microsoft's words, that "your organization is licensed for Copilot and has SharePoint Advanced Management available."

SharePoint Advanced Management availability needs a qualifying base subscription — Office 365 E3, E5 or A5; Microsoft 365 E1, E3, E5 or A5; or Microsoft 365 GCC, GCC-High or DoD — plus at least one of:

• at least one user in the organization assigned a Microsoft Copilot license;
• a subscription including SharePoint K, P1 or P2 plus the SharePoint Advanced Management Plan 1 add-on;
• Microsoft 365 E7, the Frontier Suite.

The Copilot threshold is low, and that is good news. One assigned Copilot license in the tenant gives SharePoint administrators the SAM capabilities that support Copilot deployment. If you are running a Copilot pilot, you already clear the bar. Several write-ups imply a per-user SAM purchase; that is not what Microsoft's prerequisites say.

The gap is real for everyone else. RSS was "designed for customers of Microsoft Copilot Chat and agentic experiences" — and Copilot Chat is not the licensed Microsoft 365 Copilot. An organization on Copilot Chat with no paid Copilot license and no SAM add-on could enable RSS and cannot configure RCD. That is a licensing decision dressed as a deprecation notice. And Microsoft 365 Business Premium is not on the base-subscription list at all, which puts a familiar mid-market plan outside the replacement path entirely.

If that is you, the controls are the ordinary ones: permissions remediation, sensitivity labels, Purview policies, and the per-site "Allow this site to appear in Search results" setting — which Microsoft notes blocks the site from organization-wide *and* site-specific search, so it is blunter than it looks.

---

The other deadline: 1 November 2026

Copilot in SharePoint began general availability rollout on 30 September 2026, and two things changed with it.

The preview PowerShell controls are retired. `KnowledgeAgentScope`, `KnowledgeAgentSelectedSitesList` and `KnowledgeAgentSelectedSitesListOperation` are going away. Microsoft: "Existing PowerShell settings continue to be honored until November 1, 2026. After November 1, 2026, manage availability using Site AI settings and Restricted Content Discovery."

That is a smaller sentence than it deserves. `KnowledgeAgentScope` is the tenant-level switch, default `NoSites` — how an organization that wanted Copilot in SharePoint off everywhere said so in one line. After 1 November, availability is governed by:

• Site AI settings — a panel at Settings → Site AI where site owners choose which agent opens from the global header, hide the Copilot button from visitors, and enable advanced document processing for the site;
• Restricted Content Discovery — the admin control, which Microsoft confirms is respected "regardless of your other availability settings."

So the tenant-wide off switch becomes a site-owner panel plus an administrative veto that requires a Copilot license and SAM availability. The admin keeps a hard lever; the routine decision moves to the edge of the organization — the same pattern as metered Copilot Credits in SharePoint, where the people who can spend are site owners rather than administrators. Two independent changes, one direction of travel, and governance models built around central control need rebuilding rather than adjusting.

Note that the retiring sites list carried the same 100-item cap as the RSS allow list — evidence that the allow-list approach is being abandoned as a design, not just as a feature.

Advanced work now meters. Everyday capabilities stay in the Microsoft 365 Copilot license; advanced work consumes Copilot Credits through usage-based billing, enabled by a spending policy at Microsoft 365 admin center → Copilot → Cost management → Add spending policy, selecting Advanced work in SharePoint under Agents and services.

One trap there deserves reading twice. Microsoft: "Existing cost management policies might automatically include newly available services if the Allow new agents and services as they become available option is turned on for the policy." If you created a policy for an earlier Copilot workload and left that option on, advanced work in SharePoint may already be enabled for its scope without anyone deciding so. Check it rather than assume it.

---

The 60-day plan

Week 1 — establish where you actually are.

Check whether Restricted SharePoint Search is enabled and what is on the allow list — that list is the written record of which sites someone already decided were safe, and it is about to stop doing anything. Export it. Check `KnowledgeAgentScope` and the selected sites list. Confirm a Copilot license is assigned somewhere in the tenant and that your base subscription clears the SAM requirement. Review every Copilot cost management policy for Allow new agents and services as they become available.

Weeks 2–3 — find the oversharing, with the tools built for it.

Microsoft names the inputs: the SharePoint Admin Agent, Content management assessment, Data Access Governance reports and Catalog management. Use them to rank the sites needing review before broad discoverability — high oversharing risk, permissions under review, phased Copilot rollout, governance initiatives requiring validation.

Do not treat the inverse of your RSS allow list as that list. "Not approved" and "actively risky" are different sets, and the second is much smaller.

Weeks 3–4 — apply Restricted Content Discovery to the sensitive sites, early.

Per site from the SharePoint admin center (Sites → Active sites → the site → Settings → turn Restrict content from Microsoft Copilot on) or by PowerShell:

```powershell

Set-SPOSite -Identity -RestrictContentOrgWideSearch $true

```

Start with the largest sites: above 500,000 items, propagation can take more than a week. Applying RCD to a million-item records site on 31 October achieves nothing on 1 November.

Decide whether site administrators should manage this themselves:

```powershell

Set-SPOTenant -DelegateRestrictedContentDiscoverabilityManagement $true

```

Delegation requires a justification from the site admin on every change, and those land in Microsoft Purview audit log activities alongside enable and disable events — a good audit trail, and a reason to prefer delegation if your site owners are competent.

Report across the tenant with `Start-SPORestrictedContentDiscoverabilityReport`, then `Get-SPORestrictedContentDiscoverabilityReport` to check status and download.

Week 4 — the 1 November check.

Confirm what your retiring PowerShell settings were doing, then confirm the same outcome is expressed in Site AI settings and Restricted Content Discovery. If `KnowledgeAgentScope` was `NoSites` and you intend to stay off, verify that explicitly — do not leave the intent in a cmdlet that stops being honored.

Weeks 5–8 — do the work RSS was buying time for.

Permissions remediation on the ranked list. Sensitivity labels and Purview DLP where classification is the real control rather than discoverability. Access reviews. Then, as Microsoft recommends, remove the restriction from validated sites — leaving RCD on indefinitely degrades the Copilot quality you are paying for.

Also scope the spending policy to content managers and site managers, and tell site owners that advanced work costs money — the cheapest control available is telling people the button bills.

---

Our read

The temptation is to read this as Microsoft removing a safety net. It is closer to the opposite: removing a snooze button.

RSS was never a security control, was documented as not being one, and leaked by design. What it provided was time — and a great many organizations spent that time running Copilot rather than auditing permissions. The replacement is stricter, better audited, and wired into Purview. On the merits it is better.

But it is not the same shape, and pretending otherwise is how this goes wrong. A control that defaults to closed has been replaced by one that defaults to open with named exceptions. That is only a safe trade if the permissions underneath are right — the condition RSS existed to let you postpone.

The organizations that will be fine are the ones treating 1 November as the date the postponement ends, not the date a cmdlet changes.

---

Want the oversharing report, the Restricted Content Discovery scope and the 1 November availability check done against your tenant? See SharePoint & Copilot and SharePoint Consulting, or get in touch.

Related: Copilot Credits and who holds the spending pen · agent identities and the SharePoint permission model

Sources

All Microsoft Learn pages below were read on 26 October 2026.

• Restricted SharePoint Search — Microsoft Learn
• Restrict discovery of SharePoint sites and content (Restricted Content Discovery) — Microsoft Learn
• Prerequisites for SharePoint Advanced Management — Microsoft Learn
• Get started with Copilot in SharePoint — Microsoft Learn
• Usage-based billing and Copilot Credits — Microsoft Learn