Should organisations prioritise wallet interoperability or broader IAM modernisation first?

Why interoperability should lead the programme

Wallet interoperability is the integration problem that determines whether adoption can actually start. If the organisation cannot accept more than one wallet ecosystem, any later IAM modernisation still leaves users and applications split across inconsistent sign-in, trust, and verification paths. The first priority is therefore to make the acceptance layer predictable, testable, and supportable.

That does not mean broader IAM work is postponed indefinitely. It means the modernisation roadmap should be sequenced so that wallet acceptance, trust validation, and policy enforcement are stable enough for the identity platform to absorb them without creating parallel exceptions. In practice, interoperability is the prerequisite that turns a strategy into something the business can deploy.

When wallet integration is weak, the failure is usually not the wallet itself but the surrounding identity plumbing, inconsistent claim mapping, incompatible assurance expectations, or a trust model that only works for one provider. Organisations that modernise IAM first without solving the wallet interface often end up reworking the same controls twice.

What broader IAM modernisation should still cover

Broader IAM modernisation matters, but it should be treated as the structural layer that follows once wallet integration is viable. That layer includes federation design, authentication policy, account linking, lifecycle governance, auditability, and exception handling. Those capabilities decide whether wallet use is a one-off pilot or a sustainable operating model.

A useful way to frame the dependency is that interoperability answers “Can we accept and verify this wallet consistently?” while IAM modernisation answers “Can we govern that acceptance at scale?” If the second is tackled first, the organisation may improve internal control design but still fail to connect cleanly to the wallet ecosystems users are already being asked to use.

For teams managing external trust relationships, the acceptance layer should align with established identity and access patterns rather than sit outside them. Guidance on choosing an identity provider is useful here because wallet support depends on the same practical questions: federation, assurance, admin control, migration effort, and how well the platform handles mixed identity sources.

How to sequence the work without creating long-term fragmentation

The right sequence is usually: establish interoperability requirements, prove wallet acceptance end to end, then fold the resulting patterns into the wider IAM target state. That keeps the programme from overdesigning a future state that cannot yet consume the new wallet relationships. It also reduces the chance that wallet support is built as a special case with no clear owner.

At the same time, the IAM redesign should not be left vague. Teams should define which controls will eventually own trust policy, lifecycle events, identity proofing dependencies, and logging. If those responsibilities stay ambiguous, interoperability may work technically but fail operationally because no one can explain who approves changes, who monitors breakage, or who retires obsolete paths.

For organisations already running complex identity estates, a broader roadmap can be easier to operationalise when it is anchored in a programme view rather than a tool view. The Identity Security Programme Guide is relevant because wallet interoperability is not just a technical connector, it is a governance decision about how identity is controlled, measured, and funded across the estate.

Risk and Threat Considerations

Wallet interoperability can create exposure if organisations treat every wallet as equivalent, or if they accept a wallet without clear rules for assurance, revocation, and account binding. The main risk is fragmented trust, where users appear to be supported but the backend cannot enforce consistent identity confidence or detect abuse cleanly.

Failure mechanism: Weak interoperability usually shows up as duplicate identities, inconsistent claim translation, or ad hoc exceptions that bypass central policy. That creates gaps in authentication assurance, auditability, and offboarding, especially when multiple wallet ecosystems must be supported simultaneously.

Impact: The organisation may end up with a modern IAM stack that is cleaner on paper but still unable to verify users consistently across wallet types. In the worst case, attackers benefit from the same fragmentation, because ambiguous trust boundaries make abuse, replay, or account-linking mistakes easier to hide.

Practitioner Guidance

What to prioritise: Treat wallet acceptance criteria as the first deliverable, not the final architecture. If the organisation cannot define how a wallet is trusted, mapped, and revoked, broader IAM modernisation should be scoped only to the parts that unblock those decisions.

What to verify: Confirm that the current IAM platform can handle multiple wallet ecosystems without custom exceptions, manual reconciliation, or separate policy tracks. The practical test is whether a wallet can be introduced, governed, and retired with the same operational discipline as any other identity source.

Common mistake: Teams often modernise authentication tooling first and assume wallet support will follow automatically. That usually produces a more expensive stack, not a more interoperable one, because the integration and governance gaps remain untouched.

Practitioner takeaway: Start with interoperability when wallet adoption is the immediate objective, then use the lessons from that integration to shape IAM modernisation so the target state is governable, not just technically ambitious.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• What should organisations prioritise first in IAM and IGA modernisation?
• Should organisations prioritise agent governance or broader DLP modernisation first?
• Should organisations prioritise passwordless or privileged access modernisation first?