Do You Really Need a VPN? Give It a Job Before You Renew

Executive summary

Your VPN does not protect you from the internet. It protects a particular network path, then hands the traffic back to the internet somewhere else.

That can be worth paying for. It is not the same thing as protecting your bank account, stopping malware, or making you anonymous.

Before the next renewal, finish this sentence: I want to stop this person or company from learning this specific thing. A clear answer gives the product a job. "Keep me safe online" leaves the job undefined, which makes almost any subscription sound necessary.

A virtual private network, or VPN, can reduce what your local network observes, change the address websites see, and provide a different route for your connection. Your accounts, browser, devices, and recovery arrangements still need their own protection. The video above walks through those boundaries; this article turns them into a purchase and configuration decision.

Two encrypted connections, two different jobs

Open your bank's real website over HTTPS. Your browser establishes an encrypted connection to that website. HTTPS uses Transport Layer Security to protect information in transit, including what you submit through that connection. Cloudflare's HTTPS explanation describes that browser-to-server protection.

Now add a VPN. Your device wraps the routed traffic in another encrypted connection, this time to the VPN provider's server. The provider removes that outer layer and forwards the traffic toward the bank. The HTTPS connection remains inside it and continues to the bank.

The VPN did not invent the protection around your password. Nor does its server normally decrypt the contents of a properly validated HTTPS banking session.

Think of two separate questions:

• Who can inspect the route? The VPN changes the network observer's view.
• Who receives the information? The website still receives what you send it.

This distinction matters when a product promises more than its actual function. You can buy stronger protection for one stretch of the journey and still send your information to the wrong destination.

A fake bank can have an encrypted connection

Imagine a convincing message says your bank account needs verification. You follow its link, reach a lookalike domain, and enter your credentials.

The connection may use HTTPS. The VPN may also work perfectly. Neither fact makes the website your bank.

Encryption protects the delivery. It does not decide whether the recipient deserves the information. A fraudulent site can receive information through an encrypted connection just as a legitimate site can.

Open sensitive accounts through a saved, verified address or the provider's official application rather than the message. Do not bypass certificate warnings to get a page working. A password manager that refuses to fill credentials on an unfamiliar domain gives you a reason to stop, not a nuisance to work around.

The same boundary applies to an already compromised computer. A network tunnel cannot clean the device or prevent malicious software from abusing information at the endpoint. Account protection and device maintenance remain separate work. Our article on why ordinary people get hacked explains how routine account and recovery arrangements create exposure without anyone targeting a particularly important person.

Public Wi-Fi does not erase HTTPS

A hotel or airport network has a useful vantage point: your device connects through it. A VPN can conceal the contents of the traffic carried inside its tunnel from that network. The operator can still observe that a connection exists, including its timing and volume, and can block or interrupt it.

Without the VPN, that operator cannot simply read the password inside your valid HTTPS banking connection. Treating public Wi-Fi as automatically equivalent to broadcasting every password gives people the wrong problem to solve.

It also creates a bad habit: turn on a VPN, assume everything else becomes safe.

Keep the device updated, confirm the network you intend to join, and leave unnecessary local sharing off. When a network asks you to install an unfamiliar certificate, profile, or application to obtain access, pause. Do not trade away device trust just to get online. For a quick sensitive task, a personal cellular connection may be the simpler choice, subject to signal and your own device's condition.

That is a practical alternative, not a claim that cellular service prevents phishing or account theft. The destination and endpoint questions do not disappear when the network changes.

You choose another company to trust

A VPN changes who sits between your device and the destinations it contacts. Your internet provider sees traffic toward the VPN service; the VPN operator routes traffic onward and receives your connecting network address.

That operator occupies a position from which it may associate connection activity with destinations. HTTPS still protects its contents in the ordinary case. Privacy claims therefore need more detail than "encrypted."

EFF's VPN guidance makes the trust tradeoff explicit. Apply it to the company you are considering: who operates the service, what does it retain, and why do you trust it with this visibility more than the observer you want to avoid?

Read the privacy policy alongside the sales page. Separate activity logs, connection records, account information, payment records, diagnostics, and support information. A statement about one category does not automatically cover the others. An independent assessment can support a claim, but its date and scope matter; it cannot establish what every future system will do.

The FTC's advice on VPN applications also points to provider research, permissions, and data sharing. A free price or an expensive subscription does not settle those questions.

Record the reason for your choice in one sentence. "I prefer this operator's documented data practices to my hotel network's visibility" is a decision you can revisit. "It advertised stronger encryption" is an advertisement you repeated. Keep the actual policy link and the date you checked it beside that reason, so the next renewal does not require reconstructing the whole decision.

An IP address is only one identifier

A website may see the VPN server's internet address instead of your home's address. Then you sign in and identify yourself through your account.

Those events do not conflict. The network identifier changed; your account identity did not.

The practical mistake is expecting the website to forget the information you give it directly. Your purchases, messages, account details, and choices remain visible to the service handling them. Changing the route does not delete your relationship with that company.

Write down which identifier matters to your decision. Hiding your residential network address from a destination is a different objective from limiting what an online platform learns through your signed-in activity. Do not buy one solution while expecting the other result.

People facing stalking, targeted surveillance, or serious personal safety concerns need a broader assessment of accounts, devices, shared access, and physical circumstances. A VPN recommendation alone is too narrow for that situation. Avoid changing a monitored device or shared account without considering whether the change could alert another person.

Check what your actual application covers

The word VPN on a button does not tell you which connections take the new route.

A browser feature may cover only that browser. Your email application, cloud synchronization, or another browser may continue connecting separately. Mozilla distinguishes its built-in Firefox VPN from its device-level VPN product. That is a useful example of why the product name alone is not enough.

Device-level clients can also exclude applications or destinations. This is often called split tunneling. Mozilla's split-tunneling documentation describes applications taking the ordinary connection instead. Exclusions can solve a practical compatibility problem, but they also narrow the privacy boundary.

Before relying on the service, answer these questions from its current documentation and settings:

1. Does it cover the browser, selected applications, or the device's routed traffic?
2. Which applications or destinations bypass it?
3. Does it connect automatically on the networks you use?
4. What happens before connection, after sleep, and during a connection failure?

Test with an ordinary, non-sensitive task first. Check the apparent public address in the application you actually intend to use. Seeing a different address in one browser verifies that observation at that moment; it does not prove every application follows the same path or certify the provider's privacy practices.

Name resolution deserves attention too. Your device needs a way to turn website names into network destinations. Ask whether the VPN carries those requests and whether browser or operating-system settings choose a separate resolver. The useful question is who receives the lookup, not whether the settings page contains an encryption acronym.

Decide what should happen when the tunnel fails

A kill switch attempts to stop ordinary connectivity when the VPN connection fails, rather than silently allowing traffic outside the intended tunnel. Product behavior varies. Mozilla documents its own default-on kill switch; another product may expose different settings or limits.

Blocking the connection protects a privacy preference at the cost of availability. That tradeoff becomes noticeable when you are trying to join a meeting, complete a booking, or troubleshoot an application that suddenly cannot connect.

Choose the tradeoff deliberately. Read how your product handles failures and exclusions. Keep its support instructions available outside the application. Test reconnecting during a harmless activity, not while submitting a payment or changing an important account.

Do not respond to every interruption by disabling protections indefinitely. Record the exception, identify the affected application, and determine whether the VPN still solves the reason you bought it. A product that stays off because nobody understands the interruptions is not performing its advertised job for you.

A business remote-access VPN is a different decision

A consumer VPN usually changes the route to public internet services. A business remote-access VPN can provide an entry point into company systems. Do not cancel or replace your employer's approved access method because a consumer privacy article makes another product sound optional.

For the business, the central questions include who may connect, which systems they can reach, which devices qualify, and who maintains the gateway. The NSA and CISA remote-access VPN guidance addresses gateway exposure, strong authentication, and prompt patching.

Ask your IT provider to show the approved users, access boundaries, update responsibility, and process for removing a departed employee or vendor. "We have a VPN" does not answer any of those questions.

This is also where a cheap consumer subscription can become an expensive distraction. It does not replace company access administration. Keep the two purchasing decisions separate.

Give the renewal an answer, not a feeling

Write a short renewal note with four entries: the observer you want to limit, the information you want to conceal, the applications the product covers, and the limitations you still accept.

Keep the subscription when it performs that job at an acceptable cost. Change the setup when the scope does not match. Put the money elsewhere when the real concern is account recovery, unnecessary access, or an unmanaged device. Do not remove an organizational requirement without the responsible owner's approval.

Our personal cyber foundations guide walks through the surrounding account and device work. For a review of the whole arrangement, book a conversation with Trawvid Sec. We separate useful protection from overlapping subscriptions and address the access and recovery paths those products leave behind.