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

At a glance

What this is: This is an argument that IDaaS solves authentication well but leaves post-login governance unresolved, creating access drift as roles change and entitlements accumulate.

Why it matters: It matters because IAM teams need more than secure sign-in: they need continuous evidence that access is still appropriate, reviewable, and compliant across human and non-human identity estates.

By the numbers:

• The IDaaS market is expanding from $7 billion to a projected $21.4 billion by 2028 at a 25% compound annual growth rate, according to Omada Identity.

Context

Identity as a service, or IDaaS, is a cloud-based approach to authentication that centralises login, multi-factor authentication, and basic provisioning without on-premises infrastructure. The governance problem begins after initial sign-in, when roles shift, entitlements accumulate, and the original access decision no longer reflects current need.

The article’s core claim is that IDaaS is a starting point, not a complete identity control model. For identity programmes, the missing layer is governance that can certify access, check segregation of duties, and produce audit-ready justification across the identity lifecycle.

Key questions

Q: What breaks when organisations rely on IDaaS without an IGA layer?

A: Without an IGA layer, IDaaS can secure the login event but still leave excessive access, toxic entitlement combinations, and weak audit evidence in place. The failure is not authentication itself. The failure is that access is never continuously revalidated against business need, separation of duties, or recertification requirements.

Q: Why does IDaaS create compliance risk even when authentication is strong?

A: Strong authentication does not answer the governance questions auditors ask, such as who approved access, why the entitlement exists, and when it was last reviewed. When those answers are missing, the organisation can authenticate users securely and still fail compliance expectations around evidence, justification, and access oversight.

Q: How can security teams tell whether identity drift is becoming a control failure?

A: Look for a growing delay between unauthorised changes and formal review, especially on systems that still depend on manual extracts. If access changes faster than your certification cycle can observe them, the programme is recording compliance after the fact rather than controlling privilege in real time.

Q: When should organisations add IGA to an existing IDaaS deployment?

A: Organisations should add IGA when audits, role churn, SaaS growth, or non-human identity sprawl make it impossible to prove that access is still appropriate. If the team can authenticate users but cannot certify access or explain why entitlements remain, governance has become the missing layer.

Technical breakdown

Why IDaaS stops at authentication

IDaaS platforms are built to answer a narrow question: should this user log in? They excel at single sign-on, multi-factor authentication, and basic provisioning because those are authentication and entry problems. What they do not natively resolve is whether a user should keep a given entitlement after role changes, project changes, or organisational restructuring. That gap matters because authentication confirms identity at the door, while authorisation and governance determine whether the person can still act appropriately once inside. In practice, the platform’s control boundary ends before continuous entitlement oversight begins.

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

Access drift and entitlement accumulation

Access drift occurs when the access a person or account had at provisioning time remains in place after business need changes. In cloud-first environments, that drift is amplified by SaaS sprawl, manual approvals, and role churn. Entitlements accumulate because the system can create access efficiently, but it does not continuously re-evaluate whether the same access is still justified. The result is privilege creep, where rights build up across applications and no longer map to current job function or policy. This is a lifecycle issue as much as a technical one.

Practical implication: align certification cadence with role and entitlement change, not with login activity.

Why IGA adds the missing governance control plane

Identity Governance and Administration sits above authentication and connects identity data to policy enforcement, access review, and audit evidence. It is the layer that can certify who has what access, identify conflicting permissions, and record why an entitlement exists. That matters because compliance frameworks expect evidence, not just successful logins. IGA turns access into a governed lifecycle by linking business justification, approval, and review to the entitlement itself. Without that layer, organisations can authenticate users securely while still failing to govern the permissions that matter most.

Practical implication: deploy IGA where access decisions must be provable, reviewable, and policy-bound.

NHI Mgmt Group analysis

Authentication without governance is a partial identity model. IDaaS solves the entry problem, but it does not complete the access decision. Once the user is inside, entitlements can diverge from current need without the platform automatically correcting them. For identity programmes, that means the control boundary is too narrow if it stops at login.

Access drift is the operational symptom of missing lifecycle oversight. Roles change faster than manual review cycles, so rights accumulate across SaaS applications and remain in place long after business need has shifted. This is not a one-off configuration issue; it is a structural governance gap that shows up whenever provisioning is easier than recertification.

Audit readiness depends on justification, not just authentication logs. Auditors and compliance teams need to know why access exists, who approved it, when it was last reviewed, and whether conflicting permissions were identified. Authentication records cannot answer those questions. The practical conclusion is that access evidence must be tied to entitlement governance, not login telemetry.

Separation of duties is the clearest proof that IGA is a distinct control layer. A sign-in platform can grant access, but it cannot reliably detect toxic combinations across systems or prevent a person from holding conflicting permissions. That makes SoD enforcement one of the strongest arguments for governance above the authentication layer. The implication for practitioners is that policy enforcement must sit closer to entitlement decisions than to login policy.

Identity governance for cloud-first estates needs a named control concept: entitlement drift. The article describes a pattern where cloud convenience speeds access creation faster than it speeds access review. That creates a drift between business justification and actual permission state. Practitioners should treat that drift as a governance problem, not merely as excess access to be cleaned up later.

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.

What this signals

Access drift is the governance gap that cloud identity teams tend to underestimate. Authentication platforms can reduce login friction and centralise entry control, but they do not continuously test whether an entitlement still matches business need. That means the governance burden shifts to recertification, SoD enforcement, and approval evidence.

Entitlement governance has to move closer to the point of approval. Once access is provisioned, manual review cycles are usually too slow to keep pace with role churn and SaaS sprawl. Practitioners need a model where justification, review, and exception handling are part of the access lifecycle, not an afterthought.

For practitioners

• Define the IGA control boundary Map which access decisions must move beyond IDaaS login controls into continuous governance, including certifications, approvals, and exception handling.
• Automate access certification cycles Replace spreadsheet reviews with recurring certification campaigns that follow role changes, entitlements, and system ownership.
• Enforce separation of duties at entitlement level Check cross-application combinations before approval so conflicting permissions are blocked or routed through documented exception workflows.
• Tie provisioning to business justification Require approvers to see role, context, and business purpose for each entitlement so access requests are evaluated against policy, not application names alone.
• Build audit evidence into the identity lifecycle Retain approval trails, review outcomes, and recertification history so access can be defended when compliance teams ask why it exists.

Key takeaways

• IDaaS solves the entry problem, but not the governance problem that appears after users log in.
• Access drift grows when roles change faster than entitlement reviews, leaving permissions in place without current business justification.
• The control gap closes when IGA adds certifications, SoD checks, and audit-ready evidence above the authentication layer.

Key terms

• Identity as a Service: Identity as a Service is a cloud-delivered model for authentication and access management. It centralises functions such as sign-on, policy enforcement, logging, and provisioning, but it does not remove the need for ownership, review, and offboarding discipline across all identities.
• Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
• Answer Drift: Answer drift is the gradual change in a model’s responses over time, often showing up as reduced consistency or increasing error rates. It can signal degraded grounding, shifting data quality, or prompt and retrieval issues. Monitoring drift helps teams catch reliability problems before they become widespread user-facing failures.
• 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.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management 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.