Many enterprises declare their Identity Governance and Administration program “live” once thier ERP and HR are connected, only to keep absorbing audit findings from the 80–90% of applications and non‑human identities that sit outside the model.
Let’s say a manufacturer with roughly 220 SOX‑in‑scope and business‑critical applications found that only about 15% of real access risk was actually governed, leaving hundreds of SaaS apps, integrations, and service accounts effectively invisible to controls.
Instead of trying to push everything through the IGA bottleneck, they added a federated identity governance layer and a SafePaaS‑powered onboarding factory—raising governed coverage to around 70% while cutting onboarding time per app from 10–12 weeks to about 2–3 weeks and bringing non‑human identities into the same governance model as workforce users.
This scenario breaks down how organizations typically do it, and what CISOs should demand from their own programs so coverage and time‑to‑coverage finally match the risk surface.
How did this enterprise move from truncated IGA to federated coverage?
A multinational manufacturer with around 30,000 employees and roughly 220 SOX‑in‑scope and business‑critical applications had an Identity Governance and Administration (IGA) program that was officially “live”. Directory, HR, the main ERP, and 30 priority applications were onboarded—about 15% of the critical estate—yet most access risk, especially in SaaS and integrations, still sat outside consistent governance.
This is how the CISO moved from that truncated deployment to a federated identity governance model with an application onboarding factory, and how coverage and time‑to‑coverage became numbers the audit committee and board could track.
Snapshot: by the numbers
- 220 critical applications (SOX + business‑critical)
- 30 applications initially under IGA (~15% coverage)
- ~30k workforce identities; 20k–40k non‑human identities (service accounts, integrations, bots, agents)
- Time‑to‑coverage per app: 10–12 weeks before, 2–3 weeks after the factory pattern
- Coverage after 18–24 months: ~160 of 220 apps (~70%)
The stalled IGA rollout
Joiner‑mover‑leaver workflows ran for the systems in IGA scope, quarterly user access reviews completed on schedule, and audit evidence was available for those applications.
When the CISO and Internal Audit compared IGA scope to the full application inventory, they identified more than 180 critical applications still governed through local administration, spreadsheets, and email approvals. Many of these applications handled payments, approvals, or master data changes in finance and operations, directly affecting SOX compliance for IT systems.
Three main gaps stood out:
- Only about 30 of 220 critical applications had consistent lifecycle, user access review, and evidence patterns
- Regional and SaaS tools that moved money or changed key data were outside formal identity governance and access governance
- Non‑human identities—service accounts, integration users, bots, agents—were poorly inventoried and rarely appeared in standard processes
Audit findings began to highlight incomplete coverage, unclear ownership of integration users, and uneven evidence for high‑risk activity outside the core ERP landscape. The CISO could explain the control environment for the first 30 applications, but not for the rest of the estate.
Why did every new application feel like a separate project?
The identity and security teams analysed why coverage was stuck. Each new application triggered the same problems:
Different connectivity every time
Some systems exposed data via REST, others via SOAP, JDBC, SFTP, flat files, or proprietary APIs. Each onboarding started by solving a new connectivity problem.
Inconsistent data structures
Users, roles, entitlements, transactions, and configuration objects were modelled differently in each application. Teams had to agree what counted as a role, privileged access, toxic access, or control‑relevant activity before they could map anything.
Custom schema translation
Once data was extracted, it had to be transformed into a format the identity governance and administration software could understand. In practice, this became bespoke ETL work hidden inside each onboarding.
Bespoke workflows
Each application had its own owners, approvers, reviewers, and escalation paths. Central teams had to design or adjust workflows for systems they did not directly own, turning themselves into a bottleneck for onboarding and for recurring user access review campaigns.
Cost per application stayed high, time per application stayed long, and the backlog of critical “next wave” systems never really shrank. For the CISO, these economics made it unrealistic to reach a coverage level that would satisfy Internal Audit and the board.
How did the CISO change the scorecard for identity governance?
To align everyone around the real problem, the CISO and Identity/GRC lead introduced two simple metrics that cut across federated access governance and existing IGA tools:
Coverage
The share of SOX‑in‑scope and business‑critical applications, human identities, and non‑human identities that were under defined policy, monitoring, and regular review.
Time‑to‑coverage
The time from when a new ERP module, SaaS application, or automation was introduced to when its identities, roles, high‑risk actions, and relevant ITAC/ITGC controls met the agreed standard.
The baseline looked like this:
- Application coverage: about 15% (30 of 220 critical apps)
- Human identity coverage: strong in the core ERP and HR systems, patchy in regional and SaaS applications
- Non‑human coverage: less than 20% of known service accounts and integration users in any standard process
- Median time‑to‑coverage: 10–12 weeks per application
This made it clear that while the initial IGA project scope was delivered, the governance program was not yet where risk and audit stakeholders needed it to be.
Moving to federated identity governance
Instead of replacing the IGA platform, the organization changed the operating model to federated identity governance. This model combined centralized policy and visibility with distributed execution.
The new model introduced three key elements:
Central control plane
A central team defined global policies, segregation of duties rules, risk thresholds, and minimum evidence standards, and consolidated signals across ERP, SaaS, custom applications, and integrations. This acted as the federated identity access governance layer.
Distributed execution layer
ERP security owners, platform teams, and application owners applied those standards using their own roles, workflows, and logs. They stayed responsible for how controls were implemented in their systems, while feeding back consistent evidence.
Federated RACI
A clear responsibility matrix assigned who was responsible and accountable for access decisions, application onboarding, role model maintenance, certifications, and exceptions in each domain.
The CISO shifted from reviewing individual workflows to owning standards, guardrails, and assurance. Application and process owners took on defined responsibility for governing access and high‑risk actions in the systems they understood best, within those guardrails.
How does SafePaaS power an application onboarding factory?
A federated model only works if onboarding stops behaving like a series of one‑off integration projects. This is where SafePaaS came in. The organization implemented an application onboarding factory built around three standard steps—connect, transform, govern—using SafePaaS as the connective and federated control layer.
Step 1: Connect via SafePaaS DataProbe
SafePaaS DataProbe acted as the universal connector layer for the enterprise:
- Connected directly to ERP systems, finance and procurement platforms, HR, and other core applications
- Reached into SaaS and cloud platforms using REST and other modern APIs
- Connected to databases, data warehouses, and files using JDBC, SFTP, and similar protocols
- Discovered users, roles, entitlements, transactions, and configuration objects relevant for governance
Key differences compared to a typical IGA connector approach:
- Connectivity patterns were defined once in DataProbe and reused across applications and domains
- SafePaaS owned the operational layer of connectivity (scheduling, error handling, logging) instead of pushing it into ad‑hoc scripts or IGA jobs
- The same connector framework supported both human and non‑human identities, so service accounts and integration users were not handled as exceptions
Connectivity stopped being the bottleneck. Reaching a new application no longer meant writing a new connector inside the IGA platform.
Step 2: Transform via SafePaaS DataPaaS
Connection alone did not solve the hardest part: turning inconsistent source data into something federated identity governance could use consistently. SafePaaS DataPaaS handled this.
DataPaaS is the SafePaaS data transformation and normalization layer. It gave teams a guided, no‑code way to:
- Select source objects from DataProbe (users, accounts, roles, entitlements, transactions, configuration items)
- Define transformation rules: renaming fields, splitting or merging attributes, deriving risk indicators, and filtering noise
- Map local fields into a SafePaaS universal schema that aligns identities, roles, access, and activity across systems
- Validate and preview the transformed data before it flowed into the SafePaaS control plane
This is where SafePaaS diverged most from a traditional IGA pattern:
- Normalization logic lived in DataPaaS, not in a tangle of custom ETL jobs per application
- Teams reused patterns—for example, “ERP module pattern,” “finance SaaS pattern,” “integration pattern”—rather than reinventing mappings each time
- Risk context (such as which entitlements were sensitive or SoD‑relevant) could be embedded in the transformation stage and carried into policies and user access review automation
In effect, SafePaaS became the data fabric for identity governance and administration solutions, sitting between raw application data and any workflow engine, including the existing IGA tool.
Step 3: Govern through the SafePaaS federated control plane
Once data was normalized, SafePaaS acted as the federated control plane. This is where policies, risk models, and evidence came together.
SafePaaS provided:
- A central policy and risk model for access, SoD, high‑risk actions, and IT application controls
- Standardized user access review software capabilities and campaigns that could be applied across ERP, SaaS, and custom applications
- Risk‑aware workflows for access requests, approvals, and remediation, aligned with SoD and sensitive‑access rules
- A consistent evidence model: who approved what, when, under which policy, with which exceptions
SafePaaS did not replace the IGA platform for core lifecycle tasks; it worked alongside it:
- The existing IGA tool continued to handle joiner‑mover‑leaver events, provisioning, and some access workflows, especially for core systems
- SafePaaS orchestrated policies, SoD logic, risk context, federated IAM ownership, and evidence across a wider set of applications and identities, including non‑human ones
- Application owners and process owners used SafePaaS views and workflows to make decisions inside the federated model, while the CISO and Internal Audit used SafePaaS for coverage, time‑to‑coverage, and assurance views
This connect‑transform‑govern pattern—DataProbe + DataPaaS + SafePaaS control plane—allowed the organization to treat onboarding as a factory process instead of a sequence of bespoke projects.
What changed with SafePaaS in place
SafePaaS changed both the economics and the quality of federated access governance.
Coverage
- Application coverage grew from about 30 to around 160 of 220 critical applications (from ~15% to ~70%), because onboarding no longer required custom connectors and custom ETL per system
- Core ERP, major finance and procurement SaaS, regional platforms, custom applications, and key integration hubs all plugged into the same SafePaaS‑driven pattern
Human and non‑human identities
- Workforce identities from HR, directory, ERP, and SaaS were aligned through the SafePaaS universal schema, so user access review tools and policies could span systems rather than stay siloed
- Non‑human identities—service accounts, integration users, bots, and agents—were discovered via DataProbe, normalized in DataPaaS, and governed in the same SafePaaS control plane as human users
- Ownership, purpose, and allowed actions for non‑human identities became visible, with clear lifecycle and review patterns
Time‑to‑coverage
- Median onboarding time per application dropped from roughly 10–12 weeks to around 2–3 weeks
- SafePaaS patterns meant teams could onboard multiple applications in parallel, because connectivity and transformation were standardized and workflows were reused
- Time‑to‑coverage became a metric SafePaaS could expose directly, showing how long it took to bring a new application or integration under defined policy, monitoring, and review
Audit and assurance
- SafePaaS generated consistent, cross‑application evidence on access, approvals, SoD checks, and remediation, reducing effort during audits and supporting SOX compliance for IT systems
- Internal Audit gained better visibility into which applications and identities were governed, how, and with which exceptions
- The CISO used SafePaaS dashboards to report coverage, time‑to‑coverage, and non‑human identity governance to leadership and the audit committee
In short, SafePaaS provided the continuous governance layer and onboarding fabric that the original IGA deployment lacked. It allowed the organization to finish what IGA started: moving from deep control in a small set of systems to consistent, risk‑aware governance across the broader ERP, SaaS, and identity estate.
How can CISOs apply this federated model in their own programs?
This case reflects a pattern many organizations face: strong governance in 20–30 core systems, but 150–200 business‑critical applications and tens of thousands of non‑human identities governed inconsistently.
Practical implications for CISOs:
- Treat coverage and time‑to‑coverage as primary success metrics, not just connector counts or campaign numbers
- Recognize when the onboarding model has become the bottleneck and consider an application onboarding factory with a standard connect‑transform‑govern pattern
- Use federated identity governance and federated identity access governance to keep policy and assurance centralized while moving decisions and enforcement closer to applications and data owners
- Bring non‑human identities into the same federated enterprise control plane as workforce users, with clear ownership, purpose, and lifecycle patterns
FAQ
What is federated identity governance?
Federated Identity Access Governance helps organizations govern identity access across today’s distributed identity landscape where humans and non-humans may authenticate through different identity providers, applications, and cloud platforms. SafePaaS focuses on whether each identity’s access is appropriate, approved, risk-aware, and continuously monitored. By combining identity access governance and governance, risk, and compliance, SafePaaS reduces excessive access, prevents policy violations, and strengthens compliance across complex environments.
How is SafePaaS different from a traditional IGA platform?
SafePaaS differs from traditional IGA vendors by governing identity access at the entitlement, risk, and audit-evidence level not just at the abstract role or workflow level. While many IGA platforms focus on certifications, provisioning workflows, and business roles, SafePaaS shows reviewers the actual privileges users hold across ERP, SaaS, cloud, manual, and third-party provisioning sources, so access decisions are informed, defensible, and auditor-verifiable. SafePaaS also adds contextual lifecycle controls, HR-aligned role management, fine-grained segregation of duties analysis, continuous elevated-access monitoring, real-time application change evidence, 360-degree identity intelligence, and a federated DataPaaS architecture that works alongside existing systems. Its modular approach helps organizations strengthen compliance, reduce access and transaction risk, and modernize identity governance without the cost, disruption, or all-or-nothing replacement model of traditional IGA programs.
When should a CISO consider adding SafePaaS?
A CISO should consider adding SafePaaS when existing identity governance or IAM tools can’t provide auditor-verifiable evidence, comprehensive entitlement visibility, or effective risk management across complex enterprise environments. SafePaaS complements existing investments by unifying access data enabling entitlement-level access reviews, contextual segregation of duties analysis, continuous privileged access monitoring, and real-time compliance evidence. Rather than replacing an existing IGA platform, SafePaaS helps organizations close governance gaps, reduce identity and transaction risk, satisfy auditors, and modernize identity governance through a modular, federated architecture that integrates with current systems.
Does this approach require replacing existing IGA investments?
An organization should consider SafePaaS when identity governance has become fragmented, costly, or difficult to audit. Whether replacing a traditional IGA platform or modernizing an existing IAM environment, SafePaaS provides comprehensive identity governance across ERP, SaaS, cloud, legacy, and manual provisioning systems from a single platform. It delivers entitlement-level access reviews, contextual lifecycle management, fine-grained segregation of duties analysis, continuous privileged access monitoring, and auditor-verifiable compliance evidence. With its federated architecture and modular deployment model, SafePaaS enables organizations to strengthen security, reduce identity and transaction risk, simplify compliance, and modernize identity governance without requiring a disruptive, all-or-nothing transformation.
Next step for CISOs
If this article has raised questions about whether your current IGA platform provides the visibility, governance, and audit evidence your organization needs, the next step is to evaluate where the gaps exist. Ask whether your access reviews expose actual entitlements or only business roles, whether all user access is governed from a single platform, whether segregation of duties analysis considers business context, and whether you can produce auditor-verifiable evidence without relying on spreadsheets or manual effort.
SafePaaS can be deployed alongside an existing IGA solution and expanded modularly, allowing you to assess these capabilities without committing to a disruptive transformation. A practical starting point is a focused assessment of your current identity governance environment to identify compliance gaps, quantify risk, and determine where SafePaaS can deliver measurable business value.
