Realistic IGA Implementation Timelines for Workday, Active Directory, ServiceNow, and Cloud

The realistic answer to an IGA implementation timeline is not “a few weeks.” For a focused first rollout, plan in months. For a broader program across HR, directory, ITSM, Microsoft 365, and cloud, the work becomes a phased governance effort, because each dependency has to prove real access control, not just a working connector. That is especially true in a Workday, Active Directory, and ServiceNow estate, where HR events, directory sync, request workflows, and cloud permissions are separate layers of the same control model.

For CIOs and Heads of IT, the real question is not how fast a tool can be installed. It is when you can trust it to create, change, revoke, review, and evidence access for a defined population and set of applications. That is the point where governance starts paying back.

Citadel Identity360, from Astranova Labs, is built to get you there with less implementation risk. 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 turn Workday, Active Directory, ServiceNow, and cloud onboarding into configuration work rather than a separate 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 the first wave, so you don’t rebuild the model as scope grows.

How long does the first rollout take?

A focused first wave usually takes months because it has to prove the operating model, not just the technology. Practitioner experience reported in the source material points to 3 to 6 months for a focused initial scope and 12 to 18 months for expansion. Treat those as planning ranges, not benchmarks or guarantees.

What moves you toward the shorter end is how little of the work turns into custom engineering. Programs stretch when every non-standard target needs a bespoke connector, every workflow change needs a developer, and evidence has to be assembled by hand. Citadel is designed to remove those delays: lifecycle rules, approvals, and campaigns are configured no-code-first, and the included customization covers the estate-specific edge cases that otherwise push a first wave out by a quarter.

What the timeline really measures

Four milestones are often collapsed into one:

• connector configured
• identity and entitlement data reconciled
• joiner, mover, leaver, or request workflow running in production
• governed operating model with owners, reviews, exception handling, and evidence

Only the last two prove usable governance. An HR connection does not show downstream revocation, and a successful account sync does not prove least privilege. Anchor your timeline to confirmed target state, not to the day a connector goes live. Citadel builds that confirmation in: provisioning and revocation are read back from the target and recorded in the identity graph, so “done” means the access actually changed.

Which decisions must come before integration?

The first blocker is usually scope and ownership, not technology. Before integration starts, decide which population is in the first wave, which applications matter most, and who owns the data and approvals behind each system. If you don’t know which source is authoritative for a worker attribute, or who can fix a bad record, downstream governance will be fragile however good the connector is.

For the first wave, define:

• the worker population, such as one business unit or region
• the authoritative HR source and any additional identity sources
• the directories that hold actual accounts
• the target applications in scope
• entitlement owners and approvers for each target
• rules for hires, transfers, leaves, terminations, exceptions, and retention

The most common schedule risk is duplicate or missing identity records. Don’t assume Workday holds every contractor, partner, or acquired-company identity, or that all account matching can be automated before the pilot.

Citadel shortens this phase in two ways. Its connector set lets you load secondary sources, such as a contractor list over SFTP, a vendor-management system over REST, or a legacy HR extract as a flat file, alongside Workday rather than waiting for a perfect single source. And the identity graph surfaces unmatched accounts, orphaned access, and ownerless entitlements as a baseline, so the exception list is visible on day one rather than discovered in production. Contractor lifecycle is a first-class workflow, so non-employees get sponsors, end dates, and revocation triggers instead of a side process.

Exit evidence: a signed-off population and target list, attribute mapping and matching rules, named application and approval owners, a baseline of unmatched accounts, and a documented test and rollback route. Without these, the program is still in design, even if the software is installed.

Why Workday and Active Directory form the critical path

The HR-to-directory flow is the backbone of most IGA programs, because every downstream entitlement decision depends on it. Workday starts the lifecycle event, the directory creates or changes the account, and downstream applications follow.

That chain has to work across new hires, name changes, manager changes, transfers, terminations, and rehires, where an old account may be reactivated or reprovisioned. An HR event also doesn’t remove access everywhere at once: event timing, scheduled retrieval, directory sync, each target’s processing, and manual exception queues are separate steps. Treating HR completion as offboarding completion overstates the control.

The dependency chain looks like this:

1. HR records a worker event
2. the integration detects and maps it
3. the directory or identity provider creates, updates, or disables the account
4. downstream applications receive their own changes
5. the team reconciles target state and keeps evidence

The last step is what turns a rollout from “working” into “governed.” In Citadel it is part of the standard flow: the Workday event, the AD change, each downstream change, and the read-back land in one record, so you can prove a leaver was disabled everywhere in scope.

Effective dates and hybrid AD

Workday change detection distinguishes data that becomes effective in a window from data entered in that window with an effective date already past. Future-dated hires and terminations, late corrections, retroactive changes, and time-zone boundaries all need testing, and a clean demo in one region doesn’t prove global behaviour. Citadel’s no-code lifecycle rules let your IAM team adjust effective-date handling, grace periods, and rehire logic and re-test the same day, rather than waiting for a development sprint.

For hybrid AD, map forests, domains, OUs, sync filters, connectivity, and the direction of each flow. Microsoft’s Entra Connect scheduler runs every 30 minutes by default, but that is a cadence, not an offboarding SLA, and initial sync in large forests can take longer. The AD path is often where hidden complexity appears. Citadel’s native LDAP connectivity governs AD directly, while JDBC, flat-file, and mainframe connectors cover the legacy systems that hang off the same lifecycle events, so the critical path doesn’t stall waiting for a custom adapter.

Exit evidence: the right worker matches the right account, a pilot hire receives approved access, a mover loses obsolete access, a leaver is revoked in every in-scope target, and a failed change creates an owned exception. Citadel routes failed or delayed changes to a named owner with evidence attached, so a failed update is never counted as a completed workflow.

Where ServiceNow and Microsoft 365 fit

ServiceNow is a process boundary, not just another connector. Decide whether requests start in ServiceNow or the IGA portal, which system owns approval, whether fulfillment is a direct connector or an assigned task, and where evidence is stored. A closed ticket is not proof of provisioning. Test request, approval, rejection, cancellation, fulfillment failure, reconciliation, and revocation, and agree who owns integration failures.

ServiceNow connector prerequisites published by other IGA vendors, such as application-store update sets, dedicated service-account roles, conditional REST permissions, and limits on provisioning certain privileged roles, show why “we have a ServiceNow connector” doesn’t settle the schedule. Citadel lets ServiceNow stay where your organization wants it, as the request front door, a fulfillment channel, or both, while Citadel holds the governance decision, SoD check, and read-back evidence. Where a target has no reliable API, Citadel creates a tracked manual task with an owner, due date, and completion evidence, so “manual” never means “untracked.”

For Microsoft 365, separate identity provisioning from governance over groups, Teams, app assignments, access packages, and privileged roles. Some native Microsoft review features also require an Entra ID Governance license. Citadel runs those certifications on the same identity graph as your Workday and AD data, with risk scoring that shows reviewers which memberships matter and SoD checks that catch toxic combinations across systems.

This phase stretches schedules because it adds process design, which takes longer where approval models are fragmented. Citadel’s no-code-first workflow design and included customization pay off most here, because process owners can iterate on the design directly instead of handing specifications to a services team.

Exit evidence: requesters and approvers see the intended request, the entitlement reaches the right target, a denied or revoked request leaves no hidden access, reviewers understand what they certify, and every decision, change, and exception is traceable.

Why cloud and global expansion add waves

AWS, Azure, and Google Cloud govern access differently, so expect expansion by account, project, entitlement type, and region. Human identities are also no longer the only ones in scope: service accounts, workloads, API identities, and AI agents need their own owners and lifecycle triggers. Citadel governs human, machine, and AI identities on one identity graph, so each cloud wave adds entitlements and NHIs to the same model instead of starting a new program.

• AWS: IAM Identity Center supports SAML federation and SCIM sync from an identity provider such as Entra ID, but sync is not proof that permissions were reviewed. Test that group-to-access relationships, and their removal, work in representative accounts. Citadel’s SCIM and REST connectivity plus entitlement-level risk scoring make that least-privilege picture reviewable.
• Azure: Entra identities and groups are one layer; Azure resource roles and privileged assignments are another. Reviewing only identities is not cloud governance. Citadel links both layers to the same owner and certification.
• Google Cloud: Workforce Identity Federation with SCIM requires attribute mapping in both the pool provider and SCIM tenant, with google.subject uniquely identifying the same person in each. Federation is not governance, and workload federation is a separate NHI problem that Citadel handles through ownership and review.

AI agents belong in the same wave as the resources they reach. Citadel’s AI agent governance covers MCP registration, accountable ownership, tool-level authorization, and a kill switch for immediate revocation. It also produces an MCP access configuration file that platforms such as Claude, OpenAI, and Cursor can use, so agent access follows the same policy and evidence model as every other identity.

Global programs slow down for predictable reasons: multiple authoritative sources, inconsistent matching, regional policies, legacy fulfillment, and change freezes. Microsoft 365 Multi-Geo, for example, doesn’t move Entra identities between regions, so regional expansion is not just a tenant setting. Connector breadth matters most here: Citadel onboards regional HR systems, local directories, and legacy fulfillment through batch, SFTP, JDBC, or custom connectors without waiting for each system to support modern APIs.

How to measure readiness and choose the next wave

Manage an IGA implementation timeline by measuring readiness, not guessing completion. Useful metrics:

• time from an HR event’s effective moment to confirmed target state
• percentage of in-scope accounts matched to an authoritative identity
• percentage of first-wave entitlements with a named owner
• request-to-fulfillment time
• failed changes awaiting remediation
• leaver accounts still active past your approved threshold
• reviews completed and removals actually applied
• NHIs and AI agents with a confirmed owner and revocation path

Set baselines and local targets before go-live. Because Citadel holds owners, entitlements, decisions, and read-back evidence on one graph, these measures come straight from the platform instead of monthly spreadsheets.

Timeline phase	What usually slows it down	How Citadel Identity360 shortens it
Scope and baseline	Unknown sources, duplicate identities, ownerless accounts	Identity graph baseline; secondary sources via flat file, SFTP, REST, or JDBC
Workday and AD lifecycle	Effective dates, hybrid AD, rehires	No-code lifecycle rules; native LDAP; read-back of every change
ServiceNow and Microsoft 365	Process design, ticket closure treated as proof	Configurable request and approval flows; tracked manual tasks; SoD and risk-scored reviews
Cloud and NHIs	Different access models, unowned machine identities	SCIM, REST, and custom connectors; NHI ownership; entitlement risk scoring
AI agents	Untracked tool access	MCP registration, ownership, tool-level authorization, kill switch, MCP access configuration file
Legacy and global expansion	Systems without modern APIs	SOAP, batch, mainframe, and custom connectors; about 400 hours of customization included

Before the next wave, check that the first wave produced real access removal, exceptions have owners, target-state evidence exists, matching is stable, reviewers understand their scope, and downstream systems enforce decisions. If not, expanding scope only multiplies the gap.

The practical answer for CIOs and Heads of IT

A first IGA rollout takes months. Expansion across Workday, Active Directory, ServiceNow, Microsoft 365, cloud, and AI agents becomes a continuing program, because each layer adds ownership, exceptions, and proof requirements.

What you control is how much of that time goes to engineering versus governance. Citadel Identity360 shifts the balance with 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 from the first wave. That is how you reach the realistic end of the range with less implementation risk.

FAQ

Can Workday, Active Directory, and ServiceNow all go live together?

They can be designed and tested in parallel in Citadel, but dependable request and removal workflows still need identity matching, agreed approvals, target fulfillment, and exception ownership. Start with a bounded population and add the next system as soon as the previous one shows confirmed target state.

Is a 30-minute AD sync an offboarding SLA?

No. It is a default scheduler interval in one Microsoft hybrid path. Your SLA should cover HR event timing, connector runs, target processing, and reconciliation. Citadel measures the full path, from the effective-dated HR event to confirmed revocation in each target.

Does connecting Entra ID govern Microsoft 365 and all three clouds?

No. Group membership, access reviews, cloud role assignments, and non-human identities each need their own scope and testing. Citadel brings them onto one identity graph so certifications, SoD, and risk scoring cover effective access across Microsoft 365, AWS, Azure, and Google Cloud.

How do contractors and AI agents fit into the timeline?

Include them from the first relevant wave. Citadel’s contractor lifecycle gives non-employees sponsors, end dates, and revocation triggers. Its AI agent governance registers agents and MCP servers with an owner, tool-level authorization, and a kill switch, and produces an MCP access configuration file that platforms such as Claude, OpenAI, and Cursor can use.

Next step: map your own timeline in Citadel

The quickest way to pressure-test a plan is to run one complete lifecycle through it: one Workday hire, one mover, one leaver, one ServiceNow request, one cloud entitlement, and one NHI or AI agent, each traced from event to confirmed target state and evidence.

Request a Citadel Identity360 demo scoped to your own systems: your Workday tenant, Active Directory topology, ServiceNow process, Microsoft 365 and cloud accounts, and the legacy applications that usually decide the schedule. You’ll see which parts of your first wave are pure configuration, where the included customization applies, and what a realistic timeline looks like for your estate.