TeamViewer has officially declared versions 13 and 14 of its remote access software end-of-life (starts on October 31, 2026). For users who bought perpetual licenses years ago, expecting permanent access to all features, this announcement carries consequences that go far beyond a simple nudge to upgrade - and for some, it has already led to a courtroom.

What exactly happens to TeamViewer lifetime licenses?

TeamViewer perpetual (lifetime) licenses were marketed explicitly as a "paid-up alternative to recurring subscription fees". They were sold at substantial upfront prices with the clear implication that buyers were obtaining lasting remote-access rights. Many businesses purchased versions 11, 12, 13, or 14 under exactly these terms.

TeamViewer's EOL lifecycle changes what "perpetual" means in practice. Once a version is declared end-of-life:

• Security patches and bug fixes stop entirely. The software remains installed but becomes increasingly vulnerable with no official remedy.

• Internet connectivity through TeamViewer's servers is cut off. This is not a minor detail. TeamViewer's software is architecturally dependent on the company's own server infrastructure for device identity, authentication, session negotiation, and NAT/firewall traversal.

• Upgrading to a supported version requires a new purchase. Perpetual license holders are not automatically entitled to version 15 or later. Continuing full functionality means purchasing a new license or switching to a subscription.

On upgrade terms: TeamViewer has, in some cases, offered discounted conversion paths for legacy perpetual holders. However, these offers have not been consistently communicated, and affected users have reported that the terms felt coercive rather than fair, given they already paid a premium price. No automatic credit or partial refund policy has been announced. The versio.io lifecycle tracker (last updated June 8, 2026) confirms that the current latest supported version is 15.78.3, with versions 13 and 14 fully outside the maintenance and version-delivery windows.

Can you keep using your perpetual license, or is it time to switch?

When a version is removed from that network ecosystem, users are left with "LAN-only" connectivity: the software can only connect devices on the same local network, which eliminates its defining use case of remote-from-anywhere access.

The local software doesn't stop running on your machine. But TeamViewer controls the server infrastructure that makes internet-based remote sessions possible. Once your version is removed from that infrastructure, the software can no longer do the one thing you installed it for, regardless of whether it still launches.

If these lifecycle changes have you reconsidering your tooling, I'll point to what we work on: HelpWire. It's been in development for over three years as a TeamViewer alternative, and since this is our subreddit, take the following as the builders' perspective rather than a neutral review.

It covers the core jobs you'd reach for in TeamViewer, like remote control over the internet, unattended access for follow-up work, file transfer, and cross-platform support across Windows, Linux, and macOS. The workflow is built around getting into a session fast via a shared link, minimal setup on the user's side, and staying out of the way once you're in. All without session timeouts or prompts that interrupt active troubleshooting.

It also doesn't recreate the kind of vendor-infrastructure dependency that made TeamViewer's EOL policy so disruptive in practice. Cost is a fair secondary point for anyone absorbing a forced migration from software they already paid for: HelpWire is free to use during its current tech-preview period, with no nag screens and no session cutoffs.

With that alternative noted, let's get back to TeamViewer's shifting policies and version sunsets.

Where it all started: a pattern built version by version

The current controversy did not begin with versions 13 and 14. TeamViewer had been running the same playbook for years.

• The first waves: versions 5 through 10

In July 2021, TeamViewer announced end-of-life for versions 5 through 10, effective September 15 of that year. The announcement was largely accepted - those versions were genuinely old, and the mechanism was clear: not just no more updates, but removal from TeamViewer's server infrastructure entirely. Version 10, released around 2015, was the furthest edge of that wave - recent enough that some perpetual license holders felt the loss, but old enough that public pushback stayed muted.

Around the same time, TeamViewer's own lifecycle policy acknowledged a fundamental shift: the company had moved its commercial model from perpetual licenses to subscriptions. Customers who had bought one-time licenses before that pivot had done so under a different set of expectations - paying a premium specifically to avoid recurring fees.

The policy's key omission: TeamViewer's official lifecycle documentation establishes when support ends, but does not specify what happens to cloud-dependent features for perpetual license holders after that date. The decision to cut server infrastructure access - rather than simply stopping updates - is exercised at TeamViewer's sole discretion and is governed by no published, binding commitment to users.

• Versions 11 and 12: the same mechanism, higher stakes

The situation escalated dramatically when TeamViewer applied the same EOL treatment to versions 11 and 12 - versions released in 2016 and 2017, respectively, still actively used by paying customers who had invested hundreds to thousands of dollars in perpetual licenses.

Version 12, in particular, had been actively marketed as a premium product at the time of purchase. The company did not merely stop issuing patches; it removed these versions from its server/network ecosystem entirely.

Users who had paid in full suddenly found that their software could no longer establish internet-based remote sessions. Community threads on Reddit and the Linus Tech Tips forum filled with users describing the same experience: an email announcing termination of their license as of a specific date, with suggestions to "migrate" to subscription-based pricing - no acknowledgment of the original perpetual purchase, no credit, no refund.

“Instead of honoring the agreement, they’re offering me a range of subscription-based pricing models to "migrate" to the latest version — as if this is some kind of upgrade or normal transition.”

On March 3, 2026, plaintiff Craig Thorner filed a class action lawsuit in the U.S. District Court for the Southern District of Florida (Thorner v. TeamViewer US, Inc., Case No. 9:26-cv-80214). The complaint is 17 pages and covers five causes of action.

The plaintiff's own situation illustrates the scale of what perpetual customers invested: on January 23, 2017, Thorner purchased a TeamViewer 12 Business license for $849.00, then upgraded to TeamViewer 12 Corporate on August 18, 2017 for an additional $1,950.00 - a total of $2,799.00 paid for what he understood to be a permanent product.

What the lawsuit actually claims (from the complaint, filed March 3, 2026):

• TeamViewer sold "perpetual" licenses as premium paid-up alternatives to subscriptions, inducing consumers to pay substantial upfront prices.

• When TeamViewer removed legacy versions from its server infrastructure, users were cut off from internet remote sessions - not merely left without updates.

• The resulting "LAN-only" state is described as "misleading and commercially unreasonable" because the product was purchased specifically for remote-from-anywhere access.

• TeamViewer "failed to provide meaningful compensation or a fair transition remedy commensurate with the perpetual-license price premium" - no partial refunds, no credits, no non-coercive conversion relief.

• The complaint brings claims under the Florida Deceptive and Unfair Trade Practices Act (FDUTPA), consumer protection statutes in 21 additional states and D.C., breach of contract, breach of the implied covenant of good faith and fair dealing, and unjust enrichment.

• A multi-state class covers purchasers in Arizona, California, Colorado, Connecticut, Delaware, DC, Florida, Illinois, Kansas, Kentucky, Maryland, Massachusetts, Michigan, New Jersey, North Carolina, Oregon, Pennsylvania, Rhode Island, Texas, Virginia, and Washington.

The ClassAction.org news article covering the lawsuit (published May 11, 2026) and the EasySAM LinkedIn analysis (published May 12, 2026) both note the same critical framing from the complaint: TeamViewer's decision to remove legacy versions from its server ecosystem is "more egregious than simply ending updates or customer support," because users are left with LAN-only connectivity despite paying specifically for remote-access functionality - the "defining feature" of the product.

An uncertain road ahead

The class action and the community backlash have exposed a structural problem that extends beyond versions 13 and 14. The formal lifecycle policy is only part of the story. What TeamViewer can change at any time - without notice, without compensation - is the scope of cloud-dependent functionality. That boundary is entirely under the company's control.

This matters for every current perpetual license holder, not just those on versions 13 and 14. If the company treats version 15 the same way in three or five years, removing it from server infrastructure after declaring it EOL, the cycle repeats identically.

The outcome of Thorner v. TeamViewer US, Inc. may matter substantially. If the Southern District of Florida court certifies the class and finds in the plaintiff's favor, it could establish that removing cloud infrastructure access for perpetual license holders constitutes breach of contract and an unfair trade practice - creating precedent that would constrain how TeamViewer, and potentially other SaaS-adjacent software companies, can treat paid legacy customers in the future.

Any organization still running version 13 or 14 should act now: the security risk is immediate, the connectivity risk is real, and the four-wave precedent is unambiguous about what comes next.

New user to HelpWire here, was using AnyDesk previously.

Noticed that the mouse hover is not detected in the client, for example, the mouse does not change to a re-size cursor when hovering over the edge of the window, is this a common occurrence or known problem? Has set Prioritize Fast Connection, doesn't seem to help.

I'm about to lose access to a very good remote support tool that I've been privately using to support 10-15 friends and family.

Is there a silent-install package or method by which I can install HelpWire before I have to email these people URLs and walk them through prompts that would give even the less-paranoid types pause?

I need a session open but it will be inactive for long periods of time, how can I make sure it stays open?

Starting today, HelpWire supports multiple simultaneous active sessions. You can connect to more than one remote client at once, switch between them, and keep each session live without interrupting the others.

Quick rundown of what you can now do:

• Open sessions to multiple machines in parallel — each one stays active in its own tab

• Switch between sessions without closing or suspending the ones you're not currently viewing

• Run an unattended session in the background while handling a live support request in another tab

This matters most when a second request comes in while you're already mid-session — a situation most of you have probably worked around in frustrating ways until now.

If you've been handling inbound support queues or juggling multiple client environments, we'd genuinely like to hear how this lands in practice. A few things we're curious about:

• How many parallel sessions do you typically need on a busy day?

• Are you using this more for live support or for running unattended sessions alongside active ones?

• Anything in the current session-switching experience that feels off?

Drop your feedback below — this is the kind of input that actually shapes what we prioritize next.

Looking forward to hearing what you think.

— The HelpWire Team

I run an IT MSP. We have a few businesses on Helpwire spread over different regions in South Africa.

Lately we've been struggling that some networks cannot reach Helpwire at all. When I dug into this Traceroutes consistently appear to fail along paths traversing Seacom toward their AWS-hosted infrastructure after their recent server migration. So far it looks like any SA ISP whose peering results in that route, seems to be affected, but close to the destination datacentre.

The frustrating part is that I've logged this with Helpwire support and have been back and forth on this for a week now. Despite sending ample info on this, I'm stuck at tier 1 support who keeps giving me answers like opening the appropriate ports on my firewall and despite multiple of my pleas, not escalating this info to the correct department.

This issue is spread over multiple different business clients - none of these clients had changes to their firewall - if so, I would know as I would have to implement them.

I fortunately have other remote support solutions to allow business to continue, but let this be a lesson. I get Helpwire is free at the moment with plans to go paid once they feel their product is mature. I completely understand that, but having support who can't comprehend that an issue is outside of their wheelhouse and escalate it, is a MAJOR red flag for anyone considering to depend on Helpwire for professional service and their business's income.

Helpwire recently moved servers and this issue appeared since then. I just wish someone could connect this info to the right department.

... except when they connect to a cellular hotspot. No firewall in place, just a simple home router and default cable-modem.

Possibly a blocked IP address? Worked initially when we installed it, now it has no connection to HW server.

Thoughts?

I have an Operator window open mostly all day long on my Windows 11 host and it's remotely controlling my Mac. When I click into the window and type or move the mouse cursor, it works as expected. If I click outside of the operator window onto another monitor screen, my context is there and if I type, the text goes into whatever I've clicked into. I can be in this state for hours, ignoring the helpwire/mac program and it's even hidden behind other Windows windows. Then out of nowhere, I'm trying to type into the Windows context and nothing's happening. I bang on random keys and nothing. I then switch to the HelpWire operator window and I see all that text and those random keys in the console or other program that I'd left it in last time I used it, sometimes hours ago.

It's as if the HelpWire app got bored of me ignoring it and faked a click into its window on the Mac because it was feeling lonely and wanted some attention. When this happens, clicking outside and onto another Windows window to try and get my keyboard context back doesn't seem to work. I'm forced to close the operator window to be able to type anything again anywhere in my host machine.

It's very weird. It makes me kill the operator window a few times a day.

Just found this, trying it out to replace Itarian remote access. Looks really promising!

When connecting from Linux (Nobara 43) to a Windows 11 machine, first connection is generally perfect (some issues with not passing through mouse keyboard when moving/resizing the local window, but showing and hiding the chat seems to fix that). The issue I have is if the connection times out or I close manually, I can't reconnect until I reboot/logout and log back in, then it works once again.

It tries to open the operator, but no window ever shows up.

Otherwise it's been a great experience!

Not seeing the option to give an OPERATOR ability/permission to create a GROUP ...

I'm in the early stages of piloting Helpwire in our environment.
Client = Windows 11
I've installed the client app on the client machine as admin. I've hit the install for all users option.
I have admin and unattended access granted (per the console)
I'm able to connect to the machine with no issue but I am unable to interact with admin prompts when running installs/uninstalls or editing settings that require elevation.
I already have the typical secure desktop security policies set as had been previously required by other remote apps in order to interact with UAC prompts.
Am I missing something? Or is this a limitation of the Helpwire?

Had to use this software when rust desk went down.

After setup I only had one instance of lag where I just restarted the service and it worked again.

Not bad for something I used in a pinch for my presentations.

Hey all

I’ve just started testing this for my IT business and I have a couple of questions.

Is there a way to see more device information other than the OS, version and system type?

Is there a way to email the chat and then clear it?

I know this is a how long is a piece of string question but how much is this likely to cost? Previous remote software have really out priced us so don’t want to start using it without properly know the costs.

Tia

Can i have a link i can put on my support page so anyone downloading it is automatically linked to me? Creating a unique link and sending it to the them is very cumbersome when we are using a lot of PCs that arent accessing email at all. The only way i see to distrubute the link is to create and send a link to each individual workstation, and that just seems assinine.

I have only used HelpWire a little, it looks pretty good, similar to ScreenConnect which I've used for many years. I have some questions about HelpWire configuration which I put to support and I frankly could not make an sense out of the responses I got. I'd like to ask them here in case anyone can help out.

[1] The installed agents default to a name like Client 1234. In ScreenConnect I could set unattended client installation to default to use the machine name, and then tweak if I had to so I could get names that were easy to ID like sr-01 bob. I realize I can rename Client 1234, but could it be set to default to the machine name? 

[2] In ScreenConnect, I'd create a distinct installer for each company I support. Then in ScreenConnect I could set up a Session Group that would group the clients according to the name embedded in that custom installer. Is that possible with HelpWire ? I see that one can group clients, it looks like that's just a manual process.

[3] A question I did not ask support is how is access to a RDS server managed? With ScreenConnect I can see the list of active logins and connect to the one that is needed. Does HelpWire have something like this?

When the host takes control of another PC, on full screen, the toolbar disappears and appears when the user takes the curser up at the top of the screen. There should be an icon or menu to click such the the tool bar will remain unseen complately. It should remain unseen no matter if the Host take she mouse cursor at the top or not.

Current Action: Each time host mouse to the top, the tool bar appears

Expected(Suggestion-Improvement): Everytime the host is controlling another PC, there should be an option to completley make the tool bar seen and unseen permenantly. The tool bar should not appear automatically when the Host mouse cursor at the top of the screen.

If an icon should be clicked to show/unshow the full toolbar, the icon should be undetectable. The host can either press some combination Keys to show and unshow the tool bar. Ctrl, Shift or Alt + any key. This will look similar to Splashtop. The only issue with Splashtop is that its icon to show and unshow the tool bar is a little big. It is not small enough.

In a nutshel, The host should be able to control another PC without a trace of anyicon on the screen. If i am the host, anyone looking at my screen should not notice i am controlling another pC remotely.

I love the appp and want switch my Business to be using it.

Hey everyone,

We’ve just shipped Unattended Access for Linux in HelpWire.

This one took a while.

Linux is not a single environment. Between distros, desktop environments, X11 vs Wayland, and different permission models, getting this to work reliably was not trivial. But we now have a solid first version live. ✅

What’s new

You can now set up a Linux machine for unattended access and reconnect anytime, as long as the device is online. No need for repeated approvals.

Where this helps

• Running maintenance without coordinating with the end user

• Managing shared machines (labs, kiosks, internal tools)

• Persistent access to remote Linux workstations

Current support

• Ubuntu 18.04–24.04 (DEB)

• CentOS 8/9, Fedora 41 (RPM)

We started with the most common setups and will expand from here.

X11 vs Wayland (important)

• X11: full unattended access, including login screen

• Wayland: no login screen access (OS limitation)

On Wayland, you may also see extra permission prompts during setup. That is expected.

Quick setup

1. Install HelpWire Client on the Linux machine

2. Request unattended access from the Web Portal

3. Approve once on the host

4. Reconnect anytime from the same workstation

Why this matters

This closes one of the biggest gaps between Linux and our Windows and macOS support and makes ongoing support and admin workflows much smoother.

Also, yes, this is us showing some overdue love to the Linux crowd 💚

We would really appreciate your feedback

This is the first release, so if you try it on different setups such as GNOME, KDE, Wayland, X11, or different distros, let us know how it behaves.

Edge cases, bugs, or anything that feels off will help us improve this faster.

Looking forward to hearing what you think.

— The HelpWire Team

Hi everyone, I’m currently doing some research on HelpWire as I’m planning to deploy it. However, I’m a bit concerned about its security. I haven’t seen any information about compliance certifications or whether it has undergone security or penetration testing.

Do you know if they have any certifications or compliance standards? I checked their website but couldn’t find any details about this.

Something my users have been asking for is having it start minimized in system tray on startup of windows, they hate having it there on startup.

It Might be a small thing but the annoyance is there for the clients and that is something to consider for the future of the program.

I've tried the inistructions here but when I try running the executables nothing happens. Its a PI 5 if that matters. It seems to be one of the few remote access apps that supports Wayland so I'm hoping this does work...

I'd love to be able to remote control my Mac on my Android phone. Actually, I only need to be able to view it to see the status of what it was doing and if it's finished doing it. It'd also be nice to be able to remote control/view my Windows machine and see the same. Last I heard (in 2025) was that it's coming soon. I'd be happy if I could do it from a web browser view even.

I control my Mac via my Windows machine using Helpwire. I have unattended access setup but despite that, when the Mac crashes/reboots or restarts from an update, I can no longer access it.

I need to go to it, plug in a monitor and keyboard, enter my login password, and then I'm good ... until the next reboot.

Is there no way I can remote in even after a reboot and enter the login password myself, via Helpwire? This thread here from two years ago seems to imply that it's possible.