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.
Where IDaaS Stops and Governance Must Continue
IDaaS is strong at proving that a user, session, or device can authenticate, but that is only the front door of access control. Once the login succeeds, an organisation still has to decide whether the account should keep its roles, entitlements, inherited access, and exceptions. Without that second layer, authentication can be correct while access drift grows silently.
That gap matters because business access is not static. People change teams, contractors leave, applications accumulate privileges, and emergency access often survives the incident that justified it. An IGA layer exists to keep those access decisions tied to ownership, policy, and review cycles rather than to the original login event.
The practical result is that IDaaS alone can confirm “who signed in” without answering “should they still have this access today?” That distinction is what separates authentication from governance. When the governance layer is missing, access becomes a one-time grant instead of a continuously managed control.
How Excess Access and Toxic Combinations Persist
Without IGA, excessive access often survives because no system is continuously reconciling entitlements against business need. That creates privilege creep, stale access, and inherited permissions that no longer match job function. It also makes role cleanup harder because nobody has a reliable view of which entitlements are still justified.
Toxic entitlement combinations are another common failure mode. Two permissions that are harmless in isolation can become risky when held together, especially where payment approval, vendor setup, data export, or administrative override are involved. IGA is what identifies those combinations, enforces segregation of duties, and forces a decision when conflicting access appears.
IAM and IGA Basics explains why identity governance must sit alongside authentication when access decisions need lifecycle control, entitlement review, and segregation of duties.
Segregation of Duties (SoD) Guide is the clearest reference for how conflicting permissions, toxic combinations, and compensating controls should be handled when access must stay audit-safe.
Why Auditability, Recertification, and Offboarding Break Down
One of the biggest weaknesses in IDaaS-only environments is weak evidence. A login log can show a successful authentication, but it does not prove that every active entitlement was reviewed, approved, or recertified. Auditors and internal risk teams usually need evidence that access was periodically validated against business need, not just that the identity provider allowed access.
Offboarding and mover events are also where the gap becomes visible. If access reviews, deprovisioning workflows, and ownership checks are not governed centrally, old access can linger across applications, groups, and privileged pathways. That is why lifecycle controls matter as much as login controls: they close the loop after the user has moved on.
Access Reviews and Certification Guide shows why certification only works when reviews are actionable and actually remove access, rather than documenting it.
Joiner-Mover-Leaver (JML) Guide covers the lifecycle process gap that IDaaS alone cannot solve, especially when leaver access, stale permissions, and old roles need to be revoked cleanly.
Risk and Threat Considerations
When governance is absent, the main risk is not failed authentication, it is durable overpermission. Attackers and insiders alike benefit when a valid login still leads to broad file access, admin actions, or approved-looking entitlements that nobody is rechecking. The organisation may believe it has strong identity security while the real exposure sits in dormant permissions and unmanaged exceptions.
Failure mechanism: Access is granted once and then allowed to persist across role changes, separations of duty conflicts, and stale accounts because no governance process is continuously revalidating entitlements.
Impact: Excess privilege, toxic access combinations, and weak audit evidence increase the blast radius of compromise, make policy violations harder to detect, and leave remediation to incident response instead of ordinary control operations.
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 NIST CSF 2.0 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 | Covers account lifecycle control beyond login authentication. |
| AC-5 — Separation of Duties | Directly addresses toxic entitlement combinations and conflict control. | |
| IA-5 — Authenticator Management | Supports the IDaaS login layer that remains necessary but insufficient. | |
| Recommendation — Review and remove stale accounts and entitlements on a defined cadence. Enforce separation of duties checks before approving access changes. Manage authenticators securely, but pair them with access governance. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Directly fits the need to govern access after successful authentication. |
| GV.RM-01 — Risk Management Strategy | Applies because the issue is unmanaged access risk at the governance layer. | |
| Recommendation — Implement continuous access governance alongside authentication. Treat entitlement drift as a tracked enterprise risk. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Covers policy and enforcement of access decisions beyond the login event. |
| A.5.18 — Access rights | Directly addresses granting, reviewing, and removing access rights. | |
| Recommendation — Define and enforce access rules for entitlement approval and removal. Review access rights periodically and revoke those no longer justified. | ||
Practitioner Guidance
What to prioritise: Treat access recertification, SoD checks, and offboarding as the control plane that makes IDaaS safe to rely on. If the platform can authenticate users but cannot answer who still needs which access, the organisation is missing the layer that prevents entitlement drift.
What to verify: Confirm that every high-risk application has an owner, a review cadence, and a revocation path that actually removes access, not just flags it. The key test is whether stale access can be detected and removed without waiting for a ticket, incident, or audit finding.
Practitioner takeaway: IDaaS is the entry check; IGA is the ongoing decision-making system. If you remove the second layer, you do not lose sign-in, you lose control over whether sign-in still equals legitimate access.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on compliance automation without a separate data security layer?
- What breaks when organisations rely on a third-party integration layer without continuous credential lifecycle management?
- What breaks when organisations rely on SAML without lifecycle automation?
- What breaks when organisations rely on IAM without identity threat detection?