Identity Governance and Access Certification Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the plan to connect every application collapse so often?

The kickoff deck lists forty applications and a phase plan. Twelve months later nine are connected, and the nine are the ones that already spoke SCIM. This is the most reliable failure in identity governance, and it happens because the estimate was built from a count of applications rather than an assessment of each one.

The distribution is specific to this category. A modern application with SCIM or a documented API is a few days. A database backed application where entitlements live in tables is a week or two, plus the vendor conversation to get the schema and a read only account, plus a standing obligation to retest after every vendor upgrade. A vendor hosted system with only a user interface is either a scheduled export the vendor agrees to produce, which is a commercial negotiation rather than an engineering task, or automated interaction with the interface, which is fragile and needs a named owner forever. A mainframe or terminal system usually has a report an administrator has run manually for years, and turning that into a feed is often the cheapest win in the programme.

The fix is to stop counting applications and rank them by risk, then integrate the top ten properly. A campaign over your ten most sensitive systems with real entitlement descriptions is worth more to an auditor than one over forty systems full of role codes nobody understands. Where no automated path exists, build an attested manual feed: the application owner uploads a signed extract on a schedule, the system records who provided it and when, and the feed ages visibly if it is not refreshed. A connector that silently returns stale data is worse than no connector.

What goes wrong with identity matching and entitlement data?

Two data problems sink more of these builds than any workflow decision.

The first is identity resolution. Your human resources system holds employees. Your directory holds accounts. Contractors are in neither, or in a third place. Service accounts look like people. Someone who left and returned has two employee numbers. A shared account in a clinical or trading system belongs to a rota rather than a person. Until every account resolves to an owning identity, or is explicitly classified as an orphan or a service account with a named custodian, no campaign can be trusted, because the reviewer never sees the accounts that were never linked to anybody.

The second is entitlement semantics. A connector extracts that a user holds a role called Z_MM_INV_02. Nothing extracts what that role permits, who should hold it, or whether it combines with another role to break a segregation of duties rule. That knowledge sits with application owners, and capturing it is the actual project. It is the schedule risk in nearly every build we have delivered, because it needs time from people who do not report to the programme.

Make description capture a tracked deliverable with an owner and a due date per application, not a database column somebody will fill in later. Then add last used dates. That field changes reviewer behaviour more than any other, because approving access a person has not touched in a year feels different from approving access they used yesterday.

Why do the HR feed and the application connectors break after launch?

Nothing here stays still. The human resources system gets an upgrade and the department code field changes shape. A vendor patches an application and the entitlement table gains a column. Somebody creates a new organisational unit and every account in it is suddenly unassigned. Connectors that worked on the day of go live decay quietly, and the decay is invisible, because a connector returning zero rows looks identical to an application with no changes.

The joiner, mover and leaver feed matters most because everything downstream depends on it. If a joiner arrives without a manager, their access request has no approver. If a leaver record arrives with a date format the parser did not expect, nobody is deprovisioned that day and nobody is told.

Build every collection to be observable. Record the run time, the account used, the row count and a checksum for each cycle, and show a per application freshness indicator anyone can read. Then test the failure path rather than the happy path: what happens when an application returns half its accounts, when a certificate expires on a vendor endpoint, or when a scheduled export lands empty because the vendor renamed a report. In our delivery experience the single most valuable piece of monitoring in an identity build is a daily reconciliation comparing expected record counts against received counts per source. If the answer to any failure case is that the campaign quietly runs against stale data, you have built something that produces a clean report while the estate drifts.

What happens when movers and revocation execution are not covered?

Campaigns are a periodic backstop. The continuous control is lifecycle, and movers are the weak point almost everywhere. Leavers get attention because a termination triggers an account disable. Movers accumulate: each transfer adds the new team's access and rarely removes the old, so someone who has been there eleven years and moved four times holds the union of every role they have ever needed.

Build the mover event explicitly. When the feed reports a department, manager or job code change, generate a review of that person's existing access against their new position, routed to the new manager with the old manager copied, with a deadline and an escalation. It is a smaller piece of engineering than a campaign engine and it prevents more accumulation than any quarterly review does.

The second uncovered gap is revocation. A review producing decisions nobody carries out is worse than no review, because it creates documented evidence that the organisation knew. Deprovisioning fails silently more often than teams expect: an interface returns success while the application caches the old permission, a vendor system needs a local administrator and the ticket sits, an account is disabled but a shared credential still works. The design that holds is one click to revoke, automatic deprovisioning where a write path exists, a tracked task with a named owner where it does not, and a verification step on the next collection cycle that confirms the entitlement is gone and reopens the item if it is not.

Should you build custom or configure what you already own?

Some readers should stop and configure. If your estate is essentially Microsoft, Entra ID Governance covers access reviews, lifecycle workflows and entitlement management well, because the identity data is already in the tenant and reviews become configuration rather than a project. The same holds for Okta Identity Governance in an Okta centred estate. In those situations you will run real reviews within weeks, and anyone recommending a build is selling you a project.

If you have a large but conventional estate with good connector coverage, evaluate SailPoint or Saviynt properly. Their connector libraries, campaign engines and role mining represent years of development, and rebuilding them is a poor use of money. Omada and One Identity are credible in their segments.

The build case appears when a large share of your risk sits in applications with no standard connector, when your approval hierarchy crosses legal entities or differs by business unit, when segregation of duties rules are specific to your own process design, or, most tellingly, when you have already licensed a governance product and still run the campaigns that matter in spreadsheets. That last case is common and worth naming honestly: the licence bought a campaign engine and you funded the connectors anyway. A build there is often not a replacement, it is a layer that owns the hard integrations and feeds the product you already pay for.

How do hidden costs get into the quote?

• Connectors priced as a bundle. If a proposal quotes integration as one line rather than naming each application and its method, the estimate is a guess and the overrun is already booked.
• Usage data treated as a checkbox. Collecting last used dates is a separate integration per application, often against a different interface from the entitlement extract, and it is the first item dropped when a programme runs late.
• Segregation of duties policy. Defining the rules is a business exercise involving finance and internal audit. The engineering is a week. Getting agreement on which combinations are actually prohibited can take a quarter.
• Organisational complexity. Several legal entities with different approval hierarchies and different evidence needs is a materially different build from a single company, and it is rarely priced as one.

There is a fifth cost that never appears in a quote, which is your application owners' time. Somebody has to write plain language descriptions, agree who should hold each entitlement, and confirm a revocation is safe. That work cannot be handed to a developer, and programmes that do not book it explicitly meet it as a schedule slip in month four.

What separates a build that works from one that fails here?

The working ones make the reviewer's question answerable. Every entitlement in a campaign carries a plain language description from its application owner, a risk rating, whether it is privileged, any segregation of duties conflicts, and a last used date. Where it is meaningful, peer comparison appears: this person holds three entitlements none of their fourteen colleagues in the same role hold. That is an outlier a manager can act on in seconds. They also make revocation the cheap path, because if approving is one click and revoking starts an email thread, the design has chosen approval on your behalf.

The failing ones are recognisable early. They lead with a dashboard. They price connectors as a bundle. They have no answer for an application with no interface beyond a promise. They treat the joiner, mover and leaver feed as a one off integration rather than a monitored dependency. And they leave revocation as an operational concern outside scope, which is how you end up with a well documented record of decisions nobody executed.

When you choose a developer, ask them to describe integrating your three worst applications by name. Ask what happens when deprovisioning fails silently on one system. Ask how movers are handled. Then settle code and infrastructure ownership in writing before kickoff. At Digital Heroes the client owns the repository from the first commit, and a system holding the map of who can do what across your organisation should never be rented from a supplier you cannot replace.