What 'Modern IGA' Actually Means Beyond the Vendor Slide

Every IGA vendor’s pitch deck uses the same words — “modern,” “risk-based,” “AI-powered.” Having spent a year running an enterprise RFB process across three major platforms, I’d argue most of the differentiation that actually matters in a program isn’t the platform. It’s three design decisions that hold regardless of which vendor you pick.

1. Certifications should carry context, not entitlement lists

A reviewer looking at “user has access to GL_POSTING_ADMIN” has no way to make a good decision, and defaults to approving it. Surfacing why the access exists, when it was last used, and what changed since the last review turns certification from a rubber-stamp exercise into something a reviewer can actually act on.

2. Provisioning and governance can’t be separate systems

If the provisioning process doesn’t know what the governance process decided, you get access grants that never get revoked when a certification fails them. The lifecycle engine and the governance layer need to share the same data — the same identity warehouse and entitlement catalog — or they drift apart within a couple of review cycles.

3. Risk scoring only earns its keep if it changes what a reviewer does

A risk score that’s just a colored badge next to an already-overwhelming list gets ignored within a month. It only matters if it changes the review cadence (monthly vs. annual) or the approval path (manager vs. security team) for that specific access.

The takeaway

None of this is vendor-specific. It’s a question of whether governance is treated as a continuous control loop — lifecycle event, access grant, contextualized review, policy feedback — or as a quarterly spreadsheet exercise with a platform attached to it. The RFB process reinforced this: the platforms compared closely on paper; the programs that succeeded or struggled were separated by decisions like these.