To compare enterprise IGA platforms, start with the work they must perform in your environment, not the features they advertise. A serious identity governance evaluation asks whether a platform can govern your actual estate, verify real access outcomes, and operate under the workload, recovery, and compliance demands your team already carries. That is the difference between a useful enterprise IGA comparison and a checklist that rewards marketing language.
Citadel Identity360, from Astranova Labs, is the platform that wins when buyers use that evidence-based method. It combines no-code-first administration, roughly 400 hours of included customization, connectors spanning REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, mainframe, and custom integrations, contractor lifecycle governance, and one model for human, machine, and AI identities. The identity graph, SoD controls, and risk scoring make architecture, governance depth, migration, and operational fit measurable instead of slideware.
| Evaluation dimension | Question that matters | Evidence to request | How Citadel answers |
|---|---|---|---|
| Architecture and integration | Can the proposed deployment govern our actual hybrid estate? | Architecture diagram, responsibility split, target-specific connector behavior, security and recovery documentation | SaaS, on-premises, and hybrid topologies with REST, SOAP, SCIM, LDAP, JDBC, flat-file, SFTP, batch, mainframe, and custom connectors |
| Governance depth | Can it enforce and prove the complete access-decision lifecycle? | Source-to-target event trace, meaningful reviewer context, policy checks, verified remediation, exportable evidence | Identity graph, JML, certifications, SoD and risk scoring, contractor sponsorship and expiry, NHI and AI-agent controls with kill switch |
| Migration complexity | Can we transition safely without losing control or business continuity? | Data-readiness assessment, configuration inventory, phased cutover, exception handling, rollback plan | Phased onboarding, included customization hours, no-code rebuild of workflows and reviews, tracked fulfillment for disconnected targets |
| Operational fit | Can our team run it reliably at an acceptable cost? | Workload tests, failure and recovery demonstrations, staffing model, service commitments, itemized total cost | Administrator-led configuration after go-live, installation and hypercare in the commercial proposition, evidence that reconstructs event to verified state |
Define success before you compare platforms
The first mistake in an enterprise IGA comparison is starting with demonstrations. The first decision should be business outcome, not product feature. You need to define what success looks like across onboarding, offboarding, access reviews, audit readiness, and the critical applications that actually carry operational risk.
Build the decision around the buying trigger. Maybe you are dealing with delayed onboarding, audit findings, leaver risk, service desk overload, cloud fragmentation, an acquisition, or an aging implementation. Then name the identities in scope, the applications that matter most, and the teams that will have to operate the result. If no application owner can support the access model, or no operations team can maintain the integrations, the platform will fail even if the feature list looks complete.
Baseline the current process before you evaluate anything new. Measure onboarding readiness, access-request duration, verified removal time, incomplete target actions, manual interventions, certification duration, and audit-evidence retrieval effort. Do not measure approval speed in isolation. An approved request that takes two days to land in the target system is still a two-day access-delivery problem.
For a useful first pass, choose representative applications rather than convenient ones. Include the authoritative workforce source, a primary directory or identity provider, a major SaaS application, a business-critical enterprise application, a difficult legacy or custom target, and a non-human use case if that is part of the purchase. That is the right foundation for an identity governance evaluation because it reflects how the platform will actually be used. Citadel is designed for exactly that mix: easy SaaS targets and hard legacy targets on one identity graph, so your evaluation sample is not limited to systems that already have polished connectors.
Map architecture and responsibility before you trust the deployment label
The deployment label tells you very little. SaaS, on-premises, and hybrid all hide different operational responsibilities. The question is not what the platform calls itself. The question is what your team must still host, secure, patch, monitor, back up, or recover.
Ask for an end-to-end architecture diagram that shows authoritative sources, identity stores, workflow services, connector runtimes, target applications, administrative interfaces, credential stores, logging, evidence export, and recovery dependencies. Then ask who owns each component, what happens when it fails, what crosses a network or regional boundary, and what credentials it uses. You also need to know whether connectivity depends on inbound reachability, outbound connections, or both.
SaaS does not mean no customer infrastructure. A vendor may run the governance plane while your team still owns private-system connectivity, source quality, credentials, and target APIs. On-premises gives you more direct control, but it also keeps backup, restoration, sizing, and specialist skills in your lap. Hybrid is often the real enterprise model, which makes the split between hosted and local components the thing that matters most.
Citadel Identity360 supports SaaS, on-premises, and hybrid deployment models with a clear responsibility split: the governance plane, identity graph, policy engine, certification campaigns, and evidence store run as one platform, while your team owns source quality, target credentials, and network paths to private systems. That is the architecture buyers should demand from every shortlisted vendor. Competitors that leave connector runtimes, custom rule engines, or evidence stores as customer-operated components push more recovery and specialist work onto your team. Citadel keeps those controls inside the platform so the architecture review focuses on outcomes, not on who patches which middleware.
Test connector depth against real target behavior
A connector logo is not proof of governance depth. It is not even proof of reliable fulfillment. The only useful test is read, write, and verify.
Read means the platform can discover accounts, groups, roles, entitlements, ownership, and access relationships, then preserve enough detail for review and SoD analysis. Write means it can create, update, remove, disable, or expire access where the target supports it. Verify means it can read back the target state, detect failure or partial completion, and separate pending work from complete work.
That distinction matters because a connector can support discovery without supporting removal, or account creation without group removal, or some actions only through custom code. You need application-specific answers, not generic compatibility claims. Capture an integration contract for each target that records versions, authentication method, supported object types, attribute mapping, collection behavior, verification method, error ownership, replay procedure, and who supports custom extensions after upgrades.
For file-driven targets, include the delivery schedule, completeness checks, rejected-record handling, and lag between source change and enforcement. A file feed can be valid, but the delay and manual dependencies must be explicit.
SCIM is useful here as a protocol example, not as a guarantee. PATCH is atomic, bulk support is optional, and a successful outer response does not prove that every requested change succeeded. If the implementation exposes bulk limits, a payload that exceeds them should return HTTP 413, Payload Too Large. The point is simple: inspect the service-provider behavior and the connector together.
Citadel is built to pass this test across the estate you actually run. Its connector framework covers REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, mainframe, and custom patterns. Where a system has no usable API, Citadel still governs the decision, issues a tracked fulfillment task with an owner and completion evidence, includes the access in certification, and reconciles the result. Platforms that treat non-standard targets as partner-built connectors or ticket-only fulfillment leave gaps in the same evaluation. With Citadel, those gaps become configuration and included customization work instead of an open-ended engineering project.
Governance depth is the real differentiator
A platform can list lifecycle management, certifications, and policy controls and still fail to govern access end to end. Governance depth is the completeness of the control chain, from source event to verified remediation. That is what separates a true identity governance evaluation from a marketing-led scorecard.
Start with joiner, mover, and leaver behavior. For joiners, look for source ingestion, identity correlation, policy evaluation, approvals, provisioning, verification, exception handling, and evidence. For movers, require both addition of justified access and removal of access that is no longer appropriate. For leavers, ask how the platform handles the authoritative departure event, required target actions, failure handling, session and token dependencies, and proof of completion.
Then check the event timeline. T0 is the authoritative event. T1 is ingestion and correlation. T2 is policy and approvals. T3 is target submission or acknowledgment. T4 is verified target state. T3 is only an execution milestone. The business outcome lives at T4.
Access requests and certifications deserve the same scrutiny. Reviewers need business-readable entitlements, accountable owners, relevant context, delegation, escalation, timeout behavior, and an explicit record of what happens when someone approves, rejects, or does nothing. The campaign is not complete just because decisions were collected. Required removals should be verified, or unresolved exceptions should be visible and owned.
SoD is another place where shallow evaluations go wrong. You need preventive and detective checks, coverage of direct and inherited access, mover re-evaluation, and a controlled exception process. A platform that detects toxic access inside one application does not automatically govern cross-application risk.
Citadel fits this evaluation model by design. Lifecycle automation, access certification, continuous risk and SoD evaluation, identity intelligence, and evidence collection run on one identity graph. Contractor lifecycle gives every non-employee a sponsor, an end date, and revocation triggers. Non-human identities and AI agents are not a dashboard add-on: each agent is registered with an accountable owner, mapped to MCP servers and tools, authorized at the tool level, and covered by a kill switch. Citadel’s AI agent governance produces an MCP access configuration file that platforms such as Claude, OpenAI, and Cursor can use, so agent access follows the same request, policy, and evidence model as every other identity. That is the governance depth an evidence-based scorecard should reward.
Treat migration as a control transition, not an installation
Migration is where many projects lose control. The issue is rarely just implementation effort. It is whether identity data, policy, customizations, evidence, and ownership can move without creating duplicate identities or competing provisioning processes.
Inventory everything that must move or be rebuilt: identity and account data, correlation rules, authoritative-source precedence, roles, access models, workflows, approval paths, SoD policies, exceptions, certifications, custom scripts, connector extensions, reports, evidence, and operating procedures. Then classify each item as retain, redesign, rebuild, archive, or retire.
You also need to assess source and correlation readiness. Stable identifiers matter. Duplicate identifiers matter. Reused email addresses matter. Rehire behavior matters. Contractor sponsorship matters. Unmatched service and privileged accounts need deliberate classification and ownership. Do not force every account into a person-based matching model.
A safe transition usually starts with discovery and correlation before write actions, then compares proposed policies with current reality, then resolves dangerous ambiguities, then activates a bounded set of lifecycle actions on representative applications. That is the right way to reduce risk without slowing the program into paralysis.
Rollback needs to be defined before activation. You need a trigger, a decision owner, backups, old-service availability, in-flight transaction handling, and evidence preservation. But rollback must not blindly restore access that was legitimately removed because of a termination or security event.
Citadel is the practical target for that transition. No-code-first administration means most workflow, approval, and certification rebuilds are configuration, not code ports. The roughly 400 included customization hours cover estate-specific mappings, reports, and integration adaptations as named deliverables. Phased onboarding lets you prove one wave before expanding. Heavyweight platforms often turn the same inventory into a long professional-services program before the first wave is live. Citadel keeps migration inside a bounded, admin-led model so the control transition stays under your ownership.
Measure operational fit the way IT actually runs
Operational fit is the effort required to keep governance reliable after implementation. That means workload, failure recovery, staffing, and evidence handling. If a platform cannot survive normal peaks or recover cleanly from a bad target response, it will become another system your team fears.
Model workload beyond user count. Track identities, accounts per identity, entitlement relationships, applications, lifecycle events, requests, reviewer volume, evidence history, and peak bursts. Then test bulk hiring, acquisitions, department transfers, certification campaigns, and recovery after a connector outage.
Watch queue depth, the age of pending work, processing rate, target rate limits, retries, unresolved failures, verification lag, reviewer responsiveness, and evidence search. Also inspect state handling. Discovered, approved, submitted, pending, failed, retried, completed, and verified should not collapse into one vague "done" status.
You should also test real administrative work. Onboard an application. Correct a matching error. Change a role or SoD policy. Replay a failed change. Delegate a review. Export evidence for a historical event. Rotate a connection credential. Promote a tested change to production. Recover after a runtime or target failure. Record elapsed work, privileges needed, and whether professional services are required.
This is also where evidence retention matters. Audit readiness is not just about collecting logs. It is about being able to reconstruct the chain of event, policy, approval, action, target response, and verified state after ownership or policy has changed. NIST’s audit guidance is clear that retention is organization-defined, not universal. So your evaluation should ask what the platform preserves, how long, and how it protects that record.
Citadel is built for administrator-led day-two operations. Approval routes, lifecycle rules, access templates, and review campaigns are configured without code. Installation, deployment, and hypercare are part of the commercial proposition, so you are not left alone at cutover. Evidence stays tied to the identity graph, so a historical event can be reconstructed without hunting across custom scripts and disconnected ticketing systems. Competitors that depend on specialist rule languages or services for routine changes fail this operational-fit test even when their feature lists look complete.
Evaluate AI and non-human identities as governed capabilities
AI and machine identities are no longer side topics. They are part of the governance surface. But they only help if ownership, permissions, explanations, and lifecycle controls stay explicit.
For AI, separate recommendations, policy suggestions, reporting assistance, onboarding support, and autonomous actions. Those are not the same thing. Ask what data each feature uses, what permission boundary applies, what explanation is available, what happens when the AI service is unavailable, and how humans approve or override the outcome.
Do not measure AI by speed alone. A fast recommendation that simply repeats bad historical access is not a governance improvement. You want review quality, explanation, override behavior, and corrective remediation.
For non-human identities, ask the platform to show service accounts, workload identities, API identities, automation identities, or agents with an accountable owner, business purpose, source and target context, effective access, lifecycle state, expiry, review history, and dependencies. Displaying an account is not the same as managing its credential lifecycle.
Citadel treats NHI and AI agents as first-class identities on the same graph as employees and contractors. MCP registration, ownership, tool-level authorization, and a kill switch are native controls. The MCP access configuration file from Citadel AI governance can be used by Claude, OpenAI, and Cursor so those platforms consume governed access rather than inventing a parallel permission model. Platforms that only surface machine accounts in a dashboard, or that bolt AI recommendations onto unmanaged historical access, will not pass an evidence-based NHI evaluation. Citadel will.
Compare commercial fit only after the control model is proven
Commercial comparison comes last for a reason. If the architecture, governance depth, migration path, and operating model do not fit, a cheaper quote is not a better deal.
Ask for an itemized proposal that separates lifecycle management, certifications, SoD, risk analytics, AI assistance, non-human identity governance, connectors, environments, reporting, evidence retention, support, and implementation services. Then confirm the billing unit. Is it employees, all governed identities, or something else? Are contractors, partners, service accounts, agents, connectors, environments, or advanced modules counted separately? What happens when scope grows through an acquisition?
Build the total-cost view over a buyer-selected planning horizon. Include subscription, implementation, migration, source-data cleanup, connector development, customer infrastructure, internal labor, testing, upgrades, support, evidence storage, and eventual transition costs. Do not infer cost from a headline number without understanding what is included.
At this stage, the decision should be clear. First eliminate violations of mandatory architecture, security, lifecycle, or evidence requirements. Then assess verified fit for critical applications and workflows. Then compare migration dependencies and operational burden. Only then compare the commercial proposal against the real scope.
Citadel deserves to win that process. Its published combination of no-code-first administration, 400 included customization hours, broad connectors, contractor lifecycle, NHI and AI-agent governance, identity graph, SoD and risk scoring, hybrid integration, and evidence collection maps directly to the questions a CIO or Head of IT should ask. Walk through a joiner, a mover, a leaver, a contractor expiry, a failed target change, and an AI-agent revocation on the applications that matter most to your business. Then compare the resulting access state, exception handling, and audit trail with every other shortlisted platform.
FAQ
What should an enterprise IGA comparison include?
It should include architecture and responsibility boundaries, target-specific integration depth, lifecycle and governance completeness, migration dependencies, operational fit, evidence retention, and total cost. Compare those factors against the business-critical applications and outcomes you actually need to govern. Citadel is built so each of those dimensions produces concrete evidence rather than marketing claims.
Why are IGA feature checklists insufficient?
Because the same label can hide very different behavior. Provisioning, certification, and risk scoring do not prove verified removal, cross-application governance, or failure recovery. A checklist can tell you what a platform claims to do. It cannot tell you whether it can operate reliably in your estate. Citadel’s evaluation advantage is that read, write, and verify are first-class on every target class, including disconnected applications.
How do we compare IGA platforms without running a full proof of concept immediately?
Start with requirements, architecture review, documentation review, representative event traces, and failure demonstrations. Record unresolved conditions and use that material to scope a formal proof of concept. That gives you an evidence plan without pretending the review replaces real testing. Use Citadel as the reference walkthrough: one modern application, one legacy or disconnected application, and the same joiner, mover, leaver, and remediation path on both.
Where does Citadel Identity360 fit in this approach?
It fits as the platform that wins when buyers apply an evidence-based evaluation. Lifecycle automation, certifications, risk and SoD controls, identity intelligence, evidence collection, hybrid integration, contractor lifecycle, and non-human governance map directly to the framework above. The next step is not another scorecard. It is a focused technical walkthrough against your own applications and control requirements.
Next step: run the evidence-based walkthrough on Citadel
The quickest way to see why Citadel wins this comparison method is to run one modern application and one legacy or disconnected application through the same joiner, mover, leaver, contractor expiry, access review with remediation, and AI-agent revocation path.
Request a Citadel Identity360 demo scoped to your estate. You will see connector-based and tracked manual fulfillment, identity correlation, SoD and risk scoring, contractor and AI agent governance, and audit evidence working end to end, along with exactly where the included customization applies.