Straight answers

A router running OpenBSD 7.9 (base system) and a browser on your side. Nothing to install by hand first: the package declares its two runtime dependencies (sqlite3 and p5-CGI), so pkg_add pulls them in. Any amd64 hardware OpenBSD supports works — small fanless boards up to rack servers. Or take a ready-built appliance, now open for pre-order, from a four-port desktop unit up to a 10GbE pair.

Nothing reaches us unless you ask it to: no telemetry, no licence checks, and no update check unless you turn one on. Beyond what you configure — DNS upstreams, alert destinations, VPN and HA peers — the box keeps OpenBSD's own defaults: the NTP pool for time, and the package mirror when it checks for errata. Change those and nothing else leaves. It runs fully functional on an isolated network.

The one optional outbound feature is the update check, off by default: when you enable it (or press Check now), the box fetches one small signed file from ogmaprotect.com over HTTPS, verifies the signature against the key shipped in its own package, and shows you whether a newer release exists. The request carries nothing about your box — no version, no hostname, no identifier — and the box never installs anything on its own.

In two steps you control. Stage downloads the release the update check named and verifies it against the key shipped in the package — whenever convenient, nothing changes yet. Apply, behind a typed confirmation in the window you choose, re-verifies it, takes a pre-upgrade snapshot automatically, installs, asserts the installed version and reboots. Both from the root console or the web control page. The manual procedure is on Get started.

Configuration carries a per-fragment schema version and upgrades are forward-only, so keep that snapshot: downgrading is not supported. On an appliance image that path is a symlink, and archiving it the obvious way captures no state — the exact command is on the Get started page.

Not today, and we will not pretend otherwise. OgmaProtect manages its own canonical configuration model; migrating means configuring through the interface. For most networks that is an afternoon — and the result is a config with revision history and drift detection from day one.

It is your machine and nothing is hidden — but OgmaProtect owns the configuration it manages, and its drift detection will flag hand-edits to managed domains as exactly that. Best practice: let it manage what it manages, and enjoy the shell for everything else. There is a root console for the product itself, with a manual page.

One of the two editions every appliance comes in — you choose when you order. A signed, read-only root on two slots, with your configuration on its own writable partition. An update is a whole new signed image, streamed onto the standby slot and verified before it is activated; nothing a compromised process writes to the root survives a reboot. It is built and signed with the current release and is being proven on hardware now; it is offered as soon as it is. The hardware page has the picture.

Email security@ogmaprotect.com. We practise coordinated disclosure, acknowledge within three working days, and credit researchers who want credit. Published advisories are on the advisories page.

Yes — the source is available to auditors and licensees on request; ask us. It is the product code and the customer documents, not our internal engineering notes. The security page describes the architecture and the 8-lens structural audit the codebase went through before commercial launch.

The direct dependencies are listed on the compliance page: OpenBSD base, two packages, one vendored parser, and the image-build inputs for appliances. We do not publish a machine-readable SBOM file today; if your process needs one, ask — that list is what it would contain.

No, and we do not claim to be. What we publish is a controls map: which of the things those frameworks ask about the product does, with evidence in the source tree for each. Your assessor decides what counts; the page tells them where to look.