EUDI registration certificates, intended use and overasking checks

The certificate now carries operational policy

Implementing Regulation (EU) 2026/1730 requires Member States to support wallet relying-party registration certificates and to ensure each intended use is expressed in those certificates.

The same update introduces a harmonised general access policy explaining that a relying party is only allowed to request the data specified for the registered intended use.

Wallets compare requests with registered scope

The 2026 protocol amendments require wallets to validate the relying-party registration certificate and compare the requested attestations and attributes with those covered by the certificate.

Where a request exceeds that registered scope, the wallet must warn the user and handle the mismatch according to the wallet provider's security policy and applicable law.

Relying-party systems should fail earlier

Waiting for the wallet to detect overasking creates a poor user experience and makes configuration errors visible only during a live interaction.

A better architecture validates the requested claims against the intended-use configuration before generating the presentation request.

• Check certificate validity and current status.
• Bind the transaction to one approved intended use.
• Generate requested claims from approved configuration.
• Block claims outside the registered scope.
• Record which configuration version created the request.

Certificate lifecycle belongs in operations

Certificates can expire, be revoked or be re-keyed. That makes certificate state an operational concern rather than a one-time onboarding artifact.

A multi-tenant verifier should surface certificate health per tenant and prevent a stale or invalid certificate from silently affecting production flows.