Authentication proves an identity can sign in. Provisioning gives that identity access. IGA vs IAM is the difference between those basic access functions and a governed operating process that answers a harder set of questions: who should have access, why they should have it, who approved it, whether it still belongs there, whether it conflicts with something else, and whether the change actually took effect.
That distinction matters more in a hybrid enterprise. You are not governing one identity provider and a neat set of cloud apps. You are governing SaaS, cloud permissions, older systems, contractors, service accounts, machine identities, and AI agents across different control models. That is where modern IGA earns its place.
IGA adds accountable decisions to access delivery
The practical difference is simple: IAM can establish and grant access, while IGA makes access a managed business decision with evidence attached.
In a basic access flow, authentication answers whether the claimant can prove identity, and provisioning answers whether an account or entitlement can be created. In an IGA flow, the organization also has to answer whether the access is appropriate for the role, policy, business purpose, and time period. It also has to show who made that decision and what happened after fulfillment.
That is why the account-versus-entitlement distinction matters. An account is presence in a target system. An entitlement is a specific permission, role, or group membership. If you disable a central login, that does not automatically prove every permission in connected or disconnected systems was removed.
A common failure looks like this: an employee signs in through the identity provider, but after moving from finance to sales, they still retain an approval permission in an older finance application. Authentication is working. Governance is not. A mover workflow, entitlement visibility, conflict checks, business-owner review, and verified removal address that gap.
Here is the control model in plain terms:
|
Reader's question |
Basic access capability |
Additional governance capability |
|---|---|---|
|
Can this identity get in? |
Authentication and access enforcement |
Confirms whether the access is still justified and policy-compliant |
|
Can the requested permission be granted? |
Account or entitlement provisioning |
Applies ownership, approval, least-privilege, and conflict checks |
|
What happened after a change? |
Provisioning event or ticket |
Review decision, remediation status, target-system reconciliation, and audit trail |
The point is not that IAM lacks governance in every implementation. The point is that modern IGA adds sustained accountability, not just initial access delivery.
Lifecycle automation governs joiners, movers, and leavers
The most useful modern IGA workflows start with an authoritative change in status and end with verified access action, not just a submitted request.
For a joiner, an approved hire or contractor record can trigger identity creation or correlation. Attributes such as team, location, employment type, and role inform baseline access. Additional or sensitive entitlements then pass through policy and owner approval. The goal is to have the right access ready at the start of work, without turning a loosely defined role into a blanket grant of everything nearby.
For a mover, the important step is not simply adding new access. It is adding new access and removing obsolete access at the same time. That includes direct grants outside a normal role. It also means checking for segregation-of-duties conflicts and tracking any exception with a reason and expiry that someone can review later. This is the practical defense against privilege creep.
For a leaver, termination or contract-end should trigger account disabling and entitlement removal in the systems within scope. Service ownership, delegations, shared resources, and independently issued credentials may need separate treatment. A submitted request is not proof of revocation. The target system has to reflect the change.
The operating sequence is straightforward: authoritative event, identity correlation, policy or role calculation, approval or exception, fulfillment, reconciliation, recorded result. Scheduled jobs, event-driven triggers, and manual tasks can coexist. What matters is that the workflow is timely and the outcome is verified.
That is also where control guidance stays intentionally flexible. NIST account-management guidance calls for notice when accounts are no longer needed, when someone transfers or leaves, or when need-to-know changes. It also calls for account reviews and alignment with transfer and termination processes. It does not prescribe a universal quarterly cadence or a universal offboarding SLA.
Citadel Identity360 is positioned well here because it describes joiner-mover-leaver provisioning and deprovisioning orchestration, role-based onboarding, access changes on transfer, and SoD checks. Those are the right kinds of lifecycle mechanics for a hybrid estate. As always, target-system behavior still matters, so removal has to be verified in the systems that actually hold access.
Access reviews turn permissions into recurring business decisions
Access review is where governance becomes routine rather than reactive.
A certification campaign is not just a list of names. It is a structured business decision about whether actual access is still needed. Scope matters: which population, which applications, which entitlements, who reviews them, when the campaign runs, and how high-risk access or external users are treated. Reviewers need context, not a raw account dump. They need identity, business role, application, entitlement, owner, purpose, and relevant risk.
The decision can be to retain, revoke, investigate, or record an approved exception. Missing ownership and overdue decisions should escalate. AI can help prepare the reviewer or focus attention, but it should not be confused with the authorized human decision.
The important part is closing the loop. Retained access should have a recorded rationale. Rejected access should create a removal task. The target system should be checked. Failed removals should stay open until they are resolved. A completed campaign and completed remediation are not the same thing.
This is also why “continuous governance” does not mean every entitlement gets immediate human reapproval. Review frequency should reflect risk, policy, and the ability to get current entitlement data. If the data is stale, the review is less valuable. If the entitlement is high risk, the review should be tighter.
Citadel’s published materials describe scheduled certification campaigns, AI-assisted recommendations, escalation and delegated approvals, and evidence gathering. That is a strong fit for organizations trying to reduce manual review effort without losing accountability. Just do not assume any tool can remove the need to verify the target state in the actual application.
For practical measurement, focus on internal indicators such as the share of in-scope entitlements with an owner and completed decision, overdue reviews, rejected grants still present in target systems, and time from revoke decision to verified removal. These are useful operating metrics, not published benchmarks.
SoD, least privilege, and evidence make governance testable
If access governance is worth doing, it has to be testable. That is where least privilege, segregation of duties, and evidence come together.
Least privilege means granting only the access needed for assigned work. Role templates can make that easier, but they do not remove the need to see direct grants, inherited memberships, and changing duties.
Segregation of duties is about incompatible combinations of authority. The classic example is simple: one person should not be able to create a supplier and approve payment to that supplier. The exact conflict matrix belongs to the organization’s policy. There is no universal toxic entitlement name. You have to check both requested and existing access, including permissions spread across multiple applications.
There are two useful control patterns here:
-
Preventive control: flag or block the conflicting request before fulfillment, or require a documented exception and compensating review.
-
Detective control: find an existing conflict during aggregation or review, assign an owner, and track remediation.
A detected alert is not proof of prevention or resolution. It is only proof that someone saw the issue.
Evidence matters for the same reason. A meaningful record should identify the identity and entitlement, the source of the request or lifecycle event, the applicable policy, the approver or reviewer, the decision and time, any exception, the fulfillment result, and verification of target state. Preserve scope, overdue items, escalations, and remediation history. That is what makes a governance record defensible.
Hybrid environments make this harder, not easier. A review cannot assess an entitlement that was never ingested. An audit trail showing approval cannot prove a disconnected application executed the change. You need governed application inventory, real entitlement data, and reconciliation against target systems.
Citadel Identity360 is especially relevant here because it describes SoD and risk-rule evaluation for grants, modifications, and removals, plus automated evidence gathering for reviews and policy-enforcement actions. That is useful audit support. It should be treated as support for demonstrating controls, not as a promise of compliance by itself.
Hybrid governance depends on the last mile
Central visibility is valuable only if the integration path is real.
In hybrid estates, cloud services, SaaS, directories, HR systems, enterprise applications, databases, and older systems all represent accounts and permissions differently. Governance has to correlate the right human or machine identity, bring in the right level of entitlement detail, and identify the owner of each application and sensitive permission.
The most important integration question is whether the connector can read, decide, or write.
Read-only aggregation improves visibility and supports certification. Write-capable integrations can provision or revoke. For a legacy system managed by batch file or manual administration, governance can still initiate and track an assigned action, but it should not pretend the target system was updated automatically.
This is also where operational reality shows up. You have to reconcile the governance record against the target system after changes. Investigate uncorrelated accounts, duplicate identities, stale snapshots, failed jobs, and discrepancies between a requested revoke and an active account. Someone has to own retries and exceptions.
A good evaluation sequence for a CIO is practical: inventory applications and owners, prioritize one high-volume joiner path and one high-risk application, establish event and entitlement feeds, pilot one mover and one leaver case, test one access review and one SoD conflict, then deliberately cause a failed revocation and inspect the evidence and verified target state. That tells you far more than a feature checklist.
Citadel’s integration story lines up with that reality. It describes connector patterns across cloud, SaaS, enterprise applications, directories, databases, APIs, SCIM, LDAP, JDBC, and file exchanges. It also explicitly notes that operations vary by target and connector, and that direct provisioning depends on the target’s capability. That honesty matters because hybrid governance fails when vendors overstate what every system can do.
Non-human identities need governance too
Modern identity governance is no longer just about people.
Service accounts, API identities and keys, automation accounts, machine identities, cloud workloads, and AI agents can carry meaningful access without a human ever logging in interactively. If you do not govern them, you can end up with powerful access that no manager review process ever touches.
The right approach is to inventory each identity, define what owns or uses it, document its permissions and dependencies, and track its creation, change, rotation or credential-management responsibility, and retirement path. A human-manager approval process does not map cleanly to every workload, so you need governance that reflects the actual operating model.
A simple example makes the risk clear. An automation account created for a migration keeps broad cloud permissions after the migration ends. Authentication may still work perfectly. The real questions are whether the workload still exists, who owns the account, whether the access is still necessary, and how to retire it without breaking a dependent service.
The OWASP 2025 non-human-identity risk list is useful here because it highlights issues like improper offboarding, secret leakage, overprivileged identities, reuse of one identity across systems, and people using non-human identities. It is a risk taxonomy, not proof that every enterprise has every problem. Governance ownership still needs to be paired with credential storage, rotation, and runtime secret delivery controls.
Citadel Identity360 fits this model by describing governance for service accounts, API keys, machine identities, and AI agents with accountable ownership, discovery of AI agents from major cloud identity registries, and registration of AI agents and MCP servers with ownership and tool-level authorization. That is the right level of control to expect from an IGA platform. It should not be presented as a vault or rotation engine for every machine credential.
What a buyer should test first
If you are evaluating modern IGA, start with the paths that expose the real operational model.
Test one joiner-mover-leaver flow end to end. Test one high-risk access review. Test one SoD conflict across applications. Test one failed revocation. Then inspect the evidence and the verified target state. That is where the platform’s real value shows up.
You should also verify which integrations are read-only, which can act, and who resolves failures. If the platform cannot reconcile target state, the governance record will always be incomplete. If it can only review access but not coordinate removal, the remediation burden stays high. If it can support AI recommendations, make sure those recommendations are explainable, overrideable, and logged rather than treated as automatic approvals.
The broader point is that IGA is not there to add approvals for their own sake. It is there to make timely access delivery, continued justification, removal, and proof of action part of one accountable operating process across the hybrid estate. That is the real answer to IGA vs IAM.
Citadel Identity360 is worth examining on that basis because it brings lifecycle workflows, contextual reviews, SoD and risk checks, audit evidence, and human-plus-machine oversight into one model. If your highest-priority applications and remediation paths are the test, you will see quickly whether the governance model fits your estate.
FAQ
Does IGA replace our identity provider?
Not inherently. Governance can use identity and lifecycle signals while existing authentication and enforcement systems keep doing their job. Whether anything gets consolidated depends on the estate and implementation.
Does a completed access review automatically remove risky access?
Not necessarily. The reviewer decision, fulfillment method, and verified target-system result all have to be checked. Some legacy systems still require tracked manual work.
Is quarterly recertification always required?
No. The control guidance referenced here does not set a universal interval. Review timing should follow risk, policy, and the reliability of the data you can actually review.
Can AI recommend access for a manager?
Yes, as decision support if policy allows it. It should be explainable, overridable, logged, and tested. It should not be treated as an unreviewed approval unless your policy explicitly says so.