Hiya folks,
Quick one on something I keep running into: IAM and CIAM teams that never actually talk to each other. Workforce IAM and customer IAM (CIAM) usually sit in different teams, sometimes different business units entirely, and they often build their identity practices like the other one doesn’t exist.
I want to walk through where that shows up, then what I’ve seen actually help.
Different teams, different scoreboards
The split makes sense on paper. Workforce IAM cares about governance: who has access to what, can you prove it at audit time, does the joiner-mover-leaver process actually work. CIAM cares about conversion, latency, and not annoying ten million customers with an extra MFA prompt. Different risk profile, different scale, different stakeholders funding the work.
Because the goals diverge, the teams diverge too. Different reporting lines. Different vendors, half the time. Different roadmaps that never cross-reference each other. I’ve sat in rooms where the workforce team had a mature access review and certification process running for two years, and the CIAM side of the same company was still doing manual account cleanup in a spreadsheet. Neither team knew the other existed until a security review forced the conversation.
Where it actually bites you
A few patterns I keep seeing:
Inconsistent MFA and risk logic. Workforce IAM might run adaptive MFA with proper risk signals, device trust, the works. CIAM, built separately and often years later, ends up with a bolted-on OTP flow that doesn’t share any of that risk context. Same company, two completely different answers to “is this login suspicious.”
Duplicated identity data models. Both teams end up defining their own version of “what is a user,” their own attribute schemas, their own notion of a session. When the business tries to do anything cross-cutting, like a single customer who’s also an employee, or a partner who needs both portals, nobody has a clean answer.
No shared incident learning. CIAM teams deal with credential stuffing and bot traffic at a scale workforce IAM rarely sees. Workforce IAM deals with insider threat and privilege misuse in ways CIAM rarely has to think about. Both sides are sitting on real operational experience the other side needs, and it just doesn’t move across the fence.
Compliance done twice. Privacy obligations, breach notification, access logging, sometimes even the same regulation, worked out independently by two teams who never compared notes. That’s wasted effort at best, inconsistent answers at worst.
None of this is anyone being careless. It’s what happens when two capable teams optimise for their own scoreboard and nobody owns the seam between them.
What’s helped when I’ve seen it fixed
A shared identity data model, even a light one. Doesn’t need to be one system. Just agree on what a “user” record contains at a conceptual level, and where the two worlds intersect (an employee who’s also a customer, for instance). Even a one-page shared glossary cuts down a surprising amount of confusion.
Joint threat modelling, twice a year is enough. Get both teams in a room, walk through recent incidents on both sides. CIAM’s bot and credential-stuffing playbook is real, useful input for workforce IAM’s external-facing apps. Workforce IAM’s privilege escalation lessons are relevant the moment CIAM starts handling partner or B2B access with elevated permissions.
A common IdP substrate where it makes sense. Not always practical, and I wouldn’t force it. But where the platforms can share a core identity layer, even with separate front doors and separate policies layered on top, you avoid the duplicated build and get consistent session and risk signals for free.
One person (or a small group) whose job is the seam. This is the one that actually moves the needle. Someone with enough context in both worlds to notice when a workforce control would help CIAM, or vice versa, and enough standing to get it on both roadmaps. Doesn’t need to be a big role. Just needs to exist.
The honest bit
I don’t think there’s a clean org chart fix here. Different KPIs, different regulatory pressure, different scale, they’re not going away, and honestly they shouldn’t, the teams are optimising for real and different things. What I have seen work is treating the disconnect as a known risk to manage rather than something that gets discovered during an incident review. A recurring conversation, a shared vocabulary, and someone accountable for the gap gets you most of the way there without pretending the two worlds should just merge.
If your org has actually solved this well, I’d genuinely like to hear how. This is one of those areas where I suspect the good answers are still mostly tribal knowledge, not written down anywhere.
References
NIST SP 800-63 — Digital Identity Guidelines
OpenID Foundation
NIST — Identity and Access Management