Identity as a service needs an IGA layer to close access drift

At a glance

What this is: This article argues that Identity as a Service solves authentication well, but leaves governance gaps around access reviews, segregation of duties, entitlement visibility, and audit evidence.

Why it matters: For IAM teams, the distinction matters because login control alone does not stop privilege creep, toxic access combinations, or weak offboarding across human, NHI, and broader identity programmes.

By the numbers:

• The market is expanding from $7 billion to a projected $21.4 billion by 2028, reflecting a 25% compound annual growth rate.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Omada Identity's analysis of why IDaaS needs an IGA layer

Context

Identity as a Service is the cloud layer that centralises login, single sign-on, and basic user provisioning. It solves the question of whether a user should authenticate, but it does not answer whether that access is still appropriate after role changes, project shifts, or entitlement accumulation.

That gap matters across IAM programmes because authentication is only one control plane. When organisations add cloud apps, contractors, and non-human identities, access decisions need governance, review, and justification to remain defensible to auditors and security teams.

Omada Identity frames this correctly: the problem is not that IDaaS fails at authentication, but that most enterprises mistake authentication for governance. That is now a typical cloud identity maturity gap, not an edge case.

Key questions

Q: How should organisations govern access if IDaaS already handles sign-in?

A: They should treat IDaaS as the authentication layer and add IGA for lifecycle governance, access certification, and policy enforcement. Sign-in control proves identity at the door, but it does not prove access remains appropriate as roles, projects, and risk change. Governance needs its own workflows and evidence.

Q: Why does access drift happen in cloud identity programmes?

A: Access drift happens when provisioning is automated but review is not. Users change roles, inherit new permissions, and keep old entitlements because no governance process continuously revalidates need. In cloud environments, that creates accumulated access that no longer matches current business purpose.

Q: What breaks when segregation of duties is not enforced outside IDaaS?

A: Conflicting permissions can accumulate across applications even when authentication is strong. That creates opportunities for fraud, policy violations, and audit findings because the same person can hold incompatible access paths. SoD has to be enforced as a policy and governance control, not as a login feature.

Q: Who is accountable for proving that access is still justified?

A: IAM, IGA, and application owners are jointly accountable, but the governance team must supply the evidence. Auditors need approval history, review records, and business justification, not just login logs. If those records are missing, the organisation cannot defend its access decisions.

Technical breakdown

Why IDaaS stops at authentication

IDaaS platforms are built to verify identity, enforce multifactor authentication, and broker access to applications through a central cloud service. That makes them effective at the sign-in layer, where the system decides whether the user can enter. They are not designed to continuously evaluate entitlement quality, business justification, or access combinations after login. In practice, that means IDaaS can tell you who signed in, but not whether the user should still have access, whether their permissions are excessive, or whether those permissions conflict with policy.

Practical implication: treat IDaaS as the access front door, not the governance engine.

How access certification fills the governance gap

Access certification, sometimes called recertification, is the repeated review of who has access to what and whether that access is still justified. The article’s core point is that without this layer, access drifts as people change roles and entitlements accumulate. Certification workflows pull in managers, application owners, and compliance teams so that access is reviewed against current business need rather than historical provisioning decisions. This is the control that converts identity data into governance evidence.

Practical implication: schedule certification around role changes and high-risk applications, not only annual audit cycles.

Why separation of duties cannot be left to login controls

Separation of duties is a governance rule, not an authentication feature. It prevents one identity from holding conflicting permissions that could enable fraud, error, or policy violations across systems. IDaaS can authenticate the same person everywhere, but it cannot on its own detect when a user can both request and approve a transaction, or when a combination of entitlements becomes toxic across SaaS platforms. That is why SoD enforcement belongs in governance and policy workflows, not in sign-in tooling.

Practical implication: model toxic permission combinations centrally and block them before provisioning completes.

NHI Mgmt Group analysis

Authentication-only identity programmes create a governance illusion. IDaaS solves entry control, but it does not solve whether access remains justified after the first successful login. That distinction matters because entitlement drift, orphaned approvals, and toxic combinations are lifecycle problems, not authentication problems. The practitioner conclusion is that authentication and governance must be measured separately.

Access review cadences were designed for stable entitlements, not drifting cloud access. The familiar assumption is that access can be certified after provisioning because it persists long enough to be reviewed. In cloud-first environments with rapid role change and broad SaaS adoption, that assumption weakens fast. The implication is that review models need to track changing business context, not just static permission snapshots.

Fine-grained entitlement visibility is now a governance prerequisite, not a reporting nice-to-have. The article shows why “Salesforce access” is too coarse to support approval, audit, or risk decisions. Teams need to know what the entitlement actually enables, who approved it, and whether it conflicts with other access. Practitioner conclusion: access governance fails when technical access is not translated into business meaning.

Identity drift debt: the accumulation of access rights that remain valid in systems even after the business reason for them has expired. This is the core failure mode the article exposes. IDaaS provisions access quickly, but without governance the organisation carries unresolved entitlement debt across role changes, contractors, and application sprawl. The practitioner conclusion is that the real security problem is not initial login, but unmanaged persistence of access.

IGA is the control layer that turns identity from a login function into a governable lifecycle. The article’s strongest insight is that organisations do not need to abandon IDaaS, they need to place it inside a broader governance model. That model has to include recertification, SoD enforcement, policy-based provisioning, and audit evidence. Practitioner conclusion: mature identity programmes treat authentication as necessary, but never sufficient.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly identity remediation can lag operational reality.
• For a broader lifecycle lens, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs explains how review, rotation, and offboarding fit together.

What this signals

Access governance is becoming the differentiator between identity modernisation and identity maturity. Organisations that stop at IDaaS will keep producing strong authentication logs while missing the evidence auditors and risk teams actually need. The practical signal is that review, approval, and entitlement context must now be treated as core identity telemetry, not administrative extras.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the same governance blind spot that affects human access also applies to machine and workload identities. That means identity teams cannot isolate IGA as a human-only problem.

Identity drift debt: the longer access remains outside review, the more difficult it becomes to justify, revoke, or audit. The near-term programme signal is to connect provisioning, certification, and offboarding into one lifecycle view so entitlement growth does not outrun governance capacity.

For practitioners

• Separate authentication from governance in your operating model. Map which controls belong to IDaaS and which belong to IGA, then stop using login success as evidence of access appropriateness. Use this split to reassign audit, approval, and entitlement review responsibilities to the right teams.
• Stand up certification workflows for high-risk entitlements. Start with privileged SaaS roles, finance systems, and externally shared applications where excessive access is most likely to persist. Tie recertification to role changes and offboarding events so reviews happen when business context changes.
• Model segregation of duties centrally before provisioning. Define toxic combinations across systems, not just within a single app, and enforce them as policy checks during request and approval flows. Block or escalate conflicts before the account is created or the entitlement is activated.
• Translate technical entitlements into business-readable access. Require approvers to see what a permission actually allows, not just the application name. That makes it possible to justify access, challenge excess, and produce audit evidence that proves why the entitlement exists.

Key takeaways

• IDaaS improves login control, but it does not close the governance gap that lets access drift over time.
• Evidence of access appropriateness requires certification, segregation of duties enforcement, and entitlement-level context, not just authentication logs.
• Identity teams should treat IGA as the layer that makes cloud access defensible, auditable, and lifecycle-aware.

Key terms

• Identity as a Service: A cloud-delivered identity platform that centralises authentication, sign-on, and basic provisioning for applications. It reduces the need for on-premises infrastructure, but it is primarily an entry control layer and does not by itself govern whether access remains appropriate over time.
• Identity Governance and Administration: The control layer that oversees who has access, why they have it, and whether that access is still justified. In practice, IGA adds certification, policy enforcement, and audit evidence so identity decisions can be reviewed across the full lifecycle, not just at login.
• Access Certification: A structured review process that validates whether an identity should keep its current permissions. It is used to detect access drift, excess privilege, and outdated entitlements, and it creates documented evidence that access has been challenged against business need.
• Separation of Duties: A governance rule that prevents one identity from holding conflicting permissions that could enable fraud, error, or policy violations. It must be enforced across systems and workflows, because authentication alone cannot detect toxic combinations of access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Omada Identity: What is Identity as a Service? The Authentication Solution That Needs an IGA Layer. Read the original.