The Wallet Is Not the Authority
A wallet can carry proof of authority, but it cannot create the authority it claims to represent.
Executive Summary
The European Business Wallet is easy to misread. The visible proposition is a digital container through which a company can identify itself, exchange trusted documents, sign or seal records and communicate with another business or public authority. Those capabilities matter. They could remove friction from cross-border licensing, procurement, onboarding and reporting. But they are not the most consequential part of the proposal.
The deeper possibility is a shared authority layer for European business. A counterparty could verify not only which organisation is present, but whether the person acting for it holds a valid mandate, within what limits, for what purpose and at what time. That would turn corporate authority from an assortment of registry extracts, board minutes, powers of attorney, identity checks and internal approval records into evidence that can be tested by a system.
The law and infrastructure are not there yet. The European Commission proposed a dedicated Business Wallet regime in November 2025. The Council adopted its negotiating position on 9 June 2026, explicitly retaining identity proof, trusted documents, signatures, seals, secure communications and delegation of legal authority. The same Council position also preserves national administrative requirements and existing powers of attorney, and says wallets should complement rather than replace national business systems. The legislation remains under negotiation. [S1] [S2]
That boundary defines the leadership task. Enterprises should treat the wallet as a potential external trust interface, not as the source of authority itself. Internal delegations, approval matrices, identity controls and legal mandates will still determine who may act. The wallet’s value will depend on whether those rules can be expressed as interoperable, bounded and revocable evidence, and whether a relying party can use that evidence without mistaking technical validity for legal sufficiency.
The Transaction Behind the Document
Consider a familiar cross-border supplier onboarding. A company in one member state wants to join a public procurement framework in another. It submits a company extract, tax evidence, professional licences and a signed declaration. The authority must establish that the entity exists, that the documents are genuine, that the signatory is the person named, and that this person can commit the company. The parties may repeat versions of the same exercise for a bank, an insurer, a regulator and a large customer.
Digitising the documents helps, but the difficult question is rarely whether the PDF arrived. It is whether the evidence still means what the receiving organisation needs it to mean.
The Commission’s proposal responds to fragmentation in cross-border business identification and document exchange. It envisages a harmonised framework for economic operators and public bodies to identify and authenticate themselves, exchange verified information with legal effect, manage representation rights and mandates, and interact through a secure channel. It builds on the eIDAS trust framework and related European identity infrastructure rather than starting from a blank sheet. [S2]
The Council’s position makes the intended functions unusually concrete. It includes proving identity, creating and sharing trusted documents, signing, timestamping and sealing, delegating legal authority, and communicating securely. These are not merely document-storage features. Together they describe a transaction in which identity, evidence, intention and authority can travel as a connected set. [S1]
That is the important move. A wallet can carry proof of authority, but it cannot create the authority it claims to represent.
If that sentence is lost, the programme will be designed as another channel project. If it is understood, the wallet becomes an operating-model question spanning legal governance, identity architecture, procurement, risk, records and transaction policy.
Identity Is Only the First Question
Enterprise identity programmes have spent years improving authentication: establishing that a user, device or service is the party presenting a credential. That is necessary, but corporate transactions demand a longer chain of reasoning.
When a finance director signs a document, the relying party needs answers to at least four different questions:
- Entity: Which legal organisation is involved?
- Person or service: Who is presenting the evidence or initiating the action?
- Authority: What permits that actor to act for the organisation?
- Transaction: Does the authority cover this particular decision, amount, jurisdiction and moment?
Conventional digital identity often answers the first two. Corporate governance lives in the latter two.
This distinction explains why representation is so consequential. A corporate identifier may match a registry entry perfectly while the representative’s mandate is expired, limited to another subsidiary, capped below the transaction value or restricted to a different class of document. Conversely, a person may have genuine legal authority that is poorly represented in digital systems. Neither situation is solved by stronger authentication alone.
The proposed wallet points towards bringing these layers together. Yet the Council is explicit that the authorisation system should not affect powers of attorney or legal mandates under national or Union law. National procedural requirements also remain applicable. The wallet may therefore make evidence portable without making its legal meaning uniform. [S1]
That is not a minor implementation detail. It is the difference between a shared authority layer and a shared envelope for nationally different evidence.
The Authority Chain
For machine-verifiable corporate authority to work, six links must hold.
- An authoritative identity source must establish the organisation and match it consistently across registries, credentials and transactions.
- A trusted issuer must attest to relevant attributes, licences, roles or mandates.
- The wallet must present the evidence without losing integrity, provenance or status information.
- A mandate must express who may act, for which entity, within which scope, for how long and under what delegation rules.
- The relying party must evaluate that evidence against its own transaction policy rather than accept it blindly.
- An audit record must preserve what was checked, what decision was made and which evidence supported it.
Technical research into digital delegation reaches a similar conclusion from another direction. One proposed architecture treats delegation as a first-class, revocable artefact with least-privilege scope, separates credential validation from policy evaluation, and normalises evidence across heterogeneous protocols. It is a research proposal rather than an EU standard, but it usefully exposes the design problem: reliable delegation requires more than handing over a credential. [S6]
| Evidence layer | Question answered | Enterprise control |
|---|---|---|
| Organisation identity | Which legal entity is this? | Registry matching and master data |
| Credential | What verified fact is being asserted? | Issuer trust and validity checking |
| Mandate | Who may act, and within what limits? | Legal delegation and approval policy |
| Transaction decision | Is this action acceptable now? | Risk rules, value limits and exceptions |
The table also shows where accountability sits. No single wallet provider can own the full chain. Registry operators, credential issuers, trust-service providers, the represented organisation and the relying party each control different facts. The wallet joins their evidence; it does not collapse their responsibilities.
A Worked Authority Test
Imagine an illustrative, composite transaction. A regional subsidiary of a manufacturing group is negotiating a €2 million supply agreement with a public-sector buyer in another member state. A procurement director presents a Business Wallet credential identifying the subsidiary and a mandate authorising supplier contracts.
The transaction appears straightforward until the receiving system tests the mandate.
The credential names the correct company, but the group uses similar legal names in several jurisdictions. The system must bind the credential to the exact legal entity and registry identifier. The mandate grants authority for contracts up to €500,000, unless a second officer approves. The procurement director is authenticated, but cannot act alone. The mandate expires at the end of the quarter and has been sub-delegated from a parent-company officer. The buyer’s policy requires direct authority from the contracting subsidiary for transactions above €1 million.
A document-centred workflow would see a valid identity, a valid signature and a plausible authority record. An authority-centred workflow would reject or escalate the transaction because scope, value and delegation chain do not satisfy policy.
Now change one fact. The wallet presents a second, current approval from the subsidiary’s finance director, issued by a trusted source and linked to the same transaction. The evidence chain becomes sufficient, and the buyer can retain a structured record of the decision.
This example is not a report of a deployed European Business Wallet. It is a composite designed to show the mechanism. The potential gain is not that software replaces judgement. It is that the evidence needed for judgement becomes more precise, reusable and testable.
The same mechanism could apply to regulatory submissions, licence renewals, delegated seals, supplier onboarding and corporate filings. In each case, the wallet is useful only when the relying party can distinguish valid evidence from sufficient authority.
Four Fault Lines
Identity Matching
Cross-border authority begins with a deceptively basic problem: are two records referring to the same organisation? The Commission proposal points to existing European identifiers and registry infrastructure, but also recognises that not every economic operator is covered in the same way. [S2]
An enterprise can undermine a sophisticated trust service with weak legal-entity master data. Different spellings, reorganisations, branches, trading names and duplicate supplier records can break the link between a credential and the risk record against which a decision is made. The control response is not simply to collect more attributes. It is to define authoritative identifiers, matching rules, exception handling and ownership for corporate identity data.
Mandate Semantics
Authority is rarely binary. It contains scope, value, geography, purpose, duration, conditions, delegation rights and sometimes joint-signature requirements. A mandate that says “authorised representative” may be technically portable and operationally useless.
The hard work will be creating semantics that are sufficiently common to verify across borders while remaining faithful to national law and corporate governance. A machine must be able to distinguish permission to submit a licence application from permission to enter a contract, and a general signing role from authority over a particular subsidiary. Until such distinctions travel reliably, human legal review will remain embedded in many high-value workflows.
Revocation and Time
Authority changes faster than corporate identity. People move roles, delegations are withdrawn, entities merge, temporary approvals expire and emergency powers are activated. A credential can be authentic and still be stale.
Revocation must therefore be a transaction-time control, not an occasional data-cleaning activity. The relying party needs to know which status source is authoritative, how quickly changes propagate, what happens when the source is unavailable, and whether evidence retained for audit shows the status that existed when the decision was made.
This is where wallet enthusiasm often outruns operating reality. Presentation is visible; revocation plumbing is not. Yet stale authority is precisely the failure that turns an apparently valid digital transaction into a legal and control dispute.
Liability and Reliance
Machine-verifiable evidence does not answer who bears loss when evidence is wrong, late, compromised or interpreted too broadly. Liability may sit differently with the organisation, representative, issuer, provider, registry or relying party depending on the failure.
Industry feedback reflects this concern. Bitkom supports an interoperable, integrated approach but asks for clear liability, realistic timelines, binding public-sector acceptance and proportionate security and conformity requirements. This is an interested industry position, not neutral evidence; it nevertheless identifies the adoption bargain. Firms will not redesign high-volume processes around wallet evidence unless they know when reliance is reasonable and what happens when the chain breaks. [S4]
The Strongest Sceptical Case
The credible sceptical view is that European Business Wallets will simplify administration without transforming corporate authority. Public bodies may accept a common digital channel while retaining national forms, checks and legal interpretations. Private firms may use wallets for low-risk document exchange but keep bilateral onboarding for important transactions. Provider authorisation and certification may strengthen trust while slowing market capacity. The result would be a useful front end attached to fragmented back ends.
The Council position gives this view real weight. Wallets are intended to complement existing national systems; national procedures remain; powers of attorney are unaffected. The legislation is still being negotiated, and political ambition for agreement is not implementation. [S1]
Technical caution reinforces the case. Independent analysis of the wider European digital identity architecture argues that trusted-list models can recentralise control and that existing protocols do not automatically deliver the broader identity properties attributed to them. That research is a preprint focused on the person-centred EUDI architecture, so it cannot be transferred mechanically to Business Wallets. It does, however, challenge the assumption that interoperability at protocol level produces an open, dynamic trust ecosystem by itself. [S5]
The sceptical case sharpens the thesis. The strategic value of the wallet does not follow from adoption of a common application. It follows only if four conditions converge: reliable entity matching, expressive mandate structures, timely revocation and a liability model that makes evidence usable. Without them, the wallet still has value, but as document and communication infrastructure rather than as a shared authority layer.
This conditional conclusion is more useful than either celebration or dismissal. It tells enterprise leaders what to watch in implementing acts, standards, pilots and counterparties’ acceptance policies.
External Trust, Internal Control
The most common architectural mistake will be to place the Business Wallet inside an identity team and treat it as an extension of employee access management. Internal IAM and external legal authority overlap, but they are not the same system.
IAM answers whether an account may use an application or perform a technical operation. Corporate authority answers whether a person or service may create an externally binding consequence for a legal entity. A procurement manager may have access to a contracting platform without authority to sign a €2 million agreement. A statutory director may possess legal authority without a day-to-day account in the relevant workflow. A service account may execute an approved transaction without being the source of approval.
Enterprises need an explicit bridge between these layers. That bridge should connect:
- legal entities and authoritative identifiers;
- roles, offices, mandates and delegation chains;
- IAM accounts, services and privileged access;
- transaction policies, including value and risk limits;
- signing, sealing and approval workflows;
- revocation, evidence retention and incident response.
The wallet should expose validated evidence to this control environment. It should not become a parallel source of truth that quietly diverges from board authorities, powers of attorney, HR changes or approval matrices.
Certification matters within this design. ENISA’s work on EUDI Wallet certification shows the institutional effort required to turn security claims into assessed controls, build national capability and create mutual trust. It is not a Business Wallet certification scheme, but it demonstrates that wallet infrastructure depends on governance, certification capacity and operational assurance, not only specifications. [S3]
The same caution applies to automation. Research proposals show how eIDAS trust chains might bind legal identity to smart contracts or encode bounded delegation for AI agents. These are useful demonstrations of what machine-verifiable trust could enable. They are not evidence that autonomous agents can bind companies under the proposed regime. [S6] [S7]
A Practical Authority Agenda
The immediate enterprise task is not to buy a wallet. It is to make corporate authority legible enough to connect to one.
Start by mapping a small number of external actions where repeated verification creates material friction: supplier onboarding, regulatory submissions, delegated signing, licence evidence or public procurement. For each action, separate organisational identity from representative authority and transaction acceptance. Record which source currently proves each element and where judgement enters the process.
Then test the quality of the mandate model. Can it express legal entity, role, scope, value, geography, duration, joint approval and delegation? Can it be revoked quickly? Can the organisation explain which record wins when a wallet credential, power of attorney, registry and internal approval matrix disagree?
Next, design the relying-party policy. Possessing a valid credential should never be the whole decision rule. Define which issuers are trusted, which attributes are required, how fresh status must be, when evidence is sufficient, and when the transaction requires manual or legal escalation.
Finally, assign ownership across the full chain. Legal should own the meaning of authority; identity and security should own binding and assurance; business functions should own transaction policy; records teams should own durable evidence; risk should own exception criteria. A single product owner can coordinate the service, but cannot absorb these accountabilities.
The decisive control is not whether a credential verifies. It is whether verified evidence satisfies the authority policy for this transaction, at this time.
This agenda is useful even if the final regulation is narrowed or adoption is slow. Enterprises already struggle to connect legal mandates, system roles and external transaction evidence. The Business Wallet makes that gap more visible; it does not create it.
The Question That Changes
Today, many cross-border processes ask a document question: What proof has the counterparty sent us? A mature wallet ecosystem could replace it with an authority question: What action can we accept because we can verify the entity, the actor, the mandate, its current status and our own policy?
That change is the real promise of European Business Wallets. It is also the limit. The wallet can make authority portable only to the extent that law, registries, mandates, revocation and enterprise controls make authority explicit.
The organisations that benefit will not be those that confuse a new credential with a new source of power. They will be those that know where power originates, how it is bounded, how it is withdrawn and what evidence is sufficient for another party to rely on it.
Sources
- Council of the European Union — European business wallets: Council adopts negotiating position — 9 June 2026 — https://www.consilium.europa.eu/en/press/press-releases/2026/06/09/european-business-wallets-council-adopts-negotiating-position/
- European Commission / EUR-Lex — Proposal for a Regulation on the establishment of European Business Wallets, COM(2025) 838 — 19 November 2025 — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52025PC0838
- European Union Agency for Cybersecurity — ENISA advances the certification of EU Digital Wallets — 3 April 2026 — https://www.enisa.europa.eu/news/enisa-advances-the-certification-of-eu-digital-wallets
- Bitkom — Bitkom on the European Business Wallet — consolidated statement May 2026 — https://www.bitkom.org/EN/Bitkom/Publications/Bitkom-on-European-Business-Wallet
- Wouter Termont and Beatriz Esteves — OpenID for European Digital Identity: An architectural analysis of user-centric identity management — revised 20 March 2026 — https://arxiv.org/abs/2601.14503
- David Ricardo Saavedra — Interoperable Architecture for Digital Identity Delegation for AI Agents with Blockchain Integration — 21 January 2026 — https://arxiv.org/abs/2601.14982
- Awid Vaziry, Sandro Rodriguez Garzon, Christoph Wronka and Axel Küpper — Know Your Contract: eIDAS-Based Verifiable Legal Identities for Smart Contracts, Enabling Regulatory-Compliant On-Chain Operations — revised 29 June 2026 — https://arxiv.org/abs/2601.13903