On October 19, 2026, the Microsoft Entra ID (formerly Azure AD) sign-in page will only accept scripts hosted by Microsoft. If your users rely on a browser extension, a password manager or an in-house tool that injects code into that page, they may find out one morning, facing a sign-in screen that no longer behaves as before. This guide gives you a six-step audit method to spot these dependencies, decide what to do with each one and verify the result.
What changes on October 19, 2026 on the sign-in page
In Message Center post MC1481309, Microsoft announces new Content Security Policy (CSP) protections on the Microsoft Entra ID authentication experience. These controls restrict sign-in pages to Microsoft-hosted scripts and aim to prevent the injection of unauthorized scripts, notably cross-site scripting (XSS) attacks.
The action requested from administrators fits in one sentence: check whether browser extensions, tools or custom solutions inject scripts into Entra sign-in pages, because those solutions may need to be updated. Today is October 13, 2026: six days remain.
The message lists no affected product
Message MC1481309 names no extension, vendor or password manager. The families mentioned in this guide (password managers, branding, internal tools) are logical candidates based on how they work, not a list confirmed by Microsoft. The audit exists precisely to turn these hypotheses into findings.
Why this matters for security: a sign-in page that only runs trusted code closes a door to credential theft through injection. The downside is practical: anything that legitimately hooked into it is treated as foreign code.
Prerequisites
Before touching anything, gather the following access and information. The audit itself is read-only and requires no particular license beyond what you already have.
Before you start
- Read access to the Microsoft 365 admin center to view the Message Center (a read role, for example Global Reader)
- Read access to the Microsoft Entra admin center to review the sign-in page customization
- The list of browser extensions deployed or allowed in the organization (browser policy, device management tool or, failing that, a questionnaire to the teams)
- One or two volunteer pilot users, with the most widespread extensions installed, on a non-critical machine
- The vendor contact for each password manager used in the enterprise
- A channel to warn support and users before the date
Audit dependencies in six steps
The table below summarizes the four families to examine. The steps that follow walk you through each one.
| Family | Why it is suspect | How to spot it | Possible decision |
|---|---|---|---|
| Password managers (extensions) | They fill in the page fields by hooking into it: hypothesis to validate | Extension inventory and test on a pilot machine | Vendor update, temporary manual entry, passwordless method |
| Theme, accessibility or automation extensions | They modify the display or behavior of the page | Extension inventory and test on a pilot machine | Removal or replacement |
| Sign-in page customization | The source does not say whether native settings are affected; any external script probably is | Review of branding settings and in-house additions | Return to native settings |
| Internal tools and custom solutions | Helper, test or automation scripts that inject code | Review with application and support teams | Update or abandon |
Read message MC1481309
Open the Microsoft 365 admin center > Message center, then search for MC1481309. Note the date of October 19, 2026 and the text of the required action, which you will paste into your tracking sheet.
You should see a message about blocking external script injection when signing in to Microsoft Entra ID.
Inventory the sign-in page customizations
Open the Microsoft Entra admin center and go to the company branding section (Company branding); the exact name may vary as the portal evolves. Note what is configured, then ask the web and identity teams whether a script, an in-house extension or a test tool has been added on top of the native settings.
You should end up with a document listing, for each customization, who set it up and what mechanism it relies on. An "unknown" line is a valid result: it becomes a research action.
List the browser extensions
Export the list of extensions required or allowed by your browser policies. If you have no policy, send users a short questionnaire with three questions: which browser, which password extensions, which extensions modify the appearance or automate pages.
You should get a deduplicated list, sorted by number of users, with password managers at the top.
Test on a pilot machine
On the pilot machine, open a browsing window with the extensions active and start a Microsoft Entra ID sign-in. For each extension, note whether it acts on the page: autofill, display changes, added buttons. Also open the browser developer tools to view the list of scripts loaded by the extensions, which varies by browser.
You should be able to link each observed behavior to a specific extension. Those that do not act on the page are, in principle, out of scope.
Contact vendors and choose an action
For each identified dependency, ask the vendor whether its product is compatible with the announced protections and from which version. In parallel, plan a fallback: manual entry of credentials, or a sign-in method that does not depend on autofill. Since early October 2026, Microsoft Entra recognizes Windows Hello for Business and macOS Platform SSO as standalone MFA factors in supported scenarios (MC1450134), which can reduce reliance on passwords typed in the browser.
You should get, for each line of your inventory, a decision: update, replace, remove or accept the impact.
Warn support and users
Write a short message: the October 19 date, the possible symptom (autofill no longer triggering, modified page appearance), the workaround and a point of contact. Send it to support along with the inventory so they recognize the reports.
Before October 19, you should have a validated communication and an identified contact person per team.
Verify the result after October 19
The source mentions no trial mode for these protections, so you can only validate after they take effect. Plan a check on October 19 itself, on the same pilot machines as in step 4.
Checks after October 19, 2026
- The Microsoft Entra ID sign-in page displays normally in each pilot browser and profile
- Sign-in succeeds, including with multifactor authentication
- Password extensions behave as expected, or the gap is documented with its workaround
- The internal tools inventoried in step 2 still work
- Support has received no unexplained sign-in report during the day
If something no longer works, the browser developer tools generally display, in the console, a message mentioning the Content Security Policy when a script is refused. This message gives you a precise clue to pass on to the vendor concerned.
Implementation: audit the Conditional Access policies tied to the 2026 Entra changes
The extension audit is done on devices, not by script. However, two other Entra changes from the same period can be checked automatically and repeated across several tenants. Microsoft Learn documentation states that Conditional Access custom controls are retired on September 30, 2026 with end of life in May 2027 (migration to External MFA), and that the legacy ID Protection risk policies are retired on October 1, 2026 in favor of Conditional Access policies. The script below lists the policies that use custom controls and those that target a risk level, and flags those that combine user risk and sign-in risk, which Microsoft advises against in a single policy.
- Required module:
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser - Minimum permission: the delegated scope
Policy.Read.All, with a read role on the tenant (for example Security Reader) - Output: a CSV file and a summary table of the policies to handle. The script is read-only: it changes nothing.
1param(2 # One or more tenants to audit; empty = tenant of the interactive sign-in3 [string[]]$TenantIds = @(),4 [string]$OutputPath = ('.\audit-entra-' + (Get-Date -Format 'yyyyMMdd') + '.csv')5)6 7Import-Module Microsoft.Graph.Identity.SignIns8 9if ($TenantIds.Count -eq 0) { $TenantIds = @('') }10 11$rapport = foreach ($tenant in $TenantIds) {12 # Read-only connection to Microsoft Graph13 if ($tenant) { Connect-MgGraph -TenantId $tenant -Scopes 'Policy.Read.All' -NoWelcome }14 else { Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome }15 $ctx = Get-MgContext16 17 foreach ($p in (Get-MgIdentityConditionalAccessPolicy -All)) {18 # Custom controls and targeted risk levels19 $custom = @($p.GrantControls.CustomAuthenticationFactors | Where-Object { $_ })20 $signIn = @($p.Conditions.SignInRiskLevels | Where-Object { $_ })21 $user = @($p.Conditions.UserRiskLevels | Where-Object { $_ })22 23 [pscustomobject]@{24 TenantId = $ctx.TenantId25 Politique = $p.DisplayName26 Etat = $p.State27 ControlesPersonnalises = ($custom -join ', ')28 RisqueConnexion = ($signIn -join ', ')29 RisqueUtilisateur = ($user -join ', ')30 # True if both risk types are in the same policy31 RisquesCombines = ($signIn.Count -gt 0 -and $user.Count -gt 0)32 Id = $p.Id33 }34 }35 Disconnect-MgGraph | Out-Null36}37 38# Full export for archiving39$rapport | Export-Csv -Path $OutputPath -NoTypeInformation -Encoding UTF840 41# Summary: policies to migrate or split42$rapport |43 Where-Object { $_.ControlesPersonnalises -or $_.RisquesCombines } |44 Format-Table TenantId, Politique, Etat, ControlesPersonnalises, RisquesCombines -AutoSizeA policy that targets a risk level is not a problem in itself: it is the expected form after migration. The useful information is its absence. If your tenant contains none even though you had ID Protection risk policies, the migration has not been done. The legacy policies themselves do not appear in this list, since they belong to ID Protection and not to Conditional Access.
Other Entra deadlines to plan
Script injection is not your only identity deadline. Here are, based on the Message Center and Microsoft Learn documentation, the dates surrounding October 19.
September 30, 2026
Custom controls retirement
Conditional Access custom controls are retired, with end of life in May 2027. The target is External MFA; our article on the end of Custom Controls for MFA details the transition: Microsoft Entra ID: end of Custom Controls for MFA authentication.
October 1, 2026
Legacy risk policies retirement
The ID Protection user risk and sign-in risk policies are retired. They had been read-only since July 31, 2025. They must be recreated in Conditional Access (Entra ID P2 or Entra Suite license).
October 19, 2026
Script injection blocking
The sign-in page only accepts Microsoft-hosted scripts (MC1481309).
November 3, 2026
MemberOf operator retirement
The MemberOf rule operator disappears for dynamic groups and dynamic administrative units: rewrite the rules that use it.
November 9, 2026
SSPR: registered methods only
Self-service password reset will no longer accept directory contact details that are not registered as an authentication method.
February 1, 2027
End of built-in SMS and voice
Microsoft is retiring its built-in SMS and voice call service; you will need to configure a supported telecommunications provider to continue.
For the rest of the year's calendar, our review of the September 2026 news for admins completes this picture.
Troubleshooting
The password manager no longer fills in the page
First check the extension version: the vendor may have released a fix. In the meantime, ask users to enter their username manually or to use a sign-in method that does not require autofill. Record the product and version in your inventory to follow up with the vendor.
An in-house tool stops working at sign-in
Identify the injected script using the browser console message mentioned above, then ask the owning team to remove the injection or use a mechanism supported by Microsoft Entra ID. Do not try to bypass the protection: the very purpose of the change is to prevent this kind of addition.
A migrated risk policy does not react as before
Check that the equivalent Conditional Access policy is actually enabled and not left in report-only mode. Also verify that it does not combine user risk and sign-in risk, which Microsoft Learn documentation advises against. The script in the previous section spots both cases.
If you only have an hour this week, spend it on step 3 and step 4: an extension inventory and a test on a pilot machine teach you more than any reading of the message. If your organization has no password extensions deployed and no script-based customization, your exposure is probably low; a check on October 19 is then enough.
Going further
- Microsoft Entra ID security updates: What organizations need to do now: the other Entra changes of 2026, including Custom Controls and Conditional Access for credential enrollment
- Risk policies - Microsoft Entra ID Protection: the official procedure for migrating risk policies to Conditional Access
- Deprecation of Exchange Web Services in Exchange Online (Microsoft Learn): the EWS shutdown timeline, another October 2026 deadline
- Microsoft Entra ID: end of Custom Controls for MFA authentication: our guide to the transition to External MFA
