Starting mid-October 2026, Microsoft will enforce a strict Content Security Policy on browser-based Entra ID sign-ins. Only scripts served from trusted Microsoft CDN domains will be allowed to run on the sign-in page. Anything injected by browser extensions or third-party tooling gets blocked. There is no tenant setting to turn this off, and there is nothing to approve. It is a service update, and it is on by default.
The rollout should finish by late October 2026. If you support users who sign in to Microsoft 365, you have a few weeks to find out whether anything in your environment depends on injecting scripts into the login page.
What is actually changing
Today, the Entra ID sign-in page at login.microsoftonline.com tolerates code that other things inject into it. After enforcement, the page carries a Content Security Policy that names only Microsoft's own CDN domains as trusted script sources. A CSP is just a browser-enforced allowlist: scripts from anywhere else simply do not execute, and the browser reports a violation instead.
Microsoft first signaled this change back in November 2025. The September 2026 Message Center update (MC1481309) is the final reminder before enforcement begins. Two scope notes matter:
- This applies only to browser-based sign-ins at
login.microsoftonline.com. Microsoft Authentication Library (MSAL) flows and API-based authentication are not affected. - Users will still be able to sign in even when an injected tool breaks. The change blocks the injected code, not the user.
What this breaks, and what it does not
The casualties are tools that reach into the sign-in page from the outside. In practice that means:
| Category | Examples | What happens after enforcement |
|---|---|---|
| Password manager overlays | Form-fill popups, autofill toolbars | Overlay scripts blocked; basic autofill via the browser's own credential manager still works |
| SSO and sign-in helper extensions | Customized login flows, branded overlays | Injected customizations stop rendering |
| Monitoring and analytics agents | Real-user monitoring beacons, session replay | Beacons on the sign-in page silently stop collecting |
| Helpdesk or onboarding toolbars | Guided-login walkthroughs, remote support overlays | Guides fail to appear on the login screen |
What does not break: the sign-in itself, conditional access evaluation, MFA prompts, and anything using MSAL or direct API authentication. If your scripts live server-side or in a properly registered application, this change does not touch them.
The sneaky part is that most of these breakages are silent. A blocked monitoring beacon does not throw a user-facing error. It just stops sending data, and you find out a month later when your dashboards have a gap you cannot explain. That is the failure mode to worry about, not a helpdesk ticket storm.
How to check before the deadline
Microsoft's own guidance is refreshingly practical: open a sign-in flow in the browser's developer console and watch for violations. Here is the plain version of that, in order:
- Sign in to a Microsoft 365 service in a browser profile that mirrors your standard build, with the usual extensions enabled.
- Open the developer console (F12) before submitting credentials.
- Work through the sign-in. Blocked scripts show up in the console as Content Security Policy violations, rendered in red text with the blocked script's URL.
- Note every blocked URL. If the domain is not a Microsoft CDN, that script stops working mid-October.
- Cross-reference those URLs against your extension inventory. Helpdesk and IT staff browsers deserve special attention, since they carry the most extensions.
- For anything that breaks, contact the vendor. Some have already shipped CSP-compatible versions; some need to be uninstalled.
If the console shows violations but you cannot tell which extension is responsible, test in a fresh browser profile and re-enable extensions one at a time until the violation reappears. It is slow, but it beats guessing. On managed fleets, your Edge extension policy in Intune is the definitive inventory: compare what is permitted there against what your users actually have installed, and you will usually find extensions nobody remembers approving.
If you manage endpoints with Intune or another MDM, this is also a good moment to audit your browser extension allowlists. Extensions you approved years ago may carry injection behavior nobody remembers authorizing. A quick review of which extensions are permitted in the managed profile usually turns up one or two surprises.
The durable idea underneath
This is part of Microsoft's Secure Future Initiative, the engineering overhaul that followed the 2023 breach of Exchange Online mailboxes. The pattern across that initiative is consistent: shrink the attack surface of the sign-in surface, and do it whether or not customers are ready. Script injection on a login page is an attacker's classic move for credential theft, so a CSP on the authentication page is an overdue control.
The lesson that generalizes: anything that depends on an unofficial hook into someone else's page is living on borrowed time. That has always been true of screen-scraping, and it is true of script injection too. Microsoft gave nearly a year of notice here, which is generous by their standards. When a platform tells you it is locking the door, believe it the first time.
Boring integrations survive. Supported APIs survive. Injected scripts do not.
Sources
- Microsoft to block Entra ID script injection attacks starting October — BleepingComputer, September 2026 (citing Message Center MC1481309)
- Message Center update MC1481309 — Microsoft admin portal guidance on the CSP enforcement timeline
- Secure Future Initiative — Microsoft, on the engineering program behind the sign-in hardening (launched after the May–June 2023 Exchange Online mailbox breaches)
