What happens when acquired users and applications are granted access before they are properly vetted?

Unvetted access can create immediate exposure to insider misuse, accidental misconfiguration, and unauthorized use of parent-company data. Temporary access for contractors, vendors, or subsidiary staff is especially risky when it is not paired with MFA, remote login controls, and clear approval rules. In M&A, speed without verification usually turns into privilege creep and avoidable breach potential.

Why This Matters for Security Teams

Acquired users and applications often arrive with inherited access paths, unclear ownership, and credentials that were never designed for a parent-company environment. That makes pre-vetting access a governance failure, not just an administrative shortcut. In mergers and acquisitions, the first days are usually dominated by continuity pressure, but the attack surface grows fastest when identity controls lag behind business integration. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any acquisition that depends on unknown application identities. Ultimate Guide to NHIs also shows how often excessive privileges and weak offboarding turn temporary access into lasting exposure.

Security teams get this wrong when they treat onboarding as a paperwork step instead of a risk decision. An acquired vendor tool, shared admin account, or migrated service can quickly become a bridge into sensitive data if it is connected before its purpose, owner, and privilege level are validated. Guidance from OWASP Non-Human Identity Top 10 reinforces that non-human accounts need lifecycle control from the start, not after integration is already live. In practice, many security teams encounter breach conditions only after inherited access has already been used, rather than through intentional approval.

How It Works in Practice

The safest acquisition pattern is to assume every inherited identity is untrusted until proven otherwise. That means separating business continuity from entitlement approval: allow only the minimum access needed to keep critical operations running, then verify each user, service account, API key, and application dependency before broader access is granted. The review should cover ownership, data sensitivity, MFA requirements, remote access constraints, and whether the account is human, machine, or shared. Where the environment includes automation, current guidance suggests treating workload identity as the primary control point and using short-lived credentials instead of long-term secrets.

A practical vetting workflow usually includes:

• inventorying all acquired identities and applications, including dormant accounts and embedded secrets;
• mapping each identity to a named owner, function, and business justification;
• revoking standing access that is not required for immediate operations;
• reissuing credentials through controlled channels rather than trusting inherited passwords or keys;
• reviewing logs for pre-close activity and unusual post-close use.

This is especially important for service accounts and APIs because their access is often broader than the business owner realises. NIST control guidance on account management and least privilege supports this approach, and NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control structure security teams can map to during remediation. These controls tend to break down when inherited systems depend on hard-coded credentials in production pipelines because the business insists on uptime before the credential estate has been cleaned up.

Common Variations and Edge Cases

Tighter vetting often increases integration time and business friction, so organisations have to balance speed against exposure. That tradeoff is most visible when a deal includes customer-facing services, regulated data, or operational technology that cannot simply be shut off while identities are reviewed. Best practice is evolving, but there is no universal standard for how much temporary access is acceptable in the first 24 to 72 hours after close.

Two edge cases matter most. First, third-party contractors and subsidiary staff may need limited access before full diligence is complete, but that access should be time-boxed, logged, and tied to explicit approval rules. Second, acquired applications may carry service accounts that look dormant but still authenticate to production systems. NHIMG data shows that 92% of organisations expose NHIs to third parties, which makes inherited access especially dangerous when partner connections are not revalidated. For deeper context, 52 NHI Breaches Analysis is useful because it shows how quickly identity weaknesses become operational incidents. Ultimate Guide to NHIs — Key Challenges and Risks also helps teams compare these risks against broader lifecycle failures. The hardest cases are legacy environments where access is embedded in code or shared admin practice, because those environments resist clean vetting and revocation.

Related resources from NHI Mgmt Group

• How should security teams structure access reviews when they need the same certification workflow across applications, groups, and users?
• What breaks when organisations cannot verify users before access is granted?
• How should organisations modernise access to legacy on-prem applications without creating more identity silos?
• Why do RAG agents need role-based and attribute-based access control when they use enterprise data?