Entra ID Sign-In CSP Enforcement Starts October 2026: Test Browser Extensions Now

Most organizations won't notice anything. If a browser extension, monitoring agent or customization tool adds code to the Microsoft sign-in page, though, it's about to stop doing that.

The timeline: mid-October start, late-October finish​

The message center post is MC1481309. It says the worldwide rollout will be beginning in mid-October 2026 and expected to complete by late October 2026. A third-party archive of the post, published by PupuWeb, lists the dates as Release Start: 15 Oct 2026 Release End: 31 Oct 2026. It also rates the change Admin Impact: High User Impact: Low. Put simply, users get a quiet change and admins get the homework.

This isn't a surprise announcement. MC1481309 describes itself as a reminder of our previous announcement (MC1191924), which communicated this upcoming security change and the actions organizations may need to take before rollout. In November 2025, Microsoft's Entra blog said it will enforce CSP globally starting mid-to-late October 2026, and promised periodic communications will be sent prior to release. BleepingComputer covered that first announcement in November 2025 as well.

One caveat: Microsoft's documentation page still gives the start as a window, saying CSP enforcement will start globally in mid-to-late October 2026. The "complete by late October" wording comes from the message center, and it describes an expected finish. It isn't a contractual deadline. Staged rollouts tend to reach tenants at different times, so don't assume you have until October 31.

Section summary: Enforcement starts around October 15, 2026, and Microsoft expects it to be finished by the end of the month. The change has been public for about ten months, so "we didn't know" won't be a strong defence.

What CSP actually does here​

Content Security Policy is an old and reliable browser mechanism. The server sends a header listing where a page may load resources from, and the browser refuses anything outside that list. Microsoft's documentation describes CSP as a browser security header that allows only trusted scripts and resources to load.

The Entra blog says there are two specific changes on login.microsoftonline.com:

• Only allow script downloads from Microsoft trusted CDN domains.
• Only allow inline script execution from Microsoft trusted source.

The inline rule does most of the work. Many injection attacks and "helpful" extensions don't load an outside file. They insert script straight into the page. According to 4sysops, scripts from Microsoft's trusted Content Delivery Network domains and inline scripts with valid Microsoft nonces will execute normally. All other scripts will trigger CSP violations and be blocked, though users will still complete authentication successfully. A nonce is a random, single-use token that the server attaches to each script it approves. An injected script has no way of guessing it.

Microsoft is careful to call this defence in depth, not a cure-all. Entra and modern browsers already try to keep malicious scripts off the page. The documentation says CSP is there for the cases that get past those defences, such as a user-installed malicious browser extension or a zero-day vulnerability, and that it prevents such a script from executing. It works like a bouncer checking IDs at the door, backed by a second bouncer inside who throws out anyone who got in through a window.

Section summary: The new header allows Microsoft CDN scripts and nonce-tagged inline scripts, and blocks everything else. It's a backstop for existing protections, not a replacement.

Why sign-in pages are worth protecting​

Sign-in pages attract attackers because they handle passwords, MFA prompts and session tokens. Microsoft's documentation says script injection can lead to data theft: attackers can steal sensitive information such as credentials or tokens and to session hijacking. Token theft matters in particular because a stolen session token can get past MFA the user has already completed. That's why browser-side attacks on identity providers keep showing up in incident reports.

Microsoft has put the change under its broader security programme. MC1481309 says that as part of Microsoft's Secure Future Initiative, we are strengthening the security of the Microsoft Entra ID sign-in experience by introducing additional Content Security Policy (CSP) protections. BleepingComputer notes that SFI was announced after Chinese hackers breached the Exchange Online mailboxes of dozens of organizations and hundreds of individuals worldwide in May and June 2023. The same outlet lists other SFI-era hardening moves, including disabling ActiveX controls in Microsoft 365 and Office 2024 apps on Windows and blocking legacy authentication in Microsoft 365 security defaults. Those are separate changes with their own rollouts. They show the direction Microsoft is heading, but they aren't part of this CSP update.

Who is affected, and who isn't​

The scope matters, and it's easy to overstate. Here's what the evidence supports:

Microsoft's documentation says Applies only to browser-based sign-in at login.microsoftonline.com. Microsoft Entra External ID customers using custom domains and MSAL/API flows are not affected. The message center adds that MSAL and API-based authentication flows are not affected because CSP enforcement applies only to browser-based sign-in experiences using login.microsoftonline.com.

That's good news for developers. Desktop apps, mobile apps and daemons that authenticate through MSAL or call the token service directly shouldn't need changes.

Admins of sovereign clouds should also take note. The Azure China version of the documentation carries the same October timing but names a different host. It says the change applies only to browser-based sign-in at login.partner.microsoftonline.cn. If you run a 21Vianet tenant, test against that endpoint.

What might break​

The organizations most exposed, according to MC1481309, are those using browser extensions, monitoring tools, customization tools, or other solutions that inject scripts into the sign-in experience. The post warns plainly that browser extensions and tools that inject scripts into Microsoft Entra ID sign-in pages may stop functioning.

This is based on data, not guesswork. Microsoft's documentation says its analysis found that most violations come from external browser extensions or injected scripts tied to third-party tools. In practice, look closely at:

• Password managers or autofill tools that inject code, not just fill fields
• Security or DLP browser agents that watch sign-in pages
• Session-recording, analytics or user-experience monitoring tools
• In-house customization scripts pushed through extensions or proxies

The important reassurance, quoted by BleepingComputer: Users will continue to be able to sign in even if unsupported script injection tools no longer function. This change is enabled by default as part of the service update and does not require tenant configuration. Microsoft's documentation does acknowledge that this may disrupt certain sign-in or monitoring workflows. Nobody gets locked out, but a monitoring tool that silently stops collecting data is a real risk, especially if compliance reporting depends on it.

There's no opt-out switch. Microsoft's documentation doesn't describe any tenant setting for exempting injected scripts. The only fix is to replace the tool or get the vendor to make it CSP-compliant.

How to check your tenant before enforcement​

Microsoft's preparation guidance is short. Here it is as a checklist:

1. Inventory injecting tools. List the browser extensions and agents deployed to managed browsers, whether through Intune, Group Policy or other means, and flag anything that interacts with Microsoft sign-in pages.
2. Run a sign-in with developer tools open. Microsoft's Step 1 is to go through a sign-in flow with the dev console open to spot violations. In Edge and Chrome the console usually opens with F12.
3. Read the red text. Microsoft's Step 2 is to review the violation details shown in red, which name the blocked script. According to BleepingComputer, IT administrators can identify potential impact by reviewing sign-in flows in the browser developer console: violations will appear in red text with details about the blocked scripts.
4. Test more than one persona. Microsoft warns that a violation caused by a specific team or person appears only in their flows. Your own clean console proves nothing about the finance team's extension collection. Test across departments, device builds and browser profiles.
5. Engage vendors now. Microsoft advises that if you use tools or browser extensions that inject code into the Microsoft Entra sign-in page, switch to alternative tools that don't inject code before this change is released.
6. If you find nothing, you're done. MC1481309 says if your organization does not use tools or extensions that inject code into Microsoft Entra ID sign-in pages, no action is required.

The bigger picture​

A few forum threads will grumble that Microsoft is breaking third-party tools again. That's partly fair. Vendors whose products rely on inserting code into someone else's login page have had almost a year's warning, and some may still miss it.

The counterargument is stronger, though. Any mechanism that lets a "legitimate" extension run code on your identity provider's sign-in page is also available to a malicious one. From the browser's point of view, the two look exactly the same. CSP removes that shared route, and the documented scope avoids disturbing MSAL, APIs and External ID custom domains.

What's left is a manageable job for admins: open the console, read the red text, and have a word with your vendors before October 15.