Pin OpenZiti at v2.0.6 or newer on the 2.0 line, and do not treat a pre-release tag as the customer pin

Pin OpenZiti at v2.0.6 or newer on the 2.0 line, and do not treat a pre-release tag as the customer pin

The sentence an MSP hears is “we run a zero-trust overlay, so the flat network is gone.” The answer is that the overlay is a control plane you still have to inventory, pin and lock. It is not a slogan that retires change windows. The project discussed here is OpenZiti, repository openziti/ziti, licensed Apache-2.0, with 4417 GitHub stars and 276 forks on 4 October 2026 and a homepage at openziti.io. Those are counts, not a popularity claim beyond the count.

The pin belongs in the same breath. The newest full release on the 2.0 line is v2.0.6, published on 18 September 2026. v2.0.7 (25 September) and v2.0.8 (8 October) also exist, and both are still marked as pre-releases.

What follows is what “programmable zero-trust overlay” is allowed to mean: identity-routed services, a controller, edge routers and enrolled identities. It is also what OpenZiti is not, set against six other products that solve different jobs. The maintenance advice stops at “apply a pinned release”, and the six defender controls add no attack detail.

The feature sentence this article uses comes from the repository description and nothing else: OpenZiti’s parent project ships the executables for a fully zero-trust, programmable network. The repository topics include overlay, zero-trust and ZTNA, the default branch is main, and the main language is Go. There is no high-availability topology sold here as a fact, no throughput figure and no customer count. A diagram of how one customer stitched controllers together is that customer’s design record, not a claim this page can borrow from a star count.

The objects an MSP still has to name are controllers, edge routers and enrolled identities, including an HA controller mesh if the customer runs one. Those are names for an inventory export. They are not a build guide, not a topology to copy and not a promise that every estate has the mesh. If the customer does not run a second controller, the inventory says so. An empty HA row is a fact. A guessed second controller is not.

“Identity-routed” is the buyer sentence, and it is a narrow one. A service is reached by an enrolled identity and by policy, not because the host happens to sit on the customer LAN. That is the difference an overlay is allowed to claim here. It is not a claim that misconfiguration is impossible. A policy that is too wide, an identity that was never revoked, or a router left where it should not be administered are still ordinary operational failures. The overlay changes the question from “which subnet” to “which identity and which policy.” It does not retire the question.

Stars are a count, then a stop. The 4417 stars of 4 October 2026 are not a security assessment, not a support contract and not a pin. The repository is pushed often; the latest push before this article was on 8 October 2026. That says the project moves. It does not say which tag a customer should run.

The license is Apache-2.0, as GitHub reports it. A license tells a buyer about copyright terms. It does not tell them which release is safe to put in a change window, and it does not replace the pin.

The release page reads best as a short list, not as a spreadsheet of digests. v2.0.6 (18 September 2026) is a full release. v2.0.7 (25 September) and v2.0.8 (8 October) are pre-releases. v1.6.21 (18 September) and v1.5.18 (22 September) are full releases on the older trains, and v2.0.5 (15 September) is the previous full 2.0 release. Each tag stays inside its own train. A 1.6 tag does not become “newer than 2.0” because it was published later in the day, and a 2.0 tag does not retire a 1.5 maintenance line by existing.

The pin rule is one sentence an MSP can repeat. On the 2.0 line, do not run below v2.0.6, do not run a floating latest, and do not promote v2.0.7 or v2.0.8 while they are marked as pre-releases. A customer still on 1.6 stays on a reviewed 1.6 tag (v1.6.21 is the newest) until a planned move, not because a 2.0 tag exists. “Just take latest” across 1.5, 1.6 and 2.0 is the instruction this article refuses. Maintenance trains exist so that a planned move can be a move, with a ticket, rather than an accident of sort order.

The release notes for v2.0.6, v2.0.7 and v2.0.8 describe bug fixes and component updates or backports. The security message is short: the project ships fixes, and the MSP applies a pinned release after a change window. Readers who want the issue list can open the release page.

Earlier 2026 releases, in August, also carried security fixes on the controller and router side, with the advisories listed in their release notes. The practical advice does not change: pin a current reviewed release, and treat an advisory as a reason to upgrade on schedule.

Headscale is a coordination server for a different overlay family. This article does not compare feature checklists with it. Folding the two into one hardening story would hide which control plane the ticket is actually about.

Linkerd2 is a service-mesh and proxy data plane. OpenZiti, as discussed here, is an identity overlay. This is not a mesh sidecar article, and a sidecar policy is not a release pin for an overlay controller. An MSP can run both. Running both is not the same sentence as “one of them replaces the other.”

Tetragon is runtime and observability enforcement in a different project. It is not this pin. A sensor that watches a node does not choose the OpenZiti tag, and an OpenZiti tag does not become a runtime policy because both words can appear in the same architecture slide.

Gatekeeper and Kyverno are cluster policy admission. A zero-trust overlay does not replace a Kubernetes admission policy, and an admission policy does not pin an overlay release. The objects are different: one admits or denies API requests into a cluster, the other routes enrolled identities to services. Treating them as substitutes is how a change window loses both the overlay tag and the admission constraints.

Trivy, Prowler, Grype and Syft are scanners and SBOM tools. A scanner finding is not an overlay release decision, and this article does not borrow their version lines to decorate an OpenZiti pin.

An MSP can run more than one of these. The buyer error is treating them as substitutes. The job of this article is the OpenZiti pin and the hygiene of that control plane, nothing else. If the ticket’s title could be swapped for Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno or Trivy without changing the steps, the ticket is not about this pin.

Each of the six controls below has evidence that counts and evidence that does not. A star count, a marketing line that says “zero trust” and a floating latest digest are not evidence for any of them.

First, inventory controllers, edge routers and enrolled identities, including HA controller members if they are present. Evidence is an inventory export that names those objects and says whether a second controller exists. A slide that says “overlay deployed” is not that export.

Second, pin a known train after the change window. On the 2.0 line the floor is v2.0.6. Pre-releases such as v2.0.7 and v2.0.8 stay out of that ticket unless the customer explicitly accepts a pre-release, in writing, on that ticket. Evidence is the tag string inside the change record, not a digest someone pulled the morning of the window because it sorted first.

Third, require admin MFA on controller and admin-console identities, revoke stale enrollments and keep least privilege on identity and service policy. Evidence is an MFA setting on those admin identities and a revoke record for enrollments that no longer have an owner.

Fourth, reach the management plane only from trusted admin networks or jump hosts. Public admin or enrollment exposure is not a default. Evidence is an allowlist, or an equivalent jump-host rule, attached to the ticket. A firewall diagram with no rule identifiers is a picture.

Fifth, run backup and restore drills for the controller data model and for enrollment material. Rebuild from trusted media, and rotate identities after a suspected compromise. Evidence is a restore-drill record: the date, who ran it and whether the restore produced a controller the inventory still recognizes.

Sixth, ship audit logs to a SIEM. Treat unexpected enrollments, admin MFA removals and router link churn as operational signals to watch. Evidence is the query name in the SIEM and an owner who looks at it. A log bucket nobody opens is storage, not a watch.

The sentence the change team can repeat: do not equate “we deployed an overlay” with “the control plane is pinned and locked.” Deployment is the start of the inventory. The pin and the lock are later tickets, and they have to name a train.

In short: OpenZiti (openziti/ziti) is licensed Apache-2.0 and had 4417 GitHub stars on 4 October 2026. Its pin floor on the 2.0 line is v2.0.6, released on 18 September 2026, while v2.0.7 and v2.0.8 are still pre-releases. The homepage is openziti.io.

OpenZiti is not Headscale, not Linkerd2, not Tetragon, not Gatekeeper, not Kyverno and not Trivy. Pin the train, lock the control plane, and keep the evidence on the ticket.