Topic starter
24/06/2026 9:19 pm
TL;DR: Opal Security argues that identity governance fails when security teams only get visibility, not enforcement, leaving quarterly reviews, static roles, and workflow bottlenecks unable to stop stolen credentials, overprovisioned vendors, forgotten API keys, and unmanaged service accounts. Visibility without control becomes an audit artefact, not a security control.
Editorial analysis by NHI Mgmt Group, based on content published by Opal Security: “Identity Governance is a Security Problem, Not an IT Process”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Identity governance weakens when security teams can see risky access but cannot directly enforce changes across the estate.
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
👉 Read Opal Security's analysis of why identity governance fails without security control →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 6:29 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity governance fails when security teams lack control