Hoe regelt eIDAS 2.0 back-up en herstel van de identiteits-wallet?

Verordening (EU) 2024/1183 wijzigt Verordening (EU) 910/2014 en schrijft geen gestandaardiseerd back-up- en herstelmechanisme voor de EUDI-wallet voor. De verordening stelt hoogwaardige principes vast rond beveiliging, continuïteit en gebruikerscontrole, terwijl de technische uitwerking van back-up en herstel wordt overgelaten aan lidstaten en wallet-aanbieders. De praktische aanpak kan daardoor per lidstaat verschillen, maar de onderliggende regels over wat wel en niet kan worden geback-upt zijn consistent binnen het kader. De onderstaande secties gaan in op de belangrijkste vragen die organisaties en gebruikers stellen over wallet-back-up en -herstel onder eIDAS 2.0.

Welke gegevens kunnen er eigenlijk worden geback-upt in een EUDI-wallet?

Niet alle gegevens die zijn opgeslagen in een EUDI-wallet kunnen of moeten worden geback-upt in de traditionele zin. De EUDI-wallet bevat twee brede categorieën gegevens: de wallet solution zelf (de applicatie en de configuratie ervan) en de daarin opgeslagen attestaties, zoals een mobiel rijbewijs, een diploma of een Europese ziekteverzekeringskaart. Of elk van deze kan worden geback-upt, hangt af van de aard van de attestatie en de regels die door de uitgever zijn vastgesteld.

Attestaties die zijn uitgegeven door overheden of gereguleerde instellingen bevatten doorgaans strikte regels over overdraagbaarheid. Een gekwalificeerd elektronisch handtekeningcertificaat is bijvoorbeeld cryptografisch gebonden aan een specifiek apparaat of beveiligd element. De privésleutels van PID en attestaties verlaten het beveiligde middel niet. Het kopiëren ervan naar een ander apparaat is geen neutrale technische handeling: het doorbreekt het beveiligingsmodel dat de attestatie in de eerste plaats juridisch geldig maakt.

Persoonlijke configuratiegegevens, zoals voorkeuren, gekoppelde accounts en transactiegeschiedenis, zijn over het algemeen eenvoudiger te back-uppen omdat ze niet dezelfde cryptografische beperkingen hebben. Ze vallen echter nog steeds onder de AVG, wat betekent dat gebruikers er controle over moeten hebben en organisaties er verantwoord mee moeten omgaan.

In de praktijk geldt het volgende uitgangspunt: de wallet-applicatie kan worden hersteld, maar individuele attestaties moeten doorgaans opnieuw worden uitgegeven door de oorspronkelijke uitgever in plaats van te worden gekopieerd uit een back-up.

Hoe definieert eIDAS 2.0 de back-up- en overdraagbaarheidsregels voor wallets?

Verordening (EU) 2024/1183 gebruikt de term “back-up” niet expliciet, maar stelt wel duidelijke verplichtingen vast rond continuïteit, overdraagbaarheid en gebruikerscontrole die rechtstreeks bepalen hoe back-up en herstel moeten werken. De verordening vereist dat gebruikers de soevereiniteit over hun identiteitsgegevens behouden en dat wallet-oplossingen geen lock-in creëren bij één aanbieder of lidstaat.

Overdraagbaarheid is een belangrijk principe. Gebruikers moeten tussen wallet-oplossingen kunnen wisselen zonder toegang tot hun identiteitsgegevens te verliezen of onnodig gedwongen te worden om vanaf nul opnieuw te verifiëren. Dit sluit aan bij de bredere doelstelling van de verordening om interoperabiliteit tussen EU-lidstaten te waarborgen.

Het Architecture and Reference Framework (ARF) biedt de technische blauwdruk voor de EUDI-wallet en gaat verder door eisen te specificeren voor het beheer van wallet-instanties. Dit omvat hoe wallet instances worden geactiveerd, opgeschort en ingetrokken, allemaal relevant voor wat er gebeurt wanneer een gebruiker toegang moet herstellen. Het ARF schrijft geen specifiek back-upformaat voor, maar vereist wel dat wallet-aanbieders processen ondersteunen waarmee gebruikers op een veilige en verifieerbare manier weer toegang kunnen krijgen. De juridisch bindende vereisten volgen daarbij uit de verordening en de uitvoeringshandelingen, niet uit het ARF zelf.

Voor organisaties die actief zijn in gereguleerde sectoren zoals financiële dienstverlening of de overheid is het begrijpen van deze overdraagbaarheidsverplichtingen van belang, omdat het van invloed is op hoe identiteitsgegevens tussen systemen stromen en welke continuïteitsplanning vereist is.

Wat gebeurt er wanneer een gebruiker de toegang tot zijn EUDI-wallet verliest?

Wanneer een gebruiker de toegang tot zijn EUDI-wallet verliest, door een verloren apparaat, een vergeten pincode of een softwarestoring, kan hij deze niet zomaar herstellen vanuit een cloudback-up zoals hij een fotobibliotheek zou herstellen. Het herstelproces is meer gestructureerd en omvat meerdere partijen, omdat de integriteit van de attestaties in de wallet moet worden gewaarborgd.

Het algemene herstelpad werkt als volgt:

1. Intrekking van de wallet unit: De gecompromitteerde of verloren wallet unit wordt ingetrokken om misbruik te voorkomen. Dit is een cruciale beveiligingsstap die plaatsvindt voordat enig herstel begint.
2. Heridentificatie: De gebruiker verifieert zijn identiteit opnieuw via de wallet-aanbieder of het relevante nationale identiteitsschema. Zo bevestigt het systeem dat de persoon die herstel aanvraagt de rechtmatige eigenaar is.
3. Activering van een nieuwe wallet instance: Een nieuwe wallet instance wordt aan de gebruiker uitgegeven op zijn nieuwe of herstelde apparaat.
4. Heruitgifte van attestaties: Individuele attestaties, zoals een rijbewijs of een onderwijskwalificatie, worden opnieuw aangevraagd bij de oorspronkelijke uitgevers. Ze worden niet gekopieerd uit de oude wallet unit, maar vers opnieuw uitgegeven.

Dit proces is omvangrijker dan een typische app-herstelactie, maar dat is bewust. Het beveiligingsmodel van de EUDI-wallet is gebouwd op de aanname dat attestaties zijn gekoppeld aan geverifieerde identiteiten en beveiligde apparaten, niet aan bestanden die vrij kunnen worden gekopieerd.

Wie is verantwoordelijk voor wallet-herstel: de gebruiker, de aanbieder of de uitgever?

De verantwoordelijkheid voor wallet-herstel is verdeeld over drie partijen, en begrijpen wie wat doet is essentieel voor organisaties die diensten bouwen rondom de EUDI-wallet.

• De wallet-aanbieder is verantwoordelijk voor het beheer van de wallet solution zelf, inclusief de mogelijkheid om een verloren wallet unit in te trekken en een nieuwe wallet instance uit te geven. Onder eIDAS 2.0 moeten wallet-aanbieders voldoen aan certificeringsvereisten en zijn zij verantwoordelijk voor de beveiliging en continuïteit van de wallet-infrastructuur.
• De attestatie-uitgever is verantwoordelijk voor het opnieuw uitgeven van attestaties wanneer een wallet wordt hersteld. Een uitgever, zoals een nationale autoriteit of een erkende instelling, kan een attestatie niet zomaar van de ene wallet unit naar de andere overdragen zonder de onderliggende gegevens opnieuw te verifiëren. Dit beschermt de integriteit van de attestatie.
• De gebruiker is verantwoordelijk voor het initiëren van het herstelproces en het voltooien van eventuele vereiste identiteitsverificatiestappen. De gebruiker draagt ook de verantwoordelijkheid voor het veilig en toegankelijk houden van zijn herstelgegevens, zoals back-upcodes of gekoppelde authenticatiemethoden.

In de praktijk spelen lidstaten een coördinerende rol, omdat zij op grond van de verordening verplicht zijn EUDI-wallets aan burgers en ingezetenen te verstrekken. Dit betekent dat nationale overheden een overkoepelende zorgplicht hebben om ervoor te zorgen dat herstelprocessen toegankelijk en duidelijk zijn en gebruikers niet permanent buitensluiten van hun digitale identiteit.

Wat zijn de beveiligingsrisico’s van het back-uppen van een digitale identiteitswallet?

Het back-uppen van een EUDI-wallet brengt reële beveiligingsrisico’s met zich mee die verschillen van het back-uppen van gewone gegevens. Het kernrisico is dat een back-up kan worden gebruikt om een wallet te klonen, waardoor een aanvaller de legitieme gebruiker kan nabootsen. Dit is waarom de beveiligingsarchitectuur van de EUDI-wallet is ontworpen om te beperken wat kan worden gekopieerd en onder welke omstandigheden.

De meest significante risico’s zijn:

• Blootstelling van privésleutels: Cryptografische sleutels die ten grondslag liggen aan gekwalificeerde handtekeningen en hoogwaardige attestaties mogen nooit het beveiligde middel van een apparaat verlaten. Als een back-upproces deze sleutels extraheert, wordt het beveiligingsmodel volledig doorbroken.
• Replay-aanvallen: Een gestolen back-up kan een aanvaller in staat stellen attestatie-presentaties te herhalen, waardoor hij mogelijk toegang krijgt tot diensten of documenten frauduleus ondertekent.
• Onveilige opslag: Als back-upgegevens worden opgeslagen in een onversleutelde of zwak beveiligde omgeving, zoals een onbeveiligd cloudaccount, wordt het een doelwit voor datalekken.
• Phishing via herstelprocessen: Aanvallers kunnen proberen herstelprocessen frauduleus te activeren door gebruikers na te bootsen om wallet units over te nemen.

Deze risico’s verklaren waarom het EUDI-wallet-kader de voorkeur geeft aan heruitgifte boven herstel. Heruitgifte vereist dat de gebruiker elke keer zijn identiteit opnieuw verifieert, wat een sterkere beveiligingsgarantie biedt dan vertrouwen dat een back-upbestand niet is gecompromitteerd. Organisaties die werken aan digitale identiteitsoplossingen moeten deze risico’s vanaf het begin meenemen in hun architectuur en het ontwerp van de gebruikersreis.

Hoe moeten organisaties zich voorbereiden op wallet-herstelscenario’s?

Organisaties die afhankelijk zijn van EUDI-wallets voor onboarding, authenticatie of nalevingsdoeleinden moeten rekening houden met de realiteit dat gebruikers af en toe de toegang tot hun wallets verliezen. Een herstelgebeurtenis mag niet betekenen dat een zakelijke relatie van nul af aan opnieuw moet worden opgebouwd, maar het vereist wel duidelijke processen aan de kant van de organisatie.

Praktische stappen die organisaties moeten nemen zijn:

1. Ontwerp voor herverificatiestromen: Bouw onboarding- en authenticatiestromen die kunnen omgaan met een gebruiker die een vers herstelde wallet instance met opnieuw uitgegeven attestaties presenteert. Ga er niet van uit dat een terugkerende gebruiker altijd dezelfde wallet instance heeft als aanvankelijk gebruikt.
2. Bewaar je eigen geverifieerde gegevens: Sla, waar regelgeving dit toestaat, de uitkomst van een geverifieerde identiteitscontrole op in plaats van uitsluitend te vertrouwen op de wallet. Dit maakt het mogelijk een herstelde wallet instance opnieuw te koppelen aan een bestaand klantrecord zonder een volledige heronboarding te vereisen. Koppel een klantrecord daarbij niet aan een wallet unit-identifier, omdat die bij herstel verandert.
3. Begrijp de afhankelijkheden van uitgevers: Breng in kaart op welke attestaties jouw diensten afhankelijk zijn en welke uitgevers daarvoor verantwoordelijk zijn. Als een belangrijke attestatie dagen of weken nodig heeft om opnieuw te worden uitgegeven, ontstaat er een gat in jouw servicecontinuïteit.
4. Communiceer duidelijk met gebruikers: Herstelprocessen die verwarrend of ondoorzichtig zijn, leiden tot afhakers en ondersteuningskosten. Investeer in duidelijke gebruikerscommunicatie over wat er gebeurt wanneer een wallet verloren gaat en welke stappen nodig zijn.
5. Blijf afgestemd op evoluerende standaarden: Het ARF en nationale uitvoeringsrichtlijnen worden nog steeds verfijnd. Organisaties in sectoren zoals gezondheidszorg of overheidsdiensten moeten updates bijhouden en hun processen dienovereenkomstig aanpassen.

Herstelplanning is verbonden met naleving, gebruikerservaring en operationele veerkracht, wat betekent dat het aandacht verdient van juridische, IT- en zakelijke teams samen. Organisaties die op zoek zijn naar bredere informatie over digitale identiteitsgereedheid, kunnen nuttige vertrekpunten vinden in de TrustTech-resourcebibliotheek.

Hoe ondersteunt de ID Connector van TrustTech bij wallet-back-up en -herstel

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.

In de context van wallet-herstel biedt de ID Connector concrete functionaliteit die organisaties helpt herstelscenario’s op te vangen zonder dat de dienstverlening wordt onderbroken:

• De ID Connector valideert wallet unit attestations bij elke presentatie, zodat een herstelde wallet instance op een gecertificeerde wallet solution draait voordat attributen worden geaccepteerd.
• De Connector controleert de intrekkingsstatus van attestaties via de statusinformatie van de uitgever, wat bij heruitgifte na herstel bijzonder relevant is.
• De ID Connector bewaakt de geregistreerde attributenscope per relying party, conform de registratieverplichtingen onder CIR (EU) 2025/848 van 6 mei 2025, zodat alleen de vooraf geregistreerde attributen worden opgevraagd, ook bij een nieuwe wallet instance.
• Via hergebruik van eerder geverifieerde identiteitsdata kan een bestaand klantrecord worden gekoppeld aan een herstelde wallet instance, zonder dat een volledige heronboarding nodig is.
• Voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en de overheid ondersteunt de ID Connector gekwalificeerd tekenen via een aangesloten QTSP, ook na heruitgifte van attestaties.

Wil je weten hoe de ID Connector past bij jouw herstelprocessen en identiteitsinfrastructuur? Neem contact op met TrustTech voor een gesprek over jouw specifieke situatie.