Concluzia este rezonabilă. Și este greșită.

Cele două verificări și ce dovedesc fiecare​

Autentificarea pasivă verifică integritatea datelor. Security Object Document-ul de pe card conține hash-urile SHA-256 ale grupelor de date, semnat cu certificatul Document Signer al MAI, verificat față de CSCA-ul Ministerului. Dacă verificarea trece, știi că datele nu au fost modificate după emitere și că MAI le-a semnat.

Autentificarea activă verifică că cipul deține o cheie privată. Serverul trimite un challenge de 48 de bytes, cipul îl semnează cu cheia sa privată de autentificare, serverul verifică semnătura față de certificatul din card. Dacă verificarea trece, știi că cineva cu acces la un cip funcțional a răspuns corect.

Problema este că cele două verificări sunt independente. Pasivă verifică datele. Activă verifică cipul. Dar nu verifică că datele și cipul aparțin aceluiași card fizic.

Vectorul de atac: split-proof​

Iată scenariul concret.

CAN-ul este tipărit pe fața cărții de identitate. Oricine ține cardul în mână câteva secunde îl poate citi — la o coadă, la un ghișeu, la un control de rutină. CAN-ul nu este un secret în sensul tradițional al cuvântului; este un identificator de acces la canalul NFC.

Cu CAN-ul victimei, un atacator poate stabili un canal PACE cu cardul și poate citi fișierele ICAO care nu necesită PIN — SOD-ul și datele din applet-ul standard. Aceasta include hash-urile semnate de MAI și, în funcție de configurație, date de bază. Autentificarea pasivă a acestor date va trece pe orice backend.

Atacatorul folosește acum propriul card pentru autentificarea activă. Trimite challenge-ul de la server la propriul cip, primește o semnătură validă față de propriul certificat.

Un backend care verifică pasivă și activă separat vede două lanțuri valide. Nu poate distinge atacatorul de titularul legitim — pentru că nu a verificat niciodată că datele MAI și cipul care a semnat challenge-ul sunt același obiect fizic.

Chip Authentication: legătura criptografică dintre date și cip​

Chip Authentication (CA, standardizată în BSI TR-03110) rezolvă exact această problemă.

Cardul conține în DG14 o cheie publică Q_chip — specifică acestui cip, acoperită de hash-ul SOD semnat de MAI. Chip Authentication efectuează un schimb ECDH între o cheie efemeră a terminalului și Q_chip. Numai cipul care deține cheia privată corespunzătoare d_chip poate produce secretul partajat corect.

Serverul recomputează schimbul și compară:

// Verificare server-side (Node.js)
const ecdh = crypto.createECDH('brainpoolP256r1');
ecdh.setPrivateKey(Buffer.from(caEphemeralPrivateKey, 'base64'));
const recomputed = ecdh.computeSecret(qChipFromDg14);

if (!recomputed.slice(0, 32).equals(Buffer.from(caSharedSecretX, 'base64'))) {
    throw new Error('CA binding mismatch — split-proof attack detected');
}

Dacă comparația eșuează, cineva a prezentat date MAI-semnate ale victimei cu propriul cip. Atacul este detectat.

Dacă trece, datele din card și cipul care a răspuns la challenge sunt criptografic legate — pentru că Q_chip este semnat de MAI în SOD, iar ECDH-ul confirmă că cipul fizic deține cheia privată corespunzătoare.

Ce înseamnă zero trust în contextul CEI​

Un flux de autentificare corect pe CEI impune trei condiții simultan:

Datele sunt semnate de MAI — autentificare pasivă față de CSCA.

Cipul este autentic — autentificarea activă dovedește că cipul poate semna un challenge cu propria cheie privată.

Datele și cipul sunt același obiect fizic — Chip Authentication leagă Q_chip din DG14 (semnat de MAI) de cipul care a efectuat ECDH-ul.

Fără toate trei, nu poți emite un token de autentificare cu garanție criptografică completă. Fără CA în particular, un sistem care verifică pasivă și activă separat are un vector de atac real și exploatabil — nu teoretic.

EidKit SSO: OIDC standard, zero trust pe CEI​

EidKit SSO este un identity provider OIDC standard — același protocol ca Google Sign-In sau GitHub OAuth. Client ID, Client Secret, redirect URI. Dacă ai integrat vreodată un provider OAuth, știi deja tot ce ai nevoie tehnic.

// JWT primit după autentificare reușită
{
  "sub": "a3f7bc9d...",          // pseudonim stabil per persoană, nu CNP-ul brut
  "name": "CĂTĂLIN TOMA",
  "given_name": "CĂTĂLIN",
  "family_name": "TOMA",
  "birthdate": "1985-03-15",
  "address": {
    "formatted": "Str. Exemplu Nr. 1, Timișoara, Timiș"
  }
}

Datele nu sunt auto-declarate de utilizator — vin direct din cipul CEI, verificate de MAI. Adresa de domiciliu este inclusă, deși nu mai apare tipărită pe cardul fizic.

Fluxul de autentificare implementează toate trei straturile: pasivă + activă + Chip Authentication. Serverul nu emite niciun token fără dovadă criptografică că utilizatorul deține cardul fizic, cunoaște PIN-ul și că datele prezentate și cipul sunt același obiect.

Un detaliu de UX care simplifică integrarea: nu există diferență între înregistrare și login. sub-ul din JWT este un pseudonim stabil și unic per persoană — prima atingere a cardului creează contul automat, fără formular, fără email, fără parolă.

Documentația de integrare și prezentarea completă de securitate sunt disponibile pe eidkit.ro/docs.

Scriem despre CEI — capabilitățile sale, provocările de integrare și contextul reglementar din jurul său. Dacă un subiect de aici este relevant pentru ce construiești, scrie-ne.

Termenele sunt legale, nu aspiraționale. Până la finalul lui 2026, fiecare stat membru trebuie să pună la dispoziția cetățenilor cel puțin un portofel de identitate digitală — EUDI Wallet — certificat la nivel european. Până la finalul lui 2027, companiile private din sectoarele reglementate sunt obligate să îl accepte. Iar sectoarele care intră sub această obligație includ, explicit, băncile, furnizorii de servicii de plată, companiile de asigurări și operatorii de telecomunicații.

Dacă lucrezi în oricare dintre aceste domenii în România, 2026 este anul în care trebuie să înțelegi ce implică această tranziție — nu 2027.

Ce este EUDI Wallet și ce legătură are cu buletinul electronic​

EUDI Wallet este o aplicație mobilă standardizată la nivel european în care cetățenii pot stoca și prezenta credențiale de identitate verificate — actul de identitate, permisul de conducere, diplome, calificări profesionale și alte atribute. Utilizatorul controlează ce date partajează și cu cine, prin divulgare selectivă: poți dovedi că ai peste 18 ani fără să arăți data nașterii exactă, sau poți confirma că ești rezident al unui stat membru fără să dai adresa completă.

Legătura cu CEI este directă și intenționată. Cătălin Giulescu, directorul DGEP, a declarat public că cartea electronică de identitate este „un intermediar" în procesul de digitalizare — platforma pe care se construiește EUDI Wallet în România. Cipul CEI, cu certificatele sale digitale emise de MAI, este mecanismul principal de înrolare în portofel. Fără CEI, nu există EUDI Wallet românesc.

România participă deja în proiectul-pilot european EUDIW-PACT coordonat de Ministerul de Interne din Franța, alături de alte 24 de state membre. Pe 17-18 martie 2026, la București au avut loc teste de interoperabilitate transfrontalieră în mediu live — schimb de credențiale funcțional între state membre diferite.

Termenele, clar​

Articolul 5f(2) din Regulament este direct: companiile private care sunt deja obligate prin lege să folosească autentificare puternică a utilizatorilor — Strong Customer Authentication — trebuie să accepte EUDI Wallet la cererea utilizatorului, în cel mult 36 de luni de la intrarea în vigoare a actelor de implementare. Baza legală pentru SCA în serviciile financiare este PSD2. Dacă ești bancă sau fintech care procesează plăți, obligația este certă.

Penalitățile pentru neconformare ajung la 5 milioane EUR sau 1% din cifra de afaceri globală, oricare este mai mare.

De ce 2026 este anul în care trebuie să acționezi, nu 2027​

Există o capcană comună în modul în care companiile citesc termenele reglementare: văd data de 2027 și planifică pentru 2027. Problema este că o integrare de nivel enterprise nu se finalizează în câteva săptămâni.

Experții în implementare estimează că o integrare completă, de la decizie la producție, necesită între 9 și 18 luni pentru o organizație de dimensiuni medii-mari. O bancă cu sisteme legacy, procese de procurement, cerințe de audit intern și cicluri de release bine-definite va fi la capătul superior al acestui interval, nu la cel inferior.

Companiile care încep în 2027 vor intra în producție în 2028 — după termenul obligatoriu. Companiile care încep în 2026 vor fi gata la timp și vor fi câștigat un avantaj competitiv: vor putea să ofere clienților autentificarea prin EUDI Wallet înainte ca aceasta să devină standard.

Chambers & Partners, în analiza lor pe piața fintech din România, confirmă explicit: „în practică, 2026 este un an de pregătire" pentru a putea accepta wallet-ul și adapta onboardingul până în 2027.

Ce trebuie să pregătești concret​

1. Maparea fluxurilor de identitate

Primul pas nu este tehnic — este de business. Orice companie care intră sub incidența obligației trebuie să identifice toate punctele din produsele și serviciile sale unde are loc o autentificare puternică sau o verificare de identitate: onboarding KYC, autentificare la tranzacții semnificative, semnare de contracte, acces la date sensibile. Aceste puncte sunt cele care trebuie să accepte credențiale EUDI Wallet.

2. Înregistrarea ca Relying Party

Companiile care vor să accepte EUDI Wallet trebuie să se înregistreze ca relying party la autoritatea națională competentă. Fără înregistrare, nu poți solicita credențiale din portofelele utilizatorilor. Procesul de înregistrare nu este instant — include identificarea entității juridice, specificarea atributelor pe care intenționezi să le accesezi și motivele de business pentru care ai nevoie de ele.

3. Integrarea tehnică

Standardele tehnice pentru interacțiunea cu EUDI Wallet — OpenID4VP pentru prezentarea credențialelor, OpenID4VCI pentru emiterea lor, SD-JWT pentru divulgare selectivă — sunt stabilite prin actele de implementare. Integrarea presupune implementarea acestor protocoale în sistemele existente, nu o înlocuire a acestora.

4. Redesignul fluxurilor KYC

Regulamentul impune minimizarea datelor — poți solicita doar atributele necesare pentru tranzacția respectivă. Dacă ai acum un flux KYC care colectează toate datele disponibile, va trebui să îl redesignezi pentru a cere selectiv doar ce este necesar pentru fiecare context. Aceasta este o schimbare de arhitectură, nu doar de UI.

Situația din România: fundație solidă, incertitudine operațională​

România nu pleacă de la zero. CEI este deja în rollout național, cu peste 1,5 milioane de carduri emise și un target de 5 milioane până la mijlocul lui 2026. ROeID există ca aplicație de SSO guvernamental. Testele de interoperabilitate EUDI Wallet au avut loc deja pe sol românesc.

Ceea ce lipsește este claritatea operațională pentru sectorul privat. Un raport recent al Accace constată că, deși alinierea juridică există prin Legea 214/2024, multe companii nu au claritate pe cerințele practice pe termen scurt. Conștientizarea problemei este limitată în afara sectoarelor puternic reglementate.

Există și o nuanță onestă de adăugat: la nivel european, unele state membre s-ar putea să nu respecte termenul din 2026 pentru lansarea wallet-ului, din cauza complexității tehnice și a standardelor care se finalizează în paralel. Dar termenul de 2027 pentru sectorul privat este independent de viteza de lansare a wallet-ului — obligația de acceptare există indiferent de momentul exact al disponibilității. Și în România, CEI este deja disponibilă și funcțională ca fundație.

Legătura cu infrastructura de identitate de astăzi​

Există o continuitate directă între ce e disponibil acum și ce va fi obligatoriu în 2027. EUDI Wallet va fi populat, în România, cu date din CEI. Fluxurile de KYC bazate pe NFC care citesc cipul CEI astăzi sunt arhitectural compatibile cu ce va presupune acceptarea credențialelor EUDI Wallet mâine — același nivel de asigurare, aceeași bază de date de identitate, aceleași certificate MAI în lanțul de verificare.

Companiile care integrează astăzi citirea CEI prin NFC pentru onboarding și verificare de identitate nu construiesc o soluție temporară. Construiesc infrastructura de identitate pe care vor trebui să o aibă în 2027 — cu un an sau doi avans față de obligația legală.

Scriem despre CEI — capabilitățile sale, provocările de integrare și contextul reglementar din jurul său. Dacă un subiect de aici este relevant pentru ce construiești, scrie-ne.

Dacă ai mai integrat un pașaport electronic sau un alt document de identitate cu cip, vei intra în acest proiect cu un set de presupuneri rezonabile. Cele mai multe dintre ele sunt parțial greșite pentru CEI.

Nu este că standardele ICAO nu se aplică — se aplică, ca punct de plecare. Problema este că CEI este un card de identitate național cu extensii specifice care nu apar nicăieri documentate complet în public. Ce urmează este o hartă a terenului bazată pe implementări complete pentru Android și iOS, testate pe carduri CEI reale.

Ce știi deja — și ce se aplică​

Orice card de identitate electronic bazat pe standardele ICAO folosește PACE (Password Authenticated Connection Establishment) pentru a stabili un canal securizat înainte de a permite citirea oricărui datum. CEI face același lucru, cu codul CAN — 6 cifre tipărite pe fața cardului — ca parolă.

Rezultatul PACE este un canal Secure Messaging (SM) care împachetează toate comenzile APDU ulterioare. Orice comandă trimisă raw după stabilirea canalului este respinsă de card — comportament standard, nu specific CEI.

Autentificarea pasivă funcționează după principii cunoscute pe ambele platforme: cipul conține un Security Object Document care înlănțuie hash-urile SHA-256 ale grupelor de date până la certificatul rădăcină CSCA al MAI. Verificarea arată diferit în funcție de platformă, dar principiul este același:

val sod = SODFile(sodRaw.inputStream())
val dsc = sod.docSigningCertificate
val csca = assets.open("csca_romania.der").use {
    CertificateFactory.getInstance("X.509").generateCertificate(it) as X509Certificate
}
dsc.verify(csca.publicKey) // aruncă excepție dacă invalid

let sod = try SodVerifier.parse(sodBytes)
guard let dsc = SecCertificateCreateWithData(nil, sod.dscDer as CFData) else { ... }

var trust: SecTrust?
SecTrustCreateWithCertificates(dsc, SecPolicyCreateBasicX509(), &trust)
SecTrustSetAnchorCertificates(trust!, [csca] as CFArray)
SecTrustSetAnchorCertificatesOnly(trust!, true) // nu folosi store-ul de sistem
var error: CFError?
let trusted = SecTrustEvaluateWithError(trust!, &error)

Autentificarea pasivă trebuie să ruleze întotdeauna înainte de a folosi datele citite. Până aici, un inginer cu experiență în documente ICAO va fi confortabil. Aceasta este și cam limita terenului familiar.

Unde presupunerile încep să se destrame​

Cipul are patru applet-uri, nu unul​

Documentele de călătorie ICAO standard au o structură de applet relativ predictibilă. CEI nu urmează același tipar. Cipul conține patru applet-uri cu roluri distincte:

Applet-ul ESIGN există pe cip și apare în unele documente de referință. Nu este folosit. Semnarea se face prin GenPKI, printr-o comandă diferită de ce ai presupune din lectura standardelor.

Fiecare applet urmează propriul flux de selecție și autentificare. Nu selectezi un applet și citești ce ai nevoie.

Două faze, cerințe diferite​

Citirea datelor de pe CEI se împarte natural în două faze:

Faza 1 — doar CAN: accesează datele disponibile fără PIN — fotografia titularului, semnătura olografă digitizată și datele necesare pentru autentificarea pasivă. Această fază folosește applet-ul ICAO standard.

Faza 2 — CAN + PIN de 4 cifre: accesează datele personale complete din applet-ul EDATA, inclusiv adresa de domiciliu — care nu mai apare tipărită pe cardul fizic.

Ordinea operațiilor înainte de PACE nu este documentată — și contează​

Ce trebuie să faci înainte de PACE depinde de ce vrei să faci după PACE, iar regulile sunt asimetrice în funcție de scenariu. Faza 1 cere o pregătire diferită față de Faza 2 și GenPKI. Dacă pregătirea nu este cea corectă, eșuările apar în puncte neașteptate cu coduri de eroare care nu indică problema reală.

Situația este diferită pe cele două platforme din motive arhitecturale:

// Faza 1: nicio pre-selecție necesară — stack-ul Android pornește în MF
isoDep.timeout = 20_000 // timeout-ul implicit este insuficient pentru CEI

val paceResult = ps.doPACE(canKey, paceOid, paceParams, null)
val wrapper = paceResult.wrapper
// toate comenzile de acum înainte trec prin wrapper

// Faza 2: SELECT AID1 înainte de PACE — chip-ul cere context AID1 pentru EDATA/GenPKI

// Faza 1: iOS conectează în contextul ICAO (ICAO AID este primul în Info.plist)
// PACE nu funcționează în context ICAO — SELECT MF înainte de PACE
let selectMF = NFCISO7816APDU(instructionClass: 0x00, instructionCode: 0xA4,
                               p1Parameter: 0x00, p2Parameter: 0x0C,
                               data: Data([0x3F, 0x00]), expectedResponseLength: -1)
_ = try await tag.sendCommand(apdu: selectMF)
// acum PACE funcționează — context MF, la fel ca Android

// Faza 2: SELECT AID1 înainte de PACE — același comportament ca Android

Comportamentul asimetric al pregătirii pre-PACE nu este documentat nicăieri — a fost descoperit prin eliminare pe ambele platforme.

Formatele de date: unde implementarea românească diverge​

DG1 nu este MRZ​

Acesta este momentul în care codul care funcționează perfect la pașapoarte se rupe complet, pe ambele platforme. Datele de identitate returnate de applet-ul EDATA nu sunt în formatul MRZ pe care îl parsează bibliotecile ICAO standard — sunt într-un format ASN.1 specific implementării românești, cu diacritice corecte și câmpuri structurate diferit:

SEQUENCE (0x30)
  [0] (0x80)  lastName     UTF-8  ex. "TOMA"
  [1] (0x81)  firstName    UTF-8  ex. "CĂTĂLIN"  (cu diacritice)
  [2] (0x82)  sex          UTF-8  "M" sau "F"
  [3] (0x83)  dateOfBirth  UTF-8  DDMMYYYY
  [4] (0x84)  cnp          UTF-8  13 cifre
  [5] (0x85)  nationality  UTF-8  "ROU"

// jMRTD nu ajută aici — format ASN.1 specific românesc
val tags = parseContextTags(dg1Bytes) // parser propriu
val lastName  = tags[0x80]?.toString(Charsets.UTF_8)
val firstName = tags[0x81]?.toString(Charsets.UTF_8) // diacriticele sunt corecte
val cnp       = tags[0x84]?.toString(Charsets.UTF_8)

// nicio bibliotecă iOS nu parsează acest format
let tags = parseContextTags(dg1Bytes) // parser propriu
let lastName  = tags[0x80].flatMap { String(data: $0, encoding: .utf8) }
let firstName = tags[0x81].flatMap { String(data: $0, encoding: .utf8) } // diacriticele sunt corecte
let cnp       = tags[0x84].flatMap { String(data: $0, encoding: .utf8) }

Formatul nu este documentat public — a fost determinat prin inspecție directă a bytes returnați de card.

Cele două chei criptografice din GenPKI​

GenPKI conține două chei distincte, pe curbe eliptice diferite, cu comportamente interne diferite la semnare:

A le confunda produce semnături incorecte fără niciun mesaj de eroare care să indice cauza. Comportamentul este identic pe Android și iOS — aceasta este o constrângere a cipului, nu a platformei.

Lucruri care se rup înainte să ajungi la logica de business​

Security.removeProvider("BC")
Security.insertProviderAt(BouncyCastleProvider(), 1)

PIN counter query nu funcționează în modul SM, pe nicio platformă. Nu există cale să interoghezi numărul de încercări rămase înainte de a trimite PIN-ul efectiv. Tratezi SW=63CX în răspunsul la VERIFY (X = încercări rămase) și SW=6983 pentru card blocat — detaliu care afectează direct UX-ul aplicației.

Scriem despre CEI — capabilitățile sale, provocările de integrare și contextul reglementar din jurul său. Dacă un subiect de aici este relevant pentru ce construiești, scrie-ne.

Pe 8 octombrie 2024 a intrat în vigoare Legea nr. 214/2024 privind utilizarea semnăturii electronice — cel mai important act normativ din acest domeniu din România din 2001 încoace. A abrogat vechea lege a semnăturii electronice, a clarificat cadrul juridic pentru toate cele trei tipuri de semnături și a dat, pentru prima dată, o bază legală clară semnăturii de pe noua carte electronică de identitate.

Multă lume a înțeles asta ca pe un anunț simplu: buletinul tău poate semna acte cu valoare juridică. Adevărul este mai nuanțat și merită explicat corect — mai ales că diferența dintre ce poți semna cu CEI și ce nu poți semna are consecințe practice imediate.

Trei tipuri de semnătură, trei niveluri de securitate​

Legea, urmând Regulamentul european eIDAS, recunoaște trei tipuri de semnătură electronică. Nu sunt interschimbabile.

Semnătura electronică simplă (SES) Cel mai de bază nivel. Un exemplu: numele tău scris la finalul unui e-mail sau o imagine PNG cu semnătura ta lipită într-un document Word. Legea îi recunoaște valoarea juridică în circumstanțe limitate: acte cu valoare sub jumătate din salariul minim brut (~925 RON la momentul actual), dacă cealaltă parte recunoaște documentul prin comportament (de exemplu, execută obligațiile din el), sau dacă ambele părți, ambele persoane juridice, au agreat dinainte în scris că acceptă acest tip de semnătură.

Semnătura electronică avansată (AdES) Un nivel mai sus. Trebuie să fie legată unic de semnatar, să permită identificarea acestuia, să fie creată cu date de semnare aflate sub controlul exclusiv al semnatarului și să fie capabilă să detecteze orice modificare ulterioară a documentului semnat. Semnătura de pe CEI intră în această categorie — este creată cu un certificat emis de Ministerul Afacerilor Interne, stocat pe cipul cardului, sub controlul titularului prin PIN.

Semnătura electronică calificată (QES) Cel mai înalt nivel. O semnătură avansată care, în plus, este creată printr-un dispozitiv calificat de creare a semnăturii și se bazează pe un certificat calificat emis de un prestator de servicii de încredere calificat (QTSP) — o entitate acreditată și supravegheată de stat. Sunt câțiva astfel de furnizori în România: certSIGN, DigiSign, CertDigital, Trans Sped și alții. Certificatul se obține separat, contra cost, de obicei pe un token USB sau în cloud.

Semnătura de pe CEI nu este calificată. Este avansată, cu un certificat emis de o autoritate publică — ceea ce o plasează într-o subcategorie cu efecte juridice extinse față de o semnătură avansată obișnuită, dar tot sub nivelul calificată.

Ce poate face semnătura de pe CEI, conform Art. 4 din Legea 214/2024​

Articolul 4 alineatul (5) din lege prevede că o semnătură electronică avansată produce aceleași efecte juridice ca o semnătură olografă dacă este îndeplinită cel puțin una din următoarele condiții:

a) actul a fost semnat cu o semnătură electronică avansată creată cu un certificat emis de o autoritate sau instituție publică din România sau de un prestator de servicii de încredere calificat

b) documentul electronic este recunoscut de cel căruia îi este opus — inclusiv prin executarea obligațiilor din document

c) părțile au agreat expres, printr-un înscris separat semnat olograf sau cu semnătură calificată, că vor conferi semnăturii avansate efectele juridice ale semnăturii olografe

CEI satisface condiția (a) în mod direct: certificatul este emis de MAI, care este o autoritate publică din România. Asta înseamnă că, pentru orice act pe care legea îl cere în formă scrisă ca condiție de probă (ad probationem) sau pentru care nu impune nicio formă specială, semnătura de pe CEI este echivalentă cu o semnătură olografă — fără alte condiții suplimentare.

Exemple concrete unde funcționează: contracte de prestări servicii, contracte de consultanță, contracte de muncă (prin coroborare cu OUG 36/2021 care permite AdES pentru contracte individuale de muncă), corespondență oficială, cereri administrative simple, acorduri comerciale între profesioniști.

Ce nu poate face semnătura de pe CEI​

Există două categorii de situații unde semnătura avansată de pe CEI nu este suficientă, indiferent de ce spune legea în teorie.

1. Actele care cer forma scrisă ad validitatem​

Unele acte juridice sunt valide doar dacă sunt în formă scrisă — nu ca o condiție de probă, ci ca o condiție de validitate. Exemple: contracte de ipotecă, contracte de donație, statute de asociere pentru persoane juridice. Legea spune că, pentru aceste acte, forma electronică este valabilă dacă documentul este semnat cu semnătură calificată sau cu semnătură avansată care produce efectele semnăturii olografe în condițiile legii.

CEI poate tehnic satisface această condiție (certificat MAI = autoritate publică = condiția (a) îndeplinită), dar în practică notarii și registrele publice cer semnătură calificată. Și au dreptul să o facă, deoarece legea nu le interzice să impună cerințe tehnice mai stricte în procedurile lor interne.

2. Platformele automatizate ale statului — și aceasta este problema reală​

ANAF / SPV: La data publicării acestui articol, Spațiul Privat Virtual al ANAF nu recunoaște semnătura de pe CEI. Platformele cu validare automată verifică certificatele fără intervenție umană și acceptă exclusiv semnături calificate. Poți semna un document corect și legal cu CEI, dar platforma îl va respinge automat. Sunt necesare: D212, D112, D300 și orice altă declarație fiscală.

ONRC: Același lucru. Înregistrarea actelor societare, modificările statutare, orice operațiune cu efect juridic la Registrul Comerțului necesită semnătură calificată.

SICAP/SEAP: Participarea la licitații publice necesită semnătură calificată.

Motivul tehnic: aceste platforme au fost construite și configurate înainte ca CEI să existe la scară națională. Validarea automată acceptă exclusiv semnături calificate — singurele cu o structură bine-definită și verificabilă instantaneu. Certificatul avansat de pe CEI, deși legal valid, nu trece prin același canal tehnic.

O excepție care merită menționată: sistemele electronice închise​

Art. 4 alin. (5) lit. d) din lege permite semnăturii avansate să producă efectele semnăturii olografe și în cadrul unui sistem electronic închis — o platformă utilizată de un set definit de participanți, care respectă un proces de auditare a securității. Asta înseamnă că o companie privată poate construi un flux de semnare care acceptă CEI și să îi confere deplină valoare juridică în raporturile interne sau cu clienții săi, dacă arhitectura sistemului respectă condițiile legii.

Acesta este spațiul unde sectorul privat poate și ar trebui să se miște mai rapid decât statul.

Certificatul de pe CEI: câteva detalii tehnice relevante​

Legea 214/2024 conține o prevedere specifică pentru certificatul de pe CEI: prin excepție de la regula generală de 2 ani pentru semnăturile avansate, certificatul emis de MAI și înscris pe carta electronică de identitate este valabil pentru maximum 5 ani (Art. 3 alin. 5). Valabilitatea concretă o stabilește MAI la emitere.

Certificatul acoperă semnătura electronică avansată. Nu este un certificat calificat. Dacă ai nevoie de semnătură calificată pentru SPV sau ONRC, trebuie să obții separat un certificat de la un furnizor acreditat — certSIGN, DigiSign, CertDigital sau altul din lista aprobată de Autoritatea pentru Digitalizarea României.

Unde funcționează bine acum: sectorul privat​

Dacă platformele automatizate ale statului sunt excepția problematică, tot sectorul privat este câmpul liber. Certificatul de pe CEI este emis de MAI — autoritate publică — ceea ce înseamnă că satisface direct condiția (a) din Art. 4(5). Orice companie care construiește un flux de semnare cu CEI nu are nevoie de condiții suplimentare: nici acord prealabil între părți, nici recunoaștere tacită. Semnătura este valabilă din prima.

Domeniile cu cel mai mare potențial practic:

Resurse umane și contracte de muncă. OUG 36/2021 permite explicit semnătura electronică avansată pentru contractele individuale de muncă și toate documentele aferente. Companiile care angajează remote sau care procesează volume mari de contracte HR au nevoie de exact asta — identitatea verificată și contractul semnat, în același flux.

Fintech și onboarding financiar. Contracte de servicii, acorduri de mandat, documente de consimțământ, contracte de credit (cu excepția ipotecilor care necesită notar). O platformă fintech care construiește onboardingul pe CEI obține verificarea identității, adresa de domiciliu și semnătura legal valabilă dintr-o singură interacțiune NFC.

Imobiliare — chirii. Contractele de închiriere sunt acte ad probationem, nu ad validitatem. Semnătura avansată de pe CEI este pe deplin suficientă. Platformele proptech care vor să elimine prezența fizică la semnarea contractului de chirie au baza legală.

Asigurări. Contracte de polițe, mandate de brokeraj, declarații de daună. ASF (Autoritatea de Supraveghere Financiară) a împins în mod activ spre fluxuri digitale. Companiile de asigurări au nevoie de verificare a identității la onboarding și de semnătură pe documente de poliță — CEI rezolvă ambele.

Telecomunicații. Contractele de abonament sunt acorduri comerciale standard, integral valabile cu semnătură avansată. Orange, Vodafone, Digi — fiecare are fricțiune masivă la onboarding în prezent.

Servicii medicale private. Formulare de consimțământ, acorduri de tratament, documente de internare în rețelele private de clinici.

Platforme de freelancing și colaborare B2B. Contracte de colaborare, contracte de prestări servicii între profesioniști. Conform Legii 214/2024, în relațiile B2B între profesioniști cu un acord prealabil, orice semnătură electronică avansată este valabilă.

Servicii juridice. Contracte de asistență juridică, împuterniciri, fluxuri interne de documente pentru cabinete de avocatură.

Banking — contracte cu clienții. Distinct de problema SPV/ANAF: contractele de servicii bancare cu persoane fizice, acordurile de mandat pentru investiții, documentele de onboarding pentru conturi noi — toate sunt relații private, nu interacțiuni cu platforme automatizate ale statului. CEI este valabilă.

Numitorul comun al tuturor acestor domenii: au nevoie de identitate verificată și de semnătură și beneficiază de eliminarea fricțiunii din procesul de onboarding sau semnare. CEI este singurul mecanism disponibil în România care oferă toate trei simultan, din telefon, fără hardware suplimentar, fără o vizită la un birou.

Ce urmează​

Situația nu este statică. Guvernul a anunțat că lucrează la compatibilizarea tehnică a platformelor statului cu semnătura de pe CEI, deși nu există un termen public asumat. Presiunea vine din mai multe direcții: numărul de CEI în circulație crește rapid, Regulamentul eIDAS 2.0 obligă instituțiile să accepte mijloacele de identificare electronică recunoscute, iar EUDI Wallet — portofelul european de identitate digitală — trebuie să fie disponibil în România până la finalul lui 2026.

Deocamdată, situația practică este simplă: semnătura de pe CEI funcționează bine în relațiile private și acolo unde există o persoană care verifică documentul. Nu funcționează (încă) pe platformele automatizate ale statului.

Scriem despre CEI — capabilitățile sale, provocările de integrare și contextul reglementar din jurul său. Dacă un subiect de aici este relevant pentru ce construiești, scrie-ne.

Odată cu introducerea noii Cărții Electronice de Identitate, adresa de domiciliu a dispărut de pe suprafața fizică a documentului. Nu mai există stradă, număr, oraș, județ tipărite pe verso. Toate aceste informații sunt stocate exclusiv pe cipul din interiorul cărții, accesibile doar prin NFC sau printr-un cititor de carduri.

În teorie, este un pas înainte. Adresa poate fi actualizată electronic atunci când te muți, fără să fie necesară emiterea unui nou document. În practică, tranziția a generat o criză care devine tot mai vizibilă.

Problema, pe scurt​

Milioane de români dețin acum un act de identitate care conține legal adresa lor de domiciliu — dar nu o pot prezenta unui funcționar bancar, notar sau angajat al statului într-un format pe care acesta să îl poată citi.

Până în această săptămână, Guvernul a înregistrat peste 300 de sesizări în categoria „Pașaport și Carte de Identitate" pe platforma fara-hartie.gov.ro. Cea mai frecventă problemă: lipsa adresei tipărite. Bănci, notariate, școli, birouri ANAF și autorități locale continuă să solicite o adeverință de domiciliu separată — un document care atestă adresa deja prezentă, tehnic vorbind, pe actul pe care îl țin în mână.

O persoană a povestit că a ajuns la notar pentru un act de vânzare-cumpărare și a fost trimisă acasă pentru că CEI „nu este suficientă pentru dovada domiciliului." Alta a pățit același lucru la bancă. Un tânăr de 34 de ani: „Am făcut buletinul electronic pentru că am înțeles că e mai modern și mai sigur. Nimeni nu mi-a spus că voi avea nevoie de o adeverință de fiecare dată când trebuie să dovedesc adresa."

Asta se întâmplă când infrastructura avansează înainte ca instituțiile să fie pregătite să o folosească.

Ce a făcut Guvernul​

Guvernul a reacționat rapid. Pe 25 martie 2026 — acum două zile — serviciile de evidență a persoanelor au primit instrucțiunea să verifice ele însele adresele în baza de date națională, fără să mai condiționeze preluarea dosarului de prezentarea unui document fizic.

Băncile au primit acces tehnic direct la baza de date a evidenței persoanelor și, conform anunțului guvernamental, nu mai trebuie să solicite adeverința.

Pentru notari, se testează un mecanism similar.

Pentru toți ceilalți — cetățeni care trebuie să dovedească adresa într-un loc care nu are încă acces la baza de date — Ministerul Afacerilor Interne a lansat aplicația mobilă RoCEIReader. Apropiați buletinul de telefon, introduceți codul CAN de 6 cifre și PIN-ul de 4 cifre, iar aplicația citește adresa de pe cip și permite salvarea ei ca PDF.

Disponibilă momentan doar pentru Android. Versiunea iOS „urmează în curând."

Opțiunile pentru citirea adresei​

Tranziția are consecințe reale pentru oricine construiește software care necesită o adresă de domiciliu verificată în România. Fluxul vechi — scanează actul, extrage adresa prin OCR de pe verso — nu mai funcționează. Adresa nu mai e pe verso.

Alternativele, aproximativ în ordinea robusteții:

Acces direct la baza de date guvernamentală Băncile au primit acces direct la registrul DGEP. Curat, fără NFC, fără interacțiune suplimentară din partea utilizatorului dincolo de CNP. Accesul necesită un acord formal cu autoritatea guvernamentală și nu este disponibil oricărei companii private care îl solicită.

Citirea cipului prin NFC Cardul este citit direct folosind codul CAN tipărit pe fața documentului. Adresa este furnizată exact așa cum o deține statul — semnată criptografic, verificabilă față de lanțul de certificate al Ministerului, fără dependență de o bază de date externă. Adresa se află în applet-ul EDATA al cardului, în spatele unui canal securizat PACE și al unui PIN de 4 cifre. Citirea corectă implică gestionarea unor formate de date specifice implementării românești, pe care bibliotecile ICAO standard nu le acoperă din cutie.

Certificatul produs de utilizator Soluția de compromis facilitată acum prin RoCEIReader. Valabilă legal. Introduce un pas manual pentru utilizator, o fereastră de valabilitate de 6 luni și fricțiune tocmai acolo unde fluxurile de onboarding pierd cei mai mulți utilizatori.

Imaginea de ansamblu​

Problema adresei este simptomul cel mai vizibil, dar CEI este capabilă de mult mai mult decât a reușit să asimileze orice instituție până acum.

Cipul conține date biometrice, fotografia titularului și două chei criptografice susținute de certificate emise de MAI. Una este pentru semnătura electronică avansată — conform Legii 214/2024, un document semnat cu acest certificat are aceeași valoare juridică ca o semnătură olografă. Cealaltă este pentru autentificarea activă: o dovadă criptografică că cipul este autentic și nu clonat.

Și totuși, platforma SPV a ANAF respinge semnătura de pe CEI. Acceptă doar semnături de pe certificate calificate achiziționate separat, de la furnizori comerciali autorizați. Cardul îți oferă o semnătură legal valabilă. Portalul propriu al Guvernului nu o acceptă.

Cardul este înaintea ecosistemului. Ecosistemul recuperează decalajul, instituție cu instituție. Băncile au recuperat în privința adresei. Notarii sunt aproape. ANAF nu a recuperat în privința semnăturilor. Același tipar se va repeta pentru fiecare instituție care trebuie să interacționeze cu aceste carduri în următorii doi-trei ani.

Ce presupune citirea cipului​

Pentru cei curioși din punct de vedere tehnic: cipul CEI rulează protocolul PACE (Password Authenticated Connection Establishment) cu AES-256 pentru a stabili un canal securizat înainte ca orice să poată fi citit. După deschiderea canalului, citirea datelor personale necesită selectarea applet-ului corect, verificarea PIN-ului și parsarea răspunsului într-un format ASN.1 specific implementării românești — diferit de formatul MRZ ICAO pe care îl așteaptă majoritatea bibliotecilor.

Autentificarea pasivă — verificarea că datele de pe cip sunt semnate de MAI și nu au fost alterate — trebuie să ruleze întotdeauna înainte de a folosi orice date citite de pe card. Lanțul merge de la grupele de date prin certificatul semnatarului documentului până la certificatul rădăcină CSCA al Ministerului.

Nimic din toate astea nu este exotic. Dar este specific, iar specificul contează. Nu poți integra CEI citind documentația ICAO standard și adaptând un cititor de pașapoarte. Implementarea românească are propria structură de applet-uri, propriile formate de date și propriile cerințe de secvențiere care nu sunt documentate complet nicăieri în mod public.

Din iulie 2025, CEI este singurul model de carte de identitate emis la nivel național. Fiecare act de identitate eliberat în România de acum înainte conține un cip pe care titularul nu îl poate prezenta majorității instituțiilor într-un format pe care acestea să îl poată citi.

Decalajul se va închide treptat. Întrebarea pentru oricine construiește în acest spațiu este cât timp este dispus să aștepte și dacă soluția de compromis — certificate PDF ale datelor deja existente pe card — reprezintă fricțiunea acceptabilă pentru produsul său.

Scriem despre CEI — capabilitățile sale, provocările de integrare și contextul reglementar din jurul său. Dacă un subiect de aici este relevant pentru ce construiești, scrie-ne.