PoC in IAM/IGA: Necessary Evil or Strategic Tool?

In the world of IAM/IGA projects, everyone thinks they know what a Proof of Concept (PoC) is—and most will privately admit what they really feel: PoCs are often a waste of time. They become a form of self-reassurance, a ritual to feel safer before committing to a real implementation.

And the industry silently agrees: PoCs rarely bring actual assurance. More often, they delay the start of the real project, they don’t forecast the problems that truly matter, and they certainly don’t reflect the complexity of a full deployment.

The uncomfortable truth

Let’s be honest: the real issues of an IAM/IGA implementation only surface when you go deep—into actual business processes, real data quality challenges, non-standard integration logic, post-go-live process ownership, and politically charged decision-making. No PoC predicts that. Only a real project does.

And let's add another honest point: most system integrators and subcontractors dislike running PoCs. They derail schedules, they aren’t fully funded, they require context without commitment, and they often end with “Thank you, we’ll think about it.”

That’s the dark side.

But not so fast — PoCs can have real value

In our experience, there are only two valid reasons to run a PoC in IAM/IGA:

1) To create clarity and confidence for decision-makers

Sometimes stakeholders need to see something alive. A working login flow. An approval workflow. An identity created in one system and landing in another. A portal where the user experience is not theoretical but visible.

This type of PoC is emotional, not technical. It exists to generate a moment: “Wow, it actually works.” “Wow, it might be useful for us.”

If this is the only goal, we don’t need a PoC. We need an extended demo session tailored to the client’s context. That delivers the same result without wasting weeks.

2) To validate serious technical or business concepts

This is the case where a PoC makes sense—when we must prove something non-trivial, such as:

Complex multi-system integration logic
Non-standard provisioning or deprovisioning flows
Business processes with exceptions, editable fields, or special delegation logic
Integration with legacy systems that behave “unexpectedly by design”

In this case, a PoC must be treated seriously—not as a sandbox, but as a micro-project.

So why ID Masters?

Simple: because the hard parts of PoCs are technical, and that’s where we are strongest.

Our background is not only in IAM consulting, but in software development and integration engineering. That means:

Need to integrate something “that shouldn’t logically integrate”? → We’ll make it talk.
Non-trivial business logic with editable fields, exception routing, or custom roles? → Done.
Stakeholders constantly ask to adjust the portal? → Our web development experience is at your service.

If it’s realistic in this universe, we’ll deliver it.

In other words, we don't fear PoCs. We only insist they are done for the right reasons.

Want a PoC that actually moves the decision forward?

If you’re running an IAM/IGA selection or preparing a rollout and need a PoC that is realistic, measurable, and reusable, we can help you structure it as a micro-project—not a time sink.