What a VPN Hides and What It Cannot: Metadata Limits in 2026
A VPN hides your traffic, not your metadata
A VPN builds an encrypted tunnel between your device and a server run by the VPN provider. Everything inside that tunnel — the pages you load, the messages you send, the files you download — is unreadable to anyone watching the network between you and that server. That part is real, and it is the part VPN marketing usually describes.
What the tunnel does not change is the shape of the traffic around it. The provider's server still has to forward your packets to their real destinations, and every hop from that server onward can see where those packets are going even though it cannot read them. The term for that surrounding information is metadata, and it is the part of the story a VPN does not address.
What metadata actually is
Metadata is everything about a communication except its content. For a network flow, it includes:
Source and destination — which address is talking to which address, and which service or domain those addresses belong to.
Timing — when the connection started, how long it lasted, and whether it happened at a predictable hour.
Volume — how many bytes moved in each direction, and how that flow was shaped over its lifetime.
Frequency and pattern — how often the same pair of endpoints talks, and which other endpoints appear alongside them.
None of those fields are encrypted by a VPN, and none of them need to be decrypted to be useful. A destination address plus a timestamp plus a byte count often narrows down what a person was doing more sharply than the content would have.
Why the “bulk collection” framing matters
On 2 September 2026, U.S. Senator Ron Wyden wrote to NSA Director Gen. Joshua M. Rudd urging the agency to update its public cybersecurity guidance for VPNs. Wyden cited a Congressional Research Service memo he had requested, which noted that “encryption strength alone does not protect users from an advanced, persistent threat conducting bulk data traffic collection.”
The word to notice is bulk. Analysing one person's flow records is expensive and targeted. Collecting flow records for everyone and searching for patterns afterwards is a different kind of operation, and a single-hop VPN does not defeat it. The concern in the letter was framed around people for whom that distinction carries consequences: government personnel, defence contractors, journalists and human rights defenders.
Wyden asked for unclassified answers by 20 September 2026. It is worth being precise about what this is: a senator's letter and a research memo, not a settled technical consensus and not a change to any agency's published rules.
What a single-hop VPN does and does not hide
Stated plainly, a standard commercial VPN does the following:
It hides the content of your traffic from your local network, your ISP, and anyone sitting between you and the VPN server.
It hides your real IP address from the sites you visit, which see the VPN server instead.
It moves trust — rather than your ISP seeing your destinations, your VPN provider does.
And it does not do the following:
It does not hide your destinations from the VPN provider. The provider has to route those connections, so it can see which sites and services you reach, and when.
It does not make your traffic unidentifiable. Tunnel protocols have recognisable signatures, so an observer can often tell that you are using a VPN even when it cannot tell what you are doing.
It does not hide flow size and timing. Correlating the volume and rhythm of traffic entering and leaving a tunnel can reveal a great deal without any decryption.
It does not detach your traffic from you. Account details, payment records and active log-ins can link a tunnel to a person regardless of what the tunnel conceals.
What multi-hop, onion routing and relays change
The Congressional Research Service memo suggested that multi-server technologies — Apple's iCloud Private Relay, Tor and Nym — may offer better protection than a standard single-hop commercial VPN. The reason is structural: they split the path so that no single operator sees both who you are and what you are reaching.
The designs are not identical. A multi-hop or double VPN chains two servers, usually from the same provider. Tor routes traffic through three relays and is designed so that no single relay knows both ends of the connection. iCloud Private Relay uses two separate hops, Apple plus a third-party relay, and covers Safari browsing rather than all traffic. Nym is a mixnet, which adds timing obfuscation on top of routing.
Each carries real costs. Tor is markedly slower and is blocked or challenged by many services. Private Relay only covers traffic from Safari and is not a general-purpose VPN. Multi-hop VPNs cut into throughput and are usually operated by one company, so the trust assumption is diluted rather than removed. Mixnets are slow and comparatively small, and their guarantees depend on how many people are using them at the same time.
Two cautions. More hops means more parties who could keep records, and a design is only as strong as its weakest operator. And the memo's suggestion is an argument for looking at architecture, not a verdict that any of these tools is safe for every threat model.
What an ordinary user should take from this
The honest conclusion is not that VPNs are pointless. A VPN still hides your browsing from your ISP, protects you on untrusted networks, keeps your IP away from sites that do not need it, and raises the cost of casual, localised surveillance. That is a real benefit, and for most people on most networks it is worth having.
What it is not is anonymity. If your goal is to make it hard for a well-resourced adversary to work out which services you use and when, a single-hop commercial VPN is the wrong shape of tool, and no amount of protocol tuning changes that. Treat a VPN as one layer, and be sceptical of any provider that treats “encrypted” and “anonymous” as the same word.
Bottom line
A VPN encrypts a tunnel and hides your IP. It does not hide the fact that you are using a tunnel, who you are reaching through it, or when. That gap is why the metadata question keeps returning to policy discussions, and why the useful question about any privacy tool is not whether it is encrypted but who can still see what.
