Hoe beïnvloedt eIDAS 2.0 softwareleveranciers en app-ontwikkelaars?

eIDAS 2.0 heeft directe gevolgen voor softwareleveranciers en app-ontwikkelaars die applicaties bouwen voor identiteitsverificatie, authenticatie of het ondertekenen van documenten voor gebruikers in de EU. Als jouw app gebruikers laat inloggen, hun identiteit laat verifiëren of documenten laat ondertekenen, introduceert Verordening (EU) 2024/1183, die Verordening (EU) 910/2014 wijzigt, nieuwe technische standaarden, wallet-integratievereisten en nalevingsverplichtingen waar je rekening mee moet houden. Dit artikel behandelt de belangrijkste vragen die ontwikkelaars en leveranciers op dit moment stellen.

Welke soorten software en apps vallen onder eIDAS 2.0?

eIDAS 2.0 is van toepassing op alle software of applicaties die digitale identiteitsdiensten aanbieden of daarop vertrouwen binnen de EU. Dit omvat apps die gebruikers authenticeren, identiteiten verifiëren, attestaties uitgeven of elektronische handtekeningen faciliteren. Als jouw product een van deze functies vervult voor EU-burgers, ingezetenen of bedrijven, is eIDAS 2.0 voor jou relevant.

De verordening schept verplichtingen voor twee brede categorieën van softwareactoren. De eerste categorie zijn relying parties: apps en diensten die identiteitsgegevens van gebruikers accepteren, zoals bank-apps, zorgportalen, overheidsdienstplatformen of elke applicatie met een login- of onboardingflow. De tweede categorie zijn vertrouwensdienstverleners: organisaties die certificaten, elektronische handtekeningen of andere trust services uitgeven.

Naast deze twee groepen introduceert eIDAS 2.0 ook de categorie van wallet-relying parties. Dit zijn apps die attributen van de Europese Digitale Identiteitswallet opvragen of accepteren. Elke ontwikkelaar die een dienst bouwt waarmee de leeftijd, beroepskwalificaties of nationale identiteit van een gebruiker via de EUDI-wallet geverifieerd kan worden, valt in deze categorie en moet zich registreren bij de bevoegde nationale autoriteit op grond van CIR (EU) 2025/848 voordat walletdata kan worden opgevraagd.

De reikwijdte is breed. Consumentgerichte apps, bedrijfssoftware, identiteitsplatformen en ontwikkelaarstools hebben er allemaal belang bij te begrijpen waar zij passen binnen het eIDAS 2.0-kader. Daarbij geldt dat een leverancier die walletdata technisch namens een klant verwerkt, daardoor niet automatisch zelf relying party wordt. De registratieplicht ligt bij de organisatie die de dienst aan de eindgebruiker levert.

Welke nieuwe technische vereisten introduceert eIDAS 2.0 voor ontwikkelaars?

eIDAS 2.0 introduceert vereisten op het gebied van interoperabiliteit, beveiliging en gestandaardiseerde gegevensformaten. De juridisch bindende vereisten volgen uit de verordening en de uitvoeringshandelingen. De technische uitwerking daarvan is vastgelegd in het Architecture and Reference Framework (ARF), dat de protocollen, interfaces en gegevensstructuren beschrijft die EUDI-wallet-compatibele systemen moeten ondersteunen.

De belangrijkste technische vereisten waar ontwikkelaars rekening mee moeten houden zijn:

• Gestandaardiseerde protocollen en interfaces: Het ARF specificeert welke uitwisselingsprotocollen gebruikt worden voor wallet-interacties. Voor uitgifte is dat OID4VCI, voor presentatie OID4VP. Apps die identiteitsgegevens opvragen of presenteren, moeten deze protocollen correct implementeren conform het High Assurance Interoperability Profile (HAIP).
• Attestaties en credentialformaten: Identiteitsgegevens worden uitgewisseld als Person Identification Data (PID) en Electronic Attestations of Attributes (EAAs), in de formaten mdoc (ISO/IEC 18013-5 voor proximity, ISO/IEC TS 18013-7 voor online presentatie) en SD-JWT VC. Ontwikkelaars moeten deze formaten correct verwerken in hun applicaties.
• Selective disclosure: Gebruikers moeten alleen de specifieke attributen kunnen delen die nodig zijn voor een transactie. Apps mogen niet meer gegevens opvragen dan noodzakelijk, wat gevolgen heeft voor de manier waarop identiteitsverzoeken worden ontworpen.
• Cryptografische verificatie: Verificatie van walletpresentaties omvat meerdere stappen: controle van de handtekening van de uitgever tegen de relevante nationale trusted list, controle van de intrekkingsstatus via statusinformatie van de uitgever, en verificatie van de wallet unit attestation waarmee wordt vastgesteld dat de presenterende wallet op een gecertificeerde wallet solution draait. Alleen de eerste controle kan volledig offline plaatsvinden.
• Registratie als wallet-relying party: Apps die attributen opvragen uit EUDI-wallets moeten zich formeel registreren bij de bevoegde nationale autoriteit op grond van CIR (EU) 2025/848. De registratie omvat per intended use welke attributen en attestaties worden opgevraagd. Een verzoek buiten de geregistreerde scope kan door de wallet worden geweigerd en kan gevolgen hebben voor de registratie.

De referentie-implementatie die door de Europese Commissie is gepubliceerd is open source, wat ontwikkelaars een praktisch startpunt biedt om de technische specificaties te begrijpen voordat ze hun eigen integraties bouwen. Houd er rekening mee dat het ARF regelmatig wordt herzien en dat nieuwe revisies technische vereisten kunnen aanscherpen.

Moeten app-ontwikkelaars gekwalificeerde vertrouwensdienstverleners worden?

De meeste app-ontwikkelaars hoeven geen gekwalificeerde vertrouwensdienstverleners (QTSPs) te worden. QTSP-status is voorbehouden aan organisaties die gekwalificeerde elektronische handtekeningen, gekwalificeerde certificaten of andere hoogwaardige trust services uitgeven. Het omvat formele audits, toezicht door een nationale autoriteit en opname in de nationale trusted list conform ETSI TS 119 612.

Voor de meerderheid van softwareleveranciers en app-ontwikkelaars is de relevante verplichting het integreren met vertrouwensdienstverleners. Als jouw app de identiteit van een gebruiker op een hoog betrouwbaarheidsniveau moet verifiëren, of gekwalificeerde elektronische handtekeningen mogelijk moet maken, verbind je je via hun API’s met een QTSP. Een relying party heeft geen QTSP nodig om een EUDI-wallet te accepteren. Een QTSP wordt relevant bij gekwalificeerd tekenen of het uitgeven van gekwalificeerde attestaties (QEAA).

De situatie wordt genuanceerder wanneer een softwareleverancier zijn eigen attestaties wil uitgeven, bijvoorbeeld een organisatie die werknemersgegevens of beroepskwalificaties in de EUDI-wallet van een gebruiker wil plaatsen. In dat geval moet de leverancier mogelijk een aanbieder van Electronic Attestations of Attributes worden. Daarbij is het van belang onderscheid te maken tussen drie typen attestaties: QEAA (gekwalificeerd, uitgegeven door een QTSP), PuB-EAA (uitgegeven door of namens een publieke instantie) en non-qualified EAA. Elk type heeft zijn eigen vereisten onder de verordening en de uitvoeringshandelingen.

De praktische conclusie: de meeste ontwikkelaars moeten zich richten op wallet-integratie en registratie als relying party onder CIR (EU) 2025/848. Inzicht in de identiteitsoplossingen van TrustTech kan helpen verduidelijken welke rol jouw organisatie speelt in het bredere eIDAS 2.0-ecosysteem.

Hoe beïnvloedt de EUDI-wallet apps die momenteel login of identiteitsverificatie gebruiken?

De EUDI-wallet introduceert een gestandaardiseerd kanaal waarmee gebruikers zich kunnen authenticeren en identiteitsattributen kunnen delen met apps. Voor applicaties die momenteel login of identiteitsverificatie verwerken, betekent dit het toevoegen van wallet-gebaseerde flows naast bestaande methoden. Walletgebruik is vrijwillig: artikel 5a van de verordening beschermt gebruikers tegen benadeling wanneer zij geen wallet gebruiken.

Onder eIDAS 2.0 zijn bepaalde categorieën diensten verplicht genotificeerde EUDI-wallets te accepteren als geldig authenticatiemiddel. Publieke instanties en publieke dienstverleners moeten genotificeerde wallets uiterlijk op 24 december 2026 accepteren voor onlinediensten waarvoor elektronische identificatie vereist is. Voor gereguleerde private partijen geldt op grond van artikel 5f een acceptatieplicht vanaf 24 december 2027, uitsluitend binnen de context waarin sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Relevante sectoren zijn onder meer banken en financiële dienstverlening, gezondheidszorg, telecom, energie, transport, onderwijs, sociale zekerheid, drinkwater, post, digitale infrastructuur en digitale diensten. Zeer grote onlineplatforms met meer dan 45 miljoen gebruikers in de EU vallen onder een afzonderlijke bepaling van artikel 5f: voor hen geldt de verplichting waar het platform gebruikersauthenticatie vereist, op vrijwillig verzoek van de gebruiker en voor de minimaal noodzakelijke gegevens. Micro- en kleine ondernemingen zijn uitgezonderd: organisaties met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal €10 miljoen vallen buiten deze verplichting.

Voor andere apps biedt de wallet een aanzienlijke kans. In plaats van gebruikers te vragen documenten te uploaden of langdurige identiteitscontroles te doorlopen, kan jouw app geverifieerde attributen rechtstreeks opvragen uit de wallet unit van de gebruiker. De gebruiker is al geverifieerd door hun overheid of een vertrouwde uitgever, en die geverifieerde gegevens kunnen worden hergebruikt. Dit vermindert onboardingfrictie en verbetert de gegevenskwaliteit. Houd daarbij wel rekening met de grenzen van de verordening: hergebruik van identiteitsgegevens voor KYC-doeleinden wordt mede bepaald door AML-regelgeving en sectorale regels, en een relying party heeft een zelfstandige AVG-grondslag nodig voor de verwerking van die gegevens. Goedkeuring van gegevensdeling in de wallet is niet automatisch toestemming als rechtsgrond onder artikel 6, lid 1, onder a, AVG.

De verschuiving verandert ook de UX-ontwerpuitdaging. In plaats van een eigen identiteitsverificatieflow te bouwen, ontwerp je een wallet-interactie: welke attributen heb je nodig, hoe vraag je ze op binnen de geregistreerde scope, en hoe verwerk je de reactie? Dit is een betekenisvolle architectuurwijziging voor veel bestaande applicaties, en het is zinvol om er nu op te plannen.

Wat zijn de nalevingsrisico’s voor softwareleveranciers die eIDAS 2.0 negeren?

Softwareleveranciers die eIDAS 2.0 negeren, lopen een combinatie van juridische, operationele en concurrentiële risico’s. Het meest directe juridische risico is niet-naleving van verplichte vereisten, met name voor leveranciers die gereguleerde sectoren of publieke sector-klanten bedienen waar wallet-acceptatie en specifieke betrouwbaarheidsniveaus wettelijk verplicht zijn. Verordening (EU) 2024/1183 werkt rechtstreeks in alle lidstaten en vereist geen nationale uitvoering om van kracht te zijn.

De nalevingsrisico’s zijn onder te verdelen in verschillende praktische gebieden:

1. Regelgevende sancties: Niet-conforme diensten die actief zijn in gereguleerde sectoren kunnen handhavingsmaatregelen ondervinden van nationale toezichthoudende autoriteiten.
2. Verlies van overheidsopdrachten: Overheids- en publieke sector-klanten zullen eIDAS 2.0-naleving steeds vaker als aanbestedingsvoorwaarde stellen. Leveranciers zonder wallet-integratie of de juiste betrouwbaarheidsniveaus lopen het risico uitgesloten te worden van deze kansen.
3. Onvermogen om gereguleerde sectoren te bedienen: Sectoren zoals financiën, gezondheidszorg en telecom bewegen zich naar een eIDAS 2.0-conforme identiteitsinfrastructuur. Softwareleveranciers die hier niet klaar voor zijn, zullen moeite hebben te voldoen aan de vereisten van klanten in deze sectoren.
4. Gegevensbeschermingsrisico’s: eIDAS 2.0 versterkt de principes van gegevensminimalisatie die nauw aansluiten bij de AVG. Apps die meer identiteitsgegevens verzamelen dan noodzakelijk, of die geen adequate verwerkingsgrondslag hebben, lopen een verhoogd gegevensbeschermingsrisico. Voor gezondheidsgegevens geldt bovendien dat een toepasselijke grond uit artikel 9, lid 2, AVG aanwezig moet zijn.
5. Concurrentieel nadeel: Naarmate wallet-klare concurrenten snellere en meer vertrouwde onboardingervaringen bieden, zullen leveranciers die zich niet hebben aangepast het moeilijker vinden om klanten te winnen en te behouden.

Het risico is juridisch én strategisch. Organisaties in de financiële dienstverlening en andere gereguleerde sectoren plannen al hun eIDAS 2.0-routekaarten, en zij zullen verwachten dat hun softwareleveranciers daar klaar voor zijn.

Wanneer moeten softwareleveranciers klaar zijn voor eIDAS 2.0?

De kerndeadlines voor eIDAS 2.0 zijn al in beweging. Verordening (EU) 2024/1183 trad in werking op 20 mei 2024. Eind 2024 werden de eerste vijf kernuitvoeringshandelingen aangenomen, waaronder technische specificaties, beveiligingsstandaarden en interoperabiliteitsregels voor de EUDI-wallet. Deze uitvoeringshandelingen startten de relevante 24-maandentermijn voor de wallets. In 2025 volgde een tweede golf uitvoeringshandelingen, onder andere over gekwalificeerde elektronische archivering, validatie en certificaten. Op 6 mei 2025 trad CIR (EU) 2025/848 in werking, met de registratievereisten voor wallet-relying parties.

Uiterlijk op 24 december 2026 moet iedere EU-lidstaat minimaal één gecertificeerde EUDI-wallet solution operationeel hebben voor burgers, inwoners en bedrijven. Publieke instanties en publieke dienstverleners moeten genotificeerde wallets vanaf die datum accepteren als identificatiemiddel voor onlinediensten waarvoor elektronische identificatie vereist is. Voor softwareleveranciers is dit het moment waarop de wallet-infrastructuur breed beschikbaar komt en waarop integraties in productie moeten kunnen draaien. De voorbereiding zou nu al in volle gang moeten zijn. Houd er rekening mee dat 24 december 2026 een uiterste datum is voor notificatie en uitgifte, niet automatisch het moment waarop volledige functionele interoperabiliteit in de hele EU bestaat.

Voor gereguleerde private partijen geldt op grond van artikel 5f een acceptatieplicht vanaf 24 december 2027, uitsluitend binnen de context waarin sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Dit betreft onder meer banken en financiële dienstverlening, gezondheidszorg, telecom, energie, transport, onderwijs, sociale zekerheid, drinkwater, post, digitale infrastructuur en digitale diensten. Zeer grote onlineplatforms met meer dan 45 miljoen gebruikers in de EU vallen onder een afzonderlijke bepaling van artikel 5f: voor hen geldt de verplichting waar het platform gebruikersauthenticatie vereist, op vrijwillig verzoek van de gebruiker en voor de minimaal noodzakelijke gegevens. Micro- en kleine ondernemingen met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal €10 miljoen zijn van deze verplichting uitgezonderd. Het aanvullende jaar tot 2027 biedt ruimte voor testen en certificering, maar wie pas in 2027 begint, laat vrijwel geen marge voor het benodigde integratie- en certificeringswerk.

Voor leveranciers die de publieke sector bedienen of actief zijn in gezondheidszorg of financiële dienstverlening is de urgentie het grootst. Deze sectoren hebben de vroegste en strengste verplichtingen onder de verordening, en hun technologiepartners moeten in gelijke tred met hen klaar zijn. Het verkennen van de resources van TrustTech over EUDI-wallet-gereedheid kan je helpen een realistische voorbereidingstijdlijn voor jouw organisatie op te stellen.

Hoe helpt TrustTech softwareleveranciers en app-ontwikkelaars zich voor te bereiden op eIDAS 2.0

Voorbereiden op eIDAS 2.0 is een technische en strategische transitie die van invloed is op hoe jouw product omgaat met identiteit, vertrouwen en gegevens. De ID Connector van TrustTech is een integratie waarmee relying parties elke gecertificeerde Europese wallet accepteren, ongeacht de lidstaat van uitgifte, voor identificatie, login en gekwalificeerd tekenen. Acceptatie van de EUDI-wallet staat voorop; via dezelfde koppeling lopen ook andere identiteitsmiddelen, zoals nationale eID’s, bank-ID’s en identiteitsdocumenten, binnen en buiten de EU.

Concreet ondersteunt de ID Connector:

• Verificatie tegen trusted lists: De ID Connector controleert de handtekening van de uitgever tegen de relevante nationale trusted lists conform ETSI TS 119 612 en de EU List of Trusted Lists (LOTL), zodat jouw applicatie alleen attestaties accepteert van erkende uitgevers.
• Controle van intrekkingsstatus: De ID Connector raadpleegt de statusinformatie van de uitgever om te verifiëren of een attestatie nog geldig is op het moment van presentatie.
• Validatie van de wallet unit attestation: De ID Connector verifieert dat de presenterende wallet draait op een gecertificeerde wallet solution, conform de vereisten van het ARF.
• Bewaking van de geregistreerde attributenscope: De ID Connector bewaakt dat attributenverzoeken binnen de scope blijven die is vastgelegd bij registratie onder CIR (EU) 2025/848, zodat verzoeken buiten de geregistreerde scope worden onderkend.
• Hergebruik van geverifieerde identiteitsdata: Eenmaal geverifieerde identiteitsattributen kunnen veilig worden hergebruikt binnen de contactpunten van jouw organisatie, zonder dat gebruikers zich opnieuw hoeven te identificeren.
• Gekwalificeerd tekenen via een aangesloten QTSP: De ID Connector maakt gekwalificeerde elektronische handtekeningen mogelijk via een aangesloten gekwalificeerde vertrouwensdienstverlener, waarbij de identiteitskoppeling en het auditspoor worden geborgd.

De ID Connector is relevant voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en de publieke sector, waar wallet-acceptatie verplicht is of snel strategisch noodzakelijk wordt. Het platform is gebouwd op Europese digitale identiteitsstandaarden en sluit aan op de vereisten van Verordening (EU) 2024/1183 en de bijbehorende uitvoeringshandelingen.

Wil je begrijpen wat eIDAS 2.0 betekent voor jouw specifieke product of platform? Neem contact op met TrustTech en laten we samen jouw pad naar naleving uitstippelen.