A Security Fix You Don't Have to Install

Later this month Microsoft starts refusing to run anything but its own code on the page where you type your work password. It's on by default, there's nothing to buy, and sign-in keeps working. One five-minute check tells you whether it affects you.

Sometime in the second half of October, Microsoft will change the page where your staff type their work password, and almost nobody will notice. That's the point of it. Entra ID — the part of Microsoft 365 that handles signing in — will start refusing to run any code on that page that didn't come from Microsoft. It's switched on for every tenant, by default. There is nothing to configure, nothing to buy, and no admin to brief. Our interest, up front: we deploy and support Microsoft 365 for our clients, so this is our own house rather than somebody else's. The technical part — you can skip this box Microsoft is enforcing a Content Security Policy on Microsoft Entra ID browser sign-in pages, per Microsoft's own identity-platform documentation. Rollout begins mid-October 2026 and completes by late October 2026. Scope is browser-based sign-in at login.microsoftonline.com. It is enabled by default for all tenants; no configuration is required, and none is offered. The policy permits script execution only from Microsoft-controlled content delivery network domains, blocking external and injected scripts as a defence-in-depth measure against cross-site scripting. Explicitly not affected: flows using the Microsoft Authentication Library (MSAL), API-based authentication, Microsoft Entra External ID with custom domains, and customer identity (CIAM) domains. Microsoft's stated preparation steps are to walk the sign-in flows with the browser developer console open and look for Content Security Policy violation errors, remove or replace browser extensions and tools that inject code into the sign-in page, and test sign-in scenarios across the organisation before the rollout. Microsoft states that user sign-in itself continues to succeed; what is blocked is the injected script. What that actually means A "Content Security Policy" is a short list a web page hands your browser saying which code it's allowed to run. Anything not on the list gets refused. Microsoft is putting one on the login page and leaving only its own code on it. Why the login page specifically. The password box is the most valuable rectangle on the internet. Anything that can run code on that page can read what gets typed into it. Closing that off is worth doing even if nobody has done it to you. "Cross-site scripting" is getting your own code to run on somebody else's page. That's the thing being shut out. The good news, and it is most of this You are getting a meaningful protection for free, applied automatically, including on the tenants of every business that never reads a Microsoft announcement — which is nearly all of them. That's the right shape for security to arrive in, and it's rare enough to say so. What could break, and it's a short list Browser extensions. Specifically the ones that reach into the sign-in page and add something to it: older password managers, single sign-on helpers, session recorders, some accessibility and monitoring tools. Microsoft is explicit that signing in still works — what stops is the injected part. What to do, and it's about five minutes Open your Microsoft sign-in page in the browser your people actually use, with the extensions they actually have. Not a clean test profile. The extensions are the entire question. Press F12, click the Console tab, and sign in. Watch for red errors mentioning Content Security Policy. Nothing red? You're done, and you were always done. That's the likely outcome for most small businesses. Something red? You have until mid-October to work out which extension is responsible and whether you still need it. That's a calm afternoon now instead of a confused help desk call later. If we manage your machines, send us the error rather than removing anything yourself.