Looking across the common failure patterns, there's a single theme: legacy script patterns that nobody had revisited in years. The solutions that broke were rarely recently built, they were older integrations, older web parts, scripts embedded when SharePoint was configured years ago and then forgotten.

CSP enforcement didn't create new problems; it surfaced old ones. That's actually the point. The report-only window from late 2025 through 28 February was designed exactly for this: a chance to audit before enforcement hit. Teams that used that window had nothing to worry about on 1 March. Teams that didn't are doing triage now.

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.

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.

If your SharePoint environment includes solutions from third-party vendors, analytics tools, chatbots, form builders, or similar, those vendors may need to update their products to be CSP-compliant. Reach out to them with the specific violation URLs from your Purview audit and ask for a compliance timeline.

In the meantime, you can temporarily register their script sources as trusted, but the long-term fix needs to come from their end if their solutions use inline scripting patterns.

Let's talk about what's actually happening in most organisations.

Your team opens Outlook. They jump into a Teams meeting. Maybe someone opens a Word doc or an Excel spreadsheet. And that's... pretty much it.

But your Microsoft 365 licence — whether it's Business Standard, E3, or E5 — includes a lot more than email, meetings, and documents. We're talking SharePoint for document management and intranets, OneDrive for personal cloud storage (up to 1TB per user), Power Automate for workflow automation, Microsoft Forms for surveys and data collection, Planner and To Do for task management, Lists for structured data tracking — and depending on your plan, even more.

Most of these tools are sitting there, fully licenced, fully available, and completely untouched.

Here's where it gets frustrating. Organisations will pay for a Microsoft 365 E3 licence and then also pay separately for Dropbox, Trello, SurveyMonkey, or Zoom — tools that do what their existing licence already covers.

Not because Microsoft 365 can't do it. But because nobody on the team knows it can.

Think about that for a second. You're essentially paying twice for the same capability — once through your M365 licence and again through a third-party subscription — just because your people haven't been shown what's already available.

And it's not their fault. Nobody sat them down and said, "Hey, you know that thing you're using Dropbox for? OneDrive does that. And it's already included in what we're paying for." Or, "That approval process you're running over email? Power Automate can handle that automatically."

Let me give you a few examples of what most teams are missing, even on a standard Business Standard or E3 licence:

It's not about becoming a power user overnight. It's about making sure your people understand the basics properly and then building from there.

It starts with the fundamentals: knowing where to save files (OneDrive for personal, SharePoint for team), understanding how Teams, SharePoint, and OneDrive work together, and being able to share files with a link instead of an attachment.

Then you layer on productivity skills: co-authoring documents in real time, using Planner for project tracking, setting up basic automations, organising SharePoint sites so people can actually find things.

And for the people who want to go further — your site owners, your digital champions, your IT-adjacent team members — there's governance, security settings, and advanced automation with Power Automate and eventually Copilot.

The point is, it's a journey. Not a single event.

Before you do anything else, run a quick mental audit. Ask yourself:

Are we paying for any third-party tools that duplicate what Microsoft 365 already offers? When was the last time our team received structured M365 training? Can our people confidently explain the difference between OneDrive and SharePoint? Does anyone on the team know how to set up a basic Power Automate flow? Are we using SharePoint for document management, or is it just a dumping ground?

If most of those answers make you uncomfortable, that's your sign.

Content Security Policy is a browser-level security standard that controls which scripts a page is allowed to load and execute. It's one of the most effective defenses against cross-site scripting (XSS), clickjacking, and code injection attacks.

Until now, SharePoint Online has been running CSP in report-only mode — logging violations without actually blocking anything. That changes on 1 March when enforcement goes live. After that date, any script that doesn't comply with the CSP rules will be blocked by the browser, potentially breaking custom web parts, third-party tools, and SPFx solutions.

Step 1: Check the Browser Console

Open any SharePoint page that uses custom solutions, press F12 to open Dev Tools, and look for CSP violation messages in the Console tab. You'll see entries like:

• "Loading the script '<url>' violates the following..."
• "Executing inline script violates the following Content Security Policy directive..."

Step 2: Use Microsoft Purview

For a tenant-wide view, go to Microsoft Purview (purview.microsoft.com) and create an audit report filtering for the activity "Violated Content Security Policy." This gives you a comprehensive list of every page and script generating violations across your environment.

Step 3: Review the Directives

Pay attention to both Directive 12 (script-src) and Directive 13 (style-src) violations. Both are relevant — Directive 13 applies to inline code constructs that will also be blocked under enforcement.

Add Trusted Script Sources

Go to SharePoint Admin Center → Advanced → Script sources and add any external domains your solutions depend on. A few things to note:

• You can add up to 300 entries.
• Overly broad wildcards like*or*.domainare not allowed.
• Use targeted wildcards to consolidate where possible.
• If a script loads from a CDN, you need to trust that specific CDN domain.

Refactor Inline Scripts

This is the big one. Any JavaScript embedded directly in HTML, event handlers, or injected viainnerHTMLordocument.write() must be moved into external.jsfiles hosted at a trusted location. There's no shortcut here —unsafe-inlineis not permitted, and Microsoft will not provide nonce values.

Validate Auto-Trusted Sources

If you usecdnBasePathwithout a trailing slash, the auto-generated Trusted Script Sources entry may not match correctly. Double-check these entries manually after deploying your solutions.

This pushes enforcement to June 1, 2026. It's a one-time delay — use it wisely and don't treat it as a permanent fix.

Once enforcement begins, end users may see broken functionality or warning messages on pages that rely on non-compliant scripts. Get ahead of this with proactive communication:

• Explain that this is a security improvement, not a system failure.
• Provide a clear path for users to report issues.
• Coordinate with any third-party vendors whose solutions run in your SharePoint environment.