Sphereon
insight
A wallet is a channel, not the strategy
Wallets improve one interaction: the moment a person presents a credential. They do not govern what that credential means, which policy applies after verification, or how the decision can be proven. Organizations that treat the wallet as the strategy inherit all of these problems, unsolved.
A wallet is a presentation channel. It carries data from one party to another with a cryptographic proof attached. That is genuinely useful. But it does not answer the governance questions that follow: what does the data mean? Who authorized its use? Under which policy? With what audit obligation?
Those questions exist in every channel: the portal, the API, the form, the document, the QR flow, the machine interface. If each channel answers them separately, the organization does not have one compliance posture. It has several, poorly connected, and impossible to audit as a whole.
The organisation does not live in the wallet.
Think about the touchpoints where credential data actually matters in a typical organisation. An employee presents a professional qualification during onboarding: that happens in an HR portal. A supplier confirms accreditation status: that arrives via a procurement form or an API call. A contractor accesses a restricted facility: that goes through a QR reader or an NFC check at a gate. A machine requests authorisation to operate in a controlled environment: that is a system-to-system call. None of these are wallet interactions.
Each of those touchpoints needs the same answers a wallet flow needs: is this data authentic? Does this person, organisation, or machine meet the policy threshold? What access or permission follows? And how is the decision recorded? If the wallet infrastructure provides those answers for wallet flows and everything else is handled ad hoc, the organisation has not built a trust layer. It has built a wallet feature.
What wallet-only thinking actually creates.
When each channel builds its own answer to the identity and compliance question, the organisation accumulates trust models. The HR system has one definition of a valid professional qualification. The procurement platform has another. The access control system has a third. Each was built to solve a local problem, by a different team, at a different time, under a different set of assumptions.
The consequences are practical and immediate. A regulatory change requires updates in every system that encoded the old rule, not in one place. An audit requires evidence from every system that made a decision, assembled manually. A policy exception requires changes in every channel where that policy is enforced. What should be a governance operation becomes a remediation project.
Adding a wallet to this picture does not resolve the fragmentation. It adds one more channel with its own trust logic, credential format assumptions, and verification behaviour. If that wallet channel is not connected to the same authoritative model as everything else, it compounds the problem rather than solving it.
The compliance risk is not theoretical.
Frameworks such as NIS2 and eIDAS 2.0 do not ask whether an organisation has deployed a wallet. They ask whether the organisation can demonstrate that it has taken appropriate technical and organisational measures: that access was controlled, that supplier and partner credentials were verified, that decisions were made under a defined policy, and that evidence of those decisions is retained and producible.
A fragmented identity and compliance architecture cannot reliably answer those questions. If trust logic is distributed across systems that were never designed to produce a unified audit trail, the organisation cannot prove its duty of care. It can describe what its systems were intended to do. It cannot demonstrate what they actually did, when, and under which version of policy.
Under NIS2, management bears direct liability for failure to implement adequate risk measures. That liability does not attach to the wallet. It attaches to the decision-making process and the evidence that supports it.
If that evidence is incomplete, inconsistent, or impossible to assemble across systems, the compliance gap is not a technical inconvenience. It is a board-level risk.
One model. Every channel.
The answer is not to abandon wallets. Wallets are a useful and increasingly important channel, particularly as EUDI Wallet adoption accelerates under eIDAS 2.0. The answer is to stop treating the wallet as the architecture and start treating it as one output of a wider model.
That model defines three things authoritatively. First, what each data element means: its purpose, legal basis, sensitivity, retention rules, and disclosure constraints. Second, who or what is trusted to assert it: which issuers, registries, and trust frameworks are recognised. Third, what policy governs its use: which thresholds must be met, what access follows, and what evidence must be retained.
Once that model exists, every channel becomes a projection of it. The wallet requests and verifies credentials according to the same attribute definitions as the portal. The API enforces the same policy thresholds as the access control system. The audit trail is consistent across all of them because every decision references the same model, the same policy version, and the same trust registry. A regulatory change or a policy update propagates once, not channel by channel.
Where Sphereon fits.
Sphereon provides verifiable data exchange infrastructure. It covers the full scope: defining what data means, establishing who or what is trusted, exchanging verified data across channels, enforcing policy at runtime, retaining secure evidence, and producing structured audit trails.
That infrastructure works across wallets, portals, APIs, web forms, QR flows, documents, and machine-to-machine integrations. As machines and AI agents increasingly act on behalf of people and organizations, the same trust primitives apply: identity, credentials, authority, delegation, policy, and auditability evaluated at runtime. The wallet is one channel in that model. It is not the model itself.
Stop building channels. Build the model.
Talk to Sphereon about replacing fragmented trust logic with one authoritative model of meaning, policy, and audit across every channel your organisation operates.