Warning signs include delayed design decisions, rework discovered late in testing, difficulty keeping the application onboarding pipeline moving, and exceptions becoming easy to obtain. If the team waits until UAT to show functionality to business stakeholders, problems usually surface too late. A healthy programme balances agility with control over objectives, scope, and outcomes.
How to tell the programme is outrunning its design discipline
Over-customisation usually shows up as the team solving edge cases before the core design is stable. If requirements keep changing because each workshop reveals another exception, or if architects and engineers are revisiting the same decisions repeatedly, the programme is moving faster than its control model can absorb. The clearest signal is churn: the plan feels productive, but the design baseline never hardens.
Another practical warning is when onboarding one more application requires disproportionate effort. That often means the build is no longer an enablement layer, it has become a bespoke integration exercise for each use case. In modern identity and governance programmes, that is the point where velocity starts to hide fragility rather than create it.
Teams can also spot this pattern in their governance language. If exceptions are becoming the normal path to make delivery work, or if business stakeholders are seeing functional behaviour only at UAT, the programme is deferring the most important decision point too late. That usually means the solution is being shaped by individual cases instead of a repeatable operating model.
Where speed turns into rework and operational drag
Moving too quickly rarely fails in one dramatic event. It usually fails through accumulated rework, especially when late testing uncovers that the target state was never clear enough for developers, reviewers, and business owners to align on. When changes cascade into design resets, the programme is spending effort proving the concept repeatedly rather than industrialising it.
A useful way to judge pace is to watch the onboarding pipeline and the exception workflow together. If the pipeline stalls because every new source system needs a special path, and exceptions are easy to obtain because no one wants to slow delivery, the governance model has lost force. That combination is often more dangerous than a single technical defect because it normalises short-term convenience over durable control.
Practitioners should expect some tuning in any modernisation effort, but not a permanent state of improvisation. When the team cannot explain which parts are configurable versus which parts are fixed, customisation risk is already being paid for in delayed delivery, harder support, and weaker auditability. For identity-heavy programmes, that also tends to increase exposure around access review, lifecycle consistency, and exception sprawl.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | IGA modernisation directly affects account lifecycle and exception handling. |
| 6 — Access Control Management | Over-customised IGA often weakens access decisions and normalises exceptions. | |
| 8 — Audit Log Management | Late discovery and unstable workflows are easier to spot when changes and exceptions are logged. | |
| Recommendation — Standardise account provisioning and exception handling to reduce bespoke onboarding paths. Enforce consistent access approval and review rules to keep exceptions from becoming the default. Log onboarding changes and exception approvals so rework and control drift are visible early. | ||
| NIST CSF 2.0 | GV — Govern | The question is about balancing delivery speed with control objectives and outcomes. |
| PR.AA — Identity Management, Authentication and Access Control | IGA modernisation centers on access governance and lifecycle control. | |
| DE.CM — Continuous Monitoring | Rework and exception creep are operational signals that need monitoring. | |
| Recommendation — Define governance decision rights that limit customisation and keep scope under control. Align access governance rules so onboarding changes do not undermine identity control. Monitor onboarding throughput, exception volume, and rework to detect programme drift. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Over-customised governance often weakens lifecycle control over credentials and exceptions. |
| NHI-05 — Privilege and Access Governance | IGA modernisation must prevent easy exceptions and excessive access from becoming normal. | |
| Recommendation — Tighten credential lifecycle controls so custom paths do not create unmanaged access. Apply least-privilege governance to keep approval exceptions bounded and reviewable. | ||
Practitioner Guidance
What to prioritise: Treat late-discovered rework and exception growth as programme health indicators, not isolated delivery issues. If those two signals rise together, pause expansion and stabilise the design rules before adding more integrations or variations.
What to verify: Make sure business stakeholders see working behaviour before UAT, and verify that each onboarding request can follow a documented path without a one-off approval chain. If the same decision is being re-litigated for every application, the control model is too bespoke to scale.
Decision rule: If an exception is required to make the design work for a common case, treat that as a sign the baseline needs correction. If the exception is only needed for a rare edge case, capture it explicitly and keep it out of the default flow.
Practitioner takeaway: A healthy modernisation programme is not the one that customises fastest, it is the one that can absorb change without turning every new requirement into a new design.
Related resources from NHI Mgmt Group
- What are the signs that an ISO 27001 programme is too fragmented to work well?
- What are the signs that an Active Directory forest recovery plan is too risky to rely on during an incident?
- What are the signs that cloud database credential management is becoming too brittle to operate safely?
- What are the signs that an in house SSO approach is becoming too costly to maintain?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
