Merger network access with open source zero trust

Zero trust access after a merger: giving acquired staff app access before the networks join

When a deal closes, acquired staff often need a handful of internal applications on day one, yet the two networks cannot be joined until addressing and directories are sorted out. The practical answer is to give those people identity-based access to selected apps through an overlay or proxy that sits outside the network merge, and to keep the two sides segmented until the integration plan says otherwise. Overlays such as NetBird or OpenZiti provide network-level reach to specific hosts, while Pomerium fits web applications that can sit behind an identity-aware proxy. This is different from a standard VPN replacement because the two sides may use overlapping IP ranges, two separate identity providers, and two sets of device controls, so a design that assumes one flat address space and one directory will fail at the first connection attempt. Confirm the acquired company's address plan, its identity provider and its device management before choosing a pattern.

The regulatory clock matters as much as the technology. Under SEC staff guidance, management may exclude a newly acquired business from its internal control assessment for a limited period, but not beyond one year from the acquisition date and not from more than one annual report, and the exclusion must be disclosed. Access granted during that window still needs to be documented as part of IT general controls over access to programs and data, so keep a register of who was granted which application and why. For EU entities, NIS2 requires notifying the competent authority of changes to registered details, including IP ranges, without delay and in any event within two weeks. Ask counsel and your compliance lead to confirm which of these clocks apply to the acquired entity, then map each new IP range or service to a named owner so notifications are not missed.

Keep the two sides apart while access is being granted. Publish only the specific services an acquired user needs, use a dark service model where the application accepts no inbound connections, and write policies that reference identity groups from the acquirer's provider rather than from the target's network. Log every grant and session, and decide in advance which team approves changes. The segmentation boundary should stay in place until the integration plan joins the networks, so that a compromised laptop on one side cannot reach the other side's flat network. Confirm with each vendor where its control plane and relays run, since an EU target may need EU-only processing and any remote access by a non-EEA party to EU personal data may count as a transfer under the EDPB guidance on Chapter V of the GDPR.

Which regulatory and operational requirements shape the merger access design

This table maps each regulatory requirement that touches access to an acquired network to what it means for the build, such as IP mapping, separate identity sources, per-user logging and transfer tooling. Read it before fixing the order of network joins, because several requirements set deadlines or preconditions that the technical plan must meet.

Requirement	What it asks for	What it means for the merger build
SEC ICFR exclusion (SEC FAQ Question 3, Release 33-8810)	Management may exclude a newly acquired business from its internal control assessment for up to one year, and must disclose the exclusion. IT general controls cover program changes and access to programs and data where they address financial reporting risk.	Treat acquired-staff access to finance systems as an in-scope access control from day one. Map which applications feed financial reporting and keep their access logs and approvals separate from the acquirer's own records.
Form 8-K Item 1.05 and third-party oversight (17 CFR 229.106)	Material cybersecurity incidents are disclosed on Form 8-K, generally within four business days after materiality is determined. Annual reports describe oversight of third-party service providers.	Log every session on the overlay or proxy with user, device and application so incident scope can be established quickly. Name the integration vendor and any hosted control plane in the third-party oversight record.
NIS2 Article 3(4) (Directive (EU) 2022/2555)	Essential and important entities give their competent authority their name, contact details, IP ranges, sector and service Member States, and report changes without delay and within two weeks at most.	Overlapping IP ranges change when networks are renumbered or joined. Update the registered IP ranges within two weeks of each change, so the IP inventory must be kept current during the merger.
DORA Article 28 register and exit strategy (Regulation (EU) 2022/2554)	Financial entities keep a register of all ICT service arrangements, and tested exit strategies and transition plans for services supporting critical or important functions.	Record the self-hosted overlay, proxy and identity components as ICT services. Document how acquired users would move off the bridge once networks are joined, and test that exit path.
GDPR Article 28(3)(a) and EDPB Guidelines 05/2021	Processors act only on documented controller instructions, including on transfers. Remote access from a third country to EU personal data, including for support, is a transfer that needs a Chapter V tool.	Before a non-EEA acquirer's staff reach EU target systems through the overlay, confirm the transfer mechanism and the documented instructions. Restrict access to named applications and exclude bulk data paths.
HIPAA 45 CFR 164.312 access control and audit controls	Unique user identification, audit controls that record and examine activity on systems with ePHI, person or entity authentication, and transmission security.	Do not allow shared accounts for acquired staff. Issue each person an identity from the chosen source, and make per-user logs retain the application and session detail an auditor would examine.
FTC Safeguards Rule 16 CFR 314.4(c)	Multi-factor authentication for any individual accessing any information system, encryption of customer information in transit and at rest, and monitoring and logging of authorized user activity.	Require MFA at the overlay or proxy for acquired users, including those authenticated through the acquired identity provider. Log each user's activity and confirm the encryption path between both sides of the bridge.
Segregation during integration (operational requirement)	No single regulation names this, but auditors and risk teams expect acquired and acquirer networks to remain separated until controls are verified.	Use dark services and per-application policies so acquired staff reach only listed apps. Confirm with the risk team which zones may connect before any routing between the two networks is opened.

How overlapping IP ranges change the overlay design

Two networks that both use RFC 1918 space, such as 10.0.0.0/8 or 192.168.0.0/16, cannot be joined by simply adding a route, because a packet addressed to 10.20.4.15 is ambiguous when both sides own that address. Routers on either side will deliver it to their own local host. An overlay avoids this by giving each peer its own addressing inside the overlay, independent of the addresses on the underlying networks. NetBird, for example, runs a WireGuard mesh with its own overlay addresses per peer, and routes to external networks are declared explicitly. This lets acquired staff reach a chosen set of hosts while the two address plans stay untouched. The reader should confirm, for each candidate platform, how overlay addresses are assigned, whether a route can be advertised for a range that already exists on the other side, and how that conflict is resolved in the admin console before any pilot begins.

A proxy takes a different approach. Pomerium, or an OpenZiti service published through an edge router, presents only named applications, so the acquired user never receives a route into the target's network at all. Address overlap then matters only for the back end the proxy connects to, which the proxy's own network can reach. The trade-off is reach against scope. An overlay gives broad network access that can be narrowed with groups and rules, but it places the acquired device on a shared fabric and requires careful route and DNS planning. A proxy keeps the blast radius small and is usually the safer first step for a limited list of applications, but every application needs its own route and policy. Choose the pattern per application group, not once for the whole deal.

Address plans also become compliance evidence. NIS2 entities must give their competent authority their IP ranges, along with their name, contact details, sector and Member States of service, and must notify changes without delay and in any event within two weeks (Directive (EU) 2022/2555, Article 3(4)). When an acquired entity is in scope, its ranges and any overlay address pools must be recorded and kept current as the integration proceeds, and each overlay route that bridges the two sides should be traceable to a documented decision. Ask the integration team to produce a single address register covering both estates, the overlay pools, the proxy routes and the owner of each, and to confirm with counsel which notification obligations apply to each entity and when the clock starts.

Which platforms fit a merger bridge and why

A merger bridge needs access to a few applications for acquired staff before the two networks can be joined, so the platform should reach selected services without merging address spaces. The options below differ in how much network they expose, how they handle identity and how the control plane is licensed. Confirm each feature against current documentation before you commit to a design.

NetBird as a full overlay bridge

NetBird builds a WireGuard overlay with groups and access rules, so acquired staff can reach specific subnets or hosts while the two address spaces stay separate. SSO and SCIM provisioning are listed on the Team plan, and device posture checks and traffic logging on Business. A self-hosted deployment runs management, signal, relay and STUN from one combined configuration, and the server components are licensed under AGPLv3, which your legal team should review. A route to a subnet grants network-level reach, so restrict routes to the applications the bridge actually needs.

OpenZiti for dark services

OpenZiti authenticates every connection with a cryptographic identity and authorizes it through policy, so the target service can have no open inbound ports. Private edge routers connect outward, and revoking an identity ends active sessions. Tunnelers can front unmodified software on hosts, while SDKs embed the identity check in an application you control. The platform is licensed under Apache 2.0, but the operating model is heavier than a plain overlay, and teams should confirm which deployment model fits each target before the first bridge goes live.

Pomerium for browser app access

Pomerium places an identity-aware proxy in front of selected web applications, so acquired staff reach the apps they need from a browser without installing a network client. Access rules apply per route and tie to the identity provider of the target or an agreed federation. It suits a short list of internal web tools, but it does not carry SSH, RDP or non-HTTP protocols in the same way an overlay does, so confirm protocol coverage for each application in your inventory.

Identity provider federation at the edge

Each bridge depends on how acquired staff authenticate, because the two identity providers rarely agree on groups, MFA methods or device state at the start. Map acquired users to access groups in the overlay or proxy, and decide whether to federate the providers or issue temporary accounts. Confirm that the chosen platform can consume your provider's SAML or OpenID Connect claims and which group fields it reads, since group mapping errors are the most common cause of over-broad access.

Segmentation between the two sides

Merger bridges tend to become permanent if nobody sets the boundary. Write explicit rules that allow acquired users into named applications and deny the rest of both address spaces, and log every grant for the integration period. Overlapping IP ranges also need a translation or naming plan so that a route does not silently point to the wrong network. Test the policy with a sample of acquired accounts before you announce access, and record the rules as evidence for your integration review.

Licensing and control plane location

The control plane holds the identity map, the policies and the coordination state of the bridge, so where it runs matters to the acquirer and the target. NetBird server components are under AGPLv3 while its client repository is BSD-3-Clause, and OpenZiti is under Apache 2.0 and can run on your own infrastructure. Ask the platform owner which editions are self-hostable, whether a managed service would hold target data, and what licensing obligations apply if you modify the server code.

Deployment patterns for the two sides during integration

Start with the smallest surface: internal web applications that acquired staff need on the first day. An identity-aware proxy sits in front of each app, checks identity and policy on every request, and forwards only what the policy allows. No network route is joined, so overlapping IP ranges between the two companies do not block access.

Identity brokering: The proxy trusts an OpenID Connect identity provider. Decide whether the acquirer's IdP is trusted directly or brokered through a self-hosted IdP such as Keycloak, so the target's apps accept acquired logins without copying accounts.
Group-based routes: Write route policies against groups synced from the acquirer's directory. Confirm whether the proxy reads group claims from tokens or needs a separate provisioning step.
SIEM logging: Every request is logged with user, route and outcome. Forward these logs to the existing SIEM, such as Wazuh, and confirm the field mapping before go-live.
Control plane: Your team runs the proxy and the IdP in your environment. Confirm who holds administrative access to the proxy configuration and session keys.
EU and regulated data path: Application traffic passes through the proxy in the environment that hosts the app. If non-EEA acquirer staff view EU personal data, that remote access is a transfer under EDPB Guidelines 05/2021, so a Chapter V transfer tool is required.

Check which apps set their own session cookies or rely on client certificates, because these can conflict with a proxy in front of them.

Rollout phases and the output of each

This sequence moves an acquired workforce onto selected internal apps through an overlay or proxy before the two networks are joined, while each side stays segmented. Every phase closes with a named artifact that the next phase depends on, so the integration can be reviewed and reversed at known points.

Inventory address plans, identities and applications
Collect the IP ranges, DNS zones and cloud accounts from both companies, along with the identity providers, directories and the applications that acquired staff need. Overlap in address space is recorded here, not solved yet. Owners of each application confirm which users, groups and data classes are in scope. The output is a signed-off address map and an application inventory with an owner and a data classification for each entry. The step is done when both sides have approved the map and no application is listed without an owner.
Place the control plane and broker identities
Decide where the overlay controller or proxy runs, which jurisdiction hosts it, and where its relays and logs sit. Connect the acquired identity provider to the access layer through federation or a brokered login, so that group membership becomes the basis for access rules. Confirm with each provider that the control plane can be self-hosted in the environment you choose. The output is a placement decision record and a tested login from an acquired user to the access layer. Done means a test account from each side authenticates and receives no access beyond its group.
Export the initial policy set
Translate the approved inventory into access rules: which group reaches which service, over which route, and under which device conditions. Keep rules at the level of a named application rather than a whole subnet. Review the rules with the application owners and both security teams before anything is enabled. The output is a policy export stored under version control, with each rule linked to its owner and approval. The step is done when the export can be reproduced from source and the reviewers have signed the change.
Run a pilot with a small acquired group
Enable access for a limited group of acquired staff to a short list of applications, and keep the rest of the network closed to them. Watch authentication failures, latency, and any application that assumes a flat network or a specific source address. Record each finding and whether it was fixed, accepted or sent back to the policy export. The output is a pilot test record listing each user path tested, the result, and the defect or exception raised. Done means the pilot group reaches its approved applications and cannot reach anything else.
Expand access one application at a time
Add applications in batches, each with its own rule change and its own rollback plan. Do not widen a rule to a whole network to make an application work; instead, adjust the application or the route. Confirm that revoking a user's group membership removes access and ends active sessions. The output is a change log entry for each batch, showing the rule added, the approver, the test result and the rollback step. The phase is complete when every application in the approved inventory is either live with its rule or formally deferred.
Test segmentation between the two sides
Verify that the acquired and existing networks cannot reach each other beyond the approved flows. Test from both sides using hosts in each segment, covering routing, DNS resolution, broadcast traffic and any direct paths that bypass the access layer. Include tests that try to reach services with no published rule. The output is a segmentation test record with the test cases, the expected and actual results, and the remediation for each failure. Done means every test case passes or has a documented, approved exception.
Decide the exit or consolidation path
Document whether the overlay or proxy is a bridge until the networks are joined, a long-term service, or a component to be removed later. Record the data that leaves the platform on exit, how identities and policies would be moved, and who holds the keys and backups. Where regulation applies, such as the exit strategy requirements in DORA for financial entities, confirm the plan with the compliance owner. The output is an approved exit or consolidation plan and a final change log that links every rule, test and exception to its approval. Ask the implementation partner to show how this plan will be tested before cutover.

Evidence regulators and auditors ask for after an acquisition

This table maps the evidence an assessor may request for acquired staff and networks to the component that produces it in a merged ZTNA design. Read each row as a question to answer before access is granted, not as proof that a control passes. The main takeaway is that the auditor, not DeployOpen, decides whether the evidence is sufficient, so confirm the expected format and period with them early.

Evidence	Where it comes from	Why it matters after a merger
Access policy exports and change history	OpenZiti controller or NetBird management policies, groups and rule history	Shows which acquired identities can reach which services, and when that changed during integration
Per-user activity and traffic event logs	NetBird activity and traffic logging, OpenZiti controller and edge router logs, forwarded to your log platform	Supports monitoring of acquired-user activity and reconstruction of access during the overlap period
MFA enrollment and authentication records	The identity provider that federates the acquired workforce, such as Keycloak or the acquirer's directory	Demonstrates that acquired users authenticate with MFA before reaching internal apps
Transfer impact documentation for non-EEA access	Your transfer assessment and the Chapter V transfer tool, linked to the access policy records	Remote access from a third country to EU personal data can be a transfer, so this must exist before access starts
Updated third-party register entries and exit plans	Your ICT or third-party register, updated for the acquirer's services and any new overlay or proxy provider	Shows that new service arrangements from the acquisition are recorded and that a tested exit route exists where required
IT general control evidence for in-scope systems	Change tickets, access reviews and approvals for systems that feed financial reporting	Covers how access to in-scope systems is granted and reviewed, which matters when an acquired business is excluded or included in the assessment
Segmentation and separation design records	Architecture diagrams, policy scope and documented network boundaries between the two sides	Shows the two sides stayed segmented during integration, with the basis for each allowed path

Which data moves when acquired staff connect

Before any acquired employee gets access to a target system, decide whether that access is a transfer of personal data. Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, counts as a transfer. If the acquirer's staff sit outside the EEA and can open EU customer records, HR files or ticketing data during the overlay or proxy phase, a Chapter V transfer tool must be in place before the access is granted, not after the networks are joined. Ask the acquirer's legal team which countries their staff connect from, and map each identity to a country and a system before you add it to a policy group.

Separate what the control plane sees from what the data path carries. In an overlay such as NetBird or OpenZiti, the control plane holds identities, group memberships, device attributes and access policy, and it is the component that decides who may reach which service. The data path carries the application traffic itself. With OpenZiti SDKs, the payload is encrypted application to application, so relays and routers forward ciphertext, but identity metadata and connection logs still exist at the controller. Confirm in writing where the controller, relays and logs of each deployment are hosted, which country holds the backups, and whether any vendor support staff can read the logs. Those answers determine whether the transfer analysis above is complete.

Under GDPR Article 28(3)(a), a processor may act only on the controller's documented instructions, including on transfers. If a managed ZTNA service or a partner operates the control plane for the combined company, the contract must state which entity is controller for acquired staff data, which transfers are authorized, and how instructions change during integration. Records of processing under Article 30 should describe the Article 32 security measures for the new access path. Ask the provider for its data processing terms, sub-processor list and log retention settings before the first acquired user signs in, and keep those documents with the integration change record.

How much does it cost and how long does it take to connect networks after a merger?

What drives the cost of connecting two networks after a merger?

The cost is driven by the size of the bridge, not by the license line alone. The main components are control plane hosting (servers, a public domain, certificates and backups if you self-host), the number of users and devices that need access, the number and types of applications being published (web, SSH, RDP, databases, UDP), the identity brokering work needed to trust the acquired identity provider, and the documentation that proves the bridge is scoped and logged. Hosting and staff time recur monthly, while design, app onboarding and documentation are mostly one-time. Ask any quote to split these components separately so you can see which ones scale with headcount and which with the number of applications.

Can we self-host the bridge, or do we need a managed service?

Both models are workable, and the choice depends on where you need the control plane to run. NetBird's self-hosting quickstart describes a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443 and UDP port 3478 open, and Docker with the Compose plugin. NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves, while NetBird Cloud needs no servers or domain. OpenZiti's README says the whole platform can run on your own infrastructure with no vendor dependencies. Confirm the sizing for your user count with the vendor before you commit, because the quickstart describes a starting point, not a capacity plan.

Does NetBird Cloud pricing apply to a merger bridge?

It can, if the bridge uses NetBird Cloud and your user and machine counts fit its plans. NetBird's pricing page lists Free for up to 5 users and 100 machines, Team at 6 euros and Business at 12 euros per user per month with 100 machines included plus 10 per user, and extra machines at 0.50 euros, with custom Enterprise pricing. Billing counts only active users and machines. Team adds SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging, and Business adds device approvals, MDM and EDR controls, posture checks and traffic logging. Check the current page before budgeting, because the requirements you need (SCIM, posture checks, traffic logs) decide which plan applies.

What does the work need from our IT and legal teams?

IT must supply the identity provider details for both sides, the IP ranges and DNS zones of each network, a list of applications to publish with their owners, and the device posture signals that will gate access. Legal and privacy must confirm where the control plane, relays and logs will sit, and whether any acquired staff or systems in the EU or regulated sectors create a data transfer or processor obligation. GDPR Article 28(3)(a) requires processors to act only on documented instructions, including on transfers, and EDPB Guidelines 05/2021 treat remote access from a third country as a transfer. Settle these questions before onboarding users, not after.

How long does the bridge stay in place after the merger?

The bridge usually lasts until the networks are joined or the acquired systems are retired, and its length depends on the integration plan rather than the tool. Your own rules set the upper limit: SEC staff allow a newly acquired business to be excluded from internal control assessment for no more than one year from the acquisition date, and DORA Article 28(8) requires tested exit strategies and transition plans for services supporting critical or important functions. Plan the bridge with a named end date, a review point and a retirement step for each application, so temporary access does not become permanent by default.

What changes when the integration ends?

At the end, the temporary access paths are removed and the two networks are either joined or kept segmented with a formal policy. Revoking access in OpenZiti terminates active connections immediately, and dark services stop accepting traffic once their policies are removed. Before shutdown, export the access logs and policy history, since regulators and auditors may ask for evidence of who had access and when. Confirm with the vendor how each component exports its data and how long logs are retained in your environment, because retention rules are set by your own compliance program rather than the platform.

Questions to ask an implementation partner before a merger access project

Start by asking how the partner will handle overlapping IP ranges before any tunnel is built. Ask whether they will assign overlay addresses or service names that never depend on the acquired network's numbering, and how DNS names for acquired apps will resolve for both sides. Ask where the control plane runs: a partner should state which controller, coordination or management components sit in your infrastructure, which sit in a vendor-run service, and what each one can see. For OpenZiti, the controller issues the x509 identities and defines which identities reach which services, so its location is a data-residency and continuity decision, not an implementation detail. Ask for that map in writing before scope is signed.

Ask how identities from both directories will be brokered. Good answers name the identity provider that remains authoritative for each side, how group claims from the acquired directory map to access policies, how leavers in the target are revoked from overlay access, and whether MFA enforcement is the same on both sides. Ask how the partner keeps the two sides segmented during integration: which services are dark, which routes are opened in each direction, and what happens to a connection when a policy is revoked. Ask for the exit plan too. The partner should explain how an acquired user's access is removed if the deal does not close or the networks are later joined, and how overlay configuration is exported. Confirm that the partner will document any transfer of personal data to a third country, including remote administrative access by a non-EEA acquirer's staff, and the transfer tool relied on.

Finally, ask what evidence you receive at the end of each phase. Request the access policy export, the identity mapping document, device posture settings, the logs that show who reached which application and when, and a tested revocation record. Ask which of these the partner will hand over in a form your auditors or regulators can read, and which must come from your own logging stack. Ask who holds the administrator credentials for the control plane after handover. Confirm in writing whether rollback to the previous access path is included in scope and how long it stays available during cutover. Compare the answers with the compliance mapping in your own environment, because a partner can prepare evidence but does not issue audit opinions.

How DeployOpen scopes and runs a merger access bridge

DeployOpen plans and implements self-hosted open-source access platforms inside the client's own infrastructure, so the control plane and the access bridge stay under the client's control during a merger. The work starts with a written scope that separates the short-term access bridge from the longer network join.

How we scope

Written scope names the acquired users, target applications and the two identity providers involved before any build starts.
Scope records overlapping IP ranges, the address plan for the bridge and which apps stay out of the first phase.
Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.

How we build

Deploy the chosen overlay or proxy in the client's cloud accounts or data centers, with the control plane kept on infrastructure they operate.
Configure per-application policies tied to the identity provider groups, with segmentation so the two sides cannot reach each other broadly.
Test access paths, revocation behavior and logging for each published application, and record the results before cutover.

How we hand over

Deliver architecture, network diagrams, policy inventory and runbooks covering the bridge and its address plan.
Document the exit path for each acquired application so it can move to the joined network later without rework.
Provide evidence packs for IT general control, access and logging reviews that the client's auditors can examine.

How we support

Support covers upgrades, backups and policy changes as the integration moves app by app.
Continuous security testing of the bridge, including segmentation checks, is available under a retainer.
Ask any partner to confirm who operates relays, certificates and logs after handover, and in which jurisdiction.

Connecting networks after a merger with zero trust access