Endpoint defense is the last line. It shouldn't have to be the only one.
SynGuard drops a flood in the kernel, before the OS ever commits memory to a connection — sub-millisecond, per source IP, no collateral damage to legitimate traffic sitting right next to it. That's a real defense, and it holds under real pressure. But it has one structural limit no amount of kernel-level cleverness can remove: it can only act on traffic that has already arrived. By the time a flood reaches your own network interface, it has already consumed the one resource endpoint defense can never give back — your own inbound bandwidth.
EdgeGuard moves the decision earlier. Not instead of SynGuard — in front of it.
The Limit Every Endpoint Defense Shares
This isn't a SynGuard problem specifically — it's true of any defense that lives on the protected machine itself, no matter how fast it is. A WFP callout, a host firewall, an in-kernel token bucket: all of them see a packet only after it has already traveled the full distance from attacker to target, already consumed the customer's own last-mile link. Judging it in under a millisecond once it arrives is real protection. It just isn't the earliest point it could have been stopped.
Meeting the Flood at the Nearest Gateway
EdgeGuard routes a protected service's ingress through Threatmatic's own gateway fleet — geographically distributed, so traffic meets a scrubbing point close to where it originates, not after crossing the whole path to your origin first. From there, clean traffic relays onward to the real origin over QSChannel, the same secure fabric already carrying Threatmatic's fleet traffic — encrypted end to end, origin address never exposed to the traffic that shouldn't see it.
The relay itself stays deliberately simple: EdgeGuard reads the hostname from the TLS handshake to route each connection, without decrypting it or touching anything above the transport layer. No certificates change hands. No application logic has to understand your protocol. The origin sees an ordinary incoming connection, exactly the shape it already handles today — it just arrives from the gateway instead of from the open internet directly.
| Approach | Where it acts | What it costs the customer if it works |
|---|---|---|
| Endpoint-only (SynGuard alone) | The protected machine's own kernel | Nothing — but only after the flood already consumed inbound bandwidth to get there |
| EdgeGuard + SynGuard | Nearest gateway, then the kernel | Nothing, and the flood never reaches the customer's link at all |
Sophisticated Underneath. Simple at the Console.
The gateway's own defenses lean on mechanisms that are genuinely mature, not reinvented: kernel-level connection-rate limiting, SYN cookies for handshake floods, and RFC 5961 Challenge ACK protection for connections already established. Real, well-understood engineering — none of it needs to be the operator's problem.
So it isn't. Three switches, on by default:
- Rate Limiting — caps new connections per source at the gateway, before they ever reach your origin.
- SYN Cookie Protection — engages automatically under load, invisible to every legitimate connection until the gateway is genuinely under pressure.
- Challenge ACK — hardens already-established connections against attackers trying to inject a forged reset without ever seeing the traffic.
No thresholds to tune, no sysctls to know exist. The mechanics stay Threatmatic's problem to get right. The operator's job is deciding they're on.
What's Next
EdgeGuard's architecture is settled: DNS-directed routing to the nearest gateway, transport-layer relay over QSChannel, three operator-facing switches backed by defaults that don't need tuning. Building it out further:
Bandwidth shaping at the gateway, not just connection-rate limiting — capping sustained throughput per source using the same mature Linux traffic-shaping tooling the gateway already leans on, so a flood that survives the connection-rate ceiling still can't consume more than its share.
A gateway-aware origin. SynGuard already supports exempting trusted source IPs from its own enforcement — extended into an allowlist, that same mechanism lets a protected origin accept inbound traffic only from its EdgeGuard gateway, closing the door on anyone who discovers the real origin address and tries to bypass the gateway entirely.
Deciding where SynGuard's own defenses focus once EdgeGuard is in front. When the gateway is already scrubbing the traffic a customer's real users never see, the endpoint's own kernel-level defense turns its attention to what's left: the link back from the gateway, and anything that finds a way around it.
The Bottom Line
The fastest defense is the one that never makes your own link absorb the attack in the first place. SynGuard makes sure nothing that reaches your kernel gets to hurt you. EdgeGuard makes sure less of it reaches your kernel at all — and neither one asks the operator to understand why.
See how edge and endpoint defense fit together in your infrastructure. Schedule a demo or talk to our team.