Now Live  ·  5 min read  ·  From the Onboard.id team

We want to take a moment to step back from the product and explain where it came from — not in the polished language of a press release, but in the way we’d describe it if we were having coffee.

Because Onboard.id didn’t come from a product roadmap or a market analysis. It came from watching IGA programs — across industries and sectors — hit the same wall over and over again for fifteen years.

The Wall

UberEther has been building and running identity programs for federal agencies since 2011. We’ve implemented SailPoint across multiple federal environments. We’ve operated IAM Advantage — our FedRAMP High and DoD IL5 authorized managed identity platform — for customers who need a deployment-ready ICAM foundation.

And in program after program, we watched the same thing happen: the platform gets deployed, the team gets trained, the stakeholders are aligned, and then progress slows to a crawl. Not because the platform isn’t working. Because the applications can’t get onboarded fast enough to keep up with governance requirements.

The ICAM engineers are swamped. The application owners don’t know what information the IGA team needs. The discovery process is manual and inconsistent. Documentation is an afterthought. And the compliance clock is ticking.

Why We Didn’t Just Hire More Engineers

The obvious solution — the one most programs try first — is to staff up. Hire more ICAM engineers. Bring in more consultants. Throw more expert labor at the problem.

We did this too, in our early years. And it works, up to a point. But it doesn’t scale. Every additional engineer you add to the onboarding process adds cost and coordination overhead. The productivity gains diminish. And you’re still left with a process that depends entirely on expert labor and doesn’t generate consistent documentation.

Somewhere around year five of watching this pattern, we started thinking about it differently. The onboarding bottleneck isn’t a staffing problem. It’s a workflow design problem. And workflow design problems are solved with software, not with headcount.

What We Believed Had to Be True

We started with a set of convictions about what a real solution would require:

• It would have to make application owners the primary contributors — because they’re the ones who know their applications.
• It would have to encode ICAM expertise into the platform — because that’s what makes the intake accessible to non-experts.
• It would have to generate documentation automatically — because programs can’t afford documentation as a separate effort.
• It would have to produce SailPoint IIQ connector configurations directly — because that’s the actual deliverable the IGA team needs.

None of those requirements are particularly exotic. But building a platform that met all of them required a team that understood both the IGA ecosystem and the federal compliance environment. We had that team. So we built it.

Why Now

The timing of the launch isn’t accidental. The DoD CIO ICAM mandate is creating compliance pressure that federal organizations can’t absorb with traditional onboarding approaches. The application portfolios are growing. The headcount constraints are real. The deadlines are fixed.

We launched Onboard.id because the problem is urgent, the solution is ready, and there’s nothing else like it on the market. We’re the first purpose-built IGA application onboarding platform. We didn’t plan to be first because of competitive strategy — we’re first because nobody else has built this yet.

We think that’s about to change. And we’d rather be the ones who built it.