
When IAM tooling is the wrong place to start
(why, and the implications of doing it wrong!)
The Executive Summary
IAM tooling is the wrong starting point when organisations have not yet agreed how identity decisions should be made, owned, or enforced.
We see this via a variety of triggers including:
- Product selection happens before operating model design
- Multiple IAM tools exist with overlapping responsibility
- “Customisation” becomes the default solution to every problem
- IAM roadmaps revolve around features rather than outcomes
Want to know more?
What are the implications?
Starting with tooling locks organisations into design decisions they do not yet understand. Over time, this results in brittle configurations, expensive rework, and dependency on niche skills.
What typically goes wrong?
- Implicit architecture: The tool’s defaults become the architecture
- Configuration debt: Short‑term fixes accumulate into long‑term fragility
- Vendor‑led decisions: Product capabilities dictate governance behaviour
- Re-platform pressure: Organisations consider replacement instead of repair
What does good look like in practice?
IAM architecture is defined independently of any product. (Remember, we aren't being led by tools, but by our business processes!)
Tools are selected to enforce known decisions, not discover them.
Customisation is deliberate and minimal. (You have no idea how much pain customisation has caused in the past!)
Replacement is rare because evolution is planned.
What are the trade-offs?
Delaying tooling decisions can feel uncomfortable, but it prevents years of compensating controls and workaround logic later. Fast tooling decisions almost always create slow programmes.
In our experience...
Some IAM programmes treat their products as a "strategy". This rarely goes well.
Do you need specialist support?
You probably need to call in external help when you start to spot the following behaviours:
- Tool configuration discussions are driving governance decisions
- IAM platforms are blamed for design shortcomings
- Re‑implementation is being considered within three years of go‑live
And remember...
