How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?

Why This Matters for Security Teams

When business applications, cloud infrastructure, and data access converge, identity stops being a back-office directory problem and becomes the control plane that determines what can move, change, and be exposed. That shift matters because service accounts, API keys, and workload identities now sit at the center of both operational reliability and breach containment. NHI Management Group’s Ultimate Guide to NHIs shows how often these identities are over-privileged, poorly rotated, or hidden in code and infrastructure tooling.

The practical risk is not just excess access, but inconsistent governance. A team may secure SaaS permissions, another may harden cloud roles, and a third may govern data access, yet none of them sees the full entitlement chain. The result is duplicate approval logic, stale entitlements, and a false sense of coverage. The NIST Cybersecurity Framework 2.0 treats identity as a core governance function, but many organisations still apply it in silos rather than across the full stack.

NHIMG research in the 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which is a useful warning sign for broader identity governance as workloads converge. In practice, many security teams discover the governance gap only after over-privileged access has already been used to modify infrastructure or expose data.

How It Works in Practice

The strongest model is to govern identity as a shared layer across applications, infrastructure, and data rather than as three unrelated programs. That means each access request should answer three questions at runtime: who or what is requesting access, what resource is being requested, and under what business and technical context. The OWASP Non-Human Identity Top 10 is useful here because it emphasizes the common failure modes of secrets, rotation, and authorization drift.

In practice, organisations should build around these steps:

• Inventory all human and non-human identities, including service accounts, CI/CD identities, cloud roles, and data-layer principals.
• Classify access by resource type, then define least-privilege baselines for application APIs, cloud control planes, and sensitive data stores.
• Use a single policy decision layer where possible, so access decisions are evaluated consistently at request time instead of being hard-coded into separate tools.
• Prefer short-lived credentials and workload identity over long-lived static secrets, especially for automation that spans environments.
• Review entitlements continuously as applications move, workloads scale, and data sensitivity changes.

This is where governance moves from periodic audit to operational control. The NIST controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support this model by tying access enforcement, accountability, and configuration management together, but the implementation still has to be coordinated across platform, security, and application teams. The most mature organisations also map these controls to lifecycle processes described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs so access does not outlive the workload it was issued for. These controls tend to break down when identity data is fragmented across multiple cloud tenants and legacy applications because no single team can verify effective privileges end to end.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance speed of delivery against review depth and policy consistency. That tradeoff becomes sharper when applications, cloud infrastructure, and data platforms use different identity models or different owners.

One common edge case is third-party or partner access. Shared responsibility does not remove the need for least privilege, but it often makes entitlement review slower because each external principal may be tied to separate contracts, support processes, or data processing limits. Another is machine-to-machine access in CI/CD and infrastructure automation, where short-lived access is ideal but can be difficult to implement if tools still depend on static keys or embedded secrets. The NHIMG Top 10 NHI Issues highlights how often these patterns create hidden exposure.

For organisations already using zero trust, current guidance suggests identity convergence should be treated as an enforcement problem, not only a directory cleanup problem. That means policy needs to follow the workload across control planes and data planes, especially when data access is mediated by application service accounts or ephemeral automation. The practical goal is not perfect centralization, which is rarely realistic, but consistent decisioning and rapid revocation. In hybrid estates, the model fails when legacy systems cannot express context-aware authorization and teams fall back to standing access because it is easier to operate.

Related resources from NHI Mgmt Group

• How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?
• How do organisations build a risk-based approach to managing access across business applications?
• How should organisations apply least privilege in identity governance for cloud and infrastructure access?
• Should organisations prioritise cloud identity governance before expanding privileged access controls across applications?