Your firewall rules are a file. Files can be edited.
If malware ever got write access to your rule store, the quietest thing it could do isn’t steal data — it’s delete the one rule blocking it, and let everything else keep working exactly as before. Ferrite signs the file specifically to catch that.
What’s actually signed
Every time your rule set changes, and again whenever it’s written to disk, Ferrite signs it with ML-DSA-65 — a NIST-standardized post-quantum digital signature algorithm, part of FIPS 204. On every load, that signature is checked against the on-disk bytes. If they don’t match — the file was edited by anything other than Ferrite itself — the engine refuses to load it rather than silently enforcing a rule set it can’t vouch for.
The settings the Ferrite service keeps get the same treatment, with a separate, cryptographically distinct signing context so a valid signature on one file can never be replayed onto the other. A saved setting that does not verify is ignored, and the status row says so; a rule store that does not verify is not loaded at all. The two earn different responses because losing a setting is a smaller thing than losing a rule.
Why “post-quantum” specifically
This is the part worth being precise about, because it’s easy to overstate. A large enough quantum computer would eventually be able to forge signatures made with today’s classical algorithms (RSA, ECDSA) — not decrypt them, forge new ones from scratch. That’s a real, if distant, problem specifically for signatures that need to keep meaning something years into the future: if Ferrite signed your rule store with ECDSA today, the promise “only Ferrite could have produced this signature” would quietly stop being true the day forging ECDSA becomes practical — for every rule store signed with that scheme, not just old ones.
ML-DSA is built on lattice problems believed to resist both classical and quantum attacks, so that promise is designed to keep holding. Ferrite uses ML-DSA-65 specifically — NIST Security Level 3, roughly equivalent to 192-bit classical security, a 1,952-byte public key and a 3,309-byte signature. The implementation runs on aws-lc, Amazon’s open-source cryptography library, not on a bespoke one. (Ferrite uses the standard build of it; we do not claim that the module itself is FIPS 140 validated. FIPS 204 is the standard the algorithm follows.)
What this does not claim
This is signature integrity for a local file, not encryption of your network traffic. Ferrite doesn’t claim post-quantum protection for the connections it inspects or the data that crosses your network — that’s a different problem (transport encryption), and conflating the two would overstate what’s actually shipping. What’s real today is narrower and fully verifiable: your rule store can’t be silently edited out from under you, and that guarantee is built to keep holding even once quantum computers exist.
See it yourself
Settings ▸ Engine & service shows the live signature status of the rule store and of the settings the service keeps. The rule store is the file rules.toml in C:\ProgramData\Ferrite, next to its signature rules.toml.sig. Change it as an administrator and the service will not load the changed file, and the status row reads “Doesn’t match” rather than quietly enforcing it. That refusal, not a badge or a claim, is the actual guarantee.