TL;DR: Light IGA can automate joiner-mover-leaver workflows and standard certifications, but Omada Identity argues it often leaves cloud control planes, legacy systems, service accounts, and production-adjacent access outside governance. That gap turns identity security into a coverage problem, not a feature problem.
At a glance
What this is: This is an analysis of why light IGA reaches basic lifecycle governance but stops short of the systems and identities that create the highest enterprise risk.
Why it matters: IAM and IGA teams need a scope test, not just a feature checklist, because ungoverned cloud, legacy, and service-account access can leave critical risk outside certification and remediation workflows.
Context
Light IGA is basic identity governance that covers standard joiner-mover-leaver processes and certifications for the systems it can connect to out of the box. The governance problem starts when that connector boundary leaves cloud control planes, legacy ERP, production-adjacent access, and service accounts outside coordinated oversight.
For enterprises, the issue is not whether the platform can automate routine access reviews. The question is whether identity governance reaches the identities and control planes that actually shape attack paths, audit evidence, and incident response.
This article argues that scope, not convenience, should determine IGA fit. Smaller environments may accept a narrow connector set, but enterprise identity risk quickly outgrows that model.
Key questions
Q: What breaks when light IGA does not cover all critical systems?
A: Governance breaks at the boundary between connected applications and the rest of the estate. Access reviews, SoD checks, and approval history can look complete while cloud control planes, legacy ERP, and service accounts remain outside the control plane. That leaves auditors and incident responders with partial evidence and manual reconstruction work.
Q: Why do ungoverned service accounts increase enterprise risk?
A: Ungoverned service accounts increase risk because they often hold standing access, are rarely reviewed, and can persist long after the business need has changed. If they sit outside IGA, security teams cannot reliably explain their purpose, approval path, or revocation status when an incident occurs.
Q: How do security teams know if business-driven IGA is working?
A: Look for falling revocation latency, fewer orphaned accounts, fewer unused entitlements, and faster completion of access changes after joins, moves, and exits. If review outcomes improve but stale access still persists between cycles, the programme is only documenting risk instead of reducing it.
Q: How should organisations decide between Light IGA and Full IGA?
A: They should decide based on governance scope, not feature labels. If the environment needs entitlement catalogues, role engineering, segregation of duties enforcement, or coverage across disconnected systems, lightweight governance will not be enough. If the estate is simple, cloud-connected, and already visible, Light IGA may cover the immediate need while a fuller roadmap is built.
Technical breakdown
Why connector libraries define the real governance boundary
Light IGA platforms usually ship with pre-built connectors for HR systems, directories, and common SaaS tools. That makes them useful for baseline lifecycle automation, but the connector library also becomes the effective perimeter of governance. Anything outside it, such as cloud control planes, legacy applications with local identity stores, or privileged account vaults, remains partially or fully invisible to the IGA control plane. The architectural issue is not whether workflows exist, but whether identities and entitlements can be normalized into one audit trail across every place access is granted.
Practical implication: treat connector coverage as a control boundary, not a feature list.
Why segregation of duties breaks across disconnected systems
Segregation of duties depends on seeing conflicting access across the full environment, not just inside connected applications. When toxic combinations span a cloud platform, a legacy ERP system, and a separate privileged access process, a light IGA engine can only evaluate the portion it can reach. That creates a false sense of control because the policy may be technically enforced in one domain while the real conflict survives elsewhere. In enterprise governance, SoD fails when the platform cannot correlate access across identities that are functionally related but operationally separate.
Practical implication: validate SoD across the full access path, not within one connected application set.
What incident response reveals about invisible access
Incident response exposes the difference between local access automation and enterprise governance. If a compromised service account or contractor account was never onboarded into the governance platform, the security team has to reconstruct permissions manually from logs, ticketing records, and system administrators. That slows containment and leaves the organisation unable to answer basic questions about scope, approval history, and revocation order. In practice, the governance gap is not only an audit problem. It also becomes an operational response problem when access must be understood and removed under pressure.
Practical implication: map incident response dependencies to the systems your IGA platform does not govern.
Threat narrative
Attacker objective: The attacker aims to use ungoverned access to reach sensitive systems that the identity programme cannot quickly assess, certify, or revoke.
- Entry begins where a compromised or long-lived service account already exists outside the IGA scope, so the attacker does not need to bypass the governance platform first.
- Credential access or abuse occurs through an identity that was never part of the certification and approval loop, leaving the organisation without a managed revocation path.
- Impact follows when the hidden account can reach inventory, pricing, or customer data and the security team cannot quickly reconstruct or remove that access.
Breaches seen in the wild
- Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Light IGA creates a governance perimeter, not enterprise governance. The core weakness is not that lifecycle automation exists, but that coverage stops where the connector library ends. Once cloud control planes, legacy ERP, privileged vaults, or production-adjacent systems sit outside that perimeter, the organisation no longer has one governance story to explain who approved access and why. Practitioners should treat scope as the first control decision, not a deployment detail.
Connector depth is the difference between visibility and assurance. Light IGA can complete certifications for what it sees, but enterprise identity security requires proof across human identities, service accounts, and machine access paths. That means the control plane must unify approval history, entitlement state, and remediation workflow across systems attackers actually target. Teams that cannot correlate those elements are governing convenience, not risk.
Hidden accounts are an audit failure before they become an incident. The article’s service-account and contractor examples show that ungoverned identities create a parallel access estate that auditors and responders both struggle to reconstruct. That is not a tooling nuisance. It is a structural gap in identity governance scope that turns every exception into a manual investigation. Practitioners need to ask whether their IGA programme can explain access end to end.
Enterprise identity risk should be measured by reach, not deployment speed. Fast rollout and lower cost are real benefits, but they do not answer whether governance extends to the systems that carry the highest blast radius. The practical distinction is between automating known workflows and controlling the full access surface. Security leaders should evaluate IGA on how far it governs, not how quickly it goes live.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: IGA Buyer's Guide
What this signals
Governance scope is the real control decision. Light IGA is often assessed as a cost or deployment choice, but the more important question is whether it can govern the identities and control planes that shape attack paths. If the platform cannot see service accounts, cloud control planes, and legacy systems together, the programme will always rely on manual exception handling.
Hidden access becomes the weakest link in both audit and response. The same identities that slip past certification also slow containment when an incident hits, because the team has to rebuild ownership and privilege history after the fact. That is why enterprise identity security must be designed around reach and evidence, not workflow convenience. In practice, the programme has to extend to the full identity estate, not just the easiest integrations.
For practitioners
- Map governance coverage against critical systems List cloud control planes, legacy ERP, privileged vaults, production-adjacent environments, and service-account stores, then compare them with current connector coverage.
- Reconcile toxic combinations across all access domains Test segregation-of-duties rules across identities and systems that live outside the same workflow engine, especially where approval paths are split between tools.
- Inventory ungoverned non-human identities Find service accounts, contractor accounts, and local application identities that were never onboarded into certification or remediation workflows.
- Pressure-test incident response on hidden access Ask whether the team can reconstruct who approved access, why it was granted, and how quickly it can be revoked when the account never entered IGA.
- Use scope questions before feature comparisons Judge any IGA platform by whether it can govern the identities and systems that matter most to attackers and auditors, not by deployment simplicity alone.
Key takeaways
- Light IGA can improve routine identity workflows, but it stops being sufficient when critical access sits outside its connector coverage.
- The article shows how service accounts and other ungoverned identities create both audit blind spots and incident response delays.
- Enterprise teams should judge IGA by how much of the real access surface it can govern, not by how quickly it can be deployed.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Ungoverned service accounts and contractor access are not being lifecycle-managed inside the IGA scope. |
| NHI-05 — Overprivileged NHI | The article shows access that can be granted and retained without complete governance visibility. | |
| Recommendation — Extend offboarding controls to every non-human identity that can outlive the governance platform's coverage. Review high-risk NHI entitlements outside standard connectors and reduce privileges where approvals cannot be reconstructed. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is incomplete visibility into who can access critical systems and why. |
| Recommendation — Use PR.AA-05 to verify that access permissions are known, governed, and revocable across the full identity estate. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Hidden accounts with standing access undermine least-privilege governance across disconnected systems. |
| Recommendation — Apply AC-6 to reduce standing access where IGA cannot prove business need or approval history. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The attack pattern centres on compromised credentials leading to damaging access to sensitive systems. |
| Recommendation — Map ungoverned service-account exposure to TA0006 and prioritise the systems that can produce the largest impact. | ||
Key terms
- Light IGA: Light IGA is a reduced identity governance model that covers the essentials of access lifecycle and request handling. It usually trades depth for simplicity, offering faster deployment and lower administration overhead, but less flexibility for complex entitlements, nuanced policy, and audit-grade evidence.
- Connector coverage: Connector coverage is the extent to which an identity platform can integrate with the systems where real access decisions exist. It matters because governance controls only work when the platform can see entitlements, roles, and conflicts in the applications that actually hold risk.
- Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
- Governance Scope Of Use: Governance scope of use defines where an AI tool may be used, who may use it, what data it can process, and what controls must apply. In healthcare, this includes review requirements, legal constraints, retention rules, and boundaries that prevent a pilot from expanding before risks are understood.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org