Enforcement window: Mid to late October 2026 (Source: Microsoft message center update, reported by BleepingComputer (September 30, 2026))
Attackers who inject code into a sign-in page do so to steal credentials. Microsoft is now adding a stricter rule about which code may run on its own sign-in page.
The lesson here is about dependencies. A rule that lists allowed sources cannot tell a helpful tool from a hostile one. It checks only where the code came from. That is an inference from Microsoft's wording, not a finding in the report.
What Microsoft is changing
Microsoft is adding Content Security Policy (CSP) defenses to Entra ID sign-ins, starting mid-October 2026. A CSP is a set of rules a website sends to the browser about what the page may load. BleepingComputer reported on a Monday message center update. Microsoft first announced the plan in November 2025.
During sign-in, the browser will accept scripts only from Microsoft's trusted content delivery network (CDN) domains. A CDN is a network of servers that hands out a site's files. Microsoft describes the target as "unauthorized or externally injected code." The rollout should finish by late October 2026.
How an allow-list stops injected code
A web page normally runs the scripts it is told to load. Extensions and other tools can also push scripts into a page from outside the site's own files. Without a rule, the browser has no basis to refuse them.
A script allow-list changes that. The site names the sources it trusts. The browser checks scripts against that list. Microsoft says the rule blocks unauthorized or externally injected code.
Microsoft names cross-site scripting (XSS) as one threat. In XSS, an attacker plants malicious code in a website to steal credentials. The rule is meant to keep such code from running during sign-in.
The scope is narrow. It covers only browser sign-ins at login.microsoftonline.com. Apps using the Microsoft Authentication Library (MSAL) and API-based sign-in flows are not affected.
Why enterprise tooling is the question
Before the change lands, Microsoft wants enterprises to stop relying on any browser extension or tool that pushes code or scripts into sign-in pages. It also asks them to test sign-in scenarios first, to find dependencies.
Microsoft describes such tools as unsupported. It says users can still sign in if they stop working. The tool is what fails, not the login.
The report names no products. It describes only a category. The examples below are ours, not the report's. They are the kinds of tool worth checking for code injection: password managers, single sign-on helpers, and tools that restyle the login page. Monitoring add-ons belong on the same list.
The change is on by default, and Microsoft says no tenant configuration is needed. A team that does nothing may find out only when a tool stops working.
Part of a longer programme
BleepingComputer says the change belongs to Microsoft's Secure Future Initiative. Microsoft announced that programme after a 2023 breach. Chinese hackers had entered the Exchange Online mailboxes of dozens of organisations and hundreds of individuals. The intrusions happened in May and June 2023.
Two other changes fall under the same programme. ActiveX is disabled in the Windows editions of Microsoft 365 and Office 2024 apps. Microsoft 365's default settings now refuse older sign-in protocols when someone tries to reach files in Office, SharePoint or OneDrive.
These are separate changes. The report does not tie this CSP rule to any specific attack.
What to ask your team this week
Microsoft points administrators to the browser developer console. Blocked scripts appear there as violations in red text, with details of what was stopped.
Put four questions to your identity and desktop teams before the deadline:
1. Which browser extensions or tools do we deploy to staff that change sign-in pages?
2. Has anyone tested the main sign-in scenarios and checked the console for red violations?
3. Does any business process depend on a tool that alters the sign-in page? What is the fallback if it stops working?
4. Do our apps sign in through MSAL or APIs, which Microsoft says are unaffected, or through browser flows, which are covered?
An allow-list asks where a script came from, not whether you meant to install it. Know what your staff have added before the browser starts asking.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: BleepingComputer.
