Notifications
Clear all
Topic starter
24/06/2026 9:19 pm
TL;DR: Identity governance tools can expose risk, but they do not prevent real-time abuse when access reviews lag, roles stay static, and security teams cannot enforce changes themselves, according to Opal Security. The governance model breaks once identity control is fragmented across IT, DevOps, and security, making standing privilege and delayed remediation the real problem.
NHIMG editorial — based on content published by Opal Security: Identity Governance is a Security Problem, Not an IT Process
Questions worth separating out
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.
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.
Q: What do security teams get wrong about identity governance?
A: Teams often confuse governance with security.
Practitioner guidance
- 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.
What's in the full article
Opal Security's full article covers the operational detail this post intentionally leaves for the source:
- How Opal frames direct security ownership over access across human and machine identities.
- Specific examples of just-in-time and use-it-or-lose-it access in cloud and data systems.
- The platform integrations and deployment options described for teams that want enforcement across AWS, GCP, Azure, Snowflake, and Databricks.
- The vendor's own explanation of how Terraform and CLI support fit into existing DevOps workflows.
👉 Read Opal Security's analysis of identity governance as a security control problem →
Identity governance as a security problem: what changes now?
Explore further
25/06/2026 6:29 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity governance fails when security teams lack control
