About Zedmos
Zedmos began in 2024 as a Linux and FreeBSD systems project and became a company in Germany in 2026. We build one thing and ship it three ways: an inspection engine inside the firewall you already run, the same engine as a complete appliance on our own operating system, and a console you host yourself to manage every one of them.
A systems project before it was a company, which is why the engine came first and the company was built around it rather than the other way round.
2024
Work begins as a Linux and FreeBSD systems project: an inspection engine that sits directly on the interfaces of a firewall rather than beside it, so a decision is reached where the packet already is.
2025
The engine is packaged for OPNsense and for pfSense, and the console is built above them. From this point the policy model is the same wherever it runs — which is the reason an estate on both platforms can be operated as one, and the reason the next step was possible at all.
Running inside other people's platforms proved the engine; Zedmos OS is the other half of the answer. A FreeBSD-based operating system with the engine attached to the interfaces from the first boot, installed from one image onto hardware you choose — for sites that want a firewall rather than an addition to one they already run. Same engine, same policy model, same console.
2026
The project becomes a company, under German and European law: the EU Cyber Resilience Act, the GDPR, and a published support period and vulnerability-disclosure policy that a buyer can hold us to.
Today
The engine is written, reviewed and released here. Nothing in the product requires a Zedmos cloud: your traffic is inspected on your appliance, your records stay in the console you host, and the decision about a file or a prompt is reached on your premises.
Three positions the product is built on. They are the reason it looks the way it does, and they are the ones to argue with if you think we are wrong.
01
Sending traffic to a separate service to be examined adds a round trip to every session and a dependency to every site. We put the work on the appliance that is already routing the packet.
02
Several subsystems reaching separate conclusions about the same session produces an outcome nobody can reconstruct afterwards. Everything we learn about a session feeds one verdict, and that verdict is what gets recorded.
03
The console is software you install. That is a harder product to build than a hosted service and an easier one to put through a procurement review, because the answer to where the data lives is: on your server.
The engine is developed, reviewed and released in Germany, under German and European law. For a European buyer that is not a slogan on the packaging — it is the jurisdiction the vendor answers in.
A technical question is answered by someone who has read the code it is about. That is a property of how we are organised, and we will say plainly when the answer is that something is not built yet.
Support period, security-update commitment, software bill of materials and the vulnerability disclosure process are written down and dated on the security page — not described on request.