According to Microsoft's documentation, Content Security Policy (CSP) enforcement for browser-based sign-in starts globally in mid-to-late October 2026. That is, about now.
What Is Changing
Entra will add a Content Security Policy header to its browser sign-in pages. CSP tells the browser which script sources a page may trust. In Microsoft's implementation, only scripts from trusted Microsoft origins, identified by nonces and allowed domains, will run during authentication, and everything else is blocked by default. Microsoft's documentation frames it as defence in depth. Browsers and Entra already try to stop injection at the source. CSP covers the case where a script gets in anyway, for example through a malicious browser extension or a zero-day.
The Message Center notice (MC1191924) puts the rollout start in mid-October 2026, with completion expected in late October. The scope is narrow:
- Affected: browser sign-in at login.microsoftonline.com.
- Not affected: MSAL and API-based authentication flows, Entra External ID using custom or CIAM domains, and other domains or non-browser authentication.
Microsoft says most of the violations it has analysed come from external browser extensions and scripts injected by third-party tools. Users can still sign in. What stops working is the tool that depended on injected code.
Why the Sign-In Page Is the Right Place to Start
Everything that matters in a login flow passes through that one page: the password, the MFA response, and the session the user ends up with. A script running in that context sees what the user sees. Microsoft's own list of what script injection leads to is short and uncomfortable: stolen credentials or tokens, hijacked sessions, malware delivery, and loss of trust in the sign-in page itself.
Notice what CSP does not depend on. It does not need Entra to have a bug. It assumes code may already be running somewhere it should not be, and limits what that code can do on the one page where the damage would be greatest. That is a sensible posture for an identity provider, and it fits the way the browser has become part of the identity perimeter.
The awkward part is the failure mode. Because users can still sign in, the first sign of trouble will not be a login outage. It will be a service desk ticket saying a tool has "stopped working", or a monitoring workflow that has gone quiet. Those are easy to misdiagnose as a fault in the tool itself.
How to Check Your Tenant This Week
1. Inventory what injects code
Pull the managed extension list from your browser management tooling, and ask the teams that run monitoring or sign-in helper tools whether anything touches the Entra sign-in page. Microsoft's own recommendation is not to use tools that inject code into it.
2. Reproduce with the console open
Run through a sign-in with the browser developer console open and read the CSP violation details shown in red. That tells you what was blocked and gives you something concrete to take to a vendor.
3. Test across people, not just one browser
A violation appears only in the flows of whoever has the offending tool, so a clean run on your own machine proves very little. Cover different teams, roles, browsers and profiles.
4. Talk to the vendors
Microsoft's advice for tools that rely on injected scripts is to work with the vendor on a CSP-compliant fix, or move to an alternative that does not inject code. With the rollout landing this month, that conversation should start now.
5. Brief the service desk
Give them the symptom to listen for: sign-in works, a tool does not. MSAL and API flows are unaffected, so application authentication errors are unlikely to trace back to this change, which helps when tickets start arriving.
Where This Is Heading
Identity providers are hardening the one surface attackers most want to run code on. Session and token theft are a recurring theme in identity attacks, and the browser is where credentials and tokens meet. A vendor-side control like CSP also takes a decision away from customers: any tool that wanted to sit inside the login page now has to find somewhere else to stand.
It is worth turning that lens on your own estate. If you run sign-in pages for customers, partners or staff, list every third-party script on them and ask what each one could see. A script you cannot explain carries the same risk as an extension on Microsoft's page, and an equivalent policy on your own pages deserves serious consideration.
The Trevonix Perspective
At Trevonix, we see this as a good example of identity security hardening in layers. The strength of the authentication method is only part of the picture. The integrity of the page where authentication happens matters just as much. For organisations running workforce access and authentication on Entra, the immediate work is small and practical: find what injects, test, talk to vendors. For those running customer and partner identity, the same question applies to every third-party script on the sign-in journey.
Key Takeaways
- Microsoft starts enforcing Content Security Policy on Entra browser sign-in in mid-to-late October 2026, with completion expected in late October.
- It applies to login.microsoftonline.com. MSAL and API flows, and External ID on custom domains, are not affected.
- Scripts injected by extensions and third-party tools will be blocked. Users can still sign in, so the failure is quiet.
- Test with the developer console across teams and browsers, and start vendor conversations now.
- Apply the same scrutiny to third-party scripts on your own sign-in pages.
Source Credits: Microsoft Learn: Content Security Policy overview for Microsoft Entra ID, Microsoft 365 Message Center (MC1191924)
