How to Issue Electronic Attestations of Attributes Without Becoming a QTSP

Every organisation that first hears about eIDAS 2.0 and the EUDI Wallet assumes issuing a credential means becoming a regulated trust service provider. It doesn't. The Regulation deliberately created a second, lighter-weight route — the non-qualified Electronic Attestation of Attributes (EAA) — precisely so that employers, universities, retailers, insurers, and platforms could put verifiable attributes into a citizen's wallet without taking on the supervisory burden of a QTSP. This article walks through what that route actually looks like end to end.

Why QTSP status is the wrong default assumption

A Qualified Trust Service Provider exists to issue attestations that carry a legal presumption of accuracy — the eIDAS equivalent of a notarised document. That presumption is expensive to earn: an accredited conformity assessment, HSM-backed key infrastructure, a formal trust service practice statement, supervisory body approval, EU Trust List inclusion, and annual re-audits. None of that is required for most attribute types an organisation actually wants to put into a wallet — employment status, membership tier, loyalty level, course completion, professional affiliation, or a discount entitlement rarely need a notarial-grade legal presumption to be useful to a relying party.

The question is not 'can we become a QTSP' — almost any organisation with enough budget can. The question is whether the attribute you want to attest needs that legal weight at all.

The issuance platform model

Instead of building trust-service infrastructure, an organisation can issue non-qualified EAAs through an intermediary issuance platform that already holds the registrations, keys, and protocol implementation needed to talk to EUDI Wallets. The organisation supplies the attribute data and business logic; the platform handles wallet-facing protocol compliance, key custody, and national scheme registration.

• The source organisation authenticates its own users, decides what attribute value is true, and calls an API to request issuance.
• The platform (e.g. Arkadiz) formats the attribute as a credential, signs it with keys registered under the applicable national attestation scheme, and serves it over an OpenID4VCI issuance endpoint.
• The citizen's wallet requests the credential, completes user authentication and consent, and stores it locally.
• When a relying party later requests presentation, the wallet responds directly — the issuance platform is not in the transaction path at verification time.

Registering under a national attestation scheme

Even non-qualified issuance is not a legal free-for-all. Each Member State operates a national framework — typically administered by the national digital identity authority — under which non-qualified attestation providers register, declare the credential types they issue, and commit to baseline security and interoperability requirements defined in the eIDAS 2.0 implementing acts and the Architecture and Reference Framework (ARF). Registration is materially lighter than QTSP accreditation: no external conformity assessment body, no mandatory annual audit cycle, and no capital requirements — but it does require a documented security policy, a published credential schema, and a point of contact for supervisory enquiries.

Where an issuance platform already holds this registration, the issuing organisation typically operates under the platform's scheme entry as a declared credential type or sub-issuer, which removes the registration step from its own critical path entirely.

Technical implementation: OpenID4VCI in practice

The wallet-facing protocol stack is fixed by the ARF regardless of qualified status, so the technical build is identical whether or not you pursue QTSP accreditation later.

1. Credential format: choose SD-JWT VC or mdoc (ISO/IEC 18013-5) based on the wallet ecosystems you need to reach and whether selective disclosure of individual attribute fields matters for your use case.
2. Issuance flow: implement OpenID4VCI's credential offer, authorization, and credential endpoints, including pre-authorized code flow for account-linked issuance or authorization code flow for interactive onboarding.
3. Key management: generate and store issuer signing keys in an HSM or equivalent secure key store; rotate keys on a defined schedule and publish the corresponding verification material via the trust infrastructure your national scheme uses.
4. Revocation and status: expose credential status via a status list mechanism (e.g. OAuth Status List / Token Status List) so relying parties can check validity without contacting the issuer directly at verification time.
5. Metadata and discovery: publish issuer metadata and credential schemas so wallets and relying parties can validate credential structure automatically.

Using a platform collapses most of this list into an integration task: the source system calls an issuance API with attribute values, and the platform's already-certified infrastructure performs formatting, signing, revocation-list management, and metadata publication on its behalf.

Governance and liability without a statutory framework

Non-qualified issuance sits outside the QTSP liability regime, which means the issuing organisation's obligations come from ordinary contract and tort law rather than a statutory trust-service framework. That is not a loophole — it is a governance responsibility that has to be designed deliberately.

• Define who within the organisation is accountable for the accuracy of each attribute type before it is attested — typically the business owner of the underlying data, not the technical team issuing the credential.
• Set a data-freshness and revocation policy: if the underlying fact changes (an employee leaves, a membership lapses), the credential's status must be revoked within a defined window.
• Document the issuance decision logic so that, if a relying party disputes an attestation, the organisation can demonstrate why it was issued and on what evidence.
• Carry the exposure in contract terms with relying parties or in a public issuance policy, since there is no statutory presumption of accuracy to fall back on.

Cost comparison: platform issuance vs. QTSP build-out

The economics are not subtle. A QTSP build-out is a six-figure, multi-month capital commitment with recurring annual audit and supervisory fees that do not scale down with low issuance volume. Building your own non-qualified OpenID4VCI issuer avoids the QTSP overhead but still requires engineering investment in key management, status-list infrastructure, and ongoing wallet-compatibility testing as the ecosystem evolves. Issuing through a platform such as Arkadiz reduces this to an integration project — a single API, no key custody, no national scheme registration to manage independently — with cost scaling roughly with issuance volume rather than fixed compliance overhead.

When you might still need QTSP status later

Non-qualified issuance is not a permanent ceiling. If a specific credential line later needs a legal presumption of accuracy — because it is used in regulated procurement, professional licensing, or cross-border legal proceedings — nothing prevents pursuing QTSP status for that line while continuing to issue everything else non-qualified through the same or a different platform. Starting non-qualified lets an organisation validate wallet demand, relying-party acceptance, and internal governance before committing capital to qualified status.

For the overwhelming majority of B2B attributes — membership, employment, entitlement, certification of low-to-medium stakes — the practical path is exactly the one described here: register or piggyback on a national scheme, implement or integrate OpenID4VCI, put governance in writing, and skip the QTSP build entirely.