What breaks when organisations manage identity separately across multiple business units and platforms?

Why This Matters for Security Teams

Managing identity separately across business units and platforms creates more than administrative overhead. It fragments trust decisions, so the same service account, API key, or workload can be treated differently depending on where it is used. That undermines least privilege, slows incident response, and makes revocation unreliable when ownership is split. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why separate identity stacks so often become blind spots rather than safeguards.

The practical failure mode is consistency collapse. One platform may rotate secrets automatically while another leaves long-lived credentials in code or configuration. One team may require approvals for privilege changes while another provisions access directly into local tooling. When those patterns coexist, audit evidence becomes hard to reconcile and offboarding depends on tribal knowledge instead of policy. Current guidance from NIST Cybersecurity Framework 2.0 and the NHI lifecycle perspective in NHI Lifecycle Management Guide both point toward centralized visibility and lifecycle control. In practice, many security teams discover the drift only after a stale secret, duplicate account, or overprivileged token has already been used in production.

How It Works in Practice

The technical issue is not simply that identity lives in multiple tools. It is that identity becomes non-portable, and each platform starts to define its own source of truth. That creates mismatched account lifecycles, inconsistent RBAC mappings, duplicated secrets, and different revocation paths for the same workload. For NHIs, the problem is sharper because the identity is often embedded in automation, pipelines, and service-to-service calls rather than tied to a human approval workflow.

A better operating model is to standardise the identity primitive while allowing local enforcement. Teams should aim for one authoritative lifecycle policy, one inventory view, and one credential posture across cloud, SaaS, and on-premise systems. The NIST SP 800-53 Rev 5 Security and Privacy Controls framework supports this through access control, account management, and auditability expectations. For NHIs, that means:

• centrally registering every service account, API key, certificate, and workload identity;
• assigning a single owner and system of record for each identity;
• issuing short-lived credentials where possible instead of reusing static secrets;
• enforcing rotation, offboarding, and revocation through the same process across platforms;
• logging entitlement changes so discrepancies can be detected quickly.

This is especially important where a shared workload authenticates to multiple data stores or deployment platforms, because a local exception in one environment can become a persistent backdoor elsewhere. The strongest programmes treat access as a lifecycle problem, not an account-management problem, and they align lessons from the 52 NHI Breaches Analysis with the operational controls in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. These controls tend to break down when business units insist on separate admin domains, because revocation, ownership transfer, and privilege review stop being synchronised.

Common Variations and Edge Cases

Tighter central control often increases integration overhead, requiring organisations to balance standardisation against the reality of legacy platforms and regulatory boundaries. That tradeoff matters because not every environment can be migrated to a single identity plane quickly, and some systems will continue to require local accounts or isolated admin roles. Best practice is evolving, but the current guidance suggests treating exceptions as temporary and explicitly governed, not as a second normal.

Common edge cases include mergers, multi-cloud estates, and vendor-managed platforms where identity delegation is partially outside direct control. In those cases, separate identity stacks may be unavoidable, but they should still feed one inventory, one review cadence, and one offboarding process. The biggest mistake is letting local convenience override enterprise revocation discipline. NHIMG’s research on the Top 10 NHI Issues and its broader Regulatory and Audit Perspectives shows that fragmented ownership usually becomes visible during audits, incidents, or failed deprovisioning. The practical test is simple: if a team cannot answer who owns an identity, where it is used, and how fast it can be revoked, the environment is already operating with hidden risk.

Related resources from NHI Mgmt Group

• How should security teams manage role-based access for mixed identity populations across multiple countries and business units?
• What breaks when identity support content is scattered across multiple platforms?
• What breaks when authorization is fragmented across identity, API, and data platforms?
• Why do identity and device management platforms matter more as organisations scale across global teams?