How should organisations respond when a major IGA program cannot be completed at once?

Why This Matters for Security Teams

When a major IGA program cannot be completed at once, the issue is usually not the tooling but the scope. Trying to automate every entitlement, connector, and approval path in one release creates a control project that is too large to verify and too slow to land. A better response is to pick one high-value identity flow, prove measurable reduction in risk, then expand only after the first control is stable. That is the same logic behind a phased governance model used in NHI programmes, where visibility comes before rotation and rotation comes before full lifecycle automation.

This matters because incomplete IGA often leaves the most exposed identities untouched. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts according to Ultimate Guide to NHIs by NHI Mgmt Group. If the rollout waits for perfect coverage, the real control gap stays open. Current guidance in NIST Cybersecurity Framework 2.0 supports outcome-based risk reduction, not just program completion. In practice, many security teams encounter the hidden failure of unfinished governance only after a stale account, API key, or service credential is abused, rather than through intentional review.

How It Works in Practice

The practical move is to redesign the rollout into a sequence of bounded controls. Start by selecting one domain where identity risk is both visible and measurable, such as service accounts, CI/CD secrets, or privileged admin access. Define the control outcome in operational terms: fewer unmanaged accounts, shorter secret lifetime, faster revocation, or reduced standing privilege. Then build the minimum governance loop needed to support that outcome, including inventory, ownership, policy, and exception handling.

For NHI-heavy environments, the first phase often means inventory and classification, not automation. Teams need to know where identities exist, who owns them, and which are tied to production workloads. That aligns with the remediation logic in the Schneider Electric credentials breach, where credential exposure and control gaps show how quickly unmanaged identities become an incident. From there, the next phase is to attach policy to the identity lifecycle: issuance, approval, rotation, and offboarding. A mature sequence usually looks like this:

• discover the identity population and assign owners
• prioritise the highest-risk credentials and access paths
• enforce approval and recertification for that narrow scope
• add rotation or revocation where the control can be operationalised
• measure drift, exceptions, and time to remediate

Use NIST Cybersecurity Framework 2.0 to keep the rollout tied to outcomes such as protect, detect, and respond, rather than to a calendar milestone. The implementation goal is not to finish the whole IGA estate in one pass, but to create a repeatable control pattern that can be copied to the next scope. These controls tend to break down when identity ownership is unclear across inherited platforms because exceptions pile up faster than the governance team can review them.

Common Variations and Edge Cases

Tighter rollout sequencing often increases short-term overhead, requiring organisations to balance speed of delivery against the risk of creating a brittle, hard-to-audit program. That tradeoff becomes sharper in distributed estates, where multiple business units, legacy directories, and third-party integrations all use different entitlement models. Current guidance suggests that teams should not treat every identity type the same way, because a high-risk privileged account, a workload identity, and a low-risk human user do not need identical onboarding logic.

There is no universal standard for sequencing, but best practice is evolving around risk-led prioritisation. If the first phase fails to produce a measurable outcome, the scope is probably still too broad. If a team can only automate part of the lifecycle, it should automate the part that reduces the most standing exposure first. That is especially true where secrets are embedded in code, because a partial program that leaves static credentials in place creates a false sense of control. The same lesson appears in the broader NHI data set: 91.6% of secrets remain valid five days after notification, showing how slow remediation can be when lifecycle processes are immature.

In highly regulated environments, the edge case is not whether to proceed, but how to document what remains manual. A phased plan should clearly mark what is out of scope, why, and when it will be revisited. If the program touches privileged workflows, map the rollout to zero-trust and identity assurance principles in NIST Cybersecurity Framework 2.0 and treat Schneider Electric credentials breach as a reminder that unmanaged identities are often found only after damage is visible. The practical standard is simple: if the first scope cannot be controlled, the next scope should not be added.

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?
• What does a mature secrets governance program need to cover?