Behind every "scan this QR code to verify your identity" moment sits a chain of certificates that the wallet checks before it ever shows the user a consent screen. If you plan to operate as a Relying Party rather than route through an intermediary, this trust infrastructure becomes part of your production stack — with its own lifecycle, failure modes and on-call responsibilities.
Registration certificates vs access certificates
The two are often confused but serve different purposes in the trust chain.
- Registration certificate — proves you are a registered Relying Party (or intermediary) in a given Member State's ecosystem, tied to your legal identity, registered purpose and attribute scope.
- Access certificate — the operational, shorter-lived certificate used to sign individual presentation requests. The wallet validates this certificate against the registration and against the applicable trust list before rendering the consent screen.
In practice, the registration certificate is closer to a business license; the access certificate is closer to an API key with cryptographic teeth — and unlike an API key, its expiry and revocation are enforced by every wallet you talk to, not by your own systems.
How EU Trust Lists fit in
EU Trust Lists are the machine-readable registries that let a wallet answer the question "is this Relying Party, or this credential issuer, actually who it claims to be, and in good standing?" without a manual lookup. Two directions matter:
- Relying Party side: wallets check that your access certificate chains back to a registration listed as valid by the relevant national or EU-level trust list before granting access to attributes.
- Issuer side: your verifier, when checking a presented credential, must check that the issuer's certificate is anchored in the applicable trust list — otherwise you have no basis to trust the attestation regardless of signature validity.
A valid signature proves the credential was not tampered with. A trust list lookup proves the signer was ever entitled to make the claim in the first place. You need both, every time.
Revocation: the check nobody wants to build
Certificates and credentials can be revoked before their natural expiry — a compromised key, a withdrawn registration, a credential the issuer needs to invalidate. Building revocation checking correctly means handling several distinct mechanisms rather than a single lookup.
- Status list mechanisms for individual credentials, which must be fetched and cached with a sane refresh policy.
- Certificate revocation for access and registration certificates, checked at the trust-list or CA level depending on the ecosystem.
- Graceful degradation logic: what your service does when a status endpoint is temporarily unreachable, since failing open is a security decision, not a technical shortcut.
Key rotation without downtime
Access certificates have finite validity windows, and every wallet ecosystem you support imposes its own rotation cadence and renewal process. The operational risk is not the rotation itself but the overlap window: requests signed just before rotation must still validate, and your signing service needs a clean cutover mechanism, not a single hard-coded certificate reference.
- Track expiry dates centrally, not per environment or per developer's local config.
- Automate renewal requests well ahead of expiry — manual, calendar-reminder renewal is the single most common cause of unplanned outages in this space.
- Test the rollover in staging against a real wallet before it happens in production.
Multiplying this across Member States
None of the above is a one-time setup. If your service accepts wallets from several Member States, you are running this registration-certificate-revocation cycle once per ecosystem, each with its own supervisory body, renewal timeline and technical trust list format. A team supporting five Member States is effectively running five parallel compliance pipelines with different expiry calendars.
Operational pitfalls we see repeatedly
- Treating the access certificate like a static secret checked into config, with no automated expiry alerting.
- Caching trust list data indefinitely instead of respecting its own refresh signals, which silently accepts revoked issuers.
- Assuming a valid signature is sufficient evidence of trust, and skipping the trust-list lookup under load to save latency.
- Underestimating the lead time a national supervisory body needs to process a registration renewal or amendment.
The intermediary alternative
This entire section of the stack — registration across Member States, access certificate issuance and rotation, trust list monitoring, and revocation checking — is exactly what an intermediary Relying Party absorbs on your behalf. Arkadiz maintains the registrations, rotates certificates before they expire, and keeps trust list and revocation checks current across every supported wallet, so your engineering team calls one verification API instead of running a parallel compliance pipeline per country.