How should security teams handle access when onboarding users after an acquisition?

Why This Matters for Security Teams

Acquisition onboarding is rarely just an HR exercise. It creates a short period where two identity ecosystems, two device standards, and often two security cultures overlap. If access is granted too broadly during that window, inherited permissions can outlast the integration effort and become a permanent risk. NIST guidance on access control and account management, including the NIST SP 800-53 Rev 5 Security and Privacy Controls, is useful here because it frames access as something that must be governed, not assumed.

The practical issue is that post-acquisition users often arrive with working credentials, local device trust, and business pressure to be productive immediately. That combination encourages shortcuts: shared groups, temporary exceptions, or blanket VPN access. Those decisions can expose internal systems before logging, conditional access, and ownership mappings are stable. In practice, many security teams encounter excessive privilege only after a merger-related incident review, rather than through intentional access design.

How It Works in Practice

The safest approach is staged onboarding with explicit trust checkpoints. Start by establishing identity assurance, confirming the source of truth for the user record, and mapping the new joiner to a business sponsor or role owner. Next, gate access by sensitivity level rather than by department label. Low-risk collaboration tools may open first, while production systems, finance applications, and administrative interfaces remain blocked until device posture, authentication strength, and logging are verified.

For teams managing privileged or automated access, the acquisition period is also a good time to inventory non-human identity relationships. Inherited service accounts, API keys, and integration tokens can create hidden pathways into the environment, so NHI governance should be checked alongside user provisioning. The OWASP Non-Human Identity Top 10 is a strong reference point for finding those weak spots.

• Use conditional access to require compliant endpoints before production access is allowed.
• Assign temporary, time-bound access instead of standing entitlements during the transition period.
• Separate identity verification from network reach, and avoid using VPN membership as a proxy for trust.
• Review inherited privileged groups, shared mailboxes, and application roles before broad enablement.
• Log every exception with an owner, expiry date, and revalidation step.

Where the onboarding path touches finance, customer due diligence, or regulated data workflows, align the identity process with KYC and AML expectations. That matters when acquisition staff interact with customer-facing systems, payment processes, or controlled records, and the FATF Recommendations - AML and KYC Framework help anchor the accountability model. These controls tend to break down when the acquired company’s directory, endpoint estate, or application owners remain unmapped, because no one can reliably tell which access is temporary versus permanent.

Common Variations and Edge Cases

Tighter onboarding controls often increase friction, requiring organisations to balance rapid productivity against the risk of overexposure. That tradeoff becomes sharper when the acquisition includes remote staff, contractors, or regions with different legal and employment requirements. Best practice is evolving, but there is no universal standard for whether all acquired users should be re-verified immediately or only when they request access to sensitive systems.

Some environments can phase users in quickly because they already rely on centralized identity, unified endpoint management, and strong conditional access. Others cannot, especially when the acquired company uses legacy directories, unmanaged devices, or hard-coded application permissions. In those cases, security teams should treat the first 30 to 90 days as a controlled risk window and use session-scoped access, targeted reviews, and short expiry periods. For high-trust admin paths, ZSP principles are more reliable than broad network access. When the acquisition is large, cross-border, or heavily regulated, access policy should be tied to the system’s actual sensitivity rather than to org-chart assumptions.

Related resources from NHI Mgmt Group

• How should security teams handle third-party access that looks legitimate after a supplier breach?
• How should security teams handle onboarding access delays in IAM programmes?
• How should security teams handle VPN users without blocking legitimate access?
• How should security teams govern access when two companies keep separate identity providers after an acquisition?