The common mistake is treating due diligence as a paperwork exercise rather than an operational identity review. Documentation matters, but it is not enough on its own. Teams also need validation through targeted recon, access inventory review, and clear decisions about which systems and identities are actually in scope for integration.
Why This Matters for Security Teams
Acquisition due diligence is where identity risk gets inherited, not just disclosed. Security teams often focus on contracts, SOC reports, and policy binders, but the operational reality sits in service accounts, API keys, OAuth grants, CI/CD tokens, and shadow integrations that never appear in a board deck. NIST’s NIST Cybersecurity Framework 2.0 treats governance, identification, and protection as connected functions for a reason: if the acquired environment cannot be inventoried, it cannot be safely integrated.
This matters even more for non-human identities because their blast radius is usually larger than a human user’s and their lifecycle is less visible. NHIMG’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and 97% carry excessive privileges. That means the acquisition team is not just evaluating an asset base, but an identity fabric that may already be overextended, misconfigured, or externally exposed. In practice, many security teams encounter the first true identity crisis only after integration has begun, rather than through intentional pre-close validation.
How It Works in Practice
Effective due diligence starts with operational recon, not documentation review. Teams should identify where identities actually live, what they authenticate to, which third parties can use them, and whether the credentials are static or actively rotated. The goal is to separate verified control from asserted control. A mature review also checks whether the target organisation has a reliable inventory of service accounts, machine credentials, and delegated access paths, because integration decisions depend on that inventory being real.
Current guidance suggests four practical steps:
- Map all non-human identities, including service accounts, workload identities, API keys, OAuth apps, and CI/CD secrets.
- Validate privileged access paths, especially shared admin accounts, broad token scopes, and dormant integrations.
- Test rotation and revocation processes, not just policy wording, to see whether credentials can actually be removed on demand.
- Determine integration boundaries early, so the acquiring team knows which systems and identities must be quarantined, reissued, or rebuilt.
The Ultimate Guide to NHIs is clear that only 5.7% of organisations have full visibility into their service accounts, which explains why many acquisitions inherit unknown access rather than controlled access. That is why due diligence should include targeted recon such as secret discovery, access inventory sampling, and outbound integration testing, not just interviews with the target’s IT leadership. The operational question is whether the buyer can prove what exists before it trusts what is documented. These controls tend to break down in fast-track acquisitions where production access is federated before the inherited identity estate is fully mapped.
Common Variations and Edge Cases
Tighter identity diligence often increases deal friction and closing timelines, requiring organisations to balance acquisition speed against containment risk. That tradeoff is unavoidable when the target uses heavy SaaS integration, outsourced development, or shared cloud tenants, because identity boundaries are less obvious and revocation is harder to prove. Best practice is evolving here, and there is no universal standard for how deep pre-close identity testing must go.
Some deals justify a phased approach: clean systems can be integrated first, while high-risk environments remain isolated until secrets are rotated and privileged access is revalidated. Others require a harder stance, especially when third-party OAuth exposure or long-lived secrets are embedded in source code and automation. The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly the kind of exposure that makes acquisition scope creep dangerous. Security teams should treat unknown identities as an integration blocker, not as a post-close cleanup item.
Edge cases also appear when the target claims to have “zero trust” controls but cannot demonstrate revocation, auditability, or ownership for machine credentials. In those environments, the control failure is usually not the technology itself but the absence of accountable identity stewardship across business units, DevOps, and third parties.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Acquisition due diligence must inventory and validate non-human identities before integration. |
| NIST CSF 2.0 | GV.RM-03 | Due diligence is a risk decision that should reflect validated identity exposure. |
| NIST AI RMF | Operational validation supports AI risk governance when acquired environments include automated systems. |
Use acquisition findings to update risk acceptance, remediation priorities, and integration gates.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
