Identity governance is the firewall cloud programs keep leaving open

At a glance

What this is: This is an analysis of why identity governance, not authentication, determines how far access risk spreads in cloud environments.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams all have to govern the full access lifecycle, not just the login moment, or stale and excessive privileges will remain exposed.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.

👉 Read Clarity Security's analysis of identity governance as the cloud firewall

Context

Identity governance is the control layer that decides whether access remains appropriate after authentication succeeds. In cloud and SaaS environments, that question matters more than the login event itself because privileges persist, accumulate, and outlive the conditions that justified them.

Clarity Security frames this as the gap between securing the front door and governing what happens once an identity is inside. That is a familiar failure pattern for human IAM, but it also maps directly to NHI estates where service accounts, tokens, and API-backed access often escape review.

The article argues that many programmes have tooling without governance depth. That is a common state for organisations that have adopted SSO, MFA, and conditional access but still lack a coherent model for access review, ownership, and blast-radius control.

Key questions

Q: How should teams govern access after authentication succeeds?

A: Teams should govern post-authentication access as an active lifecycle problem, not a one-time approval record. That means tying every entitlement to ownership, usage, and expiry, then revoking access that no longer has a business reason. Authentication proves entry. Governance proves the access is still justified.

Q: Why do stale accounts and unused groups increase cloud risk?

A: Stale accounts and unused groups widen the blast radius because they preserve reachable access paths that no longer match current job duties or system needs. Attackers and insiders benefit from privilege that remains valid but unmonitored. The longer that access persists, the harder it becomes to distinguish legitimate from dangerous entitlement.

Q: What do security teams get wrong about access reviews?

A: Teams often treat access reviews as proof of control, when they are really only a point-in-time check. If reviewers cannot see current activity and business context, they may approve access that is technically valid but operationally obsolete. The better test is whether the governance model can explain why access still exists.

Q: Who should own identity governance when it spans cloud and enterprise systems?

A: Ownership should sit with the identity governance team, but implementation must be shared with application, cloud, and platform owners because the access data lives in their systems. If accountability stays central while operational control stays fragmented, certifications and exception handling will lag.

Technical breakdown

Why identity governance, not authentication, determines blast radius

Authentication answers who can get in. Governance answers what that identity can still do after entry, how long access should last, and whether the entitlement still matches the role or task. In cloud and SaaS stacks, the dangerous part is usually persistence, not login. Excessive entitlements, stale accounts, and orphaned group memberships create a larger effective blast radius than the initial access path ever did. That is why IGA and PAM sit downstream of SSO and MFA, not alongside them as substitutes.

Practical implication: teams should measure post-authentication entitlement drift, not just login control coverage.

What “open ports” means in identity governance terms

The article uses “open ports” as a metaphor for excessive or stale access. In identity terms, that includes standing privilege, unused role grants, inactive contractor accounts, and service credentials that were never re-scoped or revoked. These are not visibility issues alone. They are governance failures because access exists without a current business reason, owner accountability, or time boundary. Once that state is normalised, every new exception compounds the effective attack surface.

Practical implication: treat dormant and over-permissioned identities as governance defects requiring removal or re-certification.

Why static access rules fail without context

Static rules can tell you that an identity was approved once, but they do not tell you whether the access is still used, still owned, or still appropriate. Context adds those missing signals by combining role, usage, ownership, and review status into one decision plane. That is the difference between a checkbox access review and a control that actually reduces exposure. Without context, teams end up certifying entitlements mechanically while leaving the real risk untouched.

Practical implication: unify usage, ownership, and entitlement data before recertification so reviews become decision-quality controls.

NHI Mgmt Group analysis

Governance is the firewall, not an admin convenience layer. The article is right to separate authentication from access governance because the risk starts after the front door opens. In mature programmes, review, ownership, and expiry are what keep identity from becoming an uncontrolled perimeter. For IAM and IGA teams, the practical conclusion is that governance coverage must be treated as a core control surface, not an afterthought.

“Open ports” is the right mental model for stale access. Excessive entitlements behave like exposed services because they create reachable attack paths long after the original business justification has expired. That framing is especially useful for NHI estates, where service accounts and tokens often remain active far beyond the lifecycle that created them. Practitioners should read this as a blast-radius problem, not a paperwork problem.

Context is the control plane that turns identity decisions into defensible ones. The article’s central point is that static approval histories are not enough to govern access in distributed environments. When ownership, usage, and business purpose are not visible together, recertification becomes ceremonial. The operational takeaway is that governance must be built around current context, not archived entitlement records.

Identity governance now spans human and non-human estates by default. The same failure pattern appears whether the identity is a contractor account, a service account, or an API token. That makes lifecycle discipline the common language across IAM, IGA, PAM, and NHI programmes. Teams that still govern only human access are leaving a large part of the perimeter outside the firewall they think they have.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which means the governance model is already lagging operational reality.
• Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the next step for teams that need a lifecycle model for access, rotation, and offboarding.

What this signals

Access governance is becoming the pressure point that separates visibility from control. As cloud and SaaS estates expand, teams need a single view of ownership, usage, and entitlement drift or they will keep certifying risk instead of reducing it. The next programme maturity jump is not another login control, but a decision layer that can explain why access still exists.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the same governance problem now reaches far beyond human users and into delegated non-human access. That makes lifecycle oversight and ownership mapping unavoidable for IAM and NHI programmes.

Context-heavy review workflows will matter more than static policy lists. The practical shift is toward entitlement decisions that combine business purpose, access recency, and accountable ownership. That is how identity governance becomes a control plane rather than a record-keeping exercise.

For practitioners

• Map identity blast radius by entitlement depth Inventory who can reach what after authentication, then rank identities by the scope of their standing access rather than by login method. Include human accounts, contractor accounts, service accounts, and API credentials in the same view so excessive reach does not hide in separate tools.
• Rebuild access reviews around ownership and usage Require each entitlement to have a named owner and a current usage signal before review approval. If access has not been used, or if no business owner can confirm the need, route it to revocation instead of another manual approval cycle.
• Eliminate stale access before it becomes normalised Prioritise dormant accounts, unused groups, and long-lived service credentials for removal or re-certification. A control is only effective if it reduces the number of reachable identities, not if it merely records that they still exist.

Key takeaways

• Identity governance, not authentication alone, determines how far cloud access risk can spread once an identity is inside.
• Stale accounts, excessive entitlements, and unowned access are the practical equivalents of open ports in the identity perimeter.
• Teams need context-aware reviews that reduce reachable access, not just audits that record it.

Key terms

• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full article

Clarity Security's full article covers the operational detail this post intentionally leaves for the source:

• How the vendor frames identity governance as a control-plane problem across cloud access.
• The access review workflow concepts behind context-based entitlement decisions.
• The practical distinctions between siloed visibility, ownership, and review coverage.
• The product context behind the platform positioning, which this analysis deliberately does not evaluate.

👉 Clarity Security's full post expands the governance model behind access blast radius and open ports.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.