Notifications
Clear all
Topic starter
11/08/2026 3:25 pm
TL;DR: IGA migrations often stall because application onboarding becomes the hidden critical path, with each system introducing its own account model, entitlement structure, and remediation workflow, according to Redblock. Starting application readiness before platform selection turns migration sequencing into a governance problem rather than a tooling problem.
NHIMG editorial — based on content published by Redblock: Why IGA Migration Should Start Before You Choose the IGA
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should teams reduce risk when IGA migrations involve many disconnected applications?
A: Treat application readiness as a separate workstream from platform selection.
Q: Why do IGA programmes slow down once they reach legacy or departmental systems?
A: Legacy and departmental systems usually have weaker APIs, local account models, and inconsistent entitlement data.
Q: What do security teams get wrong about application onboarding in IGA projects?
A: They often assume onboarding is a late-stage operational task rather than the hidden critical path.
Practitioner guidance
- Front-load application discovery Map every application's account model, entitlement structure, owner, and execution method before selecting the new IGA platform.
- Separate readiness from selection Run application readiness work in parallel with IGA vendor evaluation so connector gaps and workflow exceptions surface before commitments harden.
- Measure enforcement, not approvals Require evidence that access changes were applied inside each application, not just recorded in the governance workflow.
What's in the full article
Redblock's full blog covers the operational detail this post intentionally leaves for the source:
- The application-first migration workflow for preparing disconnected systems before IGA cutover
- The execution-layer approach for turning approvals into verified application changes
- The evidence and verification steps used to support audit and compliance sign-off
- The sequencing model for running platform selection and application readiness in parallel
👉 Read Redblock's analysis of why IGA migrations should start before platform selection →
IGA migration sequencing: where application readiness breaks down?
Explore further
11/08/2026 3:34 pm
Application-first migration is a governance model, not a delivery shortcut. The article is right to treat onboarding sequence as the determining factor in IGA success. When application complexity is discovered after platform decisions are locked, governance becomes constrained by integration reality rather than business policy. That affects both human access and NHI governance, because service accounts and API-driven entitlements often sit in the same unmanaged application layer. Practitioners should treat application readiness as a prerequisite control, not a downstream implementation task.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How can organisations tell whether their IGA migration is actually improving control coverage?
A: Look for verified enforcement inside the target applications, not just completed approval records in the IGA platform. Strong programmes can show account changes, entitlement updates, and audit evidence for each connected system. If access decisions still depend on manual tickets or local administrators, control coverage has not really improved.
👉 Read our full editorial: Why IGA migrations fail when application readiness starts too late
