TL;DR: Access governance, lifecycle control, and visibility fail when service accounts, API keys, and AI agents sit outside the programme, according to Zluri; the deeper issue is that identity governance still treats machine access as an exception instead of the operating model.
NHIMG editorial — here’s why we think this discussion matters
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern service accounts inside an IGA programme?
A: Treat service accounts as governed identities with owners, lifecycle states, and review evidence.
Q: Why do access reviews fail when applied to non-human identities?
A: They fail when teams use human review logic for machine access.
Practitioner guidance
- Map every non-human identity to a named owner Build an inventory that links each service account, API key, token, and certificate to a business owner, technical owner, and system of record.
- Separate machine identity certification from human access review Use different evidence, approval criteria, and review cadences for service accounts and employee accounts.
- Tie offboarding to application and integration change events Revoke machine identities when the integration, workflow, or vendor relationship ends.
What to expect at the briefing
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- The article's product workflow for bringing access reviews and lifecycle management into the same platform
- The specific feature set Zluri maps to service account visibility, access governance, and lifecycle control
- The implementation framing for teams that want to connect identity management to broader SaaS administration
👉 Read Zluri's view on NHI governance inside IGA →
NHI governance in 2026: what IGA teams need to fix?
Explore further