Microsoft is removing VBScript from Windows in three phases, and the organisations that will be hurt are those that do not know which logon scripts, scheduled tasks, installers and Office macros still call it. VBScript is also one of the most abused script hosts in Windows intrusions, so every month it stays enabled without a business reason is attack surface kept for nothing. This guide covers the official timeline as Microsoft states it, how to inventory .vbs files, wscript and cscript use and VBA projects that depend on the VBScript library, the replacement options, how to disable the feature early in rings with a rollback, and what happens if you wait. It is written for endpoint engineers, desktop and packaging teams and Office solution owners. The wider picture of Windows component removals is in Windows Deprecated Features; this page goes deeper on VBScript only.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- Three phases, one named date. VBScript is a pre-installed, enabled feature on demand in Windows 11 version 24H2; Microsoft says it will be disabled by default around 2027 and later removed, with no removal date announced.
- Office is a hidden dependency. VBA projects that shell out to .vbs files or reference the VBScript RegExp library break once VBScript is gone, unless they move to the native RegExp in Microsoft 365 version 2508 or later.
- Turning it off early is the best test. Microsoft's own advice for VBA is to run projects on machines with VBScript turned off to expose hidden dependencies.
- PowerShell and JavaScript are the official replacements. PowerShell for automation and installer custom actions, JavaScript for web pages.
- Security gains arrive before removal. Disabling the feature, blocking wscript and cscript with application control and enabling the relevant attack surface reduction rule shrink a common initial access path now.
What is changing and why
VBScript has been part of Windows since the 1990s, run by the Windows Script Host (wscript.exe for windowed scripts, cscript.exe for console) and loaded by Office and other applications through vbscript.dll. Microsoft's deprecated features list records VBScript as deprecated in October 2023, stating it "will be available as a feature on demand before its removal from the operating system". Modern browsers never supported VBScript in web pages, and Microsoft directs automation to PowerShell.
The security reason is well documented. MITRE ATT&CK T1059.005 Visual Basic describes adversaries automating actions with VBScript and embedding VBA macros in spearphishing attachments, and lists many groups using VBScript, including FIN7 and Turla. The ATT&CK mitigations for the technique include M1042 Disable or Remove Feature or Program and M1038 Execution Prevention, which is exactly what the deprecation lets you do. See the T1059 Command and Scripting Interpreter Defensive Guide.
Official timeline and current status
Dates and wording below are from Microsoft's own pages, checked on 8 November 2026. Microsoft gives approximate years, not fixed dates, and two Microsoft posts phrase phase 2 slightly differently.
| Phase | What happens | Microsoft's stated timing | Source |
|---|---|---|---|
| Announcement | VBScript listed as deprecated | October 2023 | Windows deprecated features list |
| Phase 1 | VBScript features on demand pre-installed and on by default | Windows 11, version 24H2 | Windows IT Pro Blog, 22 May 2024 |
| Phase 2 | Features on demand no longer enabled by default; manual enablement needed | "Around 2027" (Windows IT Pro Blog); "about 2026 or 2027" (Microsoft 365 Developer Blog, 9 September 2025) | Both posts |
| Phase 3 | VBScript retired and eliminated from future Windows versions; the .dll files removed and dependent projects stop working | No date announced | Windows IT Pro Blog |
As of the check date, no phase 2 release has been confirmed on the deprecated features page, which was last updated on 23 September 2026. Treat "around 2027" as a planning horizon, not a guarantee, and recheck the page before each Windows feature update.
Who and what is affected
| Dependency | Where it hides | Effect at phase 2 or 3 | Replacement |
|---|---|---|---|
| Logon, logoff and startup scripts | Group Policy script settings, NETLOGON and SYSVOL shares | Drive mappings, printer setup and inventory scripts silently stop | PowerShell scripts or Group Policy Preferences |
| Scheduled tasks | Tasks running wscript.exe or cscript.exe, often as service accounts | Jobs fail; failures may not alert | PowerShell tasks under a managed identity |
| Installer custom actions | MSI packages with VBScript custom actions | Installs or uninstalls fail | PowerShell or compiled custom actions (Microsoft names PowerShell) |
| VBA calling .vbs files | Excel, Access and Word solutions using Shell or a script host object | Not supported in phase 3 | Rewrite the called logic in VBA or PowerShell |
| VBA referencing VBScript RegExp | Tools > References, or CreateObject("VBScript.RegExp") | Breaks on Office before 2508 when VBScript is disabled or removed | Native RegExp in Microsoft 365 version 2508 (build 19127.20154) or later |
| HTA and classic ASP pages, vendor tools | Line-of-business and monitoring agents, legacy web apps | Features stop working | Vendor update, JavaScript for web pages |
Where identity fits: old .vbs files are a known hiding place for hard-coded passwords, mapped-drive credentials and service account secrets, and scheduled tasks that run them often use accounts with broad rights. Treat the VBScript inventory as a secrets and service account review too: rotate any credential found in a script and move the task to a managed service account. See the PowerShell Security Guide for how to avoid repeating the problem in the replacement scripts.
Finding affected systems and identities
Build the inventory from execution evidence as well as files, because files that exist are not always run, and scripts that run are not always where you expect.
- Process telemetry: collect process creation events (Windows Security event 4688 with command line, or Sysmon event 1) for wscript.exe and cscript.exe for at least 30 days. Group by parent process, command line, user and host. Parents such as Office applications, mshta.exe or a browser are a security finding, not a migration item.
- Library loads: where your EDR records image loads, look for vbscript.dll loaded by processes other than the script hosts. This catches Office, installers and vendor agents using VBScript in-process.
- File discovery: search file servers, SYSVOL, NETLOGON, software packages and endpoint inventories for .vbs, .vbe and .wsf files, and record owner, last run time and any embedded credentials.
- Group Policy and tasks: report Group Policy objects whose logon, logoff, startup or shutdown scripts reference VBScript files, and scheduled tasks whose action runs a script host. Record the run-as account for each task.
- Office projects: search VBA source in shared templates, add-ins and business-critical workbooks for CreateObject("VBScript.RegExp"), VBScript RegExp references and calls that launch .vbs files. Record the Office build in use, as 2508 and later remove the RegExp dependency.
- Packages: scan the software packaging library for MSI custom actions of VBScript type and list the vendors to contact.
- Attack surface reduction audit: in Microsoft Defender for Endpoint, put the rule "Block JavaScript or VBScript from launching downloaded executable content" (GUID d3e037e1-3eb8-44c8-a917-57927947596d) into audit mode and review the AsrScriptExecutableDownloadAudited events. Microsoft notes that some line-of-business apps use scripts to download installers, so these events also find legitimate dependencies.
Measure progress with: distinct script host command lines seen per week; percentage of devices with the VBScript feature disabled; number of VBA solutions still referencing the VBScript library; credentials found in scripts and rotated; and ASR audit events trending to zero before switching to block.
Migration options
- Rewrite in PowerShell: Microsoft's recommendation for task automation and installer custom actions. Use signed scripts, Constrained Language Mode where application control allows it, and script block logging, so the replacement is more observable than the original.
- Replace with configuration: many logon scripts only map drives or printers. Group Policy Preferences or Intune configuration removes the script altogether, which is the cheapest end state.
- Update Office: move VBA users to Microsoft 365 version 2508 or later and switch to the built-in RegExp class. Early binding to RegExp needs 2508 or later; late binding with CreateObject("VBScript.RegExp") keeps working on 2508 and later on any Windows, but fails on older Office when VBScript is disabled.
- Vendor remediation: for packaged software and agents, request a version without VBScript dependencies and record the commitment date in your deprecation register.
- Temporary re-enable: for an exception that cannot be fixed before phase 2, Microsoft says users who still need VBScript must enable the feature on demand manually. Keep exceptions on a named device list with an expiry date.
| Situation | Choose | Trade-off |
|---|---|---|
| Script only maps drives, printers or sets registry values | Configuration (GPP, Intune) | Fastest; no code to maintain |
| Complex automation, file or AD operations | PowerShell rewrite | Needs testing and signing; gains logging |
| VBA uses RegExp only | Office 2508+ native RegExp | Depends on Office update channel |
| Third-party package or agent | Vendor update | Timeline outside your control; track it |
| Cannot fix before phase 2 | Time-limited exception | Attack surface stays on those devices |
Small organisations can usually remove VBScript in one project of a few weeks. Large estates should run it as a programme with a register, owners and rings, often alongside the PowerShell 2.0 and WMIC removals.
Testing and rollback
- Ring 0, IT devices: disable the VBScript feature on demand (Settings > System > Optional features, search for VBSCRIPT) and the ASR rule in block mode. Run for two weeks and log every break.
- Ring 1, pilot business users: include heavy Excel and Access users and anyone using legacy line-of-business tools. Microsoft says a VBA runtime or compile error may mean an administrator has disabled VBScript, so brief the service desk to check this first.
- Ring 2, broad deployment: disable by policy across the estate and add application control rules for wscript.exe and cscript.exe so they cannot be reintroduced by a user re-enabling the feature. See App Control for Business (WDAC).
- Rollback: re-enable the feature on demand on the affected device or group and move the ASR rule back to audit. Record the dependency in the register before re-enabling so the exception has an owner and expiry.
- Verify: confirm no script host process creation events from production devices outside the exception list for 30 days.
Risks of doing nothing
- Unplanned outage: when phase 2 arrives in a feature update, every unmanaged dependency fails on the same day, often in logon paths where failures are quiet.
- Continued attack surface: VBScript remains a common downloader and execution host in phishing chains (T1566.001 Spearphishing Attachment, T1204.002 Malicious File). Leaving it enabled for no business reason works against least functionality. See the Macro Malware Guide.
- Exposed credentials: scripts with embedded passwords stay on shares, readable by anyone who finds them.
- Exceptions that never end: re-enabling VBScript "just for now" on whole device groups after phase 2 undoes the protection Microsoft is applying by default.
| Framework | Reference | Why it applies |
|---|---|---|
| MITRE ATT&CK | T1059.005; mitigations M1042, M1038, M1040 | Visual Basic execution; remove the feature, application control, ASR rules |
| NIST SP 800-53 Rev. 5 | CM-7, CM-7(2), CM-8, SI-3 | Least functionality; prevent program execution; inventory; malicious code protection |
| NIST CSF 2.0 | PR.PS-01, PR.PS-02, ID.AM-02 | Configuration management; software replaced commensurate with risk; inventory |
| CIS Controls v8.1 | 2.7, 4.8 | Allowlist authorised scripts; uninstall or disable unnecessary services |
| ISO/IEC 27001:2022 Annex A | 8.9, 8.19 | Configuration management; installation of software on operational systems |
Practitioner checklist
- Collect script host process creation telemetry for 30 days and build the dependency register from it.
- Search SYSVOL, NETLOGON and file shares for .vbs, .vbe and .wsf files and rotate any credentials found.
- List scheduled tasks and GPO scripts that call wscript.exe or cscript.exe, with their run-as accounts.
- Scan VBA projects for VBScript RegExp references and .vbs calls; plan Microsoft 365 version 2508 or later.
- Run the VBScript ASR rule in audit, review events, then switch to block.
- Disable the VBScript feature on demand in rings ahead of Microsoft's phase 2.
- Add application control rules for the script hosts to stop reintroduction.
- Keep a named, expiring exception list and recheck Microsoft's deprecated features page before each feature update.
Standards and references
- Microsoft Windows IT Pro Blog: VBScript deprecation: Timelines and next steps
- Microsoft Learn: Deprecated features for Windows client
- Microsoft Learn: Resources for deprecated features
- Microsoft 365 Developer Blog: How to prepare VBA projects for VBScript deprecation
- Microsoft Learn: Attack surface reduction rules reference
- MITRE ATT&CK: T1059.005 Visual Basic
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Windows Endpoint Hardening Guide · Windows Deprecated Features · Office Macro Blocking Guide · PowerShell Security Guide · Living off the Land Guide