Identity governance fails when security teams lack control

At a glance

What this is: Opal Security argues that identity governance is a security control problem, not an IT workflow problem, because visibility without enforcement leaves attackers free to exploit standing access.

Why it matters: For IAM teams, the issue is not only who can review access but who can actually change it fast enough across human, NHI, and emerging agentic identities.

👉 Read Opal Security's analysis of identity governance as a security control problem

Context

Identity governance is often treated as an administrative process, but the security failure is simpler: if the team that sees the risk cannot enforce the fix, the control is incomplete. That gap matters across human IAM, non-human identities, and the first wave of agent-like access patterns because attackers exploit the place where ownership and action diverge.

The article’s core claim is that quarterly reviews, static roles, and workflow-heavy remediation do not match cloud-paced identity change. In practice, that means security teams can observe excessive access, overprovisioned vendors, forgotten API keys, and unmanaged service accounts without having the authority to remove the risk before it is abused.

Key questions

Q: How should security teams reduce standing privilege in identity governance programmes?

A: Security teams should reduce standing privilege by shortening access duration, removing unnecessary persistent entitlements, and making revocation executable by the team that owns risk. The key is to treat access as temporary by default for high-risk systems, then verify that the control can actually be enforced without waiting on another department.

Q: Why do quarterly access reviews fail to stop identity abuse?

A: Quarterly access reviews fail because they identify problems after the abuse window has already opened and often after access has been used. In fast-moving cloud and SaaS environments, the useful control is enforcement speed, not retrospective validation. Reviews still have value, but only if they trigger immediate correction.

Q: What do security teams get wrong about identity governance?

A: Teams often confuse governance with security. Governance can show who has access, but security depends on whether the right team can remove that access in time, across human identities, NHIs, and service accounts. Without that enforcement path, the programme produces visibility without risk reduction.

Q: Who is accountable when identity risk is discovered but not fixed?

A: Accountability belongs to the team that can actually enforce the change, not the team that merely reports the issue. If security owns the risk but cannot revoke access, the operating model is misaligned. Frameworks such as the NIST Cybersecurity Framework 2.0 expect governance to connect detection with response and recovery.

Technical breakdown

Why access reviews miss real-time identity abuse

Quarterly or periodic access reviews are designed for stable privilege models, where access persists long enough to be observed, evaluated, and removed. In cloud and SaaS environments, that assumption no longer holds cleanly. Excess permissions can be exploited before review cycles finish, and the review itself becomes a retrospective record rather than a preventive control. This is why visibility and governance reporting are not the same as security enforcement.

Practical implication: shorten the gap between detection and enforcement so review findings can trigger immediate access change.

Why static RBAC breaks in cloud identity estates

Role-based access control works best when job functions and system boundaries are relatively fixed. The article points to a harder reality: cloud identities, workloads, and services change by the minute, while static roles tend to accumulate access over time. That creates a mismatch between entitlement design and operational reality, especially when service accounts and third-party access are added to the same environment. In that setting, RBAC becomes a coarse label, not a live control.

Practical implication: validate whether roles still match actual system use before they become a source of standing privilege.

Why security-owned enforcement changes the identity model

The operational difference is not simply who receives a report. It is who can actually change access across identity types without routing every change through IT or DevOps queues. When security can enforce just-in-time access, remove unnecessary privileges, and coordinate across cloud, SaaS, and internal systems, identity governance shifts from documentation to control. That is especially important for NHIs, where forgotten secrets and service accounts can persist outside normal human approval paths.

Practical implication: align identity enforcement authority with the team that owns security risk, not just the team that administers the directory.

NHI Mgmt Group analysis

Identity governance only becomes security when the enforcing team can act in real time. Visibility, access reviews, and approval workflows all matter, but they do not stop abuse if the remediation path still depends on another team’s queue. That is the central control gap the article identifies, and it applies across human identities, NHIs, and emerging agent workflows. The practitioner takeaway is straightforward: governance without enforcement is reporting, not protection.

Static entitlement models are already out of step with cloud identity estates. RBAC and quarterly certification were built for slower-moving environments where privilege changes could be reviewed after the fact. Cloud services, third-party access, and service accounts now change faster than those cycles can absorb. The implication is not that governance is obsolete, but that the operational model behind it is too slow for the attack surface it is meant to manage.

Just-in-time access is the named concept that best captures the article’s security direction. The article treats JIT as the practical alternative to standing privilege because it reduces the time access exists without sacrificing routine operations. That matters most for NHI and service-account governance, where persistent credentials often outlive the task they were created for. The practitioner conclusion is that access duration is now a security variable, not just an operational convenience.

Security teams need authority over identity risk, not just observability into it. The article’s deeper point is organisational: when identity control sits elsewhere, the security function inherits accountability without execution power. That structure guarantees delayed fixes, uneven enforcement, and a widening gap between what the dashboard shows and what the attacker can reach. The implication is that identity governance programmes must be evaluated by who can change access, not who can report on it.

Across human, NHI, and agentic identities, control ownership is becoming the differentiator. The same fragmentation pattern recurs in each case: one team owns creation, another owns review, and security owns the incident. That split no longer scales. Practitioners should treat identity enforcement authority as part of the control plane, not a downstream service request.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That same research found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• The governance lesson is to move from reporting to enforcement, and to ground that shift in the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs when access changes span provisioning, rotation, and offboarding.

What this signals

Identity governance is moving toward enforcement-centric operating models. Security teams can no longer rely on workflow ownership alone when cloud access, third-party access, and service-account access all change faster than certification cycles. The organisations that close this gap will measure identity control by how quickly a risk can be removed, not by how many reviews were completed.

Standing privilege has become a stronger indicator of programme weakness than missing visibility alone. If the team with the risk view cannot revoke access, the control is only descriptive. Practitioners should watch for systems where identity change still depends on ticket queues, because those are the environments where attack dwell time is likely to outpace governance response.

Just-in-time access and lifecycle control are converging into a single operational question. The issue is no longer whether access can be documented, but whether it can be created, constrained, and removed fast enough across human and machine identities. That is why the NIST Cybersecurity Framework 2.0 remains relevant as a governance scaffold, but only if teams connect identification, protection, detection, response, and recovery to actual enforcement.

For practitioners

• Map enforcement authority, not just review ownership. Document which team can remove access, reduce privilege, or revoke credentials for human users, service accounts, and third-party identities without waiting on a separate approval chain.
• Replace delayed certification with event-driven access change. Use review findings as triggers for immediate privilege adjustment, especially where excessive access, forgotten API keys, or overprovisioned vendors can be abused before the next quarterly cycle.
• Treat standing privilege as a measurable risk indicator. Inventory identities that retain access between tasks, tasks that require persistent credentials, and systems where security cannot independently enforce least privilege.
• Unify human and machine access governance under one control model. Align policies so service accounts, cloud roles, and human sessions are governed with the same enforcement standard when the security team needs to act quickly.
• Audit where identity decisions still depend on IT tickets. Track every access change that must pass through non-security queues and remove those dependencies from high-risk systems first, starting with crown-jewel applications.

Key takeaways

• Identity governance fails as a security control when the team that sees the risk cannot enforce the fix.
• Quarterly reviews and static roles are too slow for cloud-paced identity estates where abuse can happen before certification completes.
• Security teams should measure identity maturity by revocation speed, enforcement authority, and the ability to reduce standing privilege in real time.

Key terms

• Identity governance: Identity governance is the set of processes used to define, review, approve, and remove access across accounts, roles, and systems. In security practice, it only becomes effective when the same team or workflow can enforce the change, not merely document the risk.
• Standing privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. It increases exposure because the entitlement can be abused at any time, especially in cloud and NHI environments where long-lived credentials are easy to forget and hard to police.
• Just-in-time access: Just-in-time access is a model where access is granted for a specific task or window and then removed when no longer needed. For NHIs and emerging agent workflows, the control matters because access duration becomes a direct security variable, not just an administrative choice.
• Enforcement authority: Enforcement authority is the practical ability to change or revoke access without depending on another team’s queue. It is a critical security attribute because visibility alone cannot reduce risk if the control owner cannot act quickly across human, machine, and delegated identities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Opal Security: Identity Governance is a Security Problem, Not an IT Process. Read the original.