If your team signs into Microsoft 365 all day, the sign-in page feels like “just a web page”. But it’s also one of the most targeted pages in your business.

Microsoft Entra ID is tightening the rules on what can run inside that sign-in page in mid-to-late October 2026. For most businesses, nothing changes. For a few, small “helpful” add-ons and customisations can suddenly stop working.

What’s changing in October 2026 (in plain English)

Microsoft Entra ID will start enforcing a stricter Content Security Policy (CSP) for browser-based sign-ins at login.microsoftonline.com in mid-to-late October 2026.

CSP is a browser security control. The simple idea is: the page is only allowed to run scripts from approved places. If something tries to inject extra code into the sign-in page, the browser blocks it.

Microsoft’s own guidance is blunt: if you use browser extensions or tools that inject code into the Entra sign-in page, you should expect those scripts to be blocked once enforcement rolls out.

A key detail for planning: this is about the browser-based sign-in experience at login.microsoftonline.com. Microsoft notes that MSAL and API authentication flows are not affected, and that Entra External ID customers using custom domains or CIAM domains for sign-in are not impacted.

Why Microsoft is doing this

Sign-in pages are high value targets. If an attacker can get code to run inside a sign-in page (even on one user’s machine), they can try to steal credentials or tokens, hijack sessions, or tamper with what the user sees.

CSP is a defence-in-depth move. Even when other protections exist, CSP gives the browser one more reason to say “no” to code that does not belong there. Microsoft explicitly calls out browser extensions and injected scripts as common sources of violations.

What can break for a small business

Most companies will never notice this change. The businesses that do notice it tend to have one of these in play.

  • Custom sign-in branding that relies on custom CSS tricks. Entra supports company branding, including custom CSS in some tenants, but Microsoft has already been restricting custom CSS availability for newer tenants and tightening what CSS properties are supported. If you have older branding that depends on layout hacks, treat October as a good moment to re-check it.
  • Injected scripts from third-party tools. Some monitoring, “digital adoption”, accessibility overlay, translation, or browser helper tools work by injecting JavaScript into pages. Microsoft specifically warns that non-Microsoft tools may inject scripts into sign-in pages, and those scripts will be blocked when CSP is enforced.
  • Legacy browser extensions. Not all extensions are equal. Password managers that do not inject scripts may be fine, while extensions that modify the page using injected code can trigger CSP violations. Microsoft’s testing notes in their Entra blog discussion also point out that the impact depends on whether the extension injects script or alters the DOM.
  • “We customised the login page years ago” assumptions. A common gotcha is that nobody remembers what was added and why. The sign-in page still loads, but a small workflow breaks, like auto-filling a field, a help widget, or a custom banner that was being injected by a tool.

One reassuring note: Microsoft says users will still be able to sign in normally even if injected scripts are blocked, but certain sign-in or monitoring workflows may be disrupted.

A practical test plan you can run this week

You do not need a lab. You need a repeatable checklist and a couple of test accounts.

1) Pick your “real world” sign-in scenarios

List the ways people in your business sign in, especially the ones that are different from a normal office laptop on a normal network.

  • Office user on a company PC. Your most common case.
  • Remote user on home internet. Often where extensions and “helper” tools show up.
  • VIP or finance user. If anyone has extra browser add-ons, it’s usually them.
  • Admin sign-in. Different portals, higher impact if it gets weird.

2) Test in a clean browser first

Your goal is to prove the Entra sign-in flow works when nothing is “helping”.

  • Use an InPrivate/Incognito window. This reduces extension impact.
  • Try a different browser. If you normally use Chrome, test Edge too (or vice versa).
  • Confirm the basics. Can you sign in, complete MFA, and reach Microsoft 365 apps?

If clean browser tests pass, you have a baseline. That’s your anchor when troubleshooting.

3) Test with your normal extensions turned on

Now you are looking for CSP-related breakage signals.

  • Open the browser developer console. Microsoft’s CSP prep guidance specifically recommends running a sign-in flow with the dev console open and looking for violations.
  • Look for red CSP violation messages. These often mention blocked scripts or blocked sources.
  • Repeat on the devices that matter. One person’s extension problem can look like “Microsoft is down” when it hits the CEO.

4) Make a short “extension inventory” for sign-ins

You are not trying to police every extension in the company. You are trying to identify the ones that touch sign-in.

  • List the extensions on the browsers used for work. Focus on the people who sign into Microsoft 365 daily.
  • Flag anything that modifies web pages. Toolbars, coupon tools, translation helpers, screen recorders, overlays, web clippers.
  • Ask vendors directly if they inject scripts into login.microsoftonline.com. Microsoft’s guidance is to work with vendors to implement fixes that comply with CSP.

A rollback playbook (so you can keep work moving)

You cannot “roll back” Microsoft’s CSP enforcement. What you can do is roll back the things in your environment that are likely to conflict with it.

Here is a simple playbook you can keep in your back pocket.

  • Step 1: Confirm it’s browser-based sign-in. CSP enforcement is scoped to browser sign-ins at login.microsoftonline.com. If a non-browser flow is failing, you may be chasing the wrong issue.
  • Step 2: Switch the user to a clean sign-in path. InPrivate/Incognito, or a different browser profile with extensions disabled. This gets the person working while you diagnose.
  • Step 3: Disable extensions in batches. Turn off half, retest, then narrow down. Once you find the culprit, keep it off for sign-in.
  • Step 4: Move “helpful” tools away from the sign-in page. If a tool must exist, configure it to not run on login.microsoftonline.com (many extensions support site allow and block lists).
  • Step 5: Re-check Entra branding settings. If you are using custom branding, validate it still behaves as expected, and avoid relying on brittle CSS positioning tricks that Microsoft is actively deprecating.
  • Step 6: Document what you changed. A one-page note that says “we disabled Extension X because it injects scripts into Entra sign-in” saves hours later.

The takeaway

This October 2026 change is mostly a non-event for small businesses, unless something is injecting code into your Microsoft sign-in page. The best time to find that out is before a Monday morning login rush.

If you would like help running a quick sign-in impact test and cleaning up any extensions or branding edge cases before the mid-to-late October 2026 rollout, the Flexnet Networks team can help you get it sorted.

Sources