Entra ID will refuse injected scripts from mid-October, and Microsoft names one impact test: a browser console

307 days of notice, then 17 days

Microsoft first told customers on 25 November 2025 that Entra ID sign-in would stop running scripts that do not come from Microsoft. Its reminder, message centre post MC1481309, followed on 28 September 2026, 307 days later (derived: 25 November 2025 to 28 September 2026). A copy of the reminder's record lists a release start of 15 October 2026, 17 days after the reminder and 14 days after this briefing, and the reminder itself carries an act-by date of 19 October, 21 days after it.

Microsoft's own words for the start are "mid-October". The 15 October figure is metadata in a copy of the message centre record, and the dates section says how far to trust it. Everything here is as read on 1 October 2026, UK time.

What that does not establish. It does not establish that any tenant will break. Microsoft says sign-in itself keeps working: "Users will continue to be able to sign in even if unsupported script injection tools no longer function." It gives no count of tenants, users or tools affected. It also does not establish that sign-in theft gets harder in general. The policy governs scripts on one Microsoft-hosted page, and several routes to a stolen sign-in never pass through that page's script policy.

BleepingComputer's headline calls this a block on "script injection attacks". Microsoft's text is plainer and wider: only trusted Microsoft-hosted scripts run, and "unauthorized or externally injected code" is blocked. A script your own monitoring vendor injected for a good reason is blocked exactly as one an attacker injected.

The dates, and the one Microsoft page that disagrees

Microsoft's pages agree on October 2026 and differ in small ways. The table sets out what each published and when.

Microsoft's publications on the Entra script policy, with the date shown on each page. Message centre posts were read through a public archive.

Date	What it says	Where
25 Nov 2025	Enforcement "globally starting mid-to-late October 2026". Periodic communications "prior to release".	Microsoft Entra blog
26 Nov 2025	First press report, repeating the blog post.	BleepingComputer
3 Dec 2025	MC1191924: rollout begins mid-October 2026, expected completion late October. "Production/Worldwide only".	Message centre
10 Dec 2025	Monthly digest says Entra ID "rolled out" a stricter policy "In November 2025", in the past tense.	Microsoft Entra blog, What's new
28 Sep 2026	MC1481309, a reminder: general availability worldwide from mid-October, complete by late October. Act by 19 October.	Message centre
30 Sep 2026	Reports the reminder, citing a Monday message centre update.	BleepingComputer

The one page that disagrees is the December 2025 digest, which says the policy "rolled out" in November 2025. The blog post of 25 November, the Learn page and both message centre posts say enforcement starts in October 2026, and on 1 October we saw only a report-only header on the live page (next section). We follow those. Microsoft does not explain the digest's past tense, and it is the only Microsoft page that puts the change in the past.

The wording of the start also varies. The Learn page, last updated 25 November 2025, says enforcement will "start globally in mid-to-late October 2026". The reminder says rollout begins "mid-October" and is "expected to complete by late October". A copy of the record on PupuWeb lists a release start of 15 October and a release end of 31 October, with admin impact High and user impact Low. We use 15 and 31 October only as labelled, secondary dates.

Arithmetic, derived. 25 November 2025 to 15 October 2026 is 324 days, 46 weeks and 2 days of notice. By the reminder, 307 of those 324 days had gone, about 95 per cent of the notice, and 17 remained. As of 1 October, 310 days have passed since the blog post, and 15 October is 14 days away, 19 October is 18 days and 31 October is 30 days. Microsoft says the rollout is global and runs from mid-October to late October, about two weeks if the listed dates are right. It does not say whether the order is by region, ring or tenant, or how a tenant learns its day.

What is blocked, and what the live page serves today

Microsoft is adding a Content-Security-Policy header to the sign-in pages on login.microsoftonline.com. The blog post names two changes: script downloads only from "Microsoft trusted CDN domains", and inline script only from a "Microsoft trusted source". A content security policy is a header the server sends with a page to tell the browser which scripts it may run. The inline rule works through a nonce, a random value the server generates for each response and attaches to the scripts it approves, which an injected script cannot guess (MDN).

Scope, from the Learn page and the reminder: browser sign-in at login.microsoftonline.com only. MSAL and API flows, other domains and non-browser flows are not affected. The change "is enabled by default as part of the service update and does not require tenant configuration".

Microsoft frames it as defence in depth. Entra and browsers already try to keep injected scripts out, and the policy is there for the case where one gets in anyway, for example through a user-installed malicious browser extension or a zero-day. It adds: "Our analysis shows most violations come from external browser extensions or injected scripts linked to third-party tools." No count, period or method accompanies that sentence.

Three things follow, each labelled for what it is. First, a report-only policy blocks nothing and sends violations to its report address (MDN), so at that hour nothing was being refused by header. Second, no Microsoft page we read mentions a report-only phase. The header means browsers loading the page can report violations to a Microsoft address. That this is where "our analysis" came from is our inference, and Microsoft does not say.

Third, the keywords matter and the outside reader cannot see the enforced policy. MDN says unsafe-inline is ignored by browsers when a nonce is present, that unsafe-eval still works alongside a nonce, and that allowlist policies are hard to get right and "often" allow unsafe domains by accident. We make no claim about any of the 13 hosts. The point is narrower: Microsoft has not published its list of trusted CDN domains or the policy it will enforce, so nobody outside Microsoft can assess how strong the protection is.

What will break, and what Microsoft does not name

The failure is silent by design. Sign-in completes and the tool that injected script does not. The Learn page says: "Users will still be able to sign in normally, but this may disrupt certain sign-in or monitoring workflows." For a service desk that is the awkward shape of change: no failed logins, no outage, and a ticket days later saying a helper stopped working.

What breaks, in Microsoft's words, is "browser extensions, monitoring tools, customization tools, or other solutions that inject scripts into the sign-in experience". That is the whole list. Microsoft names no product, no vendor and no category of extension. Secondary write-ups name password managers, analytics products and accessibility tools. None of those appears in the blog post, the Learn page or either message centre post, so treat them as guesses until a vendor confirms.

Which extensions are hit depends on how they work, and Microsoft does not say. Chrome's documentation says a content script runs in an isolated world by default, under the extension's own policy, and that "When a content script is injected into the main world, the CSP of the page applies." Our reading, untested: an extension that places script in the page's own context is blocked by this header, and one that stays in its isolated world is not governed by it. Only a test per tool settles that. We checked Chrome's documentation only.

Company branding is a separate matter. Microsoft's branding page lists a background, logos, text, layout and an uploaded CSS file, and no script option, so a script in company branding is not a documented feature. Microsoft is also retiring the CSS option: tenants created after 5 January 2026 do not have custom CSS, tenants created before 6 January that did not already use it cannot configure it after 21 July 2026, and "Eventually, custom CSS will be retired entirely." That is a different change, but both narrow what a tenant can do to its own sign-in page.

Finding affected users is the thin part. The only method Microsoft describes, in the blog post and the Learn page, is to complete a sign-in with the browser's developer console open and look for violations "displayed in red". It adds: "If a specific team or person caused the violation, it appears only in their flows." None of the pages we read describes a sign-in log field, a report, a Graph call or an admin centre view. The violation happens in the browser, and the tenant is not a party to it. So the test is per person, per browser profile and per extension set, and a clean result in your own browser says nothing about the finance team's.

Stated and not stated

"Not stated" means the pages we read are silent. It does not mean the answer is no.

Scope and dates: what Microsoft states and does not state, from the Entra blog post, the Learn page and message centre posts MC1191924 and MC1481309

Question	Microsoft states	Microsoft does not state
What is blocked	Script downloads not from Microsoft trusted CDN domains; inline script not from a Microsoft trusted source	The list of trusted domains
Which pages	Browser sign-in at login.microsoftonline.com. MSAL, API and non-browser flows and other domains are not affected	Behaviour on the sovereign cloud sign-in domains
Start	"Mid-October 2026" (reminder); "mid-to-late October 2026" (Learn page). Act by 19 October	A day for any tenant
Phased or per tenant	"Global"; "General Availability (Worldwide)"; expected to complete by late October	Whether order is by region, ring or tenant, or any way to learn your date
Opt-out	Enabled by default; no tenant configuration	Any delay, exemption or opt-out
Scale	"most violations come from" extensions and injected scripts	Any count or percentage of tenants or sign-ins

Impact and testing: what Microsoft states and does not state

Question	Microsoft states	Microsoft does not state
Sign-in outcome	Users can still sign in	How each blocked tool behaves
What breaks	Browser extensions, monitoring tools, customization tools or other solutions that inject scripts	Any product, vendor or extension design
Finding affected users	Sign in with the developer console open and read the red entries; violations show only in the flows of whoever causes them	A sign-in log field, report or API; any tenant-wide view
Preview or report-only	No preview or report-only mode is mentioned	Whether any tenant-visible preview exists. We saw a report-only header on the live page on 1 October
The enforced policy	Two rules, in plain language	The full policy text, or whether it matches the report-only one we saw
Support	Work with vendors on compliant fixes	Any list of compliant or non-compliant tools

Who is in scope: workforce, External ID, national clouds and the UK

Workforce sign-in is in scope. The reminder says it affects "Organizations whose users authenticate through Microsoft Entra ID sign-in pages hosted on login.microsoftonline.com".

External ID is described three ways. The blog post says External ID "will see no impact". The reminder says External ID tenants "are not affected". The Learn page says External ID customers "using custom domains or CIAM domains for sign-in aren't impacted". Those are not identical. Microsoft's External ID overview says the name covers two things: external tenants for consumer and customer apps, and B2B collaboration, where guests sign in to resources in your workforce tenant. The scope statement is drawn by sign-in domain, not by product name. Our reading is that external tenants on custom or CIAM domains are out, and that a guest who signs in to a workforce tenant's resources through login.microsoftonline.com is not named anywhere and falls under the URL rule. Azure AD B2C is not mentioned in any of the pages. Test guest sign-ins rather than assume.

National clouds are not named. Microsoft's national cloud page lists separate sign-in endpoints: login.microsoftonline.us for US Government, login.partner.microsoftonline.cn for China operated by 21Vianet, and login.microsoftonline.com for the global service, with Azure Germany closed on 29 October 2021. The posts name only login.microsoftonline.com, and the earlier message centre post says "Production/Worldwide only". Microsoft does not say whether the other endpoints follow.

The UK. That national cloud page, last updated 15 January 2025, lists no UK-specific instance, and none of the posts mentions the UK. A UK organisation whose users sign in at login.microsoftonline.com is in scope on the URL rule, which is our reading of the scope statement rather than a UK-specific statement from Microsoft.

What one page's script policy does not cover

BleepingComputer says Entra will get "better protection". Microsoft says "extra layer" and "defense in depth". Those are fair labels for a control that does one thing on one page. A comforting label is not a control, and this one needs its boundary stated, because several routes to a stolen sign-in never touch it. The diagram sets the mechanism beside the routes outside it.

• Look-alike domains. A policy is delivered in the response from the site that serves the page. A look-alike domain serves its own response and its own headers, so Microsoft's header is not in it. The delivery rule is MDN's; the conclusion is ours.
• Adversary-in-the-middle proxies. Microsoft's 2022 description is a proxy "between a target user and the website the user wishes to visit", with the URL as the only visible difference. A proxy decides which of the real site's headers it forwards. That the policy would survive is not something Microsoft says, and we have tested no kit.
• Token theft after sign-in. Microsoft's playbook defines token theft as replaying tokens "even if that user has satisfied multifactor authentication". Nothing in that route needs a script on the sign-in page.
• Device code phishing. The victim enters a code on the genuine page, which carries Microsoft's own header and loads only Microsoft scripts. The EvilTokens briefing covers it.
• Extensions that read from their own world. Per Chrome's documentation they share the page's DOM. Microsoft's Learn page offers a malicious browser extension as a case the policy stops. Our reading is that it stops one design of extension, not all.
• Anything before or after the page. The Star Blizzard chain in the event invitation briefing runs through a message, an archive and Windows programs. The rogue external MFA provider briefing shows a third party drawing a full page after a redirect from a genuine Entra sign-in. Neither involves a script injected into the sign-in page.

The fix for phishable sign-in is phishing-resistant authentication, which the GOV.UK One Login passkeys briefing covers, including why a phishable route left open beside it undoes the benefit.

Microsoft's own security response centre shows why the layer is worth having and why it is not a guarantee. A post of 4 September 2025 says MSRC "has mitigated over 970 XSS cases since January 2024", that XSS was 15 per cent of all important or critical cases between July 2024 and July 2025, and that of 265 XSS cases in that year, 2 were rated Critical. Its servicing criteria also treat "DOM-based XSS that bypasses CSP and executes in a privileged context" as in scope. The Entra posts do not cite these figures, so the link between them is our reading, not Microsoft's.

Who is telling us this, and what it sells

Microsoft is the only source for every scope statement, and it sells Entra and the security tools that sit beside the kinds of third-party tool this change affects. That is not an accusation. A vendor deciding which code runs on its own sign-in page is within its rights, and the security argument is sound. Our inference, not Microsoft's, is that the commercial effect is that anything which monitored or decorated that page now needs a route Microsoft supports. Both things are true at once.

Two limits on the evidence. Microsoft's sentence that most violations come from extensions and third-party tools has no figure, period or method, so we cannot audit it. And BleepingComputer is secondary: its report restates a message centre update, which is why this briefing goes back to the posts themselves.

What to do before 15 October, in the order worth doing

The question that exposes the gap

Microsoft is about to stop scripts on your sign-in page that you may not know are there, and it has told you the one way to find out: a developer console in one person's browser, one sign-in at a time. So the question is not whether Entra's sign-in page will be better protected. It is this: if a tool in your estate is running script on that page today, who would tell you it had stopped, and would that be a console, or a user telling the service desk that something no longer works?

Key facts