Identity governance fails when security teams lack control

At a glance

What this is: Opal Security says identity governance breaks down when security teams can see risk but cannot directly enforce changes across human and machine identities.

Why it matters: This matters because IAM, IGA, PAM, and NHI programmes fail in practice when review-driven governance cannot reduce standing privilege or close access gaps in real time.

👉 Read Opal Security's analysis of why identity governance fails without security control

Context

Identity governance is supposed to help organisations understand and reduce access risk, but that model weakens when the team responsible for security cannot actually change access. In this article, the core problem is not visibility. It is the gap between knowing who and what has access and being able to enforce least privilege across human identities, service accounts, API keys, and other non-human identities.

Opal Security's argument is that identity risk is now broad enough and fast-moving enough that review cycles and workflow handoffs are too slow to keep pace. Quarterly certification, static RBAC, and IT or DevOps dependency leave security teams reacting after exposure has already occurred. The article frames this as an operating model failure, not a tooling visibility problem.

Key questions

Q: What breaks when identity governance relies only on access reviews?

A: Access reviews assume the reviewable state is a stable entitlement that reflects real risk. In fast-moving cloud and agentic environments, the risky state may have already changed by the time the review runs. Teams then certify a snapshot instead of governing the behaviour that creates exposure.

Q: Why does standing privilege create so much risk for non-human identities in cloud environments?

A: Standing privilege gives service accounts, API keys, and other non-human identities a persistent foothold that attackers can reuse after compromise. In cloud environments, that means access can linger long after the original task is complete. Removing persistent permissions and using ephemeral access reduces lateral movement opportunities and keeps the attack surface from accumulating.

Q: How can security teams know if cloud identity governance is actually working?

A: The clearest signals are fewer unresolved access findings, shorter evidence-collection cycles, lower counts of stale keys, and reduced reliance on manual review. If teams still spend days reconstructing access state, governance is not operating continuously. Effective programmes can show current MFA coverage, role scope, and credential age on demand.

Q: How should organisations govern human and non-human access during mergers?

A: They should treat both as part of the same identity estate. Human onboarding, service account inheritance, API keys, and integration credentials can all introduce hidden access paths if they are not reviewed together. A merger is the wrong time to separate IAM from machine identity governance.

Technical breakdown

Why quarterly access reviews miss active abuse

Quarterly access reviews are a governance checkpoint, not a preventative control. They compare entitlements after the fact, which means excessive access can exist long enough for an attacker to use it before anyone notices. In fast-changing environments, that delay is especially dangerous because access can be granted, abused, and retired between review cycles. The technical failure is temporal: the control operates on a cadence that is slower than the threat. Real security requires controls that can constrain issuance and use, not just document what existed last quarter.

Practical implication: Treat access reviews as evidence for governance, not as the primary mechanism for stopping abuse.

Why static RBAC breaks in cloud and machine identity environments

Role-based access control assumes access patterns are stable enough to model ahead of time. That assumption breaks in cloud environments where workloads, service accounts, and integration paths change continuously. Static roles tend to accumulate excess permissions because they are designed for persistent jobs, not ephemeral systems. When identities and resources are dynamic, RBAC becomes an approximation that lags operational reality. The result is overprovisioning, entitlement sprawl, and unclear ownership across human and machine access paths.

Practical implication: Use rightsized, task-scoped access models for identities whose permissions change faster than role definitions can keep up.

What enforcement means when security teams own identity changes

The article's central distinction is between seeing a problem and having the authority to fix it. If security teams still need IT or DevOps tickets to change access, then governance remains fragmented across process owners who do not share the same risk objective. That slows remediation and creates accountability gaps. Enforcement means the security function can directly reduce access scope, revoke risky entitlements, and apply just-in-time access without waiting for another team to act. In identity security, control ownership matters as much as policy design.

Practical implication: Assign direct enforcement paths for access changes so remediation does not depend on cross-team approval chains.

Threat narrative

Attacker objective: The objective is to turn existing identity exposure into unauthorised access to critical systems and data before governance processes catch up.

1. Entry begins with stolen credentials, forgotten API keys, or overprovisioned third-party access that already exists in the environment.
2. Escalation occurs when static roles, standing privileges, or unmanaged service accounts provide more access than the actor should have had.
3. Impact follows when attackers use that access before quarterly review or workflow-based remediation can remove it.

Breaches seen in the wild

• Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity governance becomes a security control problem only when enforcement is fragmented. Visibility alone does not reduce risk if the team discovering excessive access cannot revoke it or constrain it directly. The article correctly exposes the difference between reporting and control, which is why governance programmes that stop at certification leave the attack surface intact. The practitioner conclusion is simple: identity security fails when remediation authority sits outside the security function.

Quarterly certification is too slow for a live identity attack surface. Reviews are built for accountability, but attackers exploit identity exposure continuously, not on a schedule. That makes certification useful for audit evidence and dangerous as a primary defence. The real governance gap is a control plane that cannot react at machine speed. Practitioners need to treat review cadence as an after-the-fact signal, not a prevention strategy.

Static RBAC is a poor fit for identities that move faster than role design. The article is right to connect cloud dynamism and machine identity sprawl with role-based control failure. Roles work when access patterns are stable and human-paced. They break when service accounts, API keys, and workload permissions change with deployment and integration cycles. The implication is that rightsizing must be operational, not seasonal.

Direct access enforcement is now the defining boundary between IGA and security ownership. When security teams depend on IT or DevOps to make changes, access governance becomes a process dependency instead of a security function. That is the structural weakness this article surfaces. The named concept here is governance without enforcement: a model that can describe risk but cannot reduce it. Practitioners should recognise that this is no longer adequate for human IAM or NHI governance.

Unified identity control must cover humans, workloads, and emerging agentic access paths. The article is strongest where it refuses to separate human and machine identity risk into different organisational silos. Attackers do not distinguish between a compromised SSO session, a service account, or a forgotten key. Neither should governance design. The broader implication is that identity programmes need one enforcement model across the full identity estate, with ownership aligned to risk rather than organisational convenience.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.

What this signals

Governance without enforcement is the named failure mode here: organisations can no longer treat identity oversight as sufficient when the security team cannot directly change access. The practical shift is from documenting entitlement risk to operating a control plane that can remove it.

Review cadences built for quarterly assurance do not match identity systems that change continuously. Security programmes need to measure whether access can be reduced at the same speed that it is created, otherwise visibility will continue to outpace containment.

For practitioners

• Implement security-owned access enforcement Give the security team direct authority to revoke, reduce, and time-bound access without routing every change through IT or DevOps tickets.
• Replace review-only governance with active access controls Use access reviews for oversight, but pair them with controls that can remove excess access in real time when risk is identified.
• Scope just-in-time access for high-risk identities Apply task-scoped access to users, service accounts, and other non-human identities so standing privileges do not persist by default.
• Rationalise static roles in cloud and machine environments Review RBAC assignments that were built for stable human jobs and retire role patterns that no longer match ephemeral workloads or integrations.
• Map enforcement paths across human and machine identities Document where identity changes can actually be executed today, then remove handoff points that prevent timely remediation across the estate.

Key takeaways

• Identity governance weakens when security teams can see risky access but cannot directly enforce changes across the estate.
• The article ties that failure to review lag, static RBAC, and workflow dependency in both human and machine identity environments.
• Practitioners should treat access enforcement as the security control, with reviews serving as governance evidence rather than protection.

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.
• 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.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Rightsized access: Rightsized access means granting the minimum access actually needed for the current role, task, or system state. Unlike rigid least-possible access, it balances usability and security while still requiring continuous adjustment as identities, workloads, and permissions change.

What's in the full article

Opal Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The vendor's direct framing of why security teams need control rather than visibility alone
• Examples of how just-in-time access and use-it-or-lose-it access are positioned for human and machine identities
• Implementation context for enforcing least privilege across cloud systems, data platforms, and internal tools
• The vendor's deployment and integration claims for teams that want code-based or API-driven access workflows

👉 Opal Security's full post covers the control gap, the access model, and the deployment approach in more detail.

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.