Insights

The Azure VPN Client for Linux retires on 31 August

Braintree Insights | 24 August 2026

The Azure VPN Client for Linux retires on 31 August

The Azure VPN Client for Linux never left public preview and has no path to general availability, so Microsoft is retiring it on 31 August 2026 rather than finishing it. From 1 September it is unsupported for Point-to-Site connections, and Microsoft states that connections may fail, which could mean losing access to Azure resources.

A green-lit suspension bridge over still black water at night, its span ending abruptly in mid-air above the mist.

What changed

Microsoft’s stated reason is that the Azure VPN Client for Linux has remained in public preview and does not have a path to general availability, and that the retirement forms part of aligning Azure networking services with current security and reliability standards. The timeline has two dates. On 31 August 2026 the client is retired. On 1 September 2026 it is no longer supported for Azure VPN Gateway Point-to-Site connections. Microsoft states that after 31 August, connections using the client may fail, which could result in loss of access to Azure resources through Point-to-Site connections. The recommended action is to transition the Point-to-Site configuration to support alternative Linux VPN clients and to distribute those clients to users before the date. The retirement is listed against both VPN Gateway and Virtual WAN.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

A Point-to-Site VPN connects an individual device to an Azure virtual network, rather than joining a whole office network as a Site-to-Site tunnel does. It is how a laptop reaches internal Azure resources from home or from anywhere outside the corporate network. Azure VPN Gateway and Azure Virtual WAN both support it. The Azure VPN Client is Microsoft’s own client software for making that connection, and it exists in different builds for different operating systems; the Linux build is the one being retired.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

The Azure VPN Client for Linux never left public preview and has no path to general availability, so Microsoft is retiring it on 31 August 2026 rather than finishing it. From 1 September it is unsupported for Point-to-Site connections, and Microsoft states that connections may fail, which could mean losing access to Azure resources.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

The scope here is narrow and the consequence is not. Most organisations will find this affects nobody, and establishing that takes one conversation. Where it does apply, the shape of the work is unusual: the remediation is not a change to the gateway but a change on every Linux machine that connects, which means it is distribution work rather than configuration work, and distribution work is what takes the week that remains. There is a second question worth asking alongside the first, and it is Braintree’s view rather than Microsoft’s. A client that never reached general availability was, by Microsoft’s own framing, not covered by standard service terms while it was in use. If it has been carrying production remote access, the retirement is the visible symptom of a supportability decision that was taken implicitly some time ago. The useful outcome of this deadline is not only a working replacement, but knowing how a preview component came to sit on the access path, because the same route admits the next one.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Determine exposure first. Point-to-Site connections terminate at the VPN gateway, so start with the gateways that have a Point-to-Site configuration and the list of users or certificates provisioned against them, then confirm with the teams involved which client software those users actually run, since the gateway records the connection rather than the client build. Where Linux users are found, plan the replacement configuration and validate one connection end to end before distributing, testing not only that the tunnel establishes but that the specific internal resources those users need are reachable, since routing and DNS behaviour can differ between clients. Distribute with enough time for users to install and test while the existing client still works, which is the argument for doing it before 31 August rather than on it. Retain a dated record of a successful connection on the replacement for each affected user, because that is the only evidence that distribution actually landed rather than merely being sent.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The network lead, with whoever owns remote access to Azure.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Establish whether anyone connects to Azure over Point-to-Site VPN from Linux and whether they use this client. If they do, move the Point-to-Site configuration onto a Linux client that remains supported and distribute it to those machines before 31 August.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The list of Linux users or workstations using Point-to-Site VPN, the client each one runs, the replacement client and configuration issued, and a dated confirmation that a connection succeeded on the replacement.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

What exactly is retiring?

The Azure VPN Client for Linux, which is the preview build of Microsoft’s own VPN client software for Linux. Microsoft states it has remained in public preview and does not have a path to general availability.

What are the dates?

Microsoft’s timeline is that the client is retired on 31 August 2026, and from 1 September 2026 it is no longer supported for Azure VPN Gateway Point-to-Site connections.

Will connections stop working immediately?

Microsoft’s wording is that after 31 August 2026, connections using the client may fail, which could result in loss of access to Azure resources through Point-to-Site connections.

What does Microsoft say to do?

To transition the Azure VPN Gateway Point-to-Site configuration to support alternative Linux VPN clients, and to distribute those clients to users before the date.

Does this affect Windows or macOS clients?

The retirement notice concerns the Linux preview client. Microsoft lists it against VPN Gateway and Virtual WAN.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.

Primary Microsoft sources

AI-use disclosure: AI supported research and drafting. Every factual claim was checked against the Microsoft sources listed here.

Related Posts

Computer Vision API versions 1.0, 2.0, 2.1, 3.0...
Azure blocks the creation of new general-purpose v1...
Microsoft has published research on MacSync Stealer, a...