Should organisations merge human IAM and NHI governance after a major acquisition?

They should align the operating model, but not collapse the controls into one undifferentiated process. Human authentication, NHI lifecycle control, and agentic access risk have different evidence, ownership, and review rhythms. The right move is a shared identity governance layer with actor-specific policy, not a single review template for every identity type.

Why This Matters for Security Teams

After a major acquisition, identity teams often inherit two different risk models at once: human IAM built around people, and nhi governance built around secrets, service accounts, workload tokens, and automated access paths. Treating them as one population usually creates false consistency. The operational goal is not a single process, but a shared governance layer that can still distinguish authentication, authorization, evidence, and review cadence by actor type.

This matters because acquired environments rarely arrive with clean inventory or consistent ownership. NHI exposure is often already present in legacy automation, CI/CD, integrations, and cloud platforms before the integration programme begins. NHIMG’s The 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of non-human identities, which shows how quickly inherited NHI risk can become a post-close incident. NIST CSF 2.0 also reinforces that identity is a governance problem, not just an authentication problem, which is why the operating model must be deliberate, not merged by default.

In practice, many security teams discover the mismatch only after an acquisition’s first access review produces either false approvals for machines or endless exceptions for people.

How It Works in Practice

The most workable approach is to unify the identity governance layer while preserving separate control paths for humans, NHIs, and autonomous agents. That means one catalog, one ownership model, one evidence standard, and one risk register, but different policy logic for each actor class. Human identities usually need HR-linked joiner-mover-leaver controls, MFA, and periodic access recertification. NHIs need inventory, secret and certificate lifecycle control, workload identity, and short-lived credentials. Agentic systems need runtime policy checks because their tool use and task chains are not fully predictable.

For acquired estates, start with discovery and classification. Map service accounts, API keys, certificates, bots, scripts, and agent runtimes into an authoritative inventory, then assign each identity to a human owner and a business service. This is where current guidance suggests using Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs to separate lifecycle controls from human recertification routines. For technical control baselines, align to NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement, logging, and accountability.

• Keep one governance dashboard, but tag records as human, NHI, or agent.
• Use RBAC for people where roles are stable, but use workload identity and JIT issuance for machine access.
• Require owner attestation for every NHI, not manager attestation.
• Separate review cadences so ephemeral tokens are not reviewed like employee accounts.

For agentic workloads, policy should be evaluated at request time, not only at onboarding, because static entitlement models do not predict tool chaining, lateral movement, or task escalation. These controls tend to break down when the acquired environment has hundreds of unmanaged service accounts and no reliable mapping from credentials to business service.

Common Variations and Edge Cases

Tighter consolidation often increases migration overhead, requiring organisations to balance cleaner governance against integration speed. That tradeoff is real after an acquisition, especially when multiple IAM stacks, cloud tenants, and directory forests must be rationalised quickly. Best practice is evolving, but there is no universal standard that says humans and NHIs should share the same review workflow.

A common edge case is M&A due diligence that identifies a mature human IAM programme but almost no NHI inventory. In that situation, collapsing everything into one workflow usually hides the absence of machine ownership. Another edge case is regulated environments where human access recertification is already evidence-heavy, while NHI control evidence is cryptographic or runtime-based. Those records should be reconciled in the same governance system, but not forced into the same template. NHIMG’s Top 10 NHI Issues is useful here because it frames the governance gaps that appear when teams try to manage secrets, certificates, and workload identities as if they were employee accounts.

For agentic deployments, the edge case is even sharper. Current guidance suggests using shared policy intent with actor-specific controls, but not every organisation can yet enforce runtime authorisation consistently across legacy and cloud systems. If the acquired estate cannot distinguish a human admin session from an autonomous workload session, the safer interim step is to unify reporting and ownership first, then standardise controls in phases.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Should IAM teams re-evaluate their NHI tooling choices after a major acquisition?
• When should organisations separate human IAM from NHI governance?