“System-level enforcement” is a specific claim. Here’s what backs it.
A lot of software calls itself a firewall while actually just watching traffic and asking Windows Defender Firewall to do the real blocking. Ferrite doesn’t — and the mechanism is verifiable, not a slogan.
The Windows Filtering Platform, not an add-on
Windows itself ships a connection-filtering framework called the Windows Filtering Platform (WFP) — it’s been part of every edition since Vista, and it’s the same framework Windows Defender Firewall is built on. Ferrite talks to it directly: it opens the WFP filter engine from user space and adds ALE filters (Application Layer Enforcement) keyed to each application’s binary identity. From that point on, Windows itself evaluates every connection attempt against those filters before the connection is allowed to proceed — not Ferrite watching after the fact and reacting.
That’s the practical difference between enforcement and observation. A tool that watches netstat output and kills processes it doesn’t like is always a step behind — there’s a window where the connection already happened. Filters registered at WFP’s connect-time layer close that window: the decision is made before the connection completes, evaluated by the OS, for that specific app.
Why this is a meaningful design choice
Ferrite could have shipped its own low-level component to intercept traffic before Windows sees it, the way some competing tools do. It doesn’t need to, for blocking. WFP already does that job, it’s already trusted by the OS, and it’s already the thing every other Windows firewall answers to. Building on it instead of around it means fewer custom moving parts between your traffic and the decision to allow or deny it.
This is also why it isn’t a Pro feature. Per-app allow/block, destination IP and CIDR rules, port and protocol rules, inbound rules, DNS-layer domain blocking, time-window rules — all of it runs through this same mechanism, in every edition including Free. The one thing every tier needs is a single elevation prompt, because installing filters into WFP requires admin rights. That’s Windows’ requirement, not a license gate.
What Pro adds on top
WFP filters act on connection metadata — the app, the remote address, the port. They don’t see inside the traffic. Ferrite’s Pro tier adds a separate deep-inspection capability that reads the TLS handshake itself, which is what makes TLS-SNI-aware rules and payload-level detections possible — catching things an address-and-port rule structurally can’t, like DNS-over-HTTPS traffic sharing an IP with ordinary web traffic. That’s a genuinely different capability, which is why it’s the paid tier — not a crippled version of the enforcement every edition already gets.
Where the limits are
Country/geo rules expand to that country’s published IP block set and install as the same kind of system-level filters — proven on real hardware. But WFP has a practical filter budget, and the largest IP allocators (16 of them, including the US, UK, and Germany) exceed it. Ferrite flags those as “not enforced” rather than silently pretending the block is in place. A block that isn’t real is worse than no block at all if you don’t know it isn’t real.