Why Is OpenBSD Known for Security, and What Does Its Security Claim Mean?

OpenBSD's security reputation rests on a specific, checkable claim on its homepage: "Only two remote holes in the default install, in a heck of a long time!" That statement refers to remotely exploitable vulnerabilities in a default installation over the project's history — not to zero vulnerabilities, and not to a system that is automatically secure regardless of how you configure it. The project describes its emphasis as "portability, standardization, correctness, proactive security and integrated cryptography," which is a design philosophy rather than a product guarantee.

What the project actually claims

The homepage makes three distinct points that are worth separating:

• A track record claim: two remote holes in the default install over a long period. The qualifiers matter — "remote" (not local privilege escalation), "default install" (not a heavily customized system), and "in a heck of a long time" (a deliberately informal timeframe).
• A design claim: proactive security and integrated cryptography are stated project goals, listed alongside portability and correctness rather than as an afterthought.
• A provenance claim: OpenSSH, the widely used secure shell software, originated in OpenBSD. This is offered as evidence that the project's security work has had effects beyond its own operating system.

None of these claims assert that OpenBSD is unbreakable. They describe priorities and a historical record.

Where the security reputation comes from

Proactive rather than reactive security

The distinction the project draws is between fixing problems after they are exploited and building defenses into the code and defaults beforehand. In practice this shows up as an emphasis on code correctness and auditing, since many vulnerabilities originate in ordinary programming mistakes rather than exotic attacks.

Integrated cryptography

Cryptography is described as integrated rather than bolted on. The OpenSSH example illustrates why this matters: a cryptographic tool that ships as part of the base system, maintained by the same project, avoids the version drift and configuration gaps that appear when security software is added separately.

Default hardening

The claim is specifically about the default install. That framing implies the shipped configuration is intended to be reasonably safe without the user first performing a hardening checklist. This is a meaningful difference from systems where security depends heavily on post-installation tuning.

What the claim does not mean

A "remote hole" is a vulnerability exploitable over a network without prior access. Local privilege escalation, misconfiguration, and vulnerabilities in third-party software you add are outside the scope of that specific sentence. Reading it as "OpenBSD cannot be compromised" overstates what is being asserted.

How to evaluate the claim for yourself

Because the homepage statement is a summary, the underlying material is where the specifics live. The site's own resources point to the places to look:

• FAQ — explains configuration and operational practices, including the reasoning behind defaults.
• Manual pages — document how individual components actually behave.
• Patches — the record of what has been fixed and when, which is the most direct way to check the security history rather than take the summary on faith.
• Changelog — tracks changes across releases.
• Reporting Problems — the channel through which issues are surfaced and handled.

The current release listed on the site is OpenBSD 7.9, released May 19, 2026, described as the 60th release. Security claims should be read against a specific release and its patch history, not as a permanent property of the name.

Who this matters for

The security positioning is most relevant if you are choosing an operating system where you want safe defaults and cryptographic tooling present from the start, and you are willing to work within the project's conventions rather than assume security is automatic. It is less useful as a reason to skip configuration review, patch tracking, or the ordinary operational work that any networked system requires.

For a concrete check: pick the release you intend to run, read its entry in the patches and changelog pages, and confirm that the defaults described in the FAQ match how you plan to deploy it. That turns a reputation into something you have verified for your own case.