Identity fragmentation isn’t usually the result of bad architecture. It’s the natural byproduct of growth. New apps get added. Business units operate independently. Acquisitions bring in new identity stacks. And over time, even well-designed IAM environments start to sprawl.
In our recent masterclass, Richard Esplin (Head of Product) and Agne Caunt (Product Owner) walked through what this looks like in the real world and, more importantly, how organizations can evolve toward a unified identity architecture without ripping out the systems they already rely on. The session explored the limits of traditional federation, the shift toward reusable digital ID credentials, and a practical, phased path teams can use to reduce duplication, improve flexibility, and move closer to a zero trust model.
Below are the key insights and takeaways from the session.
Why identity architectures fragment
- Organizations keep changing, and architectures get left behind
- New teams, partners, and tools show up and demand integrations fast.
- Under time pressure, teams often stand up a new system rather than refactor an existing one, creating “identity sprawl.”
- The practical outcome: multiple IAM/identity systems + multiple records for the same person.
- The webinar anchors this in a realistic composite example
- A scaled, consumer-facing business with loyalty + medicine/pharmacy + photo pickup + call center experiences.
- Growth via acquisition leaves a patchwork of platforms where each database holds a slice of customer identity.
Why “one big customer database” usually fails in the real world
- Different datasets have different governance + lifecycle requirements
- Patient records, payment data, loyalty data, etc. can’t simply be merged into one giant accounts DB because policies and assurance requirements differ.
- Federation becomes the default tool, but it doesn’t prevent sprawl
- “Typical IAM” pattern: identity proofing → create IdP account → use integrated app; valued for mature tooling and centralized governance.
Federation in theory vs. federation in practice
- In theory
- One “beautiful” IdP, cross-app person matching, clean authn/authz separation, and consistent employee + customer access paths.
- In practice, it fragments again
- Different assurance levels drive multiple identity proofing platforms and multiple IdPs (e.g., pharmacy/medical vs. general consumer).
- New offerings under tight timelines get built alongside the IdP instead of integrated (photo pickup is the example).
- Internal teams create direct accounts in line-of-business systems (e.g., call center accounts) because needs differ and “we’ll fix it later” rarely happens.
- This is not just “enterprise pain”
- Agne’s point: startups hit the same “customer 360 / reliable central data” pressure once they scale.
- Richard’s response: smaller orgs can suffer worse because it’s often one person handling identity under constant deadline pressure.
What IAM architects say the pain looks like (signals from interviews)
- Federation sprawl is measurable
- “600 apps → integrated 120 → now 800 apps” (growth outpaces integration capacity).
- “Five customer-facing identity providers (from acquisitions) → customers update address at each counter separately.”
- “M&A rarely shares the same IT architecture” + “federation like an assembly line.”
- Recurring themes beyond sprawl
- Security: need more granular roles + movement toward “zero trust.”
- Matching records: deduping/recognizing the same person is hard; lacks an automatable pattern; may require a new architecture.
- Architecture direction: desire for a “web of data” and to simplify systems while improving UX.
- Governance: reduce data held (liability), comply with regulations, and deal with operational overhead (firewall changes, cert rotation, permissions/offboarding across teams).
- Flexibility: schema changes ripple through integrations; passkeys adoption is blocked by legacy compatibility; vendor end-of-life forces change anyway.
The core mindset shift: from “connecting systems” to “moving trusted data”
- Stop treating identity as rows in databases
- Treat identity data as reusable ID credentials issued by trusted sources.
- Put credentials in a user-specific wallet
- Use user consent as the “connection point”
- Systems request what they need from the wallet; consent is the bridge that allows identity data to move where it’s needed.
- Generic architecture pattern
- Identity proofing issues a credential → stored in holder wallet → presented for authn/authz via verification APIs.
Wallet integration: 4 practical flows
- Flow 1 — Onboarding (identity proofing → wallet issuance)
- Client app requests onboarding → redirected to wallet → user sets up wallet access → wallet returns a wallet address → issuer uses it to issue credentials.
- Wallet access options mentioned: device-bound, cloud + biometric, passkeys, mnemonic/password. Chosen to minimize UX disruption.
- Flow 2 — Authn/Authz initiated from the user’s app
- User initiates from their app → relying party sends verification request using wallet address → wallet requests consent from the user → verification response returned to relying party.
- Flow 3 — Authn/Authz initiated from the relying party (web redirect)
- Users start at a relying party website → “Do you have your ACME ID?” → redirect to wallet with verification request → user consents → wallet returns response to relying party (often via webhook).
- Flow 4 — Relying party initiated (call center / back office)
- Agent triggers verification request → needs a way to locate the wallet (phone/email/customer identifier used for lookup, not as the auth factor) → wallet prompts the user for consent → response returned to the relying party.
- Explicitly called out as especially effective for call centers, but applicable elsewhere.
A pragmatic migration path: evolve the messy reality in phases (don’t rip-and-replace)
- Phase 1: digital ID credentials for one painful use case
- Start with the “least integrated / most complained about” area (photo pickup example) and add wallet-based consent + credential issuance for that use case.
- Phase 2: make the IdP act as a verifier (bridge old + new)
- Keep legacy apps consuming traditional tokens, but have the IdP leverage credentials so the user experience becomes consistent across use cases.
- Phase 3: direct verifier integrations
- Modify relying party apps to call verification APIs directly instead of depending on IdP token flows.
- Phase 4: remove the legacy IdP (or reduce it to proofing only)
- Once apps use digital ID credentials directly, the IdP becomes mostly an identity proofing component; eventually you can remove that block and plug in new issuers/verifiers easily.
- The “promised land” outcome
- Adding a new issuer or relying party becomes “just plug in,” enabling a scalable “web of data” without constant rework of a central IM hub.
Implementation tips (how to start without boiling the ocean)
- Don’t break what’s already working
- Move incrementally; stop at any phase where you’re getting value.
- Inventory your identity verification needs
- Catalogue which systems verify identity, what attributes they need, and the required level of assurance.
- Inventory data sources + binding strategy
- Check if sources meet assurance needs, and define how you confidently bind data to the person.
- Design for flexibility + minimize UX disruption
- “Have the user carry their credentials,” and choose wallet modality that fits existing flows (OTP, biometric, etc.).
- Start internal before external
- External reuse quickly becomes a legal/business-ops project (liability, agreements, insurance), not primarily a technical one, so internal use cases deliver faster wins.
Trade-offs (what architects need to plan for)
- Wallet introduction is a big change
- Even if “hidden,” it’s still a meaningful architectural shift.
- Ecosystem support is immature
- Verifiable Credential (VC) standards are newer; most IAM systems don’t have “point-and-click” VC integrations like they do for SAML/OAuth, so REST-based custom integration is often required.
- Reporting shifts from centralized to distributed
- Moving away from an IdP-centric model means rethinking audit/security instrumentation; logging becomes more decentralized (but can yield better visibility if done well).
Advantages
- Flexibility at scale
- Add new credentials and new apps without cascading changes across everything else.
- Extends beyond internal boundaries
- Internal architecture can extend across business units, partners, and jurisdictions when you’re ready.
- Privacy/consent and “zero trust” become architectural defaults
- Consent-driven data sharing is built in, and credentials can be verified repeatedly (instead of “authenticate once, trust forever”).
- Biometric-bound credentials are a natural extension
- They flag that end-to-end biometric checks can be incorporated in a privacy-preserving way (covered in a separate session).
Q&A insights
- Business vs consumer wallets
- Richard clarifies the model supports workforce + consumer wallets, and mentions organizational wallets + delegation as a separate topic they didn’t cover deeply.
- Web wallet vs mobile wallet: likely coexistence
- Agne leans toward web wallets being more universal/easier operationally; Richard frames mobile as more important for cross-organization discovery/selection, while web works well within a single organization’s “walled garden.”
- Agentic identity teaser
- Agne highlights delegation as the key agent use case: humans need to delegate authority to agents, and verifiable credentials fit naturally, but governance/safety controls matter.
- Apple/Google support for VCs
- They note Apple/Google support is constrained (e.g., ISO mDL/mDocs with controlled schemas), and position Digital Credentials API + third-party wallets/SDKs as the practical near-term path (with Android clearer than Apple).
