When IGA is disconnected from IAM, organisations can provision access correctly and still fail governance. Access may remain approved long after the role changed, the workload moved, or the account became unnecessary. That creates a gap between policy and reality, which is where orphaned accounts and excess permissions survive.
Why This Matters for Security Teams
When IGA is not tightly connected to IAM, governance can approve access that the runtime identity layer never enforces, or revoke access in policy while credentials remain usable in production. That split turns access reviews into paperwork instead of control. NHI risk is especially sensitive here because service accounts, API keys, and workload identities often outlive the business reason they were created.
NHIMG research shows the gap is not theoretical: in Ultimate Guide to NHIs, 97% of NHIs are reported to carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts. That means IGA can look clean while the actual IAM state remains over-permissioned and under-observed. The control failure is not just “who approved what,” but whether the approval is translated into real entitlement state, secret rotation, and account lifecycle enforcement. Security teams usually discover the problem only after a workload is overexposed, a secret is reused, or an offboarded account keeps working long after ownership changed.
Current guidance in NIST Cybersecurity Framework 2.0 supports tying governance to operational enforcement, not treating review and implementation as separate systems. In practice, many security teams encounter this only after a dormant account, stale API key, or cloud role has already been abused.
How It Works in Practice
IGA and IAM need a closed loop. IGA defines the policy decision, who should have access, for what purpose, and for how long. IAM enforces the decision by creating, updating, and removing the actual account, role, token, or secret. If those systems are loosely coupled, access reviews become stale snapshots and provisioning workflows drift from reality.
For Non-Human Identities, that loop needs to include workload identity, secret lifecycle, and runtime checks. A good implementation does not stop at approving a service account. It also binds the identity to the workload, enforces short-lived credentials, and revokes or rotates secrets when the task, environment, or owner changes. That is why NHI Mgmt Group’s 2024 Non-Human Identity Security Report is so relevant: 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM, which explains why governance often outruns execution.
- IGA should drive access requests, approvals, and recertification.
- IAM should enforce entitlement creation, suspension, and removal in real time.
- Secrets managers should rotate credentials on a schedule or event, not only during annual reviews.
- Workload identity should be the anchor for machine access, not shared static secrets.
- Logging should confirm that approved access actually exists and that removed access is no longer usable.
For implementation patterns, teams should align their IAM execution with policy-as-code, zero trust, and lifecycle automation, using controls that can be validated continuously rather than manually. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity as an operational control, not a spreadsheet exercise. These controls tend to break down when identity ownership is split across platform, security, and application teams because no single system can prove that approvals, entitlements, and revocations stayed in sync.
Common Variations and Edge Cases
Tighter IGA to IAM coupling often increases operational overhead, requiring organisations to balance governance assurance against deployment speed and platform complexity. That tradeoff becomes sharper in hybrid and multi-cloud environments, where identity models differ and one approval may need to map to several enforcement layers.
Best practice is evolving for agentic and automated workloads. For human users, a periodic review may still be acceptable in low-risk cases. For NHIs, current guidance suggests the review must be tied to runtime state, because credentials, roles, and workloads change faster than recertification cycles. The exception is legacy systems that cannot support event-driven revocation; in those environments, organisations should compensate with shorter TTLs, compensating monitoring, and stricter secret storage controls.
NHIMG’s Azure Key Vault privilege escalation exposure illustrates another edge case: even when a secrets platform exists, mis-scoped permissions can turn governance into an escalation path. Similarly, incidents like the Schneider Electric credentials breach show how credential exposure can outpace policy enforcement when lifecycle controls are weak. There is no universal standard for this yet, but the practical rule is simple: if IGA cannot trigger or verify IAM changes, the organisation does not have governance, only documentation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Stale NHI access and rotation gaps are central when IGA and IAM drift apart. |
| NIST CSF 2.0 | PR.AC-4 | Access governance must be enforced in IAM, not left as paper approvals. |
| NIST AI RMF | AI RMF governance principles fit the need for accountable, verifiable identity decisions. |
Continuously verify that approved access exists only while required and is removed when no longer needed.
