What breaks when M&A onboarding relies on VPN access alone?

Why VPN Alone Breaks the Onboarding Model

VPN is a transport control, not a full access governance model. In M&A onboarding, that distinction matters because the business problem is not only getting people connected, but deciding what they may reach, on which device, under which trust level, and for how long. Without those controls, the acquisition can inherit connectivity faster than it inherits control.

VPN also tends to flatten risk by making remote users look like they are simply “inside.” That can hide differences between employees, contractors, third parties, and newly acquired users, even though those groups need different entitlements, device checks, and approval paths. The result is fast network reach with weak access precision.

What Control Gaps Appear First

The first gap is scope. A VPN may provide network connectivity, but it does not reliably restrict application-level authorization, sensitive data paths, or privileged functions. If onboarding stops at the tunnel, users can often reach more than they should, while the organisation still has to solve authorization separately.

The second gap is trust in the endpoint. A network login does not prove that the device is managed, patched, encrypted, or free of malware. NIST SP 800-207 Zero Trust Architecture is a useful counterpoint here because it treats network location as insufficient and pushes verification closer to the resource.

The third gap is revocation. In acquisitions, onboarding often gets attention before offboarding, access review, and role correction. That creates dormant paths, inherited entitlements, and accounts that remain useful long after the initial migration window closes. Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics both reinforce that provisioning and deprovisioning discipline matter as much as connectivity.

Why M&A Makes VPN-Only Access Especially Fragile

M&A environments compress timelines. Security teams are often asked to connect many users quickly while integrations, role mapping, and application rationalisation are still unsettled. That pressure encourages temporary exceptions that later become permanent, especially when the VPN is treated as the onboarding finish line.

The fragility grows when acquired users bring their own credentials, local device posture, and legacy access patterns. A VPN can bridge networks, but it cannot by itself unify identity policy, application entitlement, or credential lifecycle. In practice, that means one inherited tunnel can become the common path into many systems, even where business roles have not yet been reconciled.

That is why remote access should be built around identity and session control rather than network reach alone. NHIMG’s Remote Access Identity Guide is directly aligned to this problem because it frames VPN risk, MFA, device posture, and third-party access as separate decisions, not one bundled control.

Risk and Threat Considerations

VPN-only onboarding creates a broad attack surface because any weakness in credentials, endpoint trust, or inherited privileges can turn a temporary access path into a durable foothold. In acquisition scenarios, attackers also benefit from the confusion between legitimate migration activity and malicious access, which can delay detection.

Failure mechanism: A user authenticates to the VPN, then reaches internal resources without application-specific restriction, device validation, or timely access review. If credentials are stolen or an endpoint is compromised, the tunnel becomes a high-trust path into multiple systems.

Impact: The organisation can inherit lateral movement risk, over-privilege, delayed revocation, and visibility gaps at the exact moment when identity boundaries are already changing. That makes the acquisition period attractive for abuse and hard to unwind cleanly.

Practitioner Guidance

What to prioritise: Treat VPN as one access method, not the onboarding control plane. The first priority is to define which applications, data sets, and administrative functions are reachable by newly acquired users, and to separate that from mere network connectivity.

What to verify: Confirm that every acquired user has an explicit access path, a named owner, a device trust requirement, and a revocation route. If the only control you can point to is “they can connect,” the onboarding model is incomplete.

Common mistake: Using the VPN to prove integration success before identity governance is ready. That shortcut usually creates cleanup debt in access reviews, role mapping, and offboarding.

Practitioner takeaway: The real question is not whether the acquired workforce can get in quickly, but whether the organisation can still control, narrow, and revoke what they can do after they are in.

Related resources from NHI Mgmt Group

• What breaks when crypto onboarding relies too heavily on document checks alone?
• What breaks when a blockchain platform relies on onboarding alone for trust and compliance?
• What breaks when onboarding relies on static form data alone?
• What breaks when cloud access relies on authentication alone without API and account control?