In most identity governance programs, the real disappointment doesn’t show up in the first rollout—it arrives a year later, when everyone realizes how little actually changed in the enterprise risk profile.
The IGA program looks mature: Active Directory, HR, and ERP are connected; joiner–mover–leaver flows run; access reviews close on time; Segregation of Duties evidence is produced for every in-scope system from the initial wave. Yet questions from audit, finance, and application owners keep coming, because the governance footprint never expands beyond that first cluster of centrally governed applications.
On the other side, risk questions keep surfacing from business-critical SaaS platforms such as Coupa, SAP Ariba, Salesforce, Workday, and adjacent finance or supplier-management systems. Depending on configuration, these systems may approve spend, maintain supplier or employee data, change payment-related information, or store sensitive customer and employee data.
These systems can create vendors, approve spend, change bank details, or store sensitive customer and employee data. They are often federated into SSO, but their roles and entitlements are still managed directly in the applications. Joiner–mover–leaver does not fully reach them. Access changes are handled through local admin requests. Reviews, if they run at all, rely on spreadsheets and exports rather than a consistent lifecycle and certification model.
The same pattern shows up around non-human identities, service accounts, bots, APIs, and integrations that connect these systems. They can move data or trigger transactions across platforms, yet they sit outside the identity, review, and SoD design that governs the core.
In all of these cases, lifecycle and access reviews exist—but they stop at the edge of the systems that were onboarded first. The control concepts are sound. The control failure is not the concept. It is the coverage gap: controls operate on too small a portion of the identity attack surface
This is where many IGA programs stall. The first wave proves the model, but the second wave exposes the economics of governance: every new application requires mapping, normalization, ownership decisions, entitlement interpretation, policy alignment, and evidence collection. When that work remains bespoke, the program cannot scale at the pace of SaaS adoption, automation, and non-human identity growth.
Why IGA programs look complete while risk remains uncovered
That is how many identity programs create a misleading sense of maturity. The core estate is connected, the main workflows are live, and the reporting is clean. Joiner–mover–leaver is marked as implemented, access reviews are running, SoD rules are configured, and evidence can be produced from a central tool.
Beneath that reporting, the reality is usually more fragmented.
Lifecycle events are wired into HR and directories, plus a small set of flagship systems. Beyond that, joiners, movers, and leavers are handled by tickets, email, and local administration.
Access reviews run regularly for core platforms, but a large group of SaaS, custom, and operational applications sits outside any structured certification process.
SoD and IT application controls are carefully designed in a limited number of ERPs, while equally sensitive actions in related systems are governed less consistently or not at all.
These programs aren’t superficial; they’re simply limited in scope. The controls are effective where they are in place, but they only address part of the identity and application landscape. As the environment expands, that shortfall becomes more visible.
Externally, the program looks complete. From a risk perspective, it is still partial.
Why joiner–mover–leaver breaks down after the initial rollout
Joiner–mover–leaver is often described as a foundational control. In principle, it ensures people have appropriate access when they join, adjusted access when they change roles, and no remaining access when they leave.
In practice, it only behaves that way in the systems that are actually connected to the lifecycle model.
A new hire’s record in HR may reliably create accounts and roles in the directory and a core ERP. But access to the finance or operational SaaS used every day may still depend on a service request being noticed and actioned. When someone moves between teams, their groups in the directory may update, while access in other systems remains unchanged. When they leave, central accounts may be disabled on time, while residual access remains in SaaS applications, admin consoles, integration accounts, and downstream business platforms.
The lifecycle concept is sound. The problem is that the implementation stops at the inner circle of systems.
Lifecycle only becomes the control leaders expected when it extends into the applications people actually work in. As long as it halts at identity sources and a small number of major platforms, it reduces less risk than it should.
Why access reviews generate fatigue instead of assurance
Access reviews show the same pattern.
On paper, review cycles look like clear, repeatable controls. Managers confirm who should still have what. Exceptions are flagged and remediated. Certifications are stored. Reports show completion.
The day‑to‑day experience is different.
Reviewers are presented with long lists of entitlements across multiple systems, each using its own terminology. Campaigns from different parts of the organization overlap. The same people are repeatedly asked to make decisions about access they do not fully understand. As the number of review items increases, time and attention shrink.
Certification fatigue is not only a cultural issue. It is a control issue. When reviewers are overloaded or lack context, the default is to approve everything unless something looks clearly wrong. Clean completion metrics can hide weak decision quality.
Periodic review is a good idea. The challenge is that the process was designed around the systems that could be integrated centrally, not around where risk actually sits or how reviewers make decisions with limited time.
Why SoD and ITAC fail when risk crosses applications
Segregation of duties and IT application controls follow a similar pattern.
Most organizations can point to well‑defined SoD rules and control frameworks in a small group of core systems. They know which combinations of roles are toxic in the ERP. They enforce approvals for high‑risk transactions. They monitor important master data changes and configuration updates.
It is much less clear how far those patterns extend.
Today, critical actions are distributed. A payment may start in one application and be approved in another. Vendor data may be maintained in a separate platform from the general ledger. Configuration changes that affect how controls operate may happen in a SaaS admin console instead of an on‑premises system. Non-human identities may initiate workflows, move sensitive data, or execute transactions without being evaluated against appropriate SoD, ITAC, and policy controls.
If those systems sit outside the SoD and ITAC footprint, then the organization has detailed control in a narrow band and weaker governance around it, in exactly the places where risk is growing.
The real control environment is the combination of identities, transactions, data, and application controls across many systems—not just the systems the first phase of the program focused on.
Lifecycle and reviews are the second layer, not the first
Taken together, these patterns suggest a different way to think about identity governance.
Lifecycle, access reviews, SoD, and policy controls are not the base layer. They are the second layer.
The base layer is reach. Until a meaningful share of applications and identities are connected into a consistent governance model, even the best‑designed workflows and campaigns are only applied to a portion of the risk surface.
This is why so many programs plateau after the initial rollout. They invest in refining lifecycle processes, tuning review flows, and adjusting SoD rules within the existing footprint, instead of addressing the question that will actually change the outcome: how to extend governance, at acceptable cost and speed, across the rest of the environment.
Without that extension, every new SaaS application, automation, and nonhuman identity becomes another exception and another place where mature controls simply do not apply.
What changes with federated access governance
Changing this pattern means treating application and identity reach as the starting point, not a later improvement.
That requires two shifts.
First, organizations need a way to bring different types of systems—ERP, finance, HR, operational platforms, SaaS, custom applications, integrations, and nonhuman identities—into a common governance layer without treating each one as a separate, bespoke integration project. Standardized onboarding patterns, data normalization, and a federated operating model become more important than any single workflow.
Second, once those systems are connected, lifecycle, reviews, and policies need to be treated as second‑layer controls that sit on top of this broader surface, not as isolated workflows attached to one platform.
When that foundation is in place:
- Joiner–mover–leaver events no longer stop at the directory. They trigger changes across the applications where people and services actually perform high‑risk actions.
- Access reviews can be organized around shared policies and risk views, with business and application owners making decisions in their own context rather than only through a central lens.
- SoD and IT application controls can be applied wherever relevant roles and transactions exist, not only in the systems that happened to be integrated in the first phase.
The controls themselves have not changed. The difference is the scope they operate on.
Why the stall matters to the CISO
For the CISO, this is not an identity operations issue. It is an enterprise risk visibility issue. Unreviewed access, orphaned accounts, excessive privileges, toxic combinations, and unmanaged non-human identities create exposure across financial systems, customer data, employee data, procurement, and operational platforms. The risk is not limited to whether access exists. It is whether the organization can prove that access is appropriate, continuously governed, policy-aligned, and remediated when it is not.
How SafePaaS approaches this problem
SafePaaS starts with the CISO’s core requirement: extend identity governance to the applications, identities, and transactions where material risk actually lives.
Instead of asking a central team to keep stretching a single, hub‑and‑spoke platform, SafePaaS provides a federated governance architecture for identity, access, risk, and audit evidence. Applications across ERP, finance, HR, operations, SaaS, custom systems, and integrations are onboarded through standard patterns, their data is normalized, and a shared model for policies, risk, and evidence sits above them.
On that foundation, the controls organizations already rely on—joiner–mover–leaver, periodic access reviews, SoD, and IT application controls—can operate across a much broader estate instead of being confined to an inner circle of systems.
For organizations that see their own environment in this description, the better question is no longer “Do we need more lifecycle and more reviews?” but “How do we extend existing controls across the full application and identity risk surface without adding more manual review burden?” SafePaaS exists to make that shift possible.
If lifecycle and certifications look mature on slides but leave significant parts of the application portfolio out of scope, a practical starting point is to redesign one review cycle with coverage as the first design constraint and see how the model performs when application access data, ownership, and evidence are brought into a common governance model.
