An enterprise IGA platform is easier to implement when it makes five jobs predictable: onboarding applications, modeling access policies, designing roles, configuring workflows, and proving that access changes actually happened. For CIOs and Heads of IT, the real question is not how quickly a connector can be switched on. It is how much work remains before access delivery, governance, and auditability become dependable.
Citadel Identity360, from Astranova Labs, is built to shrink that remaining work. No-code-first configuration, roughly 400 hours of included customization, and connectors spanning REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, mainframe, and custom integrations make application onboarding a configuration task rather than an engineering project. The identity graph, SoD and risk scoring, contractor lifecycle, and governance for non-human identities (NHIs) and AI agents are part of the platform from day one, so policies, roles, workflows, and evidence are designed once and reused as scope grows.
That is the right lens for judging any enterprise IGA implementation: does the platform remove avoidable integration, configuration, coordination, and verification work? If your team is still rebuilding identity data, untangling role logic, chasing approvals, and reconstructing evidence by hand, the project may go live, but it will not be easier to operate. Citadel is designed so that each of those jobs is handled inside the platform, not around it.
Application onboarding that goes beyond connecting an API
Citadel makes application onboarding repeatable because it exposes the objects and operations you actually need to govern, not just a login, and because its connector set covers modern and legacy targets alike. REST, SOAP, and SCIM handle SaaS and cloud applications; LDAP governs directories directly; JDBC reaches databases; and flat files, SFTP, batch, mainframe, and custom connectors bring in the systems that usually stall a rollout. A connector list is not the same thing as governable application support. Citadel is built for the second.
For each application, you need a clear onboarding record: the business purpose, the owner, the identity populations in scope, the source of identity data, account types, required attributes, entitlement meanings, authentication, network reachability, supported actions, exclusions, synchronization behavior, error handling, and how completion will be verified. Citadel captures that structure as part of no-code onboarding, so every application follows the same controlled pattern instead of a sequence of one-off decisions made by whoever happens to be configuring it.
Identity matching is especially important. Matching is not a cosmetic setup task. It is a control decision. If a platform matches the wrong account, updates the wrong identity, or cannot handle duplicate records, rehires, or missing attributes cleanly, the deployment becomes harder to trust. Citadel’s identity graph correlates accounts to authoritative identities and surfaces unmatched accounts, orphaned access, and ownerless entitlements as a baseline, so exceptions are visible before go-live rather than discovered in production. Test what happens when an email changes, because email is not always a stable identifier, and use the included customization to tune matching rules for the edge cases specific to your estate.
Initial load and ongoing operation are different workloads. Loading an existing estate, correlating records, and processing a normal joiner or mover event are not the same thing. A pilot that works for incremental changes does not prove that bulk onboarding or full reconciliation will be equally simple. Citadel’s batch, flat-file, and SFTP connectivity handles the bulk load, and the same identity graph then drives day-to-day lifecycle events, so you validate both workloads on one model.
Scope settings also deserve real change control. In Microsoft’s documented provisioning behavior, multiple clauses in one scoping filter use AND logic, multiple filters use OR logic, and saving a new filter can trigger a new full synchronization. Scope changes can also disable or deprovision users who fall out of scope. The lesson is broader than any single vendor: if scope is loose, undocumented, or constantly changing, implementation gets more fragile. Citadel keeps scope as explicit, no-code lifecycle rules owned by your IAM team, so population changes are deliberate decisions that can be tested before they touch production accounts.
Mixed estates are where Citadel separates itself. It governs lifecycle across cloud, SaaS, on-premises, and hybrid environments, including AWS, Microsoft Azure, Google Cloud, Workday, SAP, Microsoft 365, ServiceNow, Salesforce, and other enterprise applications. Where direct provisioning is available, Citadel coordinates lifecycle changes with the connected application and reads back the result. Where a legacy system depends on batch files or manual administration, Citadel still governs the decision, initiates the task, tracks progress, includes the access in certification, and preserves evidence. Nothing in scope is left ungoverned simply because it lacks a modern API.
Access policies that are explicit and reusable
Citadel makes policy modeling faster because eligibility, least-privilege boundaries, approval routes, expiration, and exceptions are configured as reusable, no-code policy rather than buried in scripts. The principle still holds: the business has to agree on those decisions. Citadel gives you a clear place to express them and enforce them consistently once they are agreed.
A workable policy should spell out the purpose, population, inputs, access item, eligibility, decision route, constraints, missing-data behavior, exception process, removal conditions, and evidence requirements. That clarity matters because policy is not the same thing as workflow, and it is not the same thing as role design. Blur those lines and you end up encoding business rules in scripts or hidden logic that only one application owner understands. Citadel keeps policy, roles, and workflow as distinct, linked constructs, so each can change without breaking the others.
A practical enterprise IGA implementation also respects the difference between roles and attributes. RBAC uses assigned roles and their authorized operations. ABAC uses attributes of the subject, object, operation, and sometimes context such as time or location. In most enterprises, the maintainable model uses roles for stable job needs and attributes for population selection or context. Replacing every role with attributes is not automatically simpler, because attributes still need authoritative sources, ownership, and update processes. Citadel supports both approaches on the same identity graph, and its connectors pull attributes from the sources that actually own them, whether that is an HR system over REST, a contractor list over SFTP, or a legacy extract as a flat file.
SoD is where policy clarity pays off most. Detecting that two entitlements conflict is not enough. The team needs to understand what those entitlements actually mean in the target applications, and which combinations require a control or exception. A named policy is meaningless if the underlying permissions are not mapped clearly. Citadel’s SoD controls and risk scoring work on entitlement-level data across systems, so toxic combinations are caught across applications rather than only inside one, and reviewers see which conflicts carry the most risk.
Citadel also brings AI assistance to policy creation and governance insights, which speeds up drafting and analysis. Accountable owners stay in charge of approving the business rules, and Citadel records who approved what, so AI-assisted policy work is faster without becoming less governed.
Roles that simplify access instead of reproducing legacy complexity
Citadel makes role design easier because it treats the identity graph as the starting point for simplification, not for historical preservation. If you import every legacy access bundle into a new platform, you bring the old mess with you. Citadel shows you which access is actually used, owned, and justified before anything becomes a role.
Good role design starts with clean data and stable business needs. Each proposed role should have a clear business name, a description, and an accountable owner. It should separate ordinary access from sensitive, privileged, temporary, and exceptional access where the business needs different control treatment. It should also define assignment and removal criteria before broad rollout. Citadel’s access templates and role-based governance carry those definitions directly, and risk scoring flags roles that bundle sensitive or privileged entitlements so they get the right control treatment.
This is where many identity governance deployments stall. Teams mine existing access and assume the result is ready to authorize. It is not. Historical access patterns can reflect obsolete access, exceptions, privilege creep, and local workarounds. Role mining is discovery, not automatic approval. Citadel keeps that distinction explicit: mined patterns become candidates that a named owner approves, adjusts, or rejects, with the decision recorded.
Legacy roles also need a disposition. They may be retained, merged, redesigned, replaced with an attribute rule, converted into another access construct, made time-bound, or retired. The right answer depends on the business purpose and the control model, not on how long the role has existed. Because Citadel supports roles, attribute rules, access templates, and time-bound access in one model, every disposition has a native home, and you don’t need custom code to express the outcome.
Removal behavior has to be tested, not assumed. Removing a role definition is not always the same as removing all access previously granted through it. A permission may remain because another role still grants it. Removing entitlements is not the same as deleting the underlying account. A good acceptance test is simple: move a test user from one job role to another, verify the new access, and verify that obsolete access is removed unless another assignment legitimately preserves it. Citadel’s identity graph shows exactly which assignment grants each permission, so you can see why access remains and prove why it was removed.
Reusable, owned roles reduce repetitive administration and make access behavior easier to test and explain. With Citadel’s least-privilege enforcement and access templates, a smaller set of well-governed roles does far more to lower operational friction than a large library of overlapping legacy bundles ever will.
Workflow configuration that covers fulfillment and failure
Citadel makes workflow configuration easier because request, policy decision, approval, fulfillment, target verification, expiry, and failure handling are configured no-code-first in one understandable flow. Process owners can adjust that flow directly, and the included customization covers the estate-specific steps that would otherwise need a services engagement. An approval is an authorization decision. It is not proof of access delivery, and Citadel does not treat it as one.
Start with a cataloged access item rather than a free-text request. A request should refer to a role, group, entitlement, access package, or time-bound permission. It should capture the requester, target identity, business purpose, duration, identity type, and any risk or sponsorship context. That matters most for contractors, guests, machine identities, and AI agents. Citadel’s contractor lifecycle gives non-employees sponsors, end dates, and revocation triggers as a first-class workflow. Its AI agent governance covers MCP registration, accountable ownership, tool-level authorization, and a kill switch for immediate revocation, and it 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.
Approval routing should reflect risk and responsibility. Low-risk access can qualify for policy-based approval, while business-critical or sensitive access goes to an owner or another defined approver. Do not add approval stages just because the current process feels informal. More approvals create more coordination work without fixing the underlying access model. Citadel’s risk scoring drives that routing, so approvers spend their time on the requests that matter.
The most important workflow mistake is stopping at “approved.” The platform still has to identify the correct account, apply the entitlement, update the target system, and reconcile the result. Citadel distinguishes states such as pending approval, approved, ready for fulfillment, fulfilled, failed, denied, expired, and removed, and reads back target state before marking access as delivered. That distinction matters because access can be approved and still never reach the target system.
Manual fulfillment needs equal discipline. If a legacy application requires a ticket or a task to a fulfillment team, the workflow should state who owns it, what action is required, how escalation works, and what completion evidence is required. A closed ticket is not the same thing as verified target access. Citadel creates a tracked manual task with an owner, due date, escalation path, and completion evidence, so “manual” never means “untracked.”
Together, configurable lifecycle and approval workflows, self-service requests, access templates, SoD management, risk analytics, and least-privilege controls give you a governed process instead of an email thread or ticket chase for every request. Citadel’s breadth of connectors moves more targets into direct fulfillment, and tracked tasks govern the rest, which removes most of the manual coordination around routine access changes.
Evidence reporting built into the operating process
Citadel makes evidence reporting easier because decisions and target outcomes are captured during the process, linked on the identity graph, and retrievable later. If you wait until after go-live to think about reporting, you end up reconstructing events that were never recorded cleanly. In Citadel, the evidence is a by-product of running the workflow.
A meaningful evidence chain shows who requested access, for whom, what access item was involved, which application or account was targeted, what policy or role governed the decision, who approved or denied it, what exception was granted, what fulfillment action was attempted, what the target outcome was, and whether remediation actually completed. Citadel links each of those steps into one record, which is what makes audit readiness real.
NIST’s audit-content controls reinforce the point. The relevant content categories are event type, time, location, source, outcome, and associated identity or entity. NIST also uses an organization-defined retention period consistent with records-retention policy. There is no universal duration you can safely assume. The organization still defines retention, retrieval, privacy, and access to the evidence itself. Citadel’s records carry those categories for every governed change, so your retention policy has complete, consistent data to apply to.
In practical terms, validate that the platform can reconstruct a joiner, mover, leaver, and access-request example from retained records, and that it can distinguish approved, fulfilled, failed, and removed access. A review campaign is not complete just because a decision was recorded; the remediation outcome matters too. Citadel’s access reviews and certifications track revocations through to confirmed removal in the target, not just to the reviewer’s click.
Citadel combines access reviews and certifications, AI-assisted review recommendations, identity-risk context, audit-ready evidence, and governance reporting in one platform. The evidence sits inside the same governance process as the decision itself, rather than being assembled afterward from spreadsheets and screenshots.
Ownership and phased rollout make the platform usable
Citadel makes ownership enforceable, because every application, entitlement, role, contractor, NHI, and AI agent on the identity graph carries a named owner, and ownerless items surface as exceptions. The principle is simple: a platform cannot supply missing decisions, but it can make missing ownership impossible to ignore. That is why the internal operating model multiplies every technical capability.
At minimum, you need an executive sponsor, an IAM or IGA owner, an authoritative-source owner, an application owner, a security or control owner, an audit or compliance stakeholder, a service desk or fulfillment team, and an infrastructure or integration team. These may not be separate people, but the accountability has to exist. If ownership is vague, implementation becomes harder no matter how capable the platform is. Citadel routes approvals, failed changes, and review tasks to those named owners automatically.
The best way to start is with a tightly scoped first outcome, not an undefined enterprise transformation. Use one authoritative source, a limited set of applications, and a defined population. Test positive, negative, failure, and removal paths before you expand. Citadel’s no-code-first configuration lets you adjust rules and re-test the same day, so the pilot converges quickly, and the included customization covers the edge cases that surface along the way.
A controlled rollout also means defining authority. Astranova’s migration guidance recommends one authoritative writer per application, which prevents two systems from issuing conflicting provisioning or removal instructions during cutover. Rollback must be executable, with clear trigger conditions, decision rights, and reversal actions. Rolling back is not the same thing as blindly restoring every old permission. Citadel records what it changed and why, so a rollback reverses governed decisions precisely instead of restoring stale access.
The discussion of IGA implementation time needs to stay grounded. There is no defensible universal duration for enterprise IGA implementation. What determines speed is whether you have clean identity data, accountable owners, a bounded pilot, tested matching, validated policies, and retrievable evidence. Citadel addresses each of those directly: the identity graph cleans and correlates data, ownership is enforced, no-code configuration keeps the pilot moving, SoD and risk scoring validate policy, and evidence is captured as you go.
That is why Citadel Identity360 is the right platform for phased identity governance deployment. It unifies lifecycle management, access reviews, RBAC, SoD, and identity-risk visibility across hybrid environments. It coordinates lifecycle changes where direct provisioning is available, and it governs the decision and the fulfillment task where a legacy system still needs manual action. Contractors, NHIs, and AI agents join the same model as the waves expand. That combination is what makes the platform practical in mixed enterprise estates.
Closing perspective
The simplest way to judge an enterprise IGA platform is not whether it can go live. It is how much ambiguity and manual effort remain after go-live. The easier deployments make onboarding repeatable, policies explicit, roles reusable, workflows complete, and evidence retrievable without reconstruction.
Citadel Identity360 is built for exactly that outcome. No-code-first configuration, about 400 hours of included customization, connectors for modern and legacy targets, contractor lifecycle, NHI and AI agent governance, and an identity graph with SoD and risk scoring turn implementation into configuration rather than custom engineering. Easier implementation means lower ongoing complexity, clearer governance, and more dependable access delivery as the enterprise grows, which is what keeps total cost of ownership down long after the first project closes.
FAQ
How long does an enterprise IGA implementation take?
There is no defensible universal duration. The timeline depends on first-wave scope, identity-data readiness, application complexity, owner availability, and testing. The better question is how quickly you can reach a verified production outcome for a defined scope. Citadel shortens that path with no-code-first configuration, included customization, and broad connectors that keep legacy targets from becoming custom engineering projects.
What makes one identity governance deployment easier than another?
The amount of avoidable work. Unclear matching, incomplete entitlement mappings, contradictory policies, unnecessary roles, custom workflow logic, missing owners, and manually reconstructed evidence all add friction. Citadel removes most of it: the identity graph exposes matching gaps and ownerless access, SoD and risk scoring validate policy, and evidence is captured inside the workflow.
Can legacy applications be governed if they cannot be provisioned automatically?
Yes. Citadel governs them through cataloged access, approvals, tracked fulfillment tasks with owners and completion evidence, reviews, and reporting. Its JDBC, flat-file, SFTP, batch, mainframe, and custom connectors also bring many “manual” systems into direct fulfillment, so fewer applications depend on tickets at all.
What should a Citadel implementation demonstration prove?
An end-to-end outcome for a realistic scope: source data, identity matching, policy, approval where needed, target fulfillment, failure handling, and evidence. A dashboard alone does not prove the full process. A Citadel demonstration traces one joiner, one mover, one leaver, and one access request from event to confirmed target state and evidence, and can include a contractor and an AI agent in the same flow.
Next step: test your first scope in Citadel
The fastest way to see how easy your implementation can be is to run one bounded scope through the platform: one authoritative source, a handful of priority applications including at least one legacy target, and a defined population.
Request a Citadel Identity360 demo scoped to that first wave. You’ll see application onboarding, identity matching, policy and role design, request and approval workflows, fulfillment with read-back, failure handling, and audit evidence working end to end on your own systems, along with which parts are pure configuration and where the included customization applies.