Webinar: IGA Built On and For ServiceNow — The Best of Both Worlds
Watch Past Webinars covering real customer use cases in Identity, Access, and JML Automation
ServiceNow customers evaluating identity governance are choosing between two architectures: building IGA natively inside ServiceNow (ClearSkye, ZertID, and now ServiceNow’s own Veza acquisition), or pairing a dedicated identity engine with ServiceNow as a companion app (Hire2Retire, Saviynt).
The native approach keeps everything in one platform but strains under real JML volume, RBAC/ABAC rule complexity, and multi-system provisioning — problems ServiceNow’s workflow engine wasn’t built to solve. The companion model treats the identity engine as the control plane and ServiceNow as the engagement plane, letting each platform do what it’s best at without displacing your existing ServiceNow investment.
If your organization runs on ServiceNow, chances are you’re already using it to manage identity and access requests in some form — a catalog item for new software, an approval workflow when someone asks for a permission, a CMDB record tying an asset to a user. It’s a natural extension of what ServiceNow already does well.
But there’s a difference between routing identity account creation and access request work through ServiceNow and actually governing identity through a dedicated engine. That difference is becoming one of the more important architecture decisions IT and security leaders will make this year — and the market itself is split on the answer.
The ServiceNow identity governance market has split into two competing architectures: native, where identity and entitlement logic lives directly inside ServiceNow tables, and companion, where a dedicated identity engine owns governance logic while ServiceNow serves as the approval, catalog, and CMDB front end. Nearly every serious vendor in this space has placed a bet on one side or the other over the past year.
Camp one: build IGA natively on the Now Platform.
Vendors in this camp store identity, entitlement, and workflow data directly inside ServiceNow tables, so the entire program — identity creation, access requests, certifications, lifecycle events — lives inside one platform, with no separate application or data model.
This is now a genuine category, not a single vendor: ClearSkye markets itself around the idea that identity works better when it’s native to ServiceNow, and ZertID — built by Sysintegra, a ServiceNow Elite Partner — takes the same approach a step further, converging IAM, IGA, and PAM into one ServiceNow-resident app with a codeless-implementation pitch.
ServiceNow itself has now placed a version of this bet too: its acquisition of Veza, which closed in March 2026, brings a patented Access Graph — mapping access relationships across human, machine, and AI-agent identities — natively into products like its AI Control Tower and CMDB/Knowledge Graph.
Industry analysts have called this a turning point that makes ServiceNow a credible identity security player in its own right . It’s worth noting, though, that Veza’s core strength has been access visibility and graph analytics rather than the full lifecycle-automation and governance engine that JML and RBAC/ABAC programs actually run on — so “native” doesn’t automatically mean “complete.”
Camp two: pair a dedicated identity engine with a ServiceNow companion app.
Here, the heavy identity-governance logic — HR-to-identity synchronization, RBAC/ABAC rule evaluation, role mining, role modeling, policy definition and enforcement, provisioning to hundreds of downstream applications — runs in a purpose-built engine, while ServiceNow serves as the front door: approval workflows, catalog items, tickets, and the CMDB context that makes access requests meaningful to the business. Hire2Retire IGA on ServiceNow takes this approach.
Notably, Saviynt — long an enterprise-scale, pure-play IGA suite — has recently shipped a similar companion app for ServiceNow customers. We do not compete directly with Saviynt with our mid-market, no-code, low TCO positioning and see Saviynt as a reference competitor in the category, but on this specific question — should ServiceNow be the front end for a dedicated identity engine, or try to be the engine itself — its move is a useful data point: even a large, independent IGA platform concluded that ServiceNow is best used as a companion surface, not a foundation to rebuild identity governance logic on.
Building IGA natively inside ServiceNow is appealing on paper: one platform, one data model, one place for admins to work. But identity governance isn’t just workflow — it’s a set of engineering problems that ServiceNow’s table structure and workflow engine weren’t originally built to solve.
JML automation is the engine that detects hire, role-change, and termination events from HR systems and translates them into identity and access changes — creating accounts on hire, updating entitlements on role change, and revoking access on termination — without manual intervention. A real JML engine has to normalize these events from whatever HR or ATS system a company runs — Workday, UKG, BambooHR, ADP, SAP SuccessFactors, and 20+ more — each with its own data model and event timing.
That’s a purpose-built integration and mapping problem, not a ServiceNow workflow problem, and it’s also where a surprising amount of “HR-driven” provisioning quietly turns into “HR-informed” provisioning instead — IT finding out about a change well after the fact rather than acting on it in real time.
RBAC (Role Based Access Control) and ABAC (Attribute Based Access Control) are two ways of automatically deciding what access someone should have — RBAC assigns access based on a defined role, while ABAC evaluates live attributes like department, title, location, and employment type against a rule set. Doing this well means evaluating that rule set every time an HR event fires — deterministically, or with AI/ML-assisted predictions — at scale, without a developer rewriting logic every time a role changes or an approver making a manual decision. That’s a rules-engine discipline, closer to what an identity platform does natively than what a catalog item and approval does.
Two more engineering problems round out the list:
None of this is a knock on ServiceNow, or on vendors like ClearSkye and ZertID betting on a fully native build. It’s simply not what the platform’s table structure and workflow engine were built to do, and retrofitting a full identity-governance engine into ITSM tables tends to produce something that looks like IGA in a demo but strains under real JML volume, multi-system HR complexity, and audit scrutiny.
The companion approach starts from a different premise: let each platform do what it’s best at, and integrate tightly rather than trying to make one platform do everything.
In a companion-app architecture, the identity engine acts as the control plane — the system that decides what should happen — and ServiceNow acts as the engagement plane — the surface where people interact with the decisions that control plane makes. That split holds for both halves of an IGA program, not just the automated half:
ServiceNow’s job (engagement plane): workflow automation, human approvals, the CMDB, service and application catalogs, and the reporting, analytics and audit trail your organization already trusts. When a request needs a human decision — an access request, a certification review, a resource allocation — it surfaces in ServiceNow as an approval, ticket, or catalog item, fully tracked in ServiceNow’s own audit trail. These are ServiceNow’s core strengths, and there’s no reason to rebuild them elsewhere.
The identity engine’s job (control plane): everything that decides what should happen — normalizing HR and ATS events, evaluating RBAC/ABAC policy, mining and recommending roles with AI/ML, deciding what can be automated versus what needs a human, and provisioning or deprovisioning access across identity providers and applications in real time once a decision is made.
This holds whether the decision originates from an HR event or from a person requesting access beyond their birthright — both are governed by the same policy engine, not split across two independently authoritative systems. On top of that, the identity engine feeds audit trails, activity data, and analytics back to ServiceNow, so ServiceNow’s reporting stays complete even though it isn’t where the governance decision was made.
One place this matters concretely: if a request made in ServiceNow would conflict with what HR-driven policy says that person should have, the identity engine’s policy wins — because HR is the authoritative source for who someone is and what they’re entitled to. ServiceNow approvals grant permission to request; the identity engine still validates whether the resulting state is compliant.
With Hire2Retire IGA on ServiceNow, that division looks like this in practice: Hire2Retire ingests the JML event from HR, evaluates it against your organization’s RBAC and ABAC rules, and handles what can be automated end-to-end — while anything that needs a human decision surfaces as a ServiceNow approval, ticket, or catalog item. Nothing about your existing ServiceNow investment — CMDB, catalog, approval chains — gets displaced. It gets a governance engine behind it that wasn’t there before.
The practical question isn’t “does this vendor have a ServiceNow app” — most now do. It’s whether the identity logic behind that app can actually handle HR-to-identity complexity at scale, or whether it’s been retrofitted into ITSM tables that were never designed for it. If you’re an IT or security leader currently using ServiceNow for identity workflows, ask:
Hire2Retire customers have used this model to cut JML-related HR and IT workload by up to 90%, with roughly 60% cost avoidance compared to standing up the equivalent manually — without abandoning ServiceNow as the system their teams already know.
We’re covering this architecture question — and what it means for teams currently running identity workflows on ServiceNow — in an upcoming webinar:
We’ll walk through how Hire2Retire and its ServiceNow companion app divide the work, which functions genuinely belong in each platform, and why that division matters more than which vendor has the shinier ServiceNow Store listing.
Yes. ServiceNow retains full ownership of approval workflow configuration — who the approvers are, multi-level approval chains, delegation rules, and any conditional routing logic stay defined and enforced inside ServiceNow, exactly as they are today. Hire2Retire’s role is to act as the trigger: based on RBAC/ABAC policy, it determines — whether the source is a JML event, an access request, or another policy decision — when something needs human sign-off, and initiates that request in ServiceNow. From that point forward, ServiceNow’s own approval engine takes over.
Yes. Hire2Retire feeds identity, entitlement, and access-change data — including the Change Data Capture (CDC) stream from its Workforce 360 Identity Cloud — back into ServiceNow, so ServiceNow’s own reporting and dashboards stay complete and current even though the underlying governance decision was made in Hire2Retire. Nothing about ServiceNow’s existing reporting investment goes stale.
Compliance and audit reporting — SOC2, ISO 27001, HIPAA, and SOX/NIST-ready canned reports — is native to Hire2Retire out of the box; it isn’t deferred to ServiceNow. The same underlying data also flows into ServiceNow, so organizations that want a single reporting pane there can have one. In short: Hire2Retire owns the governance and audit function, and pushes that data to ServiceNow so it can be used there as well.
For catalog items specifically, yes — ServiceNow remains the source of truth for what’s in the catalog (item definitions, ownership, fulfillment steps), since that’s core ServiceNow territory. Today, catalog items are configured and mapped within Hire2Retire to reference ServiceNow’s catalog. Fully automatic, real-time sync the moment a catalog item changes in ServiceNow is on the near-term roadmap rather than generally available today — worth being upfront about that distinction rather than overstating it.
Leverage.You get a real governance engine underneath your identity program without giving up or re-platforming the ServiceNow investment your team already knows and trusts — the best of both worlds, with each platform doing what it does best.
