Why zero trust remote access for manufacturing sites differs from office VPN replacement
A manufacturing operations or security leader whose plants and vendor technicians depend on a VPN into flat OT networks should first change the access model, not the VPN product. For remote access to plant systems, the answer is identity-based access that dials out: OpenZiti edge routers or NetBird routes that let approved users reach specific services, or an identity-aware proxy such as Pomerium in front of specific web applications, all kept on the company's own infrastructure. The design question is not how many users connect but which machine, which vendor and which production asset each session may reach, and what happens to that session when a line is running. Production uptime and safety decide the architecture more than headcount does. A PLC or HMI that cannot tolerate a new network path, a vendor technician who needs a single controller for a few hours, and a plant that must keep running when the internet link drops all push the design toward dark services and tightly scoped routes.
The regulatory context raises the stakes. NIS2 Annex II lists manufacturing as a critical sector, covering NACE Rev. 2 divisions 26 to 30 and medical devices, so many plants fall in scope and must report significant incidents within the deadlines in Article 23(4). The Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and includes an essential requirement at Annex III, 1.1.9 that machinery be protected so a connected or remote device does not lead to a hazardous situation. Remote access to a machine is therefore a safety design decision as well as an IT decision. Before choosing a tool, confirm with your legal and safety teams which machines and sites fall under these rules, and which of your suppliers must meet them. The ISA/IEC 62443 series, including ANSI/ISA-62443-3-2-2020 for risk assessment and ANSI/ISA-62443-3-3-2013 for system security levels, gives a shared vocabulary for zones and conduits that your segmentation design should use.
DeployOpen plans and implements self-hosted zero trust access in your environment, including segmentation, identity integration, vendor access policies and the evidence your teams collect. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies assess compliance, so ask any implementation partner to document the controls and logs in a form your assessor can test. Also confirm the expected state of OT networks with your controls engineers before any change, because a route that works in an office lab can disrupt a production cell. Treat the first scope as a list of named assets, named vendors and named maintenance windows, and make the team that owns production sign off on it.
Which regulations and standards set the access requirements for plants
This table maps each regulation or standard that touches plant remote access to the control intent it expresses and the build decision it forces. Read it as a checklist for design choices: outbound-only connectivity, segmented OT zones, logged vendor sessions and retained incident evidence. Confirm applicability with counsel and your certification body, since the same plant can fall under several of these at once.
| Requirement or standard | What it asks for | What it means for the build |
|---|---|---|
| ISA/IEC 62443 (asset owner program and zones) | A security program for the asset owner, a risk assessment for system design, and system security levels that set how zones and conduits are protected | Define zones and conduits before choosing overlays. Route remote sessions only into the zones they need, and record the security level each zone is designed to meet |
| NIST SP 800-82 Rev. 3 (OT performance and safety) | Guidance for industrial control systems, including SCADA, DCS and PLCs, that weighs security against availability, reliability and safety | Test remote access so it cannot stall control traffic. Keep access to controllers read-only or staged where the process owner requires it, and document the safety review |
| NIS2 Annex II (manufacturing scope) | Manufacturing in NACE Rev. 2 divisions 26 to 30 is a critical sector. Significant incidents need an early warning within 24 hours, a notification within 72 hours and a final report within one month | Log vendor and remote sessions with enough detail to answer those three deadlines. Confirm whether your entity is in scope before designing the reporting pipeline |
| Machinery Regulation (EU) 2023/1230, Annex III 1.1.9 | From 14 January 2027, machinery must be protected so that connecting another or remote device does not create a hazardous situation | Enforce authenticated, policy-limited remote connections to machines. Keep remote paths from reaching safety functions, and confirm the requirement with the notified body or your conformity assessment route |
| Cyber Resilience Act (EU) 2024/2847, Article 14 (manufacturers) | Manufacturers must report actively exploited vulnerabilities and severe incidents in products with digital elements. These obligations apply from 11 September 2026, ahead of the general application date of 11 December 2027 | If you ship connected products or remote-service features, keep vulnerability and incident records tied to the access paths used to support them. Confirm your role as manufacturer or integrator |
Which open-source platforms fit plant and remote-site access
Plant and remote-site access usually combines a few distinct needs: reaching a specific OT service without opening inbound ports, placing a whole segment on a private overlay, and publishing a browser front end to a named group. The platforms below solve different parts of that problem, so the choice depends on what must be reached, from which devices, and which logs and controls the site must produce.
OpenZiti for dark services
OpenZiti fits when individual plant services, such as a historian API, a file transfer endpoint or a vendor diagnostic port, should be reachable only by named identities. Private edge routers make outbound connections, so the site needs no inbound firewall rules, and revoking an identity ends active sessions at once. Confirm whether your plant can run a tunneler beside each service or needs an SDK in the application, and plan who operates the self-hosted controller, which is the management plane for identities and policies.
NetBird for OT subnet routes
NetBird fits when engineers or integrators need routed access to whole OT subnets, such as PLC or HMI networks, from managed laptops. Groups and access rules map to plant roles, and SSO with MFA is available on the Team plan. Device posture checks and traffic logging are listed on the Business plan, so confirm which controls your site needs before choosing a tier. The control components are AGPLv3 and the client repository is BSD-3-Clause, which your legal team should review.
Pomerium for browser front ends
Pomerium fits when the target is a browser-based HMI, historian dashboard or maintenance web app that the application can run behind an identity-aware proxy. Access is set per route, tied to your identity provider, with no client on the operator workstation. It is a poor fit for native thick clients, legacy protocols and applications that cannot tolerate a proxy in front of them. Confirm the supported authentication flows and how sessions and request logs are retained before relying on it for plant screens.
Headscale as a simple overlay
Headscale is a self-hosted coordination server for Tailscale clients, and it suits a small number of sites with flat, low-risk access needs, such as a few engineering laptops reaching a single test cell. It adds little for segmentation or posture control on its own, so plants that need per-service policy usually outgrow it. Confirm the client platforms your engineers use, how the coordination server is backed up and upgraded, and which access and logging features your plan requires.
How a plant rollout is phased without stopping production
The sequence starts with inventory and risk assessment, proves access at one non-critical site and with vendors, then moves site by site while the VPN stays in place until each cutover is verified.
Inventory sites, zones and existing remote paths
Engineering and OT staff list every plant, production line, controller, historian and HMI that remote users or vendors reach today, along with every VPN tunnel, firewall rule, remote desktop jump host and modem or cellular path. Operations and the plant safety lead confirm which systems cannot tolerate latency or restarts. The output is a zone map that places each asset in a candidate zone with its current inbound and outbound paths. The step is complete when the plant owner signs off that no remote path has been left out.
Assess risk against the ISA/IEC 62443 approach
The security team and plant engineers work through the zone and conduit model of the ISA/IEC 62443 series, rating each zone's consequence and threat exposure and setting a target security level for each. They use the asset-owner program requirements in ANSI/ISA-62443-2-1-2024 and the system risk assessment guidance in ANSI/ISA-62443-3-2-2020 as reference points. The output is an approved flow matrix listing each permitted source, destination, port, protocol and purpose, with the business owner named for every flow. The step closes when the matrix is approved by OT, IT security and the site manager.
Pilot access at one non-critical site
The team deploys a private OpenZiti edge router or NetBird peer inside a non-critical site's zone, with only the approved flows enabled. Outbound connections from the site to the controller or coordination service are the only new paths, and the pilot confirms that no inbound firewall rule is added. Engineers test that each permitted service is reachable and that every other address is not. The output is test evidence: recorded results for each flow, the firewall configuration snapshot, and the connection logs showing identity and policy decisions.
Run a time-bound vendor access pilot
Vendor technicians are onboarded through identity groups that carry an expiry, and each group is mapped to one device or one service in the approved matrix. Access requests are approved by the plant owner, and sessions are recorded in the platform's logs. The team verifies that revoking a group ends active sessions and that an expired group loses access without manual cleanup. The output is a vendor access test record with approvals, session logs and a documented revocation result. Confirm with the vendor how their own tooling and licensing requirements interact with the chosen platform.
Harden controllers, edge routers and backups
The controller, edge routers, identity provider and any relay are placed under change control, with operating system hardening, restricted administrative access, time synchronization and centralized logging applied before production use. The team tests restoring the controller configuration and certificates from backup in a separate environment and records the recovery steps. The output is a hardening baseline, a tested restore record and a change record that names each component's owner. Confirm the platform's own upgrade and backup procedures against the version in use.
Cut over each site with the VPN kept in place
Each remaining site moves through the same sequence: the approved flow matrix is applied, the edge router or peer is installed, and the site's users and vendors are switched to identity-based access while the legacy VPN stays available as a fallback. Operations observes the site through at least one normal production cycle before any change to the VPN. The output for each site is a cutover change record with test results, the list of users moved and any exceptions approved by the plant owner.
Retire inbound rules after verification
Once a site has run on the new path without unplanned access issues, the team removes the VPN concentrator entries and inbound firewall rules for that site, one rule at a time, with the change recorded and a rollback plan held for the period the change window requires. A final review compares the live firewall state with the approved flow matrix and confirms the segmentation between production and business networks is intact. The output is the retirement change record, a reconciled firewall report and an updated zone map for the next audit cycle.
Deployment patterns for plants, remote sites and vendor access
A single plant with one production network is the simplest pattern. Place a private OpenZiti edge router or a NetBird peer inside the plant's trusted zone so it makes only outbound connections to a controller reachable from the internet, which removes the need for inbound firewall rules to plant systems. The control plane can run in the company's own cloud account or a server in the corporate data center, while the plant router handles dialing and encryption.
- Identity provider: Connect the overlay to the workforce identity provider so that access groups map to roles such as maintenance, quality or engineering.
- SIEM feed: Forward access and connection logs to Wazuh or Security Onion so that plant access events sit next to firewall and endpoint telemetry.
- OT segment routing: Publish only the specific HMI, historian or engineering workstation addresses through the router, and keep PLC networks unrouted from the overlay.
- Controller location: For a self-hosted NetBird deployment, the public control plane needs TCP ports 80 and 443 and UDP port 3478 open, so confirm with the network team how those ports are exposed without weakening the plant boundary.
- WAN outages: A single site keeps local access only if the router and services sit on the same segment, so test whether engineers can still reach local systems when the internet link drops.
Before committing, confirm with the OT owner which services may be reachable at all and whether the plant's change process allows a new outbound path.
A manufacturer with several plants, warehouses or remote sites usually runs one central controller with a router or peer at each site. Each site dials out to the central control plane, and policies decide which identities reach which services at which site. This keeps every plant's inbound exposure at zero and lets the central team manage access from one place.
- Central controller: Host the management plane in a hardened environment that the central security team controls, and document who can change access policy.
- Per-site routers: Deploy one router per site inside the local trusted zone so that site traffic does not depend on a shared hub.
- Identity and posture: Map site-level SSO groups to access rules and, where the platform supports it, add device posture checks for laptops used by plant staff.
- Logging: Send events from every site to one SIEM tenant so that correlation across plants is possible, and confirm the retention period with compliance.
- Unreliable links: Sites with weak WAN connections need local relays or routers that keep working for on-site traffic, and the design should state what happens to new sessions during an outage.
Ask the implementation partner to document the failover behavior for each site type, since a controller outage and a site link outage have very different effects on production.
A vendor, integrator or OEM technician often needs access to one machine or production cell for a few days. The safest design gives that person an identity-bound path to a single service, not a shared VPN account. Services can be dark, with no listening ports, so the vendor reaches only the one endpoint the policy names, and revoking access terminates active connections immediately.
- Scoped identity: Issue a dedicated external identity with a defined expiry, tied to a named sponsor inside the company.
- Single service policy: Publish only the controller's HMI or engineering port for that cell, using a tunneler or SDK at the service side.
- Session logging: Record who connected, when and to which service, and forward those records to the SIEM or to a dedicated access log.
- Approval and MFA: Require the identity provider to enforce multi-factor authentication for vendor accounts, since regulators in several sectors expect it for remote access.
- Cell segmentation: Keep the cell on its own segment so that a vendor session cannot reach adjacent lines.
Before granting access, confirm with the OT owner and the vendor whether the vendor's own laptop meets the company's posture rules and whether a privileged access tool is needed for session recording.
Evidence a plant audit or regulator will ask for
This table lists the records a plant audit, customer assessor or NIS2 authority is likely to request for remote access into manufacturing sites, the requirement each one supports and the component that usually produces it. Read it as a starting inventory: the auditor or certification body decides what is sufficient, and DeployOpen prepares the evidence without judging it. Confirm the exact asks with your auditor and the ISA/IEC 62443 security level you target.
| Evidence | Requirement it supports | Component that produces it |
|---|---|---|
| Approved access flow matrix (who reaches which OT zone, port and protocol) | ISA/IEC 62443 zone and conduit definitions and system security requirements (ISA-62443-3-3-2013) | Controller policy export, NetBird groups and access rules, documented in the zone design |
| Per-user and per-vendor access log with identity and device | Unique identification of each remote user, traceable to a named person or vendor account | OpenZiti controller identity records, NetBird activity events, identity provider logs |
| Session and connection records for vendor and engineer sessions | Monitoring of remote access into production networks and review of who connected when | NetBird activity and traffic events, OpenZiti edge router connection logs, forwarded to Wazuh or Security Onion |
| MFA enforcement evidence for remote logins | Strong authentication for remote access, shown as configuration plus login records | Identity provider MFA policy and login events, NetBird SSO and MFA settings |
| Segmentation diagram with router and route inventory | Network segmentation between enterprise IT and OT zones, with documented conduits | Architecture document, NetBird routes to OT segments, edge router placement in private zones |
| Change records for router, route and policy edits | Change control for security-relevant configuration in IACS and supporting networks | Git or ticket history for Terraform or Ansible changes, controller and NetBird admin audit logs |
| Incident reporting timeline for a significant remote access event | NIS2 Article 23 early warning within 24 hours, notification within 72 hours and final report within one month, where in scope | Alert records from Wazuh or Security Onion, dated analyst notes and response tickets |
| Vulnerability and patch notice for edge router and tunneler versions | CRA Article 14 reporting obligations for manufacturers of products with digital elements, and vendor advisory handling | Version inventory from the platform, vendor advisory subscriptions and internal patch records |
Controlling vendor and integrator access to production systems
Vendor technicians and integrators should reach a plant system only for a defined task, through a named identity, after an approval, and with a recorded session. Treat every vendor laptop as an untrusted device that gets a short-lived grant to specific assets, not a seat on the OT segment. In an OpenZiti design, the controller's service policies determine which identity can dial which dark service through which edge router, so a vendor identity can be limited to one PLC gateway or historian service and nothing else, and revoking the identity ends active connections immediately. In a NetBird design, the same idea is expressed as groups and access rules: a vendor group can reach one OT host on one port, and posture checks and device approvals decide whether that laptop joins at all. Confirm in your own environment whether the vendor's own machines can be enrolled as managed devices, since that determines whether posture rules can be enforced or only assumed.
Overlay access rules control reachability, but they do not answer who did what once a session is open. Privileged control of a vendor engineer, including approval workflows, time-boxed elevation, command or keystroke capture and video-style session replay, usually belongs to a privileged access management tool. Review the open-source PAM options covered in the open source privileged access management content group and decide early whether the vendor session passes through a jump host that records it, or whether the overlay only carries the connection. Tie vendor identities to your workforce single sign-on so offboarding a vendor engineer removes access in one place. Ask the integrator to document where session logs are stored, how long they are retained, and who can read them, because those answers become evidence during an audit or an incident review.
Before go-live, run a test with a dummy vendor identity: confirm that it cannot see any other service, that the approval step blocks access when no request exists, that revocation drops a live session, and that the session record appears in the log store you will actually review. Document the vendor access matrix as a controlled artifact owned by the plant's OT security lead rather than by the integrator alone. Expect the integrator to request broad access for convenience during commissioning. Agree a written exit date for each elevated grant, and check that the NIST SP 800-82 Rev. 3 guidance on remote access to OT and the ISA/IEC 62443 requirements your plant has adopted are reflected in the matrix.
What do manufacturers ask before replacing plant VPNs?
How much effort does replacing a plant VPN with zero trust access take?
The effort depends mostly on how many sites, OT protocols and application types are in scope, not on the software license. Each site needs a route or tunneler design, each application needs an access policy, and each OT segment needs a review of what the remote user may reach. Sites with a single line and a few HMIs take far less work than a multi-plant estate with PLC programming access, historian connections and vendor tools. Ask any implementer to price the work per site and per application class, and to state which assumptions drive the count. Software from NetBird or OpenZiti is typically free to self-host, so most of the cost sits in infrastructure, engineering time and change control.
Can a plant IT team run a self-hosted NetBird deployment alone?
A small team with Linux and Docker experience can stand up a self-hosted NetBird test, but running it in production is a continuing job. NetBird's self-hosting quickstart says self-hosted operators handle backups, upgrades and scaling themselves, while NetBird Cloud is the managed version that needs no servers or domain. The quickstart lists a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443, UDP port 3478 and Docker with the Compose plugin. Plant teams should decide who owns patching, certificate renewal, backup restores and on-call response before the first site goes live. DeployOpen can plan, implement, document and support a self-hosted deployment under a written scope, or hand it over with a runbook.
What does the plant side need to provide for the project?
The project depends on information only the plant and OT engineering teams hold, so plan that access early. Typical inputs include an asset list per site with addresses, protocols and vendor systems, network diagrams showing existing zones and conduits, and a list of which vendors and engineers need which systems. You will also need named OT engineers for reviews, a change window agreed with production, and a rollback plan approved by plant management. Standards such as the ISA/IEC 62443 series describe how asset owners structure zones and conduits and assess risk, which gives your engineers a shared language for these reviews. Confirm early whether the plant has a written security program and who signs off on changes to safety-related networks.
Can the existing VPN stay in place during a plant cutover?
Yes, running both during cutover is the usual approach, and it lets you move one application or one site at a time. The old VPN stays available for applications not yet migrated, while new access paths are tested with a small group of named users. Keep the old path until logs from the new path confirm the expected behavior, and set a removal date tied to a review, not to the end of the project. Make sure the two paths do not create a backdoor, for example a VPN route that still reaches the full OT segment. Ask the implementer to show how each path is segmented and how access is revoked on both sides.
Does using NetBird Cloud or a managed OpenZiti service change where data sits?
Yes. A managed service runs the control plane and often the relays outside your infrastructure, so you must confirm where controller, relay and log data is stored and who operates it. NetBird's pricing page offers a cloud plan, while self-hosting keeps the management, signal, relay and STUN components inside your environment. OpenZiti's README states the whole platform can run on your own infrastructure, and NetFoundry offers a managed, globally distributed network with SLAs and enterprise support. For plants with data residency or customer contract constraints, ask which components the managed option hosts, which logs leave your network and how those logs are retained. Confirm these answers in writing with the vendor before you choose.
Which NetBird edition limits affect posture checks and logging?
The edition you pick determines whether you get SSO-backed team controls, device posture and traffic logs, so check this before you budget. On NetBird's pricing page, the Team plan adds SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging. The Business plan adds device approvals, MDM and EDR device controls, posture checks and traffic logging and streaming. Pricing is listed at 6 euros for Team and 12 euros for Business per user per month, with 100 machines included in the Business plan and extra machines at 0.50 euros, and billing counts only active users and machines. Plant engineering laptops and HMIs may count as machines, so model device counts early. Confirm which features apply to self-hosted editions, since the pricing page covers the cloud plans.
Questions to put to an implementation partner for plant access
Start with the zone model. Ask the partner how they map plant zones and conduits to the IEC 62443 concepts of zones, conduits and security levels, and which ISA/IEC 62443 parts they use as the basis for the design, including ANSI/ISA-62443-3-2-2020 for the risk assessment of the system design and ISA-62443-3-3-2013 for system security requirements and target security levels. Ask where the OpenZiti controller, the edge routers and any NetBird management and relay components will sit, which zone each one belongs to, and who holds administrative access to them. Then ask who patches each component, on what cadence, and how a patch to a router in the DMZ is tested against the plant's change control before it reaches production. A partner who cannot answer these by zone and by component is not ready to design a plant network. Next, ask how the design handles an OT vendor who needs access during a planned shutdown. Ask how the partner issues time-limited identities to that vendor, binds them to named devices and specific services, and removes them when the shutdown window closes. Ask how revocation is tested, since the OpenZiti README states that revoking access terminates active connections immediately, and confirm that this has been demonstrated on the plant's own services rather than assumed. Also ask what happens if the WAN link drops mid-session, and whether local operators can still reach the controller and historian from inside the plant. The answer should be written down and rehearsed before the vendor ever connects. Finally, ask for proof and regulatory support. Request a test method that shows no inbound firewall rule was added at the plant boundary, such as an external scan of the public address space and a firewall rule export compared against an agreed baseline, repeated after each change. Ask for the evidence package in writing: diagrams, rule baselines, identity inventories, session logs and test results. For the EU Machinery Regulation, ask how the partner will help document the argument that connecting a remote device does not lead to a hazardous situation under Annex III, 1.1.9, which applies from 14 January 2027, and confirm with your own safety engineers which parts of that argument belong to the machine builder and which to the plant.
