Notifications
Clear all
Topic starter
11/08/2026 3:24 pm
TL;DR: IAM program launches often fail because organisations start with timelines and vendors instead of identity pain points, business risk, and real effort estimates, according to Fischer Identity. The core issue is governance inversion: project plans cannot succeed when the underlying access problems, stakeholders, and lifecycle failures have not been defined first.
NHIMG editorial — based on content published by Fischer Identity: Why It’s So Hard to Just “Create” an IAM Program, And What to Do Instead
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should organisations start an IAM programme without making it a pure IT project?
A: Start with business pain, identity lifecycle failures, and audit risk, then translate those findings into scope and requirements.
Q: Why do IAM programmes often fail when scope is defined too early?
A: Because early scope usually reflects guesses about identity populations, integrations, and lifecycle complexity.
Q: What breaks when teams estimate IAM effort before mapping identity complexity?
A: They underestimate the number of integrations, exceptions, and identity types that drive the work.
Practitioner guidance
- Run identity discovery before project planning Gather input from helpdesk, HR, compliance, IT, and business owners to document the real access problems, not just the requested features.
- Build a scored IAM requirements catalogue Rank lifecycle failures, excessive access, duplicate identities, and manual workarounds by business impact and urgency.
- Estimate effort from identity complexity, not optimism Count identity types, downstream applications, exception paths, non-employee populations, and integration dependencies before committing delivery dates.
What's in the full article
Fischer Identity's full blog covers the operational detail this post intentionally leaves for the source:
- The full discovery checklist for mapping IAM pain points across helpdesk, HR, compliance, and business leadership.
- The step-by-step scoping logic for estimating effort across identity types, applications, and exception paths.
- The vendor's examples of lifecycle failures, technical debt, and integration gaps that should feed a requirements catalogue.
- The broader advisory framing for turning business pain into a programme plan and delivery sequence.
👉 Read Fischer Identity's analysis of why IAM programmes fail when teams start with the project plan →
IAM program planning: why starting with scope often fails?
Explore further
11/08/2026 3:33 pm
IAM programme failure is usually a discovery failure, not a delivery failure. Teams often blame implementation discipline when the deeper issue is that they never defined the identity problem set in business terms. If lifecycle breaks, orphaned access, and manual workarounds are not captured early, the programme is forced to optimise around incomplete requirements. The implication is that IAM governance must begin with problem definition, not execution planning.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, 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: Who should be accountable for defining IAM requirements in a new programme?
A: Accountability should sit with identity, security, and the business owners who depend on access outcomes, not with the PMO alone. The programme is governing access to services and data, so the people affected by those access decisions must help define the requirements and risk priorities.
👉 Read our full editorial: Why IAM programs fail when teams start with the project plan
