Notifications
Clear all
Topic starter
24/08/2026 2:01 pm
TL;DR: Identity governance still fails where applications, service accounts, machine identities, and AI agents sit outside the governed layer, leaving organizations with incomplete visibility into who and what can access critical systems, according to Orchid Security. The real issue is not governance depth, but governance coverage: access that cannot be seen cannot be certified or controlled.
NHIMG editorial — based on content published by Orchid Security: IGA Always had a Coverage Problem
Questions worth separating out
Q: How should security teams govern applications that cannot connect to an IdP?
A: Treat disconnected applications as a separate governance class, not as exceptions to be ignored.
Q: Why do service accounts and machine identities matter under NIS2?
A: Service accounts and machine identities matter because they often carry the permissions that move data, trigger reports, and feed AI workflows.
Q: What breaks when AI agents inherit access from users and service accounts?
A: The main failure is that inherited access can be broader than the agent’s actual task, so privilege becomes easier to reuse than to govern.
Practitioner guidance
- Expand discovery beyond the IdP Map identities at the application layer, including local accounts, service accounts, API credentials, privileged roles, and inherited access relationships that never flow through central governance.
- Assign ownership to every discovered identity Require each non-human identity to have a named owner, purpose, and lifecycle state so that access reviews and offboarding are based on accountable records rather than archaeology.
- Close the gap between discovery and recertification Feed discovered application identities into the IGA review process before certifications run, otherwise recertification only validates a partial estate.
What's in the full article
Orchid Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How Orchid discovers identities, permissions, and authentication methods inside applications without relying on questionnaires
- The application-layer context that helps move unknown identities into the governed environment
- How SailPoint customers can use the integration to expand the identity universe under IGA control
- Why AI agents, service accounts, and machine identities make application discovery a governance requirement
👉 Read Orchid Security's analysis of hidden identities and IGA coverage gaps →
IGA coverage gaps and hidden identities: what teams miss?
Explore further
24/08/2026 2:01 pm
IGA coverage is now the limiting factor, not governance sophistication. Many programmes are optimized for certifications, access requests, and policy enforcement after identities are already in scope. That works only when the estate is accurately discovered and connected. The harder problem is the unknown 30% of identities, systems, and access paths that never enter the governance universe. Practitioners should treat coverage as the first control objective.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the same study.
A question worth separating out:
Q: Who is accountable when a shared application identity is abused?
A: Accountability should sit with the business owner of the entitlement, the application owner who granted it, and the IAM or governance team that certified it. Shared application identities fail when everyone assumes someone else will revoke them, so clear ownership and removal responsibility are essential.
👉 Read our full editorial: IGA coverage gaps leave hidden identities outside governance
