Application-layer visibility and enforcement, fleet-wide — no per-device configuration required.
Most security tools see the network at layer 3 and layer 4. They know which device talked to which IP address, on which port, at what time. That's valuable. It's also increasingly insufficient.
The adversary has moved up the stack. Beaconing traffic hides inside HTTPS. Data exfiltration rides legitimate application protocols. Command-and-control infrastructure registers plausible-looking domains and serves responses that look like CDN traffic. At layers 3 and 4, the behavior is invisible — indistinguishable from the background noise of a modern enterprise.
Threatmatic's answer is Threatmatic π: a fleet of geo-aware, load-balanced application-layer inspection nodes, fused into the QSChannel mesh, and controlled entirely by the same policy engine that governs every other aspect of the Threatmatic platform.
The Problem With Perimeter Inspection
Traditional SSL inspection is a perimeter control. Traffic passes through a central chokepoint — a firewall, a proxy cluster, an inline appliance — where it's decrypted, inspected, and re-encrypted before continuing to its destination.
This works well when devices are on-premises and networks have a defined edge. It doesn't work for a distributed fleet. When your endpoints are in a hospital ward, a factory floor, a remote office, or a worker's home, the "perimeter" is everywhere and nowhere. Routing all traffic through a central inspection point introduces latency, creates a single point of failure, and requires the kind of hub-and-spoke network architecture that zero trust is specifically designed to move away from.
Threatmatic's approach is different. Instead of pulling traffic to a central inspector, we push the inspection infrastructure to the traffic.
QSChannel™: The Mesh That Makes It Possible
Every Threatmatic-enrolled device participates in the QSChannel mesh — an encrypted, authenticated overlay network providing connectivity between devices, policy enforcement points, and Threatmatic's control plane.
QSChannel is not a VPN in the traditional sense. There is no single gateway that all traffic passes through. Instead, traffic flows through the mesh along the shortest authenticated path, with policy enforced at each hop. A device in Singapore doesn't backhaul to a data center in Virginia to reach a resource in Tokyo — it connects through the nearest QSChannel node with the appropriate policy clearance.
This architecture makes something possible that perimeter inspection cannot achieve: inspection nodes that live inside the mesh, close to the devices they serve, rather than at a distant edge.
Threatmatic π™: Inline, Transparent, Geo-Aware
A Threatmatic π is a specialized node in the QSChannel mesh. It operates in transparent inline mode — traffic from enrolled devices is routed through the inspector at the QSChannel layer, without any per-device proxy configuration. From the device's perspective, nothing has changed. From the security team's perspective, every HTTPS session is now visible at the application layer.
Each inspector runs a policy-driven interception engine that can:
- Decrypt and re-encrypt HTTPS traffic using a Threatmatic-managed CA certificate distributed to enrolled devices at enrollment
- Classify traffic by application, domain, path, method, content type, and response code
- Enforce policy — permit, block, throttle, or log — at the application layer, with decisions made in milliseconds
- Feed telemetry into the fleet's time-series event store for historical analysis and anomaly detection
Inspectors are deployed across Threatmatic's global infrastructure and selected based on geographic proximity to the device. An endpoint in Frankfurt connects to a Frankfurt-region inspector. An endpoint in São Paulo connects to a South America-region inspector. Round-trip latency for inspection adds single-digit milliseconds — imperceptible to users, invisible to applications.
The Policy Engine: No New Concepts Required
The most important design decision in Threatmatic π is one of omission: there is no separate policy system for application-layer rules.
Threatmatic's existing policy engine — the same engine that governs network access, device authentication, zone segmentation, and session enforcement — has been extended to cover L7. Security teams who already know how to write Threatmatic policies know how to write payload inspection policies.
A policy that blocks outbound connections to a known malicious IP at layer 4 uses the same syntax, the same weight-based priority system, and the same tag-based scoping as a policy that blocks HTTPS requests to a known C2 domain at layer 7. The concepts are identical. The tools are identical. The learning curve is zero.
This matters because the hardest part of deploying a new security control is almost never the technology — it's the operational burden. A new tool means new training, new consoles, new alert queues, new runbooks, new integration work. Threatmatic eliminates that burden by making L7 inspection a native capability of the policy engine teams already operate.
What Threatmatic π™ See
The difference between L3/4 visibility and L7 visibility is the difference between knowing a device made 47 connections to 142.251.x.x and knowing that chrome.exe made 47 GET requests to accounts.google.com/o/oauth2/token — all with 200 responses, all within expected parameters.
Or knowing that svchost.exe made three POST requests to 85.210.196.11 over a three-hour period, with consistent inter-arrival timing and high-entropy paths — a pattern that looks, at L3, like normal Windows telemetry, but at L7 resolves into a beaconing signature with no legitimate application origin.
Or knowing that across a 546,000-event telemetry corpus, every single connection from lsass.exe terminated at 20.190.x.x — Microsoft Azure AD infrastructure — and can therefore be cleared from the watchlist with confidence.
The telemetry that Threatmatic π surface is the same telemetry that trained analysts use to distinguish noise from signal. The difference is that Threatmatic π surface it automatically, continuously, and at fleet scale — without requiring an analyst to pull and examine logs.
Enforcement: From Visibility to Control
Visibility without enforcement is monitoring. Threatmatic π does both.
When a policy triggers at the application layer, the response is immediate and precise. A blocked request receives a 204 No Content response in 2–8 milliseconds — faster than the application's timeout, faster than the user notices, faster than the remote server receives the connection. The block is silent from the user's perspective and absolute from the security team's.
The same policy system that blocks inbound SSH from known scanner infrastructure at layer 4 can block outbound HTTPS to ad-tracking infrastructure at layer 7. The same tag-based scoping that exempts a honeypot endpoint from the inbound SSH block policy exempts a designated inspection device from the outbound filtering policy. The logic is consistent. The tools are the same.
This composability — network policy and application policy sharing a single engine — is what makes Threatmatic's approach qualitatively different from stacking a separate proxy solution on top of an existing ZTNA platform. There is no stack. There is one policy plane, with enforcement at every layer it touches.
The Fleet-Wide Picture
Consider what this looks like at scale.
A fleet of 5,000 endpoints, distributed across 30 countries. Each device enrolled in the QSChannel mesh. Each device's HTTPS traffic transparently inspected by the nearest Threatmatic π. Each inspector enforcing the same policy set — updated in real time from the Threatmatic control plane — across every session on every device.
When a new threat indicator emerges — a newly registered domain associated with a ransomware campaign, a C2 IP range identified by threat intelligence, an application with a known data exfiltration behavior — a single policy update propagates to every inspector in the mesh within seconds. Every device is protected before the first connection attempt completes.
And when a device behaves unexpectedly — when taskhostw.exe starts contacting an IP in a known malicious /16, or when a system process makes outbound connections on a regular 3-hour interval — the anomaly surfaces in the telemetry stream immediately, visible to the security team before it has time to propagate.
Security That Closes the Gap
Layers 3 and 4 tell you that a conversation happened. Layers 5, 6, and 7 tell you what was said.
Threatmatic π close the visibility gap that has allowed attackers to operate undetected inside encrypted traffic for years. They do it without per-device configuration, without centralized chokepoints, without a separate policy system, and without adding meaningful latency to legitimate traffic.
The QSChannel mesh is the transport. The existing policy engine is the control plane. The Threatmatic π is the enforcement point — distributed, geo-aware, always on.
The gap is closed.
Threatmatic π™ is available to enterprise customers. Contact us to discuss deployment options for your fleet.