In March 2026 the IETF published RFC 9849, standardizing TLS Encrypted Client Hello. In plain terms, the part of the TLS handshake that announces which site a client is connecting to can now be encrypted. The Server Name Indication field, which a surprising amount of enterprise security tooling quietly depends on, becomes unreadable to anything watching the wire.
If your organization filters or allowlists by hostname, writes detection rules against destination domains, or produces any report that groups traffic by site, all of that rests on a field with an expiry date.
Before anyone reaches for the fire alarm: this is a planning problem, not an emergency. What follows is what the deployment data actually shows, what breaks when it arrives, what survives, and where we think the work belongs.
How fast is this actually coming?
Slower than the headlines suggest, and that distinction matters more than it might seem.
The client side is largely ready. Chrome, Edge, Firefox and Brave enable ECH by default when encrypted DNS is in use. Safari is the notable exception, exposing no user-facing support, which on its own puts a meaningful ceiling on enterprise exposure.
The server side has barely started. Research published by Corrata in May 2025 put real-world ECH usage at 0.06% of connections, against a theoretical ceiling of roughly 2% given how few servers support it. Fewer than 10% of the top million sites offer ECH; around 3% of the top thousand, and about 1% of the top hundred.
A passive measurement study of a university network carrying roughly 35,000 users, conducted in February 2025, found something instructive. 59% of QUIC flows carried the ECH extension, which sounds substantial until you look closer: only 1.96% of those were valid ECH. The remainder was GREASE, the deliberate padding clients send to keep middleboxes honest. Every valid ECH connection in the study went to Cloudflare.
That is the central constraint. Cloudflare is effectively the only CDN running ECH in production, and not on its free tier. No other major CDN has announced support since the RFC published. There is also a second gate that gets less attention: the ECH configuration is bootstrapped through DNS HTTPS records, specified in the companion RFC 9848, which in practice depends on DNS-over-HTTPS. The same study found only 3.8% of HTTPS DNS queries received a response at all, and most of those lacked the address data needed to act on them.
A realistic horizon for material enterprise impact is two to four years. RFC publication is the unlock, because CDNs and security vendors generally will not ship a protocol still in draft. The signal worth watching is the second and third major CDN announcing support.
There is a wrinkle, though, that makes that timeline less comforting than it first appears. Corrata’s research found roughly 17% of ECH-enabled sites fell into malicious or risky categories, with more than 90% of the phishing they detected riding Cloudflare infrastructure. That figure comes from a security vendor and is worth treating as directional rather than precise. The underlying logic is harder to argue with: if your operation depends on not being identified by the site you connect to, ECH is the first thing you adopt. The mainstream web is years out. The traffic you most want to inspect is already there.
What ECH actually changes
ECH encrypts the ClientHello, including SNI, under the server’s public key. An observer on the path sees a cover domain belonging to the CDN rather than the real destination. Millions of distinct hostnames collapse into a handful of shared names.
This is the successor to Encrypted SNI, which encrypted only the server name field and had known weaknesses. ECH covers the whole handshake message, which is why it closes gaps that ESNI left open, and also why it is more disruptive to anything that was reading those fields.
Worth noting alongside this: QUIC hides the entire ClientHello as a matter of course. Techniques built on observing the TLS handshake do not carry over to QUIC cleanly, so any answer to ECH that only works on TCP covers a shrinking portion of the traffic.
What this breaks
Framed as controls rather than concepts, because that is how the problem arrives:
- SNI-based allowlisting and category filtering. The most common enterprise compromise, and the most directly affected.
- Detection rules keyed to destination hostnames. Hostname indicators of compromise remain effective only where ECH is not in play.
- Endpoint-agent TLS proxying. This one is worth dwelling on. As Kathleen Moriarty sets out at RIPE Labs, an ECH-enabled browser treats interception as an attack, because that is precisely what the protocol was designed to prevent. It does not degrade gracefully; it fails.
- Reporting and capacity planning that groups by hostname. Less dramatic, more pervasive, and usually discovered late.
- Any architecture built on “we don’t decrypt, we just read SNI.” A reasonable compromise for years, and one with a limited remaining life.
Why “just decrypt it” is not the answer it used to be
To be fair to decryption: it still has a legitimate place at defined boundaries, and organizations that have invested in it are not wrong. The issue is that its coverage keeps narrowing.
Certificate pinning already puts a growing share of application traffic out of reach. Inline decryption at scale carries real cost, in appliances and in latency. Privacy and regulatory exposure has grown, not shrunk. And ECH specifically defeats the endpoint-agent approach that many organizations adopted as the lighter-weight alternative to inline proxies.
The pattern is consistent: decryption is becoming a targeted tool for specific segments rather than a general strategy. That is a meaningful shift for anyone whose visibility architecture assumed otherwise.
What still survives on the wire
Quite a lot, as it happens. None of it is payload.
Addresses and ports remain visible. So do volume, timing and directionality. Flow and session behaviour is unchanged, and behavioural patterns are often the most durable signal available. Client-side TLS and QUIC fingerprinting still works against the outer handshake, though it is worth being precise about what that gives you: it characterizes the client, not the destination. Connection metadata and certificate information remain available where they are still exposed. DNS is readable where it has not been moved to DoH.
The useful realization is that for most enterprise purposes, payload was never the thing that mattered. Knowing that a host is talking to a command-and-control endpoint on a schedule matters. Reading the contents of that conversation is rarely what generates the detection. This is a point we have made before in a different context, and encryption has only sharpened it.
So what is deep packet inspection now?
This is where the industry’s vocabulary works against clear thinking.
“Deep packet inspection” still carries the connotation it earned in the 2000s: reading payloads, inspecting content, seeing inside the conversation. In an enterprise network in 2026, that describes an increasingly small and specialized activity.
What the term actually describes in current practice is application classification and metadata extraction, using behavioural and statistical signals rather than payload reading. The question it answers is not “what is in this session,” but “what application is this, what is it doing, and does that pattern make sense.”
That is a genuinely different capability, and the naming confusion costs teams good decisions. We see organizations reject classification approaches because they have privacy concerns about DPI as they remember it, and other organizations buy decryption infrastructure to answer questions that classification would have answered without it.
Where that work belongs
If classification is the capability, the architectural question is where to perform it.
The common pattern is to let every tool do its own. The NDR platform classifies. The SIEM ingests and classifies again. Performance monitoring runs its own copy. Each needs a full packet feed, each does overlapping work, and each produces its own vocabulary for the same traffic.
The alternative is to classify once at the visibility layer and distribute structured metadata to the tools that need it. This is not a new idea, and it follows the same logic we set out when looking at where the packet broker market is heading. Encryption strengthens it considerably: classification is getting harder and more specialized, so doing it once, well, in a purpose-built place makes more sense than asking five tools to each do it adequately. It assumes you have solved the layer below it first, which is a separate conversation about TAPs and capture.
This is where Cubro’s Omnia platform is worth a look, and specifically why. Cubro runs classification as an application on the packet broker rather than as another appliance, which addresses the objection that actually kills these projects. Most organizations already need a broker. Adding classification to infrastructure that is already in the rack, already in the change process and already understood by the team is a materially different proposition from introducing a new box. We have looked at the same platform previously from the high-speed 100G and 400G angle.
Output formats matter as much as the classification itself, because compatibility is the first thing a working architect will ask about. Cubro produces IPFIX, IPFIX with DPI enrichment, and a time-window format of their own. Cubro states that its DPI engine identifies layer 7 applications regardless of encryption, using a combination of deep packet inspection and machine learning. That is the vendor’s claim rather than ours, and it is the right thing to test in an evaluation against your own traffic, particularly against ECH and QUIC specifically rather than TLS 1.3 generally.
The economic argument follows from the architecture. Metadata is a small fraction of the traffic it describes, so tools downstream ingest far less than they would from full packet feeds. Where NDR and SIEM licensing scales with volume, that difference shows up directly on an invoice.
A note for Canadian employers
One thing worth flagging, because it tends to surface late.
In Ontario, an employer with 25 or more employees on January 1 must have a written electronic monitoring policy in place before March 1 of that year, describing how and in what circumstances employees are monitored and what the resulting information is used for. Network visibility tooling is not usually deployed with employees in mind, but the question of whether it belongs in that policy is a fair one, and it is easier to answer accurately for a metadata-based architecture than for one built on full decryption.
There is a broader point here. Where Canadian privacy law does reach employee information, the recurring test is proportionality. The Office of the Privacy Commissioner’s workplace privacy guidance asks directly whether there are less invasive means of achieving the same ends at comparable cost and with comparable benefits. An architecture that collects connection facts rather than message content is a more defensible answer to that question. We will cover this properly in a follow-up post.
This is not legal advice, and the policy itself is a conversation for your counsel rather than your network team.
Five questions worth asking
If you want to size your own exposure before it becomes urgent:
- Do any of your security or filtering controls key on SNI or destination hostname? Do you know which?
- What share of your egress is already QUIC, and can your current tooling classify it?
- Where do you decrypt today, and what proportion of total traffic does that actually cover?
- If hostnames disappeared from your monitoring tomorrow, which dashboards, reports and detection rules break?
- Are you paying to ingest full packet data into tools that only need metadata?
Most organizations cannot answer the second and third from memory, and the answers are usually further from expectations than people assume.
Finding out where you stand
Telnet’s Network Visibility Assessment is a time-boxed engagement that answers those questions against your actual traffic rather than in the abstract. It includes the tooling and the analysis, and the output is a clear picture of what your current architecture sees, what it misses, and what changes as encryption continues to close in.
If the questions above were uncomfortable to read, that is usually a good reason to look.
Telnet Networks is a Canadian value-added reseller specializing in network performance monitoring, test and measurement, and network visibility. We work with Cubro alongside other visibility and security vendors, and our recommendations depend on the network in front of us.
