How should organisations plan for IGA maintenance after go-live?

Why This Matters for Security Teams

IGA maintenance is where many programmes succeed or fail after the project team leaves. Go-live often fixes the first wave of access cleanup, but it does not eliminate role drift, business change, connector breakage, or approval fatigue. Current guidance from the NIST Cybersecurity Framework 2.0 treats identity as an ongoing governance function, not a one-time deployment, which is the right mental model for post-launch operations.

The operational risk is straightforward: roles lose fidelity as applications, org structures, and entitlements change, and exceptions quietly become the real access model. That is especially visible when security teams inherit hidden technical debt from the launch phase, such as manual reconciliations, stale certifications, and brittle integrations. NHIMG’s research on the State of Secrets in AppSec shows how fragmentation and weak hygiene persist when controls are not continuously maintained; the same pattern applies to identity governance. In practice, many security teams encounter access sprawl only after audit findings, production incidents, or a failed recertification cycle has already exposed it.

How It Works in Practice

Effective post-go-live planning treats IGA as a service with recurring operating tasks, not a capital project with an end date. That means assigning owners for role engineering, policy tuning, application onboarding, certification support, exception adjudication, and integration monitoring. It also means defining how changes enter the governance process, because the business will keep changing faster than the catalog does.

A workable operating model usually includes:

• Regular role mining and role review to keep entitlements aligned to current job functions.
• Policy maintenance for new systems, new risk rules, and changed approval paths.
• Connector health checks so provisioning and deprovisioning do not silently fail.
• Exception management with expiry dates, escalation paths, and named accountable owners.
• Recertification support that helps managers make decisions instead of simply sending reminders.

The most durable programmes tie IGA maintenance to measurable service levels: how quickly new apps are onboarded, how often roles are updated, how long exceptions remain open, and how many orphaned entitlements remain unresolved. That operating discipline matters because access models degrade whenever business change outruns governance capacity. NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs research shows how quickly exposed identity material can be abused, which is a useful reminder that stale controls create real exposure, not just audit noise. For implementation detail, the NIST Cybersecurity Framework 2.0 is best read as a continuous lifecycle model, while the operational mechanics of IGA should be adapted to each organisation’s platform and change rate. These controls tend to break down when ownership is split across IT, HR, and application teams because no one is funded to close the maintenance loop.

Common Variations and Edge Cases

Tighter post-go-live governance often increases administrative load, so organisations must balance control quality against business speed. That tradeoff becomes most obvious in fast-moving environments where application portfolios change weekly and role models never stabilise.

There is no universal standard for exactly how often roles should be revalidated, but current guidance suggests matching review cadence to change velocity rather than using a fixed annual cycle for everything. High-risk entitlements, privileged roles, and regulated systems usually need more frequent attention than low-impact business apps. Similarly, exception handling should be stricter where access is externally facing, financially sensitive, or tied to privileged administration.

Two common edge cases deserve explicit planning. First, organisations with poor data quality in HR or asset inventories should expect IGA maintenance to require manual cleanup for longer than planned. Second, environments with many custom applications often need connector exception handling and workflow tuning that never fully disappears. In both cases, best practice is evolving toward continuous governance with clear service ownership, rather than assuming that certification campaigns alone will keep access clean. The most common failure mode is treating residual access issues as an occasional audit task instead of a standing operational backlog.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?