What breaks when organisations separate identity governance and authorisation in cloud-first environments?

Why This Matters for Security Teams

When identity governance and authorisation are split across different tools or teams, cloud-first environments lose the connection between entitlement, intent, and enforcement. That gap is especially dangerous for non-human identities, which often authenticate through service accounts, tokens, and automation paths that change faster than review cycles. The result is not just excess access. It is uncertainty about whether access still matches the workload’s purpose.

Security teams also end up with fragmented evidence. Identity governance may show that an account was approved, while authorisation systems may still be granting access long after the original business need changed. This creates audit friction, weakens least privilege, and slows incident response. The NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs both point to the same operational reality: identity lifecycle control is not effective if access decisions are detached from runtime context.

That disconnect is visible in the data as well. In the 2026 Infrastructure Identity Survey, 70% of organisations said AI systems receive more access than human employees doing the same job, which is a warning sign for cloud environments where permissions are already sprawling. In practice, many security teams encounter this only after over-privileged automation has already touched production, rather than through intentional access design.

How It Works in Practice

In a cloud-first model, governance should answer who or what the identity is, why it exists, who approved it, and when it should be removed. Authorisation should answer whether that identity can perform a specific action right now, in this environment, against this resource, under this risk posture. When those functions are separated, reviews become stale and policy enforcement becomes inconsistent.

For non-human identities, the practical fix is to connect lifecycle governance with runtime enforcement. Current guidance suggests using workload identity as the anchor, then layering policy decisions at request time. That means short-lived credentials, tightly scoped token issuance, and automated revocation when the workload ends or changes. The NIST SP 800-53 Rev. 5 controls support this approach through access review, least privilege, and auditability requirements, while NHIMG’s lifecycle guidance for NHIs emphasises rotation, offboarding, and visibility.

• Use a single identity record for each workload, service, or agent, not separate records for governance and access.
• Issue just-in-time credentials with short TTLs instead of durable secrets that survive role changes.
• Evaluate policy at runtime so authorisation reflects the actual request, not last quarter’s approval.
• Log identity, approval, policy decision, and resource action in one evidence chain for audit and response.

This breaks down when legacy applications require static shared secrets or when cloud teams hard-code access into CI/CD pipelines, because governance cannot reliably revoke or re-evaluate what it cannot see.

Common Variations and Edge Cases

Tighter integration between governance and authorisation often increases operational overhead, requiring organisations to balance speed of delivery against control precision. There is no universal standard for this yet, especially across hybrid estates where some platforms support policy-as-code and others only support coarse IAM roles.

One common edge case is machine-to-machine traffic across multiple clouds. In that environment, a central identity governance tool may record entitlement approval, but the effective authorisation still depends on local cloud policy, service mesh rules, and token exchange behaviour. Another case is automated agents that chain tools together. Their access pattern is not fixed in advance, so static RBAC often over-grants to avoid outages. For these environments, best practice is evolving toward context-aware or intent-based authorisation, because the decision must be made from the task at hand rather than from a predeclared role alone.

NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce that the failure mode is rarely a single broken control. It is the accumulation of disconnected approvals, stale entitlements, and incomplete offboarding. The practical exception is highly regulated environments where access must remain static for evidentiary reasons, but even there, compensating controls such as time-bound elevation and continuous review are usually necessary.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on compliance status instead of continuous control verification for cloud identity governance?
• Why do Infrastructure as Code pipelines need a separate governance layer in cloud environments?
• How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?
• How should organisations enforce identity governance across multi-cloud and AI-driven workflows?