The clearest signs are unowned service accounts, access reviews that exclude workloads or automation, manual exceptions for common identity flows, and certification processes that only cover employees. Those gaps show that governance is still centred on people rather than on the full access graph. The result is incomplete control coverage, not just an administrative backlog.
What it means when IGA stops at employees
An IGA programme that covers only employees is effectively governing one slice of the access estate while leaving other identity types to local teams, scripts, or ad hoc approvals. The practical test is whether the programme can explain, review, and remediate access across the full access graph, including service accounts, workloads, bots, and other non-human identities.
That gap usually shows up as “known exceptions” that never really enter the governance process: accounts that exist outside the joiner-mover-leaver flow, access that is granted but never recertified, or entitlements that are accepted because the system owner is not in the review scope. The programme may look mature on paper while still missing material control surface.
In practice, this is why a complete view of identity lifecycle matters. A foundational IGA model has to include both human and machine populations, otherwise governance becomes a reporting exercise rather than a control system.
Operational signs of an incomplete identity estate
The clearest signs are not obscure edge cases, but routine control failures that point to missing scope. If service accounts are created outside standard request flows, if workloads authenticate with secrets no reviewer can name, or if automation is granted “temporary” access that persists, the programme is not reaching the identities that actually move data and change state.
Another strong indicator is review design. When certification campaigns only ask managers about employees, the process is measuring people rather than access. If reviewers never see application identities, cloud roles, shared accounts, or non-interactive credentials, the review outcome will be incomplete even when the workflow is technically successful.
Gaps also show up in role design and entitlement cleanup. Role models that do not distinguish human, workload, and automation patterns tend to accumulate exceptions that are later treated as “just how the system works”. Once exceptions become normal, the programme has lost the ability to tell standard access from unmanaged access.
A useful diagnostic is whether orphaned or stale identities are being discovered as part of the programme, or only after incidents, audits, or system decommissioning. If discovery depends on someone remembering a forgotten account, the estate is not being governed continuously.
Where coverage usually breaks down in the control model
Coverage usually breaks at the boundary between governance and operations. IGA tools often integrate cleanly with HR-driven employee lifecycle events, but they are weaker where identity is created by application deployment, infrastructure provisioning, or DevOps automation. That is where ownership, source systems, and review cadence become ambiguous.
Manual exceptions are another structural weakness. They are sometimes necessary, but if they are used for common access paths, they become a parallel control process. At that point, the programme is no longer enforcing policy consistently; it is documenting the fact that policy does not fit the real estate.
The same pattern appears in segregation of duties and access certification. A SoD programme that only models employee conflicts will miss conflicting privileges held by service accounts, bots, or platform identities. Likewise, access reviews that do not include non-human identities are structurally unable to close the gap they are meant to manage.
If the organisation cannot answer who owns a non-human identity, why it exists, when it was last reviewed, and how it is decommissioned, then the identity estate is broader than the governance model. That mismatch is the core failure, not a tooling defect.
Risk and Threat Considerations
Incomplete identity coverage increases the chance that privileged or persistent access remains outside normal review and revocation paths. Unowned service accounts, long-lived credentials, and unmanaged automation accounts are attractive because they are easy to overlook and often have durable access across systems.
Failure mechanism: attackers and insiders can abuse identities that were never brought into certification, lifecycle, or ownership workflows, then retain access long after the business believes it has been removed.
Impact: the organisation gets a false sense of control, while exposure grows through privilege creep, stale access, weak offboarding, and hidden paths for lateral movement or unauthorized actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control for credentials used by non-human and human identities. |
| AC-2 — Account Management | Requires account inventory and lifecycle governance across all account types. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports detecting blind spots when reviews and certifications miss key identities. | |
| Recommendation — Enforce credential issuance, rotation, revocation, and reuse limits for every identity class. Maintain authoritative inventory and lifecycle handling for every account, including non-human accounts. Review audit evidence for unmanaged accounts, exceptions, and uncaptured entitlement changes. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems Inventoried | Identity estate completeness depends on knowing what assets and identities exist. |
| PR.AA-01 — Identities and Credentials Issued, Managed, Verified, Revoked, and Audited | Directly addresses lifecycle governance gaps in the identity estate. | |
| Recommendation — Inventory all identity-bearing assets and accounts, including workloads and automation. Extend issuance, review, revocation, and audit processes to all identity types. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account governance is central when employee-only coverage misses service and machine accounts. |
| Recommendation — Inventory, review, and remove all accounts that can access systems, not just employee accounts. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud identity governance must cover human and non-human identities across access paths. |
| Recommendation — Map IAM controls to every cloud identity class, including workloads and service accounts. | ||
Practitioner Guidance
What to prioritise: start with the identities that can cause the most damage if they are missed, which usually means service accounts, privileged automation, shared credentials, and cloud or application identities with write access. If those are excluded from governance, the programme should be treated as incomplete regardless of employee review coverage.
What to verify: every identity class should have an owner, a source of truth, a review path, and a retirement path. If any of those four are missing for workloads or automation, the programme is relying on local memory rather than governable control.
Common mistake: treating successful certification completion as evidence of coverage. A clean campaign can still be blind to the identities that actually carry the highest operational and security risk.
Practitioner takeaway: the question is not whether IGA exists, but whether it can govern every identity that can authenticate, authorize, or persist in the environment. If it cannot, the programme is reporting on identity governance without actually controlling the estate.
Related resources from NHI Mgmt Group
- What are the signs that an IGA platform is no longer fit for a modern identity programme?
- What are the signs that data labeling is not covering the full data estate?
- How can teams tell whether identity lifecycle automation is actually covering the full app estate?
- How do teams know whether PAM and IGA are working across the full identity estate?