What happens when organisations rely on legacy IGA for separation of duties and service account governance?

Legacy or homegrown IGA often struggles with fragmented identity data, weak policy enforcement, and limited visibility into access relationships. In practice, that makes it harder to manage conflicting privileges, remove stale access, and detect suspicious service account activity. The result is a larger attack surface and less confidence that identity controls are actually reducing risk.

Why legacy IGA breaks down on SoD and service account governance

Legacy IGA usually treats identity governance as a workflow and reporting problem, not as a living control plane for conflicting entitlements and non-human access. That works poorly when separation of duties depends on current, complete relationship data and when service account need distinct ownership, expiry, and exception handling. As environments fragment across cloud, SaaS, and platforms, the control becomes slower, less trusted, and easier to work around.

The practical issue is not that the control objective is wrong. It is that stale connectors, incomplete inventories, and weak policy models make SoD checks noisy or incomplete, so teams either over-escalate exceptions or stop trusting the review. Service accounts make that harder because they often sit outside the clean joiner-mover-leaver pattern and can accumulate access without clear business context. NHIMG’s IAM and IGA Basics explains why this gap matters when access governance depends on reliable entitlement data.

Once the governance layer cannot accurately represent who or what has access, SoD becomes a paper control instead of an enforceable one. Conflicting permissions may still exist even after certifications close, and service accounts may keep access long after the system or integration that justified them has changed. That is why modern governance needs to treat service accounts as first-class governed identities rather than as administrative leftovers.

What failure looks like in real operations

In practice, failure shows up as recurring exceptions, manual spreadsheets, and policy rules that only cover the easiest systems. Legacy IGA often cannot model technical entitlements, shared accounts, or machine-to-machine dependencies with enough fidelity to support strong SoD decisions. The result is that reviewers approve access with limited context, or they approve the same conflict repeatedly because the tool cannot prove whether the violation is still active.

service account governance fails in a different way. Accounts remain active after ownership changes, are reused across systems, or retain privileges that no one can confidently explain. NHIMG’s Service Account Security Guide is useful here because it shows why discovery, least privilege, and ownership are prerequisites for credible governance, not optional extras.

SoD degrades further when access reviews do not distinguish between human roles and non-human operational access. A control that was designed for employee roles can miss integration users, automation accounts, or privileged service principals, which means the organisation may think it has a closed loop when it really has only partial coverage. NHIMG’s Segregation of Duties (SoD) Guide shows how toxic combinations need to extend to service accounts and other non-human actors.

What organisations should change before the control loses credibility

The control objective should shift from periodic approval to continuous confidence in the access graph. That means SoD rules must be backed by current entitlement data, clear identity ownership, and a way to distinguish business-approved exceptions from orphaned or inherited access. For service accounts, governance should include lifecycle state, owner, purpose, privilege scope, and a review cadence that is stricter for higher-risk accounts.

NHIMG’s Access Reviews and Certification Guide is relevant because it focuses on reducing review noise and closing the loop on remediation. NHI Lifecycle Management Guide reinforces the same point for provisioning, rotation, offboarding, and visibility, which are the lifecycle points where legacy IGA most often falls short.

Legacy tools also need stronger role design discipline. If SoD rules are built on bloated, overlapping roles, the governance team ends up reviewing a structural problem instead of enforcing policy. NHIMG’s Role Mining and Role Design Guide helps frame the better approach: reduce role sprawl, separate technical and business roles, and avoid hiding risky access inside broad group assignments.

Risk and Threat Considerations

When legacy IGA cannot keep pace with actual access relationships, the risk is not just administrative inefficiency. Conflicting privileges can persist unnoticed, service accounts can retain unused or excessive access, and attackers can exploit the weakest governed identity path to move laterally or hide activity inside automation traffic.

Failure mechanism: Incomplete inventories, stale entitlements, and weak ownership make SoD checks and service account reviews depend on outdated records rather than current effective access.

Impact: Excess privilege, hidden conflicts, and undetected misuse increase the chance of fraud, unauthorized change, credential abuse, and broader compromise.

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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Governance of accounts and lifecycle directly affects service account control and SoD enforcement.
	AC-5 — Separation of Duties	SoD is the central control being weakened by legacy IGA and poor entitlement visibility.
	IA-5 — Authenticator Management	Service account governance depends on managing credentials and their lifecycle, not just roles.
Recommendation — Implement AC-2 to inventory, approve, review, and disable service accounts on a controlled schedule. Apply AC-5 to define incompatible access combinations and enforce compensating controls for exceptions. Use IA-5 to control issuance, rotation, storage, and revocation of service account credentials.
ISO/IEC 27001:2022	A.5.15 — Access control	Access control governance is directly implicated by weak SoD and account oversight.
	A.5.16 — Identity management	Identity management underpins ownership, provisioning, and lifecycle control for governed accounts.
	A.5.18 — Access rights	The issue is stale and excessive access rights that legacy IGA fails to remove or validate.
Recommendation — Use A.5.15 to define and enforce access rules for privileged and service accounts. Use A.5.16 to maintain authoritative identity records and ownership for accounts and roles. Use A.5.18 to review, adjust, and revoke access rights when entitlement purpose changes.
CIS Controls v8	CIS-5 — Account Management	Account inventory, lifecycle control, and review are directly relevant to service account governance.
	CIS-6 — Access Control Management	SoD and privilege restriction are access-control problems that legacy IGA may not enforce well.
Recommendation — Use CIS-5 to track account ownership, disable stale accounts, and enforce lifecycle controls. Use CIS-6 to limit conflicting access and remove unnecessary privileges from service accounts.

Practitioner Guidance

What to prioritise: Start with the identities and entitlements that can create the largest blast radius, especially privileged service accounts, shared technical accounts, and roles that bridge multiple systems. If the control cannot tell you who owns an account, why it exists, and what it can do, treat it as a governance gap rather than a review backlog.

What to verify: Confirm that SoD rules are evaluated against current entitlements, not just assigned roles, and that exceptions expire or are re-approved on a fixed schedule. For service accounts, verify that every account has a named owner, a documented purpose, and a rotation or offboarding path.

Practitioner takeaway: Legacy IGA is usually weakest where governance needs the most precision, so the real test is whether it can prove effective access and ownership for both people and service accounts, not whether it can generate a completed review.