Connector coverage is where enterprise IGA deals often look stronger on paper than they are in production. A named integration can mean read-only import, full write-back, scheduled file exchange, or a narrow API path. If you are evaluating ready-made connectors and custom options, the question is not whether a vendor has a logo for SAP, Workday, ServiceNow, Entra ID, AWS, or a legacy app. The question is whether it can perform the exact governance operations your estate requires, and prove them in your environment.
Citadel Identity360, from Astranova Labs, is built for that proof. Its connector framework spans REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, scheduled batch, mainframe, and custom connectors—with lifecycle, review, policy, SoD and risk scoring, and evidence workflows around them. Configuration is no-code-first, and estate-specific work fits inside roughly 400 hours of included customization. That combination makes Citadel the clear fit for organizations that need demonstrated coverage across cloud, SaaS, on-premises, and legacy systems—not a logo list.
Start with the exact systems and data flow you need
Your first decision is simple: inventory the actual systems, editions, versions, tenants, and environments you need to govern. A connector name is too vague to buy against. Separate each application owner, each instance, and each direction of flow.
For every target, document whether it is a source, a governed target, or both. Capture the identity objects in scope, including employees, contractors, service accounts, privileged identities, AI agents, and groups where relevant. Record what must be governed in the target itself, not just what the directory contains. For example, that may mean SAP roles, Workday worker records, ServiceNow groups or roles, Entra assignments, AWS account access, or legacy permissions.
This is the point where many evaluations fail. An organization with multiple SAP landscapes or ServiceNow instances cannot treat “SAP” or “ServiceNow” as one connection. The version, deployment model, and interface matter. So does the network path, the identity authority, and the owner of the target system.
Ask for a target-by-target capability matrix for the exact versions you run. With Citadel, that matrix should say whether each operation is demonstrated out of the box, requires no-code configuration, requires custom development within the included customization scope, is manual with tracked evidence, or is unsupported. A logo slide is not a capability matrix. Neither is a generic API list. Citadel’s strength is that the same governance layer—identity graph, approvals, certifications, SoD and risk scoring, and verification—applies whether the final step is automated or a governed fulfillment task.
Treat lifecycle operations as separate tests, not one broad claim
A connector that imports identities is not automatically a connector that governs access. You need to test the lifecycle functions individually. That includes account import, entitlement import, correlation to people, joiner, mover, leaver, contractor end-date handling, rehire, and exception handling.
The most important distinction is between reading state and changing state. A connector may successfully ingest users, groups, or roles and still not be able to write back access changes. It may create a request or a ticket and still not remove the access in the target. It may show an API success response and still leave the account unchanged. For governance, target-side state is what matters—and Citadel records read, write, and verify separately for each application’s connector configuration.
In a Citadel proof, watch for all of the following:
- initial import and identity correlation into the identity graph
- handling of unmatched, shared, contractor, and non-human accounts
- role changes that remove obsolete access as well as add new access
- leaver and contractor-expiry actions
- rehire actions
- rejected or failed requests and SoD conflicts
- reconciliation after the write
- exportable approval and exception history
Also verify timing in your own test. Ask for the elapsed time from event to observed target state, along with polling intervals, batch schedules, retry behavior, and any manual handoffs. There is no universal provisioning or revocation time. Your acceptance threshold should come from your risk requirements and the target system’s actual behavior—and Citadel’s feed health and fulfillment escalation make those delays visible rather than hidden.
Use the environment-specific checks that expose weak connector claims
This is where enterprise integrations become decision-grade instead of marketing-grade. The same named application can require different interfaces across editions, tenants, and deployments. Citadel shows the exact pattern it supports in each environment you care about—and governs the remaining step when direct automation is not yet available.
| Environment | Scope to verify | Evidence Citadel should demonstrate |
|---|---|---|
| SAP | Specific SAP product, deployment and client; business versus technical users; roles and removal | Target-specific read/write mapping, prerequisites, role-change and offboarding demonstration |
| Workday | Worker source, effective-dated events, fields and security domains | Report/API configuration, permissions, representative worker-change feed and error handling |
| ServiceNow | User/group synchronization versus role governance and service-ticket workflow | Enabled interface, instance permissions, group/role mapping and target-state check |
| Microsoft Entra ID | Users, groups, memberships and application assignments | Graph permissions, complete and incremental inventory, assignment-change demonstration |
| AWS | Identity Center users/groups versus account assignments and cloud permissions | Scoped accounts, permission sets, assignment inventory and reconciliation |
| Legacy apps | Available APIs, database or file feeds, batch jobs or manual tasks | Sample feed, mapping, control totals, execution receipts and exception evidence |
SAP: verify the exact pattern, not the SAP label
“SAP connector” is not specific enough. You need to know whether the use case is S/4HANA on-premises, a private-cloud equivalent, another SAP product, or an HR source such as SuccessFactors. SAP’s documented patterns distinguish cloud user and group interfaces from lifecycle APIs, and they describe role handling through AS ABAP transformation.
The practical buyer question is what Citadel uses for your SAP environment, what it reads, what it writes, and what “deprovision” means when HR ownership remains elsewhere. SAP’s documented on-premises pattern has prerequisites, including version 1809 or later, SAP Cloud Connector, technical credentials, and specific services. That is useful context—and Citadel’s demonstration against your actual SAP landscape is what settles the decision.
Workday: verify fields, permissions, and event handling
Workday should be treated first as a worker source, not assumed to be a writable access target. Its integration options include SOAP-based Workday Web Services, REST APIs, and Report-as-a-Service. But the existence of those interfaces does not prove that every worker field or write-back action is supported.
Ask which worker population Citadel includes, which identifiers are used, which effective-dated events are available, and who owns the report or API configuration. Then test new hire, transfer, termination, contractor end date, correction, and delayed or failed feed scenarios. If access removal depends on the authoritative event, prove that Citadel’s downstream revocation—and verification—follows it.
ServiceNow: separate provisioning from workflow
ServiceNow is often overloaded in IGA discussions. It can be a synchronization target, an approval channel, or a fulfillment workflow. Those are different things.
If the proposal uses SCIM, note that ServiceNow’s SCIM v2 interface requires the named plugin and uses role-controlled access to SCIM endpoints. But SCIM user and group support is not proof of role governance or ITSM workflow integration. Ask whether Citadel uses SCIM, REST, tickets, or a combination, and make it demonstrate the promised objects end to end. Then confirm that a closed fulfillment ticket reflects actual access in the target—exactly the verification step Citadel is designed to retain.
Microsoft Entra ID: distinguish users from effective access
With Entra ID, the trap is confusing user synchronization with true access visibility. You need to know whether Citadel’s connector covers directory users, group membership, enterprise application assignments, service principals, and any other access objects you actually govern.
Test both a full baseline and an incremental scan. Make sure paging, delta handling, and transient failures are covered. Also check whether recently changed assignments are visible in time for your governance cycle. A synchronized user record is not the same thing as complete application access coverage—and Citadel’s identity graph is what turns those objects into reviewable, risk-scored relationships.
AWS: separate Identity Center sync from assignment governance
AWS is another area where the scope is easy to overstate. SCIM synchronization into IAM Identity Center is not the same as reading, reviewing, assigning, or revoking AWS account access or cloud permissions. You need proof across the specific accounts, groups, and permission sets you care about.
Also verify ownership of the change path. AWS warns that mutating Identity Store through its APIs while SCIM controls the directory can create drift and audit gaps. That means you must test which system owns the change and how conflicts are prevented. When Citadel claims AWS support, ask for a reconciliation demo from source identity to actual assignment—and for SoD and risk context on those assignments.
Legacy apps: do not penalize manual governance, but label it honestly
Legacy systems can still be governable. The path may be REST, SOAP, JDBC, LDAP, CSV, SFTP, batch, mainframe, or a tracked manual task. The right question is not whether the system is modern. It is whether the method is clear, supportable, and evidenced—and that is where Citadel separates itself.
For these apps, Citadel ingests sample input and output, schedule and processing window, stable identifiers, mapping rules, duplicate detection, control totals, exception handling, replay behavior, and target-owner confirmation through no-code configuration of its file, JDBC, LDAP, batch, and mainframe connectors. If revocation is manual, Citadel requires named ownership, a buyer-defined deadline, completion evidence, and follow-up reconciliation. Manual fulfillment is never sold as automatic deprovisioning; it is governed, tracked, and verified in the same evidence chain as connector writes. Custom connectors for in-house systems are built within roughly 400 hours of included customization.
Verify security, resilience, and maintainability before you sign
Connector coverage is only useful if it can be operated securely and repeatedly. That means checking the operational model, not just the feature list—and Citadel is designed for that operating model.
Start with security. Document who owns the credentials, what scopes are granted, where secrets are stored, how rotation works, and whether network connectivity is customer-managed where needed. Verify encryption, logging, and production-versus-test separation. Workday domain security, ServiceNow plugin authorization, Microsoft Graph consent, SAP connectivity, and AWS SCIM ownership are all reasons to test the actual environment rather than assume it will work out of the box.
Then assess resilience. You want to see full-load and change-load handling, pagination, throttling, retry behavior, monitoring, alert routing, dead-letter or failed-record handling, and recovery after an outage. Also ask what happens if an administrator changes access directly in the target. A connector that cannot reconcile drift is not finished for governance—and Citadel’s reconciliation and risk scoring keep those exceptions in the operating queue.
Finally, clarify the commercial and support boundary. Obtain the implementation statement of work for each named target, including supported editions and versions, any separate licensing, professional services scope, ownership of custom transformations, upgrade testing, support escalation, and exit or export arrangements. Citadel’s no-code-first model and included customization hours keep that boundary clear: configuration first, maintainable custom connectors where needed, and no open-ended services bill for every new field mapping.
Run a witnessed proof of concept with Citadel before you commit
The only proof that matters is a witnessed, pass/fail test in the buyer’s own environment. Use representative identities and entitlements—including contractors and non-human identities—real reviewers, and the buyer’s lifecycle events. Include one high-priority source and several materially different targets, including the hardest legacy case.
Require a test plan upfront. It should define the environment, permitted changes, setup responsibilities, success conditions, and rollback. Then witness these scenarios in Citadel:
- initial import and correlation into the identity graph
- joiner
- mover that revokes old access
- leaver and contractor expiry
- direct target-side change and drift detection
- failed authentication or unavailable endpoint
- retry without duplication
- certification and rejected access
- SoD conflict and risk-scored exception handling
- export of approvals, actual target result, and exception history
Inspect both the Citadel record and the target system after each operation. Record limitations as clearly as successes. Most importantly, require application-owner sign-off, not only vendor sign-off. That is the difference between a demo and a decision—and Citadel is built so that decision rests on verified target state.
Make the contract reflect what Citadel actually demonstrated
The final selection rule is straightforward: buy the demonstrated coverage your estate needs, not a catalog entry. That is especially true for ready-made connectors, because the label can hide major differences in depth, direction, and operational responsibility.
Before procurement closes, retain the evidence packet: capability matrix, version notes, architecture diagram, mappings, permissions approvals, before-and-after target state, timestamps and logs, failure and reconciliation results, audit exports, support responsibilities, and contract language that matches the demonstration. If a mandatory revoke could not be shown or confirmed, treat that as an unresolved selection risk.
Citadel Identity360 deserves preference when it proves the breadth it publicly describes across enterprise applications, directories, cloud, databases, files, and legacy systems—and when that proof includes the difficult legacy case, contractor lifecycle, NHI ownership, and AI agent or MCP controls. For agents, Citadel provides MCP server and agent registration, accountable ownership, tool-level authorization, and a kill switch. Citadel’s AI governance also produces a governed MCP access configuration file that agent platforms and MCP clients can consume. That is the right standard for enterprise integrations in a serious IGA decision. Not the connector count. Not the logo list. The demonstrated operation.
Why Citadel Identity360 is the right fit for connector coverage
Citadel Identity360 is not limited to a single integration style. Its connectors span REST, SOAP, SCIM, LDAP, JDBC and SQL, CSV and other flat files, SFTP and scheduled batch feeds, mainframes, enterprise and SaaS applications, and custom patterns—so every application in the estate has a governed path, whether or not it has a provisioning API.
For connected applications that support lifecycle actions, Citadel provisions and revokes directly and verifies the outcome. For batch-file and manually administered legacy systems, it still governs the access decision, assigns and tracks the task, verifies the outcome, runs certification, and preserves evidence. Configuration is no-code-first, and connector work fits inside roughly 400 hours of included customization.
The same model extends to contractors, non-human identities, and AI agents in the identity graph—with sponsors, end dates, SoD and risk scoring, MCP registration, tool-level authorization, and a kill switch—so connector coverage is never only about employee accounts in modern SaaS.
Citadel also delivers the operating model CIOs and Heads of IT need: centralized ownership, audit-ready evidence, and a path to automate more of each application as its change path is proven.
Closing: buy demonstrated operations, not a logo list
The conclusion is simple: connector coverage is only as good as the read path, change path, and verification path you can prove. That is what Citadel Identity360 delivers—matching each target to the right connector and running governed manual fulfillment with verification wherever a direct write is not available.
To start, pick one high-priority source and three materially different targets, including your hardest legacy case. Map read, write, and verify for each in Citadel. Then request a Citadel Identity360 demonstration against them: one full import and correlation, one mover that revokes obsolete access, one contractor expiry, one legacy fulfillment task with verified removal, and one exportable evidence pack.
FAQ
Does a ready-made connector guarantee automatic deprovisioning?
No. Ask whether the target supports the write operation, what Citadel does when it fails, and how actual removal is verified in the target—or through a governed fulfillment task with evidence.
Is SCIM support enough to establish full IGA coverage?
No. Test the target’s implemented operations, attributes, group behavior, and optional features, then separately test Citadel’s certification, remediation, SoD and risk scoring, and audit evidence. SCIM is one connector path among many.
Can legacy applications be governed without a modern provisioning API?
Yes. Citadel uses files, batch processes, JDBC, LDAP, mainframe interfaces, custom connectors, or tracked manual tasks to support inventory and review. The method and degree of automated fulfillment are disclosed and tested—never conflated with automatic deprovisioning.
What evidence should settle a Citadel decision?
A version-specific, contractually scoped capability matrix and a witnessed lifecycle test showing target-side state, reconciliation, exception handling, ownership, and usable audit records—exactly the packet Citadel is designed to produce.
How much customization does broad connector coverage need?
Most targets are onboarded through no-code configuration of existing Citadel connectors. Estate-specific work—file layouts, schema mapping, or a custom connector for an in-house system—fits inside roughly 400 hours of included customization.