DORA, NIS2 și PSD3: Checklistul cerințelor de autentificare pentru 2026
Ce cer DORA, NIS2 și PSD3/SCA de la autentificare în 2026 - MFA rezistent la phishing, jurnale de audit rezistente la modificări și management de chei, într-un singur checklist.
DORA, NIS2 și PSD3: Checklistul cerințelor de autentificare pentru 2026
TL;DR
- Trei regimuri UE converg acum spre aceeași bază de autentificare: DORA (risc ICT pentru sectorul financiar), NIS2 (autentificare puternică + jurnalizare de audit pentru entitățile esențiale și importante) și PSD3/PSR (autentificare strictă a clienților pentru plăți).
- În practică, ele cer patru capabilități: MFA rezistent la phishing, jurnale de audit rezistente la modificări, un management disciplinat al cheilor criptografice și o guvernanță a accesului demonstrabilă.
- Un jurnal de audit rezistent la modificări, construit pe un lanț Merkle BLAKE3, vă permite să dovediți unui auditor că jurnalele nu au fost alterate ulterior - o cerință recurentă în toate cele trei regimuri.
- Folosiți checklistul de capabilități de mai jos pentru a corela fiecare obligație cu un control, apoi descărcați versiunea PDF completă (cu acces controlat) pentru pachetul dumneavoastră de audit.
Ce autentificare cer DORA, NIS2 și PSD3 în 2026?
DORA, NIS2 și PSD3 nu publică un singur “standard de autentificare” comun, dar împreună cer entităților reglementate din UE să implementeze autentificare multifactor rezistentă la phishing, să păstreze jurnale de audit rezistente la modificări pentru evenimentele de acces și de chei, să gestioneze cheile criptografice sub controale documentate și să demonstreze aceste controale la cerere. Suprapunerea este suficient de mare încât să poată fi acoperită cu un singur strat de identitate bine proiectat.
Dacă administrați o bancă, un serviciu de plăți, infrastructură critică sau un serviciu digital pe care legislația UE îl clasează acum drept “esențial” sau “important”, furnizorul dumneavoastră de identitate a devenit, pe nesimțite, un artefact de conformitate. Auditorii nu mai întreabă doar dacă aveți MFA - întreabă dacă rezistă la phishing, dacă jurnalele de acces pot fi considerate de încredere și dacă puteți demonstra lanțul de custodie pentru cheile de semnare. Acest checklist corelează fiecare reglementare cu capabilitatea de autentificare care îi răspunde.
CAI Technology nu este o autoritate guvernamentală; recomandările de mai jos reprezintă o interpretare inginerească a textelor legale publice ale UE, nu consiliere juridică. Citați sursele primare indicate inline și confirmați domeniul de aplicare cu consilierul dumneavoastră de conformitate.
Cele trei regimuri pe scurt
| Regim | Instrument | Cine intră în sfera de aplicare | Cerința centrală de autentificare |
|---|---|---|---|
| DORA | Regulamentul (UE) 2022/2554 | Bănci, asigurători, firme de investiții, furnizori de cripto-active, terți ICT critici | Management al riscului ICT: control al accesului, autentificare puternică, guvernanță a identității, jurnalizare rezistentă la modificări |
| NIS2 | Directiva (UE) 2022/2555 | Entități “esențiale” și “importante” din 18 sectoare (energie, sănătate, infrastructură digitală, administrație publică) | Măsuri de management al riscului, inclusiv MFA / autentificare continuă și jurnalizare securizată (Art. 21) |
| PSD3 / PSR | Propunerile PSD3 + PSR (COM/2023/366, COM/2023/367) | Furnizori de servicii de plată, instituții care administrează conturi | Autentificare strictă a clienților (SCA): doi factori independenți, legare dinamică, anti-fraudă |
Concluzia practică este că aceste trei regimuri au fost redactate de direcții diferite, în scopuri diferite - reziliență operațională, securitatea rețelelor și frauda în plăți - și totuși converg spre aceleași controale atunci când le reduceți la primitivele de autentificare.
Cum se citește diagrama: Coloana din stânga reprezintă cele trei reglementări; coloana din mijloc este obligația specifică de autentificare pe care fiecare o impune; coloana din dreapta este capabilitatea inginerească ce o satisface. Rostul convergenței (fan-in) este că obligații legale distincte - controlul accesului din DORA, mandatul MFA din Articolul 21 al NIS2 și regula SCA cu doi factori din PSD3 - se reduc toate la același control: MFA rezistent la phishing. Citită astfel, schema împiedică echipele să construiască trei programe paralele de conformitate când unul singur, cu un strat de identitate bine arhitecturat, le acoperă pe toate trei. Totodată, ea evidențiază unde o singură slăbiciune, precum un jurnal care nu este rezistent la modificări, ar genera constatări simultan sub DORA și NIS2.
DORA: riscul ICT și unghiul autentificării
DORA (Regulamentul (UE) 2022/2554), aplicabil din ianuarie 2025, este o reglementare de reziliență operațională pentru sectorul financiar al UE. Cadrul său de management al riscului ICT (Articolele 5-15) cere entităților financiare să implementeze “mecanisme de autentificare puternică” și controale de acces bazate pe principiul privilegiului minim, precum și să mențină jurnale care înregistrează evenimentele legate de ICT într-un mod care sprijină reconstituirea incidentelor și revizuirea de către autoritatea de supraveghere.
Pentru autentificare, asta se traduce în trei cerințe concrete. În primul rând, accesul privilegiat și cel de la distanță trebuie să utilizeze autentificare multifactor rezistentă la interceptare și la atacuri de tip replay. În al doilea rând, fiecare eveniment de autentificare și de management al cheilor trebuie jurnalizat cu garanții de integritate - un auditor care reconstituie un incident trebuie să poată avea încredere că jurnalul nu a fost editat după breșă. În al treilea rând, cheile criptografice care stau la baza furnizorului dumneavoastră de identitate (în special cheile de semnare a token-urilor) intră direct în inventarul de active ICT și în așteptările de management al schimbării din DORA. O cheie de semnare este o rădăcină de încredere; DORA vrea să o gestionați ca atare.
NIS2: autentificare puternică plus jurnalizare securizată
NIS2 (Directiva (UE) 2022/2555) extinde vechiul domeniu NIS la optsprezece sectoare și înăsprește baza minimă. Articolul 21 enumeră măsurile minime de management al riscului și menționează explicit “utilizarea soluțiilor de autentificare multifactor sau de autentificare continuă” și “comunicații securizate de voce, video și text”, alături de politici privind criptografia și controlul accesului.
Domină două obligații relevante pentru autentificare. Prima este autentificarea puternică pe întreaga infrastructură - nu doar pentru clienți, ci și pentru administratori, conturi de serviciu și personalul de la distanță, exact acolo unde aterizează atacurile de phishing pe credențiale. NIS2 ridică costul unui MFA slab, deoarece organele de conducere pot fi trase personal la răspundere pentru neconformitate. A doua obligație este jurnalizarea pe care o poți apăra: obligațiile de gestionare și raportare a incidentelor sunt lipsite de sens dacă jurnalele subiacente pot fi rescrise în tăcere. Transpunerile statelor membre din 2024-2025 au interpretat în general “jurnalizarea securizată” ca însemnând protejată în integritate, păstrată și verificabilă - exact ceea ce oferă un jurnal de audit rezistent la modificări.
Pentru dimensiunea de suveranitate - de ce contează și unde rulează furnizorul dumneavoastră de identitate sub aceste regimuri - consultați analiza noastră despre identitatea suverană UE versus CLOUD Act-ul american.
PSD3 / SCA: ce se schimbă față de PSD2
Pachetul de plăți - directiva PSD3 și Regulamentul privind serviciile de plată (PSR) - reafirmă și modernizează Autentificarea Strictă a Clienților. SCA se bazează în continuare pe doi factori independenți aleși din cunoaștere, posesie și inerență, cu legare dinamică ce ancorează fiecare autentificare la o sumă și un beneficiar specifici. Standardele Tehnice de Reglementare ale EBA privind SCA rămân setul detaliat de reguli.
Ce este nou este direcția de evoluție. PSD3/PSR ascute obligația de a face SCA accesibilă (astfel încât furnizorii să nu se poată baza pe un singur canal precum SMS), întărește așteptările privind monitorizarea tranzacțiilor și anti-frauda, abordează autentificarea pentru utilizatorii vulnerabili și înăsprește răspunderea pentru frauda facilitată de spoofing. Semnalul clar este o îndepărtare de codurile unice prin SMS - care sunt vulnerabile la phishing și la interceptare - către factori de posesie ancorați în hardware. Asta face din MFA rezistent la phishing, bazat pe hardware, ținta de proiectare sigură pentru orice flux de plată pe care îl construiți astăzi.
Checklistul de capabilități: corelarea obligațiilor cu controalele
Iată corelarea consolidată. Fiecare rând asociază o obligație de reglementare cu capabilitatea de autentificare care o satisface și cu o notă de implementare de un rând.
| Capabilitate | Satisface | Cum arată “bine” |
|---|---|---|
| MFA rezistent la phishing | Controlul accesului din DORA; NIS2 Art. 21; SCA din PSD3 | FIDO2/passkey-uri sau push cu atestare hardware; respingerea OTP exclusiv prin SMS |
| Factor de posesie ancorat în hardware | Posesia din SCA (PSD3); autentificarea puternică din NIS2 | Chei demonstrabil rezidente într-un secure element (StrongBox / Secure Enclave / TEE) |
| Jurnal de audit rezistent la modificări | Jurnalizarea din DORA; jurnalizarea securizată din NIS2 | Jurnal append-only cu înlănțuire criptografică; verificabil independent |
| Management al cheilor criptografice | Active ICT din DORA; politica de criptografie din NIS2 | Ciclu de viață documentat al cheilor, rotație, chei de semnare atestate, recuperare |
| Guvernanță a accesului cu privilegiu minim | DORA; controlul accesului din NIS2 | Scope-uri per client, revocare prin JTI, logout inițiat de RP, revizuire periodică |
| Legare dinamică | SCA din PSD3/PSR | Fiecare aprobare ancorată la sumă + beneficiar, rezistentă la replay |
| Sesiuni cu forward secrecy | Confidențialitatea din DORA; criptografia din NIS2 | Acord de chei efemer, astfel încât sesiunile anterioare rămân protejate |
Singura linie care surprinde majoritatea echipelor este jurnalul de audit. Toată lumea are jurnale; puțini pot dovedi că jurnalele lor nu au fost alterate după un incident. Aceasta este lacuna pe care o închide un design rezistent la modificări.
De ce contează un jurnal de audit rezistent la modificări - și cum îl verifici
Atât DORA, cât și NIS2 vor jurnale pe care le poți apăra, nu doar jurnale pe care le păstrezi. Distincția stă în integritate: dacă un atacator (sau un insider) poate edita înregistrarea de audit după fapt, înregistrarea este inutilă ca probă. Soluția este să faci orice modificare detectabilă matematic.
Jurnalul de audit al CAI-AUTH este un exemplu public al acestui model: este un lanț de audit rezistent la modificări, construit pe o structură Merkle BLAKE3. Fiecare eveniment este transformat în hash, fiecare hash este împletit într-un lanț continuu, iar lanțul produce o rădăcină compactă care rezumă întregul istoric. Pentru verificare, un auditor recalculează hash-urile; dacă o singură intrare anterioară a fost alterată, fiecare hash din aval și rădăcina finală nu mai corespund, iar manipularea este expusă. Beneficiul pentru un cumpărător reglementat este direct: puteți oferi unui auditor o dovadă verificabilă că jurnalele dumneavoastră de acces și de management al cheilor sunt intacte, satisfăcând așteptarea de integritate atât din clauzele de jurnalizare ale DORA, cât și din cele de jurnalizare securizată ale NIS2 - fără a fi nevoie să vă încredeți în cuvântul operatorului. (CAI Technology nu este o autoritate guvernamentală; aceasta este o capabilitate de produs, nu o certificare de reglementare.)
Cum se citește diagrama: Fiecare intrare de jurnal din stânga este transformată în hash, iar hash-urile sunt combinate pereche urcând pe lanț până produc o singură rădăcină Merkle în dreapta. Verificatorul recalculează acea rădăcină din intrările stocate și o compară cu rădăcina publicată. Dacă fiecare intrare este originală, rădăcina recalculată corespunde și jurnalul este certificat intact; dacă vreo intrare - să zicem “Entry 3” - a fost modificată ulterior, hash-ul ei se schimbă, schimbarea se propagă prin fiecare legătură-părinte, iar rădăcina finală nu mai corespunde, astfel încât ramura comută pe “tampering detected”. Tocmai de aceea un jurnal înlănțuit Merkle este rezistent la modificări (tamper-evident), nu doar greu de modificat: nu poți rescrie istoria în tăcere, fiindcă matematica face alterarea vizibilă oricui verifică.
Pentru modul în care factorul de posesie din acest tablou este ancorat în hardware real (și de ce un furnizor de identitate ar trebui să respingă dispozitivele rootate sau emulate), acest aspect se conectează la mișcarea mai amplă către eIDAS 2.0 și EU Digital Identity Wallet, unde asigurarea de nivel wallet și aceste regimuri de conformitate se întâlnesc tot mai des.
Unde se încadrează CAI-AUTH
CAI-AUTH este un furnizor de identitate OIDC operat în UE, self-hostable, scris în Rust. Oferă autentificare prin push de tip tap-to-approve, rezistentă la phishing, cu atestare hardware obligatorie, jurnalul de audit Merkle BLAKE3 rezistent la modificări descris mai sus, recuperare de cont Shamir 3-din-5 și semnare post-cuantică compozită (CAI-PQ-HYBRID-87-Ed25519). Postura sa de conformitate este documentată pentru DORA, NIS2, PSD3, eIDAS 2.0, PCI-DSS și GDPR. Vedeți corelarea completă pe pagina de conformitate CAI-AUTH. CAI Technology nu este o autoritate guvernamentală.
FAQ
DORA cere MFA?
DORA nu numește “MFA” ca punct distinct, dar cadrul său de management al riscului ICT (Articolele 5-15 din Regulamentul (UE) 2022/2554) cere autentificare puternică și control al accesului cu privilegiu minim pentru sistemele ICT. În practică, autoritățile de supraveghere interpretează asta ca autentificare multifactor pentru accesul privilegiat și de la distanță, susținută de jurnalizarea protejată în integritate a evenimentelor de autentificare.
Ce autentificare cere NIS2?
NIS2 (Directiva (UE) 2022/2555), Articolul 21, enumeră măsuri minime de management al riscului care includ explicit “utilizarea soluțiilor de autentificare multifactor sau de autentificare continuă”, alături de politici de criptografie și de control al accesului și de jurnalizare securizată. Se aplică entităților esențiale și importante, iar organele de conducere pot fi trase la răspundere pentru neimplementarea acestor măsuri.
Ce se schimbă pentru SCA sub PSD3?
PSD3 și PSR reafirmă Autentificarea Strictă a Clienților - doi factori independenți plus legare dinamică - împingând totodată furnizorii dinspre codurile SMS vulnerabile la phishing către factori de posesie ancorați în hardware, întărind anti-frauda și monitorizarea tranzacțiilor, îmbunătățind accesibilitatea SCA și înăsprind răspunderea pentru frauda facilitată de spoofing. Standardele Tehnice de Reglementare ale EBA privind SCA rămân setul tehnic detaliat de reguli.
Cum dovedesc că jurnalele mele de audit nu au fost manipulate?
Folosiți un jurnal rezistent la modificări: transformați fiecare intrare în hash și înlănțuiți hash-urile într-o structură Merkle care produce o singură rădăcină verificabilă. Un auditor recalculează rădăcina din intrările stocate; orice editare ulterioară schimbă un hash, rupe lanțul și face ca rădăcina să nu mai corespundă. CAI-AUTH implementează asta cu un lanț de audit Merkle BLAKE3.
Poate un singur strat de identitate să satisfacă DORA, NIS2 și PSD3 deodată?
În mare măsură, da. Deși cele trei regimuri au domenii de aplicare diferite, obligațiile lor de autentificare converg spre MFA rezistent la phishing, jurnale de audit rezistente la modificări și management disciplinat al cheilor. Un singur furnizor de identitate care le oferă pe toate trei - și documentează corelarea - vă permite să acoperiți baza comună o singură dată, în loc să construiți programe paralele de conformitate.
Descărcați checklistul complet (PDF). Obțineți checklistul complet de autentificare DORA / NIS2 / PSD3, pregătit pentru audit - fiecare obligație corelată cu un control, cu note de implementare și indicii pentru dovezi - sub forma unui PDF cu acces controlat. Solicitați checklistul.
Ultima actualizare: 2026-06-27. CAI TECHNOLOGY SRL, CUI 50512457. CAI Technology nu este o autoritate guvernamentală. Acest articol reprezintă consiliere inginerească, nu consiliere juridică.