Replace OpenVPN without interrupting operations? The VPN migration sprint covers discovery, the target environment, a pilot group, parallel operation and rollback. Managed NetBird can then take over operations from €349.90 net per month; the base package includes monitoring, updates, backups and support. View migration sprint
OpenVPN has been running stably in many companies for years - and that is exactly what makes the decision hard. The pressure rarely comes from the technology but from missing multi-factor authentication, missing user management and flat network access. This guide shows the move to NetBird as a procedure: what happens to certificates, how identity and policies come about, and how the cutover runs without downtime. As of July 2026.
Table of contents
- Why replace it
- Retrofit or switch
- What happens to the certificates
- Step by step
- Sites and systems without a client
- Cutover without downtime
- Pitfalls from practice
Why replace it
OpenVPN is mature and open source. The reasons for switching lie not in the encryption but in what is missing alongside it:
- No central user management. Identity is the certificate. When someone leaves, their certificate has to be revoked - manually, and across all servers.
- MFA only via add-on modules. Possible, but bolted on: a PAM plugin or RADIUS with OTP, each with its own operations and failure paths.
- Flat access after dial-in. Whoever is in the tunnel typically reaches entire network segments. Separation would have to be handled by the firewall and is rarely maintained finely enough.
- An exposed service. The OpenVPN port is reachable from outside and thus part of the attack surface.
On top comes the regulatory trigger: the German NIS2 implementation act in force since 6 December 2025 explicitly names multi-factor authentication as a risk management measure for important and particularly important entities. Details in NIS2-compliant remote access.
Retrofit or switch
The honest answer is: it depends, and both are legitimate.
Retrofitting is enough when there are few access paths, all users need the same systems anyway and separation via the firewall stays manageable. A RADIUS with OTP in front of OpenVPN meets the MFA requirement.
A switch pays off as soon as several user groups need different targets, external contractors and machine access come into play, or certificate management starts eating time. Then the overlay solves three problems at once instead of one.
The basis for deciding between the protocols is in OpenVPN vs WireGuard; the target model is placed by What is ZTNA?.
What happens to the certificates
The most common misconception is wanting to migrate the PKI. It is replaced, not carried over:
| OpenVPN | NetBird | |
|---|---|---|
| Identity | Client certificate | User account in the IdP |
| Second factor | Add-on module (PAM, RADIUS) | In the IdP, incl. MFA policies |
| Revocation | Revoke certificate, distribute CRL | Change account or group in the IdP |
| Machines | Own certificate per device | Setup key, optionally assigning groups |
In practice: the existing PKI stays untouched in operation during the parallel phase and is decommissioned only after cutover. There is no intermediate state in which both have to be maintained at once.
Step by step
1. Take inventory. Which certificates exist, which people or systems own them, and what does each access? Experience shows a number of certificates surface here that nobody can attribute any more - those are the first candidates for revocation.
2. Control plane and identity. The control plane is set up self-hosted or as an operated service in the EU. More important is the identity provider: NetBird connects OIDC-capable IdPs, including the self-hostable Authentik and Keycloak. That is where users, groups and MFA live.
3. Register peers. Workstations log in interactively via the IdP. Everything unattended runs on setup keys (documentation): one-off or reusable with a limit, with automatic group assignment, optionally as ephemeral peers that disappear automatically after ten minutes offline. For server estates this belongs in automation.
4. Groups and policies. Now comes the separation OpenVPN never had. A policy defines source and destination group, protocol, ports and direction (documentation). Important: on first setup a default policy is created that allows connections between all peers. Anyone leaving it in place has rebuilt the flat tunnel exactly. It belongs replaced by rules following the table from step 1.
Sites and systems without a client
Where a route previously led through the tunnel, a routing peer takes over: a NetBird peer in the respective subnet that mediates between overlay and local network. This keeps legacy servers, printers and controllers reachable without installing anything there.
An operational detail: NetBird performs the required outbound SNAT itself only on Linux routing peers. On OPNsense or pfSense it has to be configured manually - for site connectivity a Linux peer is therefore the calmer path.
Cutover without downtime
- Pilot: one uncritical user group, one uncritical target system - including verifying that policies and logging take effect.
- Switch group by group. OpenVPN stays active; anyone with problems keeps using the old path.
- Contractors and machines last, because they need the most coordination.
- Switch off. Only when nobody works over OpenVPN any more is the service disabled and the PKI subsequently decommissioned. That removes the exposed port.
A sensible intermediate step: log OpenVPN connections for a week before switching off. Anyone still dialling in was missed during the inventory.
Pitfalls from practice
- Leaving the default policy. The most expensive mistake: the security gain of the migration only materializes through restrictive rules.
- Carrying shared certificates over. Shared accounts cannot be protected with MFA and render logging worthless. The migration is the moment to dissolve them.
- Mapping push routes one to one. What OpenVPN distributed as
push routewas often broader than necessary. Instead of copying it, it belongs re-cut along actual access needs. - Forgetting DNS. Internal name resolution often came with the old tunnel. It has to be set deliberately in the new network, otherwise IP access works but hostnames do not.
- Switching off too early. The old access is the way back - until the last group has been confirmed as migrated.
How the target architecture works is explained in What is NetBird?. If a firewall appliance rather than OpenVPN is up for replacement, Migrate FortiGate SSL-VPN to NetBird covers that case.
