Is Classic ASP still supported in 2026?

The short answer

Classic ASP is still technically supported by Microsoft in 2026, but only as a component of IIS on Windows Server. There will be no new features, no language updates, and no security improvements beyond what IIS itself receives. If you run a business on it, you are on borrowed time — not because it will stop working, but because every year it gets harder to hire anyone who will touch it.

Wait, Classic ASP is still supported?

Yes, and that surprises people. Microsoft's current statement is that Classic ASP (the VBScript server pages that shipped with IIS 3.0 in 1996) is "still supported" as part of IIS on Windows Server 2022 and Windows Server 2025. It gets security patches as part of Windows, not as its own product.

What that does not mean:

• It is not getting language features. VBScript on the server is frozen where it was in 2005.
• It is not getting security improvements beyond what IIS gives it.
• Microsoft has explicitly deprecated VBScript on the client side (Edge dropped it years ago; Windows 11 24H2 marks VBScript as deprecated). Server-side Classic ASP has not been marked deprecated, but "supported" and "recommended" are different words, and Microsoft only uses the first one.

Why this matters even though it still runs

Three reasons Classic ASP apps break even when the runtime does not:

1. Dependencies rot. Your app probably calls a COM object from 2003. That DLL was built for 32-bit IIS and a specific version of ADODB. Every Windows update is a coin flip on whether it still loads.
2. Nobody will touch it. The pool of developers who know VBScript, ADO, and classic session state is shrinking every year. The ones who are left charge a premium, and most of them do not want the job. We've heard this directly on calls: "I can't find anyone who will even quote on it."
3. Security reviews fail. If you sell B2B, the security questionnaire will ask you about "modern authentication" (OAuth, OIDC), CSP headers, and TLS 1.3. Classic ASP is not a good place to add those. One of the biggest costs we see on those calls is "hundreds of hours and well over six figures in potential lost deals" (Vanta customer, cited in our pain-points research).

What you can actually do

Option 1: Leave it alone

Valid if the app has fewer than 10 active users, is behind a VPN, and has no compliance exposure. Budget a yearly "is the server still up" check and move on. The risk is mostly dependency rot, not security.

Option 2: Wrap it in a reverse proxy and port endpoints

Put a modern app (ASP.NET Core, Node, or anything HTTP-speaking) in front. Slowly move endpoints from Classic ASP pages to the new app. The users see one URL. Over 12-18 months you can cut the old app entirely. This is the same strangler-fig pattern we recommend for .NET Framework modernizations and for Bubble exports.

Option 3: Rebuild on a modern stack

If the app is small (fewer than 50 screens) and well-understood, a port to a modern framework takes 2-4 months and gets you onto a stack where you can hire. This is usually the right answer when the Classic ASP app is also the thing blocking your next enterprise deal.

Option 4: Do not pick Option 4 (the "lift and shift to Azure" trap)

Azure App Service can host Classic ASP on a Windows container. It works. It also costs more than a roll-your-own IIS VM, and it buys you nothing except a cloud bill. If anyone proposes this as a "modernization," they are selling you a hosting change, not a modernization.

What a 2026 security review will flag in a Classic ASP app

| Check | Typical Classic ASP app | Modern expectation | |---|---|---| | TLS version | Whatever IIS default is | 1.2+ enforced, 1.3 preferred | | Auth | Forms auth or "IUSR" with DB lookup | OIDC / OAuth 2.1 with MFA | | CSP | None | Enforced, report-only at minimum | | Password storage | MD5 or SHA1 in many old apps | Argon2id or bcrypt | | Dependencies | COM DLLs from 2003-2010 | SBOM + CVE scanning | | Logs | IIS logs, maybe | Structured + centralized |

Every row of that table is a question on a B2B security questionnaire. Every "no" on the right column slows a deal by weeks.

What would make this guide wrong

1. Microsoft formally deprecates Classic ASP. As of April 2026, they have not. Client-side VBScript is deprecated; server-side is not. If that changes, the "leave it alone" option becomes a fixed countdown instead of a slow rot.
2. You are running Classic ASP inside a regulated industry (healthcare, finance, government). The compliance math is different — we'd argue the app is already non-compliant with most modern frameworks, not "on borrowed time." Talk to your auditor, not this guide.
3. Your app is actually ASP.NET Web Forms, not Classic ASP. These get confused constantly. Web Forms is a different platform with a different modernization path — see modernize .NET Framework.

Changed since last time

• 2026-04-21 — First published.

Sources

• Microsoft VBScript deprecation notice (Windows 11 24H2): Microsoft Tech Community, October 2023.
• IIS Classic ASP support status: Microsoft Learn, IIS documentation.
• Security-questionnaire cost data: softwaremovers/marketing/pain-points-research/04-pain-themes.md (Vanta customer testimonial).

Classic ASP apps are one of our common inbound audits. Start with a $299 legacy audit to map the port effort, or see pricing for hosting the post-port app on a flat monthly.