Microsoft Entra ID to enforce CSP, blocking sign-in script injection

Microsoft will begin enforcing a Content Security Policy (CSP) on Entra ID browser sign-ins starting mid-October 2026, restricting scripts to trusted Microsoft CDN domains and blocking externally-injected code on the login page. It's a preventive hardening measure — no CVE — aimed at the class of credential-theft that rides malicious scripts injected into the authentication experience.

The primary reference is Microsoft's Content Security Policy rollout documentation and message-center notice MC1481309. Microsoft first flagged the change in November 2025; the enforcement window is now.

What's changing

On sign-in pages served from login.microsoftonline.com, Entra ID will:

• Permit scripts only from trusted Microsoft CDN domains.
• Restrict inline script execution to Microsoft-authorized sources.

The stated goal is to block external script injection and reduce exposure to cross-site scripting (XSS) against the sign-in flow. Rollout runs mid-to-late October 2026.

Who's affected

• Affected: browser-based interactive sign-in at login.microsoftonline.com. Browser extensions and tools that inject scripts into the sign-in page may stop working once CSP is enforced.
• Not affected: MSAL and API-based authentication flows, and Entra External ID customers using custom domains.

The practical breakage risk is on the client side — password managers with aggressive injection, accessibility overlays, session-recording or SSO-helper extensions, and any home-grown tooling that manipulates the Microsoft login DOM.

Action checklist

1. Test interactive sign-in now, before mid-October. Run your standard browsers and managed extension baseline against login.microsoftonline.com.
2. Watch the browser developer console for CSP violations — they appear in red — and note which extension or script triggers each one.
3. Inventory and retire code-injection dependencies on the sign-in page. Microsoft's guidance is explicit: don't use extensions or tools that inject code into the Entra sign-in experience.
4. Confirm password managers autofill via supported mechanisms, not DOM injection, so credential entry keeps working after enforcement.
5. Brief your help desk — post-rollout sign-in oddities are likely to trace back to a blocked extension, not an outage.

Context

CSP on a first-party identity provider's login page is overdue rather than novel — it closes a real gap, since anything that can run script on the authentication page can, in principle, read what a user types there. The catch is operational: enforcement predictably breaks well-intentioned tooling that has quietly depended on injecting into Microsoft's login DOM for years. Organizations that test ahead of the window will absorb this as a non-event; those that don't will spend mid-October triaging sign-in tickets. This is preventive, not a response to active exploitation — but it changes behavior for every Entra tenant, which is why it belongs on the October change calendar.