Ask an IAM, security or compliance leader to show everything one identity can do across the organisation’s material applications. The answer often requires data from several systems.
Access requests may begin in an IGA or ITSM platform. Authentication may be managed through SSO. Provisioning may occur through connectors, application administrators or local workflows. Certifications and Segregation of Duties analysis may use another set of data altogether.
Each component can operate as designed while the organisation still struggles to answer a basic governance question: who—or what—has access to which sensitive capabilities, why was that access approved and is it still appropriate?
The answer is not necessarily to move every identity function into one platform. It is to connect distributed access processes to a common governance model.
A federated control plane centralises policy, risk decisions and evidence while allowing authentication, provisioning and enforcement to remain in the systems best suited to perform them. Access management and governance stop operating as disconnected workstreams, even though execution remains distributed across IGA, IAM, ITSM, ERP and SaaS platforms.
The answer in brief
Different provisioning solutions solve different parts of the problem:
- SSO establishes and manages authenticated sessions.
- IGA manages access requests, lifecycle events and provisioning.
- ITSM routes service requests and operational tasks.
- ERP and SaaS applications enforce their local permissions.
- Governance evaluates whether access complies with policy and business risk.
The strongest architecture does not force every function into one platform. It connects them through shared policy, entitlement-level risk analysis and a traceable record of each access decision.
Why separate tools create gaps
Most organizations do not end up with fragmented access control on purpose. It accumulates over years:
- The ERP has its own role and security model, managed by the ERP team.
- SaaS access may be provisioned through IGA, IAM connectors, SCIM or local application workflows, while SSO manages authentication. Those processes may not include the application-level entitlement and organisational context needed for ERP-specific SoD analysis.
- Governance — certifications, SoD checks, risk reviews — runs in yet another tool, often only covering a subset of systems.
No single source shows a complete picture of one identity’s access across all of this. Each tool may provide an accurate view of the access it manages. The gap appears when no shared governance layer correlates identities and entitlements across provisioning sources and applications.
Where those sources are not connected, teams fall back on exports and manual reconciliation. The resulting view is labour-intensive to maintain and represents a point-in-time snapshot rather than a continuously governed population. The same coverage question applies to service accounts, integrations, bots and AI agents. If those identities sit outside ownership, certification and policy processes, centralising employee access alone will not create a complete governance picture. [see “What is the best access provisioning solution for machine identities?”].
What a federated control plane should do
A federated control plane should complement IAM, IGA, SSO, ITSM and application-native security. It does not need to perform every local access function. Its role is to establish consistent governance across those functions.
At minimum, it should:
- Correlate identities and effective entitlements from multiple provisioning sources.
- Normalise application-specific access into a form that policy and reviewers can interpret.
- Evaluate SoD and sensitive-access risk across applications.
- Apply organisational context such as legal entity, ledger, operating unit and geography.
- Run certifications across the complete governed population—not only access provisioned through one platform.
- Retain the request, policy result, approval, exception, mitigation and remediation as a traceable record.
- Show which material applications and identity types remain outside governance.
One practical test is whether the platform can identify a conflict created by privileges held in different applications, for example, the ability to create supplier or purchasing data in one system and release related payments in another.
Detecting that conflict requires more than aggregating role names. The platform must correlate the identity, interpret the underlying privileges and apply a cross-system policy to the combined access.
How provisioning ties to policy (and business risk)
Centralizing governance only works if provisioning feeds the same policy engine instead of running independently as an IT workflow. When a new access request comes in, it should be evaluated against the same SoD rules, process risks, and role definitions the governance layer already uses — not a separate, looser set of checks specific to whichever system is granting access.
This matters most at the moment of request, because that is when a conflict is cheapest to catch:
- A conflict identified before provisioning can be resolved before the access becomes operational. The same conflict discovered months later may require investigation, access redesign, mitigation and retrospective evidence.
- The same conflict, found six months later during a certification, becomes a remediation project with an audit trail attached.
Connected provisioning and governance close that gap by using the same approved policy model for pre-provisioning analysis, ongoing monitoring and periodic certification.
Provisioning in this model becomes a business policy decision, not just an IT ticket. High-risk requests should be evaluated against relevant SoD, sensitive-access and organisational-context policies before provisioning. Lower-risk access may follow a more streamlined approval path.
Human and non‑human governance
A control plane that only accounts for employees is already incomplete. Service accounts, integration accounts, bots, and AI agents now hold access across the same ERP and business systems people use, and they need to be visible in the same centralized view — not tracked separately, or not tracked at all.
Federating governance does not mean forcing every identity type through an identical workflow. It means applying a consistent set of governance principles, adapted to the identity’s lifecycle and risk.
- Every material identity has an accountable human owner or sponsor.
- Access is linked to a documented business or technical purpose.
- SoD and sensitive-access policy evaluates the identity’s effective capabilities.
- Review frequency reflects privilege, activity and business criticality.
- Changes, exceptions and remediation remain traceable.
- Retirement and emergency suspension triggers are defined.
Splitting human and non‑human governance into different systems recreates the exact fragmentation a centralized control plane is supposed to eliminate. As AI agents and automations become embedded across finance, HR, procurement, and operations, governance has to be federated: policy defined centrally, enforcement and ownership distributed to business and application teams within that framework.
What “centralized” means in practice
“Centralized” gets used loosely. A genuinely centralized control plane means more than a single UI:
- One governance framework for identities, applications, and processes — not different rules per system.
- One policy and SoD model applied consistently regardless of where access resides.
- One audit trail covering provisioning, certifications, exceptions, and remediation in a common format.
- One coverage story for auditors and boards: which ERP, finance, operational, and SaaS systems are under governance, how non‑human identities are treated, and how new systems get onboarded.
SafePaaS’s guidance for audit and SOX teams emphasizes this point: the real test is whether you have a single governance view spanning ERP plus every connected system relevant to financial workflows, not just another dashboard sitting on top of siloed data.
If any of the items above still require pulling data from multiple tools and reconciling it manually, the control plane is not truly centralized yet. It is a reporting layer on top of fragmented governance.
Centralization also has to survive scale. A setup that looks centralized with one entity and one ERP often breaks once a second or third ERP, region, or business unit enters the picture. The right question is not “do we have a centralised platform?” It is “how much of our material access is governed today, and how quickly can the model extend when the business adds an application, entity or identity type?”
Which solution approach fits which problem?
|
Solution type |
Strongest fit |
Limitation when used alone |
|
SSO and directory platform |
Authentication, federation and baseline account access |
Does not by itself provide deep entitlement, SoD or certification governance |
|
Lifecycle IGA |
Joiner–mover–leaver, requests and provisioning across connected applications |
Coverage and entitlement depth may vary across ERP, legacy and locally administered systems |
|
ITSM-led provisioning |
Operational request and fulfilment workflows |
Policy evaluation and access evidence may remain separated from fulfilment |
|
ERP-native GRC |
Detailed access and SoD controls in its home ERP |
Limited reach across heterogeneous applications and provisioning sources |
|
Federated governance |
Shared policy, cross-system risk, certification and evidence across existing tools |
Depends on clear ownership and a prioritised application-onboarding model |
The best answer is often an architecture rather than a single product. Existing IAM and provisioning tools can continue performing the functions they handle well, while a federated governance layer supplies the policy, risk and evidence model they share.
SafePaaS is designed for organisations that already have multiple identity and application systems but lack consistent governance across them.
Proof that governance can connect existing identity investments
A Fortune 500 financial-services company already used SailPoint for identity administration, Okta for authentication, Workday for HR and Oracle ERP. SafePaaS was added as the federated governance layer rather than replacing those systems.
The organisation:
- Reduced Oracle ERP access fulfilment from two to three days to a few hours.
- Reduced role and entitlement management effort by 50–70%.
- Freed approximately 110 hours each month across business and IT teams.
- Cut tickets for stuck access requests by 60–80%.
Read the financial-services customer story
Business outcomes: what buyers should expect
The point of bringing access management and governance into one centralized place is not a prettier access report. It is better business outcomes:
Compliance: More complete access populations and traceable evidence for reviews, approvals and exceptions.
Business enablement: Faster access decisions because policy and approver context are built into the request.
Security: Better visibility into excessive, toxic and unowned access across human and non-human identities.
Operational efficiency: Less manual reconciliation between provisioning, certification and application data.
Affordability: A modular path to broader governance that preserves identity and application investments already delivering value.
The best user provisioning solutions for this problem are not just identity platforms. They are federated governance platforms that deliver one governance framework across identities, ERP, SaaS, AI agents, and business processes.
FAQ
Does federating access governance mean replacing our existing IAM or SSO tool?
No. SSO can continue managing authentication, while IGA, IAM connectors and applications continue provisioning and enforcing access. The governance layer correlates those processes through common policy, risk analysis and evidence.
How do we know if our access controls are actually centralized or just look that way?
Ask a cross‑system question: can the platform show every conflict and high‑risk access for one identity across ERP and connected apps in a single view, with one audit trail. If that requires exporting data from more than one tool and combining it by hand, it is not centralized yet.
Why do cross‑system SoD conflicts get missed so often?
They are missed when identity correlation, entitlement data or policy coverage stops at application boundaries. Some platforms support cross-application analysis, but only for systems and privileges they have onboarded at sufficient depth.
Should service accounts and AI agents go through the same governance process as employees?
They need the same governance principles ownership, appropriate access, risk analysis, review and retirement but not necessarily the same workflow. Non-human identities require purpose,
Where SafePaaS fits
SafePaaS provides a federated governance control plane across existing identity, access and business-application systems.
Rather than requiring every access function to move into another central platform, SafePaaS connects them through:
- A shared policy and SoD model.
- Entitlement-level access visibility.
- Organisational context such as legal entity, ledger and operating unit.
- Preventive risk analysis before provisioning.
- Certifications covering access from multiple provisioning sources.
- Governance for human and non-human identities.
- Traceable evidence from request through remediation.
This architecture allows SailPoint, Okta, ITSM, ERP and SaaS investments to continue performing their established roles. SafePaaS supplies the governance consistency across them.
The objective is not one system performing every identity function. It is one defensible answer to every material access question.
Book time with SafePaaS to see a centralized control plane in action.
