If your organisation opted into Microsoft's enforcement delay back in February, the window is closing. Here's everything you need to do before 1 June, and why the time to start is now, not May
When Microsoft announced SharePoint Online's Content Security Policy enforcement in early 2026, they included a lifeline for organisations that needed more time: a Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true flag that pushed enforcement from 1 March to 1 June 2026. If your IT team enabled that flag, you bought yourself 90 days.
Those 90 days are now running out.
The purpose of the delay was to give organisations time to audit their environments, fix non-compliant scripts, and test changes, not to skip preparation entirely. If you haven't started yet, this post is your starting gun.
What Happens on 1 June
- Inline JavaScript will be blocked on all modern SharePoint Online pages.
- Scripts loaded from external sources not registered in your Trusted Script Sources list will be blocked.
- Users will see broken web parts, missing functionality, and JavaScript errors with no visual warning that CSP is the cause.
Check Whether You're on the Delay
If you're not certain whether your tenant enabled the delay, check it now via PowerShell:
Get-SPOTenant | Select-Object DelayContentSecurityPolicyEnforcement
If the value returns True, enforcement is delayed until 1 June. If it returns False, enforcement was already live on 1 March. Check whether anything broke in your environment around that date.
Your Action Plan: The Next 8 Weeks
Week 1–2: Audit
Before you can fix anything, you need to know what's broken. Two tools:
- Microsoft Purview: Search the audit log for "Violated Content Security Policy". This returns a tenant-wide list of every page and script source that triggered a CSP violation during the report-only window. This is your master list.
- Browser console +
?csp=enforce: Append?csp=enforceto any modern page URL to force enforcement mode. Open Developer Tools (F12) and check the Console tab for blocked script errors. Use this to verify specific pages.
Don't Skip the Audit
The most common mistake teams make is fixing the scripts they know about and missing the ones they don't. The Purview audit log is the only way to surface violations across your entire tenant, including pages and solutions built by people who may no longer be on the team.
Week 3–5: Fix and Register
Work through violations by type:
- Inline scripts: Extract JavaScript into external
.jsfiles, host in a trusted location, update references. Register the hosting URL as a Trusted Script Source. - Dynamic external loads (
SPComponentLoader): Register each external URL manually in SharePoint Admin Center under Trusted Script Sources. The 300-entry limit applies across your entire tenant, audit before adding everything. - Third-party tools: Contact vendors. Most major vendors have CSP-compliant versions of their SharePoint integrations available. This is a version upgrade, not a rebuild.
Week 6–7: Test in Enforce Mode
Once fixes are in place, use ?csp=enforce systematically across your critical pages to verify nothing is still breaking. Involve your end users or QA team, have them walk through their normal workflows on the pages they use most.
Week 8: Sign Off and Communicate
Before 1 June, communicate the change to relevant stakeholders. If any web part behaviour has changed as a result of refactoring (however minor), users should know what to expect. Frame it as a security improvement, because it is.
The Risk of Waiting Until Late May
The pattern we've seen with 1 March enforcement is that the teams who struggled were the ones who started late. Trusted Script Source changes can take up to 24 hours to propagate across a tenant. If you're making changes on 30 May and something doesn't propagate in time, you have no margin for error.
Eight weeks sounds like plenty of time. In practice, the audit usually surfaces more than expected, vendor responses take longer than expected, and internal sign-off processes take time. Start now.