Passkeys în 2026: parolele dispar, riscurile rămân

Parola a fost mult timp poarta principală către identitatea digitală. În 2026, această poartă începe să fie înlocuită de passkeys: credențiale criptografice pe care le folosim prin amprentă, recunoaștere facială sau codul dispozitivului. Schimbarea nu este doar o promisiune comercială. Datele recente arată că metoda a devenit obișnuită pentru milioane de utilizatori, iar marile platforme o transformă treptat în opțiunea implicită.

Totuși, eliminarea parolei nu înseamnă eliminarea tuturor atacurilor asupra conturilor. Un utilizator se poate autentifica perfect sigur, după care un program malițios îi poate fura sesiunea din browser. Un administrator poate proteja intrarea principală și poate lăsa vulnerabilă procedura de recuperare. Tocmai această diferență dintre autentificare, sesiune și recuperarea accesului merită analizată înainte de a declara sfârșitul phishingului.

Ce s-a schimbat concret în octombrie 2026

Pe 15 octombrie 2026, FIDO Alliance a publicat Passkey Index 2026, realizat pe baza datelor oferite de 15 servicii de consum. În eșantionul analizat, 36% dintre autentificările reușite au folosit un passkey, față de 26% în ediția anterioară. Rata de reușită a fost de 93%, comparativ cu 78% pentru metodele tradiționale evaluate, iar economisirea medie declarată a fost de 27 de secunde per autentificare.

Organizația estimează, separat, că există aproximativ șapte miliarde de passkeys în utilizare la nivel mondial. Este o estimare a ecosistemului, nu un recensământ al persoanelor unice: un singur utilizator poate deține multe credențiale. Nici procentul de 36% nu descrie automat întregul internet. El reprezintă autentificările raportate de participanții la studiu, printre care platforme mari, cu niveluri diferite de adoptare.

Interpretarea relevantă este mai modestă, dar importantă: tehnologia a depășit faza în care exista numai în meniurile de securitate. Oamenii o folosesc repetat. Pentru un serviciu online, întrebarea nu mai este exclusiv dacă poate implementa passkeys, ci dacă le poate integra fără să lase parola, codul SMS sau suportul tehnic drept căi de acces mult mai slabe.

De la secret memorat la pereche de chei

O parolă este un secret comun: utilizatorul îl cunoaște, iar serviciul păstrează o reprezentare verificabilă a acestuia. Dacă cineva îl află prin phishing, reutilizare sau o breșă, îl poate încerca în altă parte. Un passkey funcționează diferit. La înregistrare se creează o pereche de chei criptografice, una privată și una publică, asociată serviciului respectiv.

Cheia publică ajunge la server, iar cea privată rămâne administrată de autentificatorul utilizatorului. La conectare, serverul trimite o provocare nouă; autentificatorul semnează datele cerute, iar serverul verifică semnătura. Nu este necesar ca secretul privat să fie trimis site-ului. În consecință, compromiterea bazei de date cu chei publice nu oferă atacatorului echivalentul unor parole utilizabile.

Amprenta sau recunoașterea facială nu reprezintă, în acest mecanism, parola transmisă site-ului. Ele pot fi metode locale de deblocare a autentificatorului, alături de PIN-ul dispozitivului. Serviciul primește dovada criptografică, nu fotografia feței. Această distincție contează pentru confidențialitate, dar și pentru a explica de ce pierderea accesului la telefon trebuie tratată separat de compromiterea serverului.

De ce un site fals nu poate folosi ușor un passkey

Protecția decisivă nu este faptul că utilizatorul tastează mai puțin. Standardul WebAuthn leagă credențiala de identificatorul serviciului, numit relying party ID, și impune verificarea originii. Un domeniu care imită vizual banca sau furnizorul de e-mail nu poate, în mod normal, solicita o semnătură validă pentru domeniul legitim. Browserul și autentificatorul aplică această regulă independent de atenția utilizatorului.

Acesta este sensul tehnic al expresiei phishing-resistant. Codurile primite prin SMS sau generate de o aplicație TOTP pot fi introduse pe o pagină falsă și retransmise rapid către site-ul real. Un passkey proiectat și implementat corect nu furnizează acelei pagini un rezultat reutilizabil pentru alt domeniu. Standardul NIST SP 800-63B-4 face explicit diferența dintre codurile introduse manual și autentificarea criptografică legată de verificator.

Există însă o condiție importantă: serviciul trebuie să verifice corect provocarea, originea și credențiala. O implementare defectuoasă sau cod malițios executat chiar pe originea legitimă poate schimba modelul de risc. WebAuthn nu repară automat vulnerabilitățile aplicației, erorile de autorizare sau o infrastructură deja compromisă. Protecția împotriva paginilor false nu trebuie confundată cu invulnerabilitatea întregului cont.

Ce înseamnă passkey sincronizat și passkey legat de dispozitiv

În utilizarea obișnuită, multe passkeys sunt sincronizate între dispozitive printr-un manager de credențiale. Această facilitate reduce riscul de a pierde accesul atunci când telefonul este înlocuit și permite folosirea aceleiași identități pe laptop și tabletă. Sincronizarea trebuie să protejeze materialul criptografic și depinde de securitatea contului și a ecosistemului care o administrează.

Există și credențiale legate de un singur dispozitiv sau de o cheie fizică FIDO2. În aceste cazuri, secretul este conceput să nu poată fi exportat. Pentru roluri administrative cu risc ridicat, proprietatea aceasta poate fi esențială. NIST permite autentificatori sincronizabili la niveluri de asigurare mai reduse, dar cere chei neexportabile pentru nivelul AAL3, unde condițiile sunt mai stricte.

Nu există o alegere universală între confort și securitate. Un utilizator obișnuit poate beneficia mai mult de un passkey sincronizat decât de o cheie hardware pe care o pierde și pentru care nu are rezervă. O organizație cu acces privilegiat poate prefera dispozitive controlate, politici de atestare și două chei fizice înregistrate. Decizia depinde de consecințele unui acces neautorizat și de capacitatea reală de recuperare.

De ce Microsoft schimbă implicit autentificarea Entra

Microsoft a anunțat la 13 iulie 2026 că, începând cu 1 septembrie, a început tranziția către passkeys ca metodă implicită pentru utilizatorii Entra ID care aveau activată autentificarea prin SMS sau apel vocal. În funcție de implementarea din fiecare organizație, aceștia sunt încurajați să înregistreze o credențială rezistentă la phishing. Este o schimbare de politică, nu o dovadă că toate conturile au migrat deja.

Documentația Microsoft indică și un termen important: 1 februarie 2027 pentru retragerea livrării native SMS și voce pentru majoritatea utilizatorilor vizați. Pentru administratorii globali și utilizatorii externi, documentația actuală precizează o etapă separată, la 1 iulie 2027. Organizațiile care au o nevoie justificată de telefonie pot evalua furnizori terți; termenele și excepțiile trebuie citite în documentația oficială, nu extrapolate la toate serviciile Microsoft.

Această mutare arată unde se îndreaptă piața enterprise: autentificarea rezistentă la phishing începe să fie considerată o configurație normală, nu un avantaj rezervat conturilor foarte sensibile. Totuși, o migrare făcută în grabă poate bloca utilizatori, mai ales dacă aceștia nu au dispozitive compatibile sau nu au un proces de recuperare testat. Securitatea și continuitatea operațională trebuie proiectate împreună.

Noua recomandare W3C și maturizarea WebAuthn

Pe 25 august 2026, W3C a publicat Web Authentication Level 3 ca recomandare. Standardul descrie interfața prin care aplicațiile web creează și folosesc credențiale bazate pe chei publice. Nu este un produs comercial și nu obligă toate site-urile să adopte imediat passkeys. Oferă însă un cadru interoperabil pentru browsere, autentificatori și servicii care doresc să le implementeze.

Nivelul 3 clarifică inclusiv situații în care același serviciu operează pe mai multe domenii înrudite, fără a elimina verificarea originilor permise. Pentru companiile internaționale, această posibilitate poate reduce fricțiunea dintre domeniile regionale. În același timp, configurarea greșită a domeniilor acceptate ar crea o suprafață de atac suplimentară, motiv pentru care lista originilor trebuie administrată strict.

Evoluția standardului nu trebuie citită ca o promisiune că orice browser și orice manager de parole oferă imediat aceleași funcții. Compatibilitatea se verifică pentru versiunile de sistem de operare, browser, dispozitive și politica furnizorului de identitate. Pentru utilizator, experiența poate părea uniformă; pentru echipa tehnică, diferențele de implementare rămân relevante.

Problema pe care passkeys nu o rezolvă: sesiunea activă

După autentificare, majoritatea aplicațiilor web nu solicită o nouă semnătură criptografică pentru fiecare clic. Ele emit un cookie de sesiune sau alt token care arată că utilizatorul a trecut deja verificarea. Acest mecanism este necesar pentru o experiență normală: altfel, fiecare pagină sau cerere ar putea declanșa o autentificare completă.

Dar un cookie de sesiune obișnuit este adesea un bearer token: cine îl deține îl poate prezenta serverului, cât timp rămâne valid. Dacă un malware de tip infostealer îl extrage din browser sau dacă o vulnerabilitate îl expune, atacatorul poate încerca să continue sesiunea fără să cunoască parola și fără să dețină passkey-ul. OWASP descrie explicit acest risc, inclusiv în aplicații care folosesc autentificare puternică.

Prin urmare, afirmația că passkeys fac imposibilă preluarea conturilor este greșită. Ele reduc dramatic anumite atacuri la momentul autentificării, în special phishingul de credențiale. Nu anulează automat furtul de sesiuni, compromiterea dispozitivului, abuzul unui token OAuth sau modificarea frauduloasă a metodelor de recuperare. Modelul corect de securitate urmărește întregul ciclu de viață al accesului.

Cum se produce furtul de sesiune în practică

Un scenariu frecvent începe cu un fișier malițios descărcat dintr-o sursă nesigură, o extensie de browser compromisă sau un program instalat sub pretextul unei actualizări. Codul caută informații de autentificare disponibile în profilul browserului ori în memoria proceselor. Uneori obține și date despre dispozitiv pentru a încerca să reducă diferențele observate de sistemele antifraudă.

Un alt scenariu pornește dintr-o vulnerabilitate a aplicației. Dacă un script neautorizat rulează în contextul site-ului legitim, poate executa acțiuni în numele utilizatorului chiar și atunci când cookie-ul este marcat HttpOnly. Acel atribut împiedică citirea directă a cookie-ului prin JavaScript, dar nu oprește browserul să îl trimită automat în cererile către site. Este o protecție importantă, nu una absolută.

Din punctul de vedere al victimei, autentificarea poate să fi fost impecabilă. Nu a introdus coduri pe pagini false și nu a divulgat cheia privată. Totuși, un atacator poate exploata o sesiune existentă. Aceasta este explicația pentru care protecția endpointului, actualizările browserului, controlul extensiilor și monitorizarea sesiunilor trebuie să rămână prioritare chiar după migrarea la passkeys.

Ce arată investigațiile Mandiant din 2026

Raportul M-Trends 2026, publicat de Google Cloud și Mandiant, se bazează pe investigații de incidente efectuate în 2025. El descrie atacatori care urmăresc cookie-uri de sesiune, tokenuri OAuth și alte secrete reutilizabile, alături de tactici de inginerie socială orientate către echipele de suport. Raportul nu susține că passkeys ar fi fost compromise criptografic la scară largă; problema analizată este ocolirea autentificării prin alte căi.

Mandiant observă și că actorii malițioși caută acces în infrastructuri cloud și aplicații SaaS prin identități, integrări și tokenuri deja autorizate. În unele investigații, codurile de acces pot rămâne utile chiar după anumite operațiuni de deconectare, în funcție de sistem și de modul în care revocarea este implementată. Nu toate serviciile se comportă la fel, iar revocarea efectivă trebuie verificată pentru fiecare platformă.

Concluzia editorială este că autentificarea nu mai poate fi tratată ca singurul moment critic. Un cont are sesiuni active, aplicații conectate, dispozitive înregistrate, metode de recuperare și drepturi de acces. Fiecare poate deveni o intrare alternativă. Un proiect passwordless matur trebuie să știe nu doar cine a intrat, ci și ce drepturi păstrează după intrare și cum pot fi retrase rapid.

Device Bound Session Credentials: următorul strat

Google a prezentat Device Bound Session Credentials, sau DBSC, ca răspuns la furtul cookie-urilor. Ideea este ca browserul să folosească o cheie asociată dispozitivului pentru a demonstra periodic că sesiunea este reîmprospătată de mediul legitim. În locul unui cookie cu durată lungă, serverul poate utiliza cookie-uri cu viață mai scurtă, care devin mai greu de exploatat după expirare.

Este importantă limita tehnică. DBSC nu transformă fiecare cerere HTTP într-o operațiune semnată și nu face imposibilă reutilizarea unui cookie furat înainte de expirarea lui. De asemenea, dacă atacatorul controlează dispozitivul sau browserul victimei, poate continua să abuzeze mediul compromis. OWASP subliniază aceste diferențe în ghidul său despre mitigarea furtului de cookie-uri.

Din perspectiva arhitecturii, passkeys și DBSC rezolvă probleme complementare. Prima tehnologie protejează mai ales intrarea în cont, a doua încearcă să limiteze transferabilitatea sesiunii după autentificare. Adoptarea lor nu este identică între furnizori și aplicații. În 2026, organizațiile ar trebui să urmărească disponibilitatea reală, compatibilitatea și impactul asupra utilizatorilor, nu să presupună că protecția este activă peste tot.

Parola rămasă în spate poate compromite întregul model

Multe servicii oferă un passkey, dar păstrează parola ca alternativă imediată. În acest caz, contul poate fi atacat prin metoda cea mai slabă permisă. Dacă un atacator cunoaște parola și poate trece un factor suplimentar vulnerabil la phishing, existența passkey-ului nu blochează automat accesul. Este diferența dintre a adăuga o opțiune sigură și a elimina efectiv traseele nesigure.

Un flux de autentificare poate chiar descuraja utilizarea passkey-ului dacă afișează întâi câmpul de parolă sau codul de verificare. FIDO Alliance a remarcat această problemă în analiza din octombrie: unele servicii fac passkey-ul greu de descoperit, deși utilizatorul îl are deja configurat. Designul interfeței influențează astfel direct nivelul de securitate atins în practică.

Eliminarea parolei trebuie totuși făcută cu atenție. Nu toate conturile au un dispozitiv compatibil, iar persoanele care schimbă frecvent telefoane sau folosesc echipamente partajate pot avea nevoie de proceduri speciale. O platformă responsabilă oferă mai multe passkeys, recuperare verificabilă și comunicare clară, fără să reintroducă discret un cod ușor de interceptat drept scurtătură permanentă.

Recuperarea contului devine noua țintă

Imaginați-vă un utilizator care și-a protejat e-mailul cu o cheie hardware, dar poate recupera accesul printr-un apel la suport în care sunt cerute doar câteva date personale. Atacatorul nu mai are nevoie să spargă criptografia. Îi este suficient să convingă operatorul să schimbe metoda de autentificare. Acesta este motivul pentru care recuperarea trebuie evaluată cu aceeași seriozitate ca autentificarea normală.

Pentru conturile obișnuite, o rezervă practică poate însemna două dispozitive înregistrate și un proces de recuperare bine documentat. Pentru administratori, sunt utile aprobări separate, perioade de așteptare pentru schimbări sensibile, notificări independente și verificarea identității prin canale prestabilite. Niciuna dintre aceste măsuri nu este suficientă singură; împreună reduc probabilitatea unui transfer fraudulos de control.

Recuperarea trebuie testată înainte de incident. Un cont care nu poate fi recuperat după pierderea telefonului poate produce pierderi operaționale, iar presiunea de a-l debloca urgent încurajează excepțiile nesigure. Într-o organizație, echipa de suport are nevoie de reguli clare despre cine aprobă resetarea, ce dovezi sunt acceptate și cum sunt păstrate jurnalele acestor intervenții.

Ce se întâmplă când schimbi telefonul sau managerul de parole

Passkeys sincronizate sunt gândite să simplifice trecerea între dispozitive, dar experiența depinde de furnizor și de opțiunile de recuperare configurate. Unele ecosisteme oferă folosirea unui passkey de pe telefon pentru autentificarea pe un laptop apropiat. Acest flux nu înseamnă neapărat copierea cheii private pe laptop; dispozitivul care deține credențiala poate efectua operațiunea criptografică.

În 2025, Apple a prezentat mecanisme de import și export între manageri de credențiale participanți, printr-un schimb inițiat de utilizator și protejat prin autentificare locală. Documentația pentru dezvoltatori descrie API-urile de transfer. Totuși, suportul unei interfețe de sistem nu garantează că orice manager sau orice versiune de aplicație participă. Înainte de migrare, utilizatorul trebuie să verifice compatibilitatea și să păstreze o metodă de rezervă.

Pentru companii, problema este mai amplă: ce se întâmplă cu passkeys când un angajat pleacă, primește un dispozitiv nou sau își schimbă rolul? Politicile de identitate trebuie să permită revocarea credențialelor, închiderea sesiunilor și verificarea dispozitivelor rămase înregistrate. Migrarea tehnologică nu poate înlocui procesul de administrare a accesului pe întregul ciclu de viață al angajatului.

Passkeys pentru utilizatorii obișnuiți: unde să înceapă

Cea mai utilă ordine de adoptare începe cu e-mailul principal, contul care sincronizează dispozitivele, serviciile financiare și managerul de parole. Aceste conturi pot permite resetarea multor altora, deci compromiterea lor are efecte în lanț. Activarea passkey-ului se face din setările de securitate ale serviciului, după verificarea domeniului și a aplicației oficiale.

După configurare, merită verificat dacă există metode de autentificare vechi care pot fi dezactivate în siguranță. Nu eliminați singura cale de recuperare înainte de a înregistra un al doilea dispozitiv sau o rezervă acceptată de serviciu. Păstrați sistemul de operare și browserul actualizate, instalați aplicații din surse de încredere și limitați extensiile care au acces la paginile vizitate.

Un semnal de alarmă rămâne orice solicitare neașteptată de a aproba o autentificare. Passkeys nu cer trimiterea cheii private prin e-mail și nici introducerea unui cod de recuperare pe un site primit prin mesaj. Dacă apare o cerere suspectă, deschideți manual serviciul cunoscut, verificați sesiunile active și revocați accesul dispozitivelor necunoscute. Simplitatea noii metode nu elimină nevoia de verificări de bază.

Ce trebuie să facă administratorii Microsoft 365 și Google Workspace

În mediul enterprise, primul pas este inventarierea metodelor de autentificare existente: parole, SMS, TOTP, chei FIDO2, passkeys de platformă și conturi de serviciu. Politicile de acces condiționat trebuie să diferențieze utilizatorii obișnuiți de administratorii cu privilegii extinse. Pentru aceștia din urmă, autentificatoarele legate de dispozitive controlate și procedurile stricte de recuperare pot reduce riscurile cu impact mare.

O implementare reușită presupune campanii de înregistrare, verificarea compatibilității și măsurarea autentificărilor finalizate prin metode rezistente la phishing. Nu este suficient să numărăm utilizatorii care au creat o credențială; trebuie urmărit dacă o folosesc efectiv și dacă mai există fluxuri care permit conectarea prin metode mai slabe. Datele FIDO din 2026 arată tocmai diferența dintre disponibilitate și utilizare.

Pe lângă autentificare, administratorii trebuie să revizuiască sesiunile persistente, tokenurile OAuth, aplicațiile terțe și drepturile delegate. O aplicație conectată anterior poate avea acces la date chiar dacă parola utilizatorului nu mai este folosită. Sunt necesare politici de consimțământ pentru aplicații, expirare și revocare a tokenurilor, alerte de acces neobișnuit și proceduri de răspuns la compromiterea unui endpoint.

Pentru dezvoltatori: WebAuthn nu este un simplu buton

Adăugarea unui buton „Conectează-te cu passkey” nu finalizează proiectul. Backendul trebuie să gestioneze înregistrarea, provocările unice, verificarea semnăturilor, asocierea credențialelor cu utilizatorii și controlul originilor acceptate. Standardul W3C explică verificările pe care serviciul trebuie să le execute. Folosirea unei biblioteci mature și testate este preferabilă unei implementări criptografice improvizate.

Aplicația are nevoie și de interfețe pentru înregistrarea mai multor credențiale, redenumirea și eliminarea lor, autentificarea pe un dispozitiv nou și recuperarea contului. Operațiunile sensibile, precum schimbarea e-mailului sau adăugarea unui autentificator, trebuie să ceară verificări adecvate riscului. Jurnalele de audit trebuie să indice schimbările fără să stocheze secrete sau date biometrice inutile.

Pentru un site WordPress sau o aplicație Laravel, integrarea trebuie evaluată împreună cu sistemul de sesiuni, pluginurile și extensiile, politica CSP și mecanismele de actualizare. Passkeys nu rezolvă un plugin vulnerabil, un administrator cu privilegii excesive sau un cookie de sesiune configurat greșit. În continuarea analizelor AiZone despre securitatea datelor și dependențele software, acesta este exemplul unei protecții care funcționează numai într-o arhitectură coerentă.

Cookie-uri, expirare și revocare: partea invizibilă a securității

OWASP recomandă cookie-uri de sesiune cu atribute adecvate, inclusiv Secure și HttpOnly, și folosirea atentă a SameSite. Aceste controale reduc expunerea prin conexiuni nesigure, scripturi și anumite cereri între site-uri. Ele nu fac însă un cookie imposibil de furat prin malware sau prin compromiterea mediului. Protecția trebuie completată cu durate de viață limitate și validare pe server.

Un sistem robust invalidează sesiunile la deconectare, după schimbări de securitate și când există indicii de compromitere. Pentru acțiuni sensibile poate solicita o nouă autentificare, nu doar prezența unui cookie vechi. Detectarea schimbărilor de dispozitiv, locație sau comportament poate ajuta, dar trebuie calibrată: adresele IP se schimbă legitim, iar atacatorii pot imita unele caracteristici ale browserului.

Aici apare un compromis real între securitate și utilizabilitate. Sesiunile prea lungi cresc fereastra în care un token furat poate fi folosit; cele prea scurte întrerup activitatea și îi împing pe utilizatori spre soluții ocolitoare. Politica potrivită depinde de valoarea datelor, tipul dispozitivelor și nivelul de risc. Important este ca expirarea și revocarea să fie aplicate efectiv de server.

De ce autentificarea rezistentă la phishing nu elimină ingineria socială

Atacatorii se adaptează. Dacă nu mai pot cere o parolă reutilizabilă, pot încerca să convingă utilizatorul să instaleze un program, să autorizeze o aplicație OAuth malițioasă sau să sune la un număr fals de suport. Un passkey împiedică anumite transferuri de credențiale, dar nu poate decide singur dacă o solicitare de acces la fișiere sau o schimbare administrativă este legitimă.

Raportul Mandiant din 2026 arată importanța crescândă a ingineriei sociale prin voce în incidentele investigate în 2025. Acest lucru nu dovedește că fiecare atac folosește inteligență artificială sau că automatizarea este cauza principală. Arată însă că organizațiile trebuie să protejeze interacțiunile umane din jurul sistemelor de identitate, în special suportul tehnic și aprobarea accesului privilegiat.

O procedură bună nu se bazează pe recunoașterea vocii unui coleg sau pe urgența invocată într-un mesaj. Solicitările de resetare și acordare de privilegii trebuie validate prin canale independente, înregistrate și, când riscul o cere, aprobate de o a doua persoană. Într-un mediu cu passkeys, aceste procese devin mai importante, nu mai puțin importante.

Concluzie: sfârșitul parolei nu este sfârșitul atacului

Passkeys reprezintă un progres real. Înlocuiesc secretele reutilizabile cu dovezi criptografice asociate serviciului și reduc dependența de atenția utilizatorului în fața unei pagini false. Datele FIDO din octombrie 2026 indică o adoptare semnificativă în serviciile analizate, iar standardizarea W3C și schimbările Microsoft arată că ecosistemul se maturizează.

Ar fi însă o eroare să transformăm această evoluție într-o poveste despre securitate absolută. Un browser compromis, un token de sesiune furat, o integrare OAuth abuzivă sau o procedură de recuperare slabă pot ocoli protecția de la autentificare. Nu este un argument împotriva passkeys, ci unul pentru folosirea lor alături de protecția dispozitivelor, gestionarea sesiunilor și controale administrative solide.

Pentru utilizatori, pasul practic este activarea passkeys pe conturile importante și pregătirea unei metode de rezervă sigure. Pentru companii, adevărata reușită este reducerea tuturor traseelor de acces vulnerabile, nu doar înlocuirea unui formular de parolă. Internetul poate deveni mai sigur fără parole, dar numai dacă nu uităm ce se întâmplă după ce utilizatorul s-a conectat.

Surse și documentare

Documentarea a fost verificată la 29 octombrie 2026. Datele din 2025 citate în rapoartele publicate în 2026 sunt prezentate ca observații istorice, iar planurile pentru 2027 ca anunțuri, nu ca evenimente deja realizate.

• FIDO Alliance — Passkey Index 2026, 15 octombrie 2026
• FIDO Alliance — 7 Billion Passkeys and Counting, 15 octombrie 2026
• W3C — Web Authentication Level 3, 25 august 2026
• NIST — SP 800-63B-4, iulie 2025
• Microsoft — Passkeys default în Entra ID, 13 iulie 2026
• Microsoft Learn — Calendar retragere SMS/voce Entra ID
• Google Cloud / Mandiant — M-Trends 2026
• Google Cloud — Device Bound Session Credentials
• OWASP — Cookie Theft Mitigation Cheat Sheet
• OWASP — Session Management Cheat Sheet
• Apple Developer — What’s new in passkeys, WWDC 2025

About The Author