Starting mid-to-late October 2026, Microsoft is rolling out a stricter Content Security Policy on Entra ID's browser-based sign-in pages at login.microsoftonline.com. The policy will only allow scripts from Microsoft-trusted CDN domains and inline scripts from Microsoft-approved sources, with the explicit goal of blocking script injection and cross-site scripting attacks during authentication.
It's a useful case study because it's not a theoretical best practice from a conference talk, it's one of the world's largest identity providers deciding that its login page, arguably the single highest-value target on the entire platform, needs CSP enforcement strong enough to lock out even its own customers' browser extensions and custom scripts if they don't comply.
What's actually changing
Microsoft is narrowing the set of script sources the sign-in page will execute. Anything outside that allowlist, whether it's a browser extension injecting code, a third-party integration modifying the page, or a custom script added via a proxy, will be blocked once enforcement is live. This is squarely aimed at script injection and XSS attacks that try to intercept credentials or tokens at the point of sign-in, historically one of the most valuable places for an attacker to sit.
Importantly, this only affects browser-based sign-ins. API-based authentication and MSAL flows are unaffected, so the change is closing off a browser-rendered attack surface rather than touching the authentication protocol itself.
Why organisations need to act before it lands
Microsoft is telling admins to prepare now, not wait for enforcement day:
- Audit any tools, browser extensions, or custom integrations that interact with Entra ID sign-in pages
- Use browser developer tools to check for CSP violations before enforcement goes live
- Reconfigure or replace anything that injects scripts into the authentication flow
- Tell internal teams and third-party vendors the change is coming
That list is a good proxy for the audit most organisations should be running on their own login and checkout pages, just prompted here by a hard deadline instead of good intentions. It also exposes the two hardest parts of doing CSP properly: finding out what your page actually loads before you lock it down, and then justifying why each source is on the allowlist once someone asks.
Where most teams get stuck
Two things trip people up every time they try to do what Microsoft is now doing at scale.
The first is visibility. You can't write an accurate script-src or frame-ancestors directive if you don't know what's actually trying to load on your page, and browser dev tools only show you what happens on the machine in front of you, not what's happening across your real traffic. This is exactly what a CSP reporting endpoint is for: put your policy in report-only mode, point report-to (or the older report-uri) at a collection endpoint, and let real visitors' browsers tell you what's actually trying to execute before you commit to blocking it. Header Centaurs' reporting endpoint does this without you needing to stand up and maintain your own ingestion service, so the audit Microsoft is asking admins to do by hand becomes something you can run against production traffic for a few weeks and see the actual picture.
The second is the "why is this directive here" problem. Six months after someone writes a CSP, nobody remembers why a given domain is allowlisted, whether it's still needed, or whether it's safe to tighten. This is where Header Centaurs' new CSP builder matters: it doesn't just generate directives, it keeps a decision record alongside the policy, so every source has a documented reason for being there. That's the difference between a policy you're afraid to touch and one you can actually maintain, tighten, or hand off to someone else months later without archaeology.
The takeaway
The practical next step isn't just reading about CSP, it's putting a reporting endpoint in front of your own login and checkout pages in report-only mode, seeing what's actually loading, and building the resulting policy with a documented rationale rather than guesswork.