MFA 2026: FIDO2-vel a phishing ellen — a jelszó már nem elég

A magyar kkv-szektorban a jelszó-alapú hitelesítés dominanciája 2025-re strukturális kockázattá vált: az NKI 2025 harmadik negyedévi jelentése szerint a bejelentett incidenensek 61 százaléka kizárólag egyfaktoros jelszóval védett fiók ellen irányult, szemben a 2023-as 38 százalékkal. A növekedés oka nem a technológia romlása, hanem a támadók módszertani váltása: az adathalász kampányok ma már valós idejű, személyre szabott proxy-kiszolgálókkal dolgoznak, és a második faktorként használt SMS-kódot vagy push-értesítést is rutinosan kicsalják az áldozatból — ezt az ENISA 2025-ös éves jelentése az „MFA-fáradtság" (MFA fatigue, vagyis a felhasználó túlterhelése ismétlődő hitelesítési kérésekkel) és az „AiTM-adathalászat" (adversary-in-the-middle, vagyis közbeékelődéses támadás, ahol a támadó a felhasználó és a szolgáltatás közé ékelődve továbbítja a hitelesítési adatokat) kategóriákba sorolja.

A probléma gyökere, hogy a magyar szervezetek többsége a „valami plusz" elvén gondolkodik: bármilyen második faktor jobb, mint a jelszó önmagában. A valóságban azonban a második faktorok erőssége drasztikusan különbözik. Az SMS-alapú egykódos üzenet (OTP, vagyis one-time password) SIM-cserés támadással (SIM swap, amikor a támadó a szolgáltatónál átiratja a SIM-kártyát a saját eszközére) és SS7-protokoll-hibákkal (a telefonhálózat jelzésprotokollja, amelyen keresztül a támadó képes eltéríteni az SMS-forgalmat) kompromittálható, míg a push-alapú értesítés az MFA-fáradtság klasszikus célpontja. A FIDO2-protokoll ezzel szemben kriptográfiailag köti a hitelesítést a cél-doménhez: a privát kulcs soha nem hagyja el a hardvereszközt vagy a platform-hitelesítő biztonságos környezetét, így a közbeékelődéses támadás fizikailag lehetetlen.

A magyar szabályozási környezet 2026-tól egyértelműsíti a minimumot. A NIS2 irányelv (EU 2022/2555) 21. cikk (1) bekezdése a kockázatkezelési intézkedések között kifejezetten nevesíti a „többfaktoros hitelesítést vagy folyamatos hitelesítést" (multi-factor authentication or continuous authentication), míg a 21. cikk (2) bekezdése a kriptográfia alkalmazását írja elő. A 2024. évi kiberbiztonsági törvény ezt a hazai jogrendbe ültette, és a SZTFH mint nemzeti kiberbiztonsági hatóság 2026-tól auditálhatja az alapvető és fontos szervezetek — köztük a beszállítói láncon keresztül érintett KKV-k — megfelelését. Az ISO/IEC 27001:2022 A.8.5 szakasza („Secure authentication") ugyanezt a logikát követi a nemzetközi tanúsítási keretrendszerben.

Tehát a döntéshozó számára az üzenet: a „jelszó + bármi" megközelítés 2026-ban már nem elégséges sem jogi, sem technológiai értelemben. A tét a beszállítói lánc (supply chain) megőrzése: egy NIS2-hatály alá tartozó nagyvállalat 2026-tól nem működhet együtt olyan KKV-val, amely nem tud NIS2-kompatibilis hitelesítést garantálni a közös rendszerek eléréséhez. Ez nemzetgazdasági szinten a magyar KKV-szektor 30-40 százalékát érintheti a 2024. évi kiberbiztonsági törvény hatálya alá tartozó ágazatokon (energia, közlekedés, egészségügy, digitális infrastruktúra, gyártás) keresztül, becslésünk szerint.

Az átállás nem egyetlen nagy projekt, hanem három fázisra bontható, és a NIS2 2026-os határideje figyelembevételével 90-180 napos tervvel reálisan megvalósítható. Az első fázis (0-30 nap) a hatókör-meghatározás (scope): azonosítani kell minden olyan rendszert, amely külső vagy belső hozzáférést igényel — levelezés, VPN, felhőalkalmazások, ERP, belső admin-konzolok, fejlesztői rendszerek. Az ENISA ajánlása szerint a scope-ot a „crown jewel" (legértékesebb üzleti rendszer) analógiára kell építeni: onnan indulunk, ahol egy kompromittálódás a legnagyobb üzleti kárt okozná.

A második fázis (30-90 nap) a szabályalapú (policy) és technológiai kiválasztás. A döntéshozónak három kérdésre kell válaszolnia: kik a felhasználók (alkalmazottak, alvállalkozók, ügyfelek), milyen eszközöket használnak (vállalati, BYOD, mobilos), és milyen kockázati szintű rendszerekhez férnek hozzá. A NIS2 hatálya alá tartozó alapvető szervezeteknél (energia, közlekedés, egészségügy, bankszektor) a FIDO2-hardverkulcs kötelező a privilegizált hozzáféréseknél (privileged access, vagyis rendszergazdai és magas jogosultságú fiókok), míg a fontos szervezeteknél és a nem-kritikus felhasználóknál a platform-hitelesítő (Windows Hello, Touch ID) is elfogadható. A szabályzatot az ISO/IEC 27001 A.5.16 (identitáskezelés) és A.8.5 (biztonságos hitelesítés) szakaszokkal összhangban kell dokumentálni.

A harmadik fázis (90-180 nap) a bevezetés és a felhasználói tudatosítás (awareness training). A FIDO2 bevezetésének tipikus buktatója, hogy a szervezet kihagyja a felhasználói élmény-tervezést: a kulcs regisztrációja, az elvesztés-kezelési eljárás és a tartalék hozzáférési útvonal (recovery path, vagyis vészhelyzeti belépési módszer) mind előre definiálandó. Az NKI 2025-ös oktatási anyaga szerint a felhasználók 70-80 százaléka elfogadja a biometrikus vagy hardverkulcsos hitelesítést, ha az egyszerűbb és gyorsabb, mint a jelszó — az üzenet tehát a „könnyebb és biztonságosabb" narratíva, nem a „kevesebb kényelem".

A költségvetési modell egy 50 fős magyar KKV esetén: 50 db YubiKey 5 NFC beszerzése 1,4 millió forint (átlagos, kiskereskedelmi ár 28 000 Ft/db), a bevezetés IT-tanácsadói költsége 1,2-2,5 millió forint (becslésünk, közép-magyar szolgáltatói áron), a felhasználói képzés belső időráfordítása 40-60 óra. Alternatívaként a Windows Hello és Touch ID használata 0 forint hardverköltséggel jár, de a platform-hitelesítő kockázata, hogy elveszett vagy ellopott eszközzel a támadó hozzáférhet a fiókhoz — ez kiküszöbölhető a Microsoft Entra ID vagy a Google Workspace device-bound (eszközhöz kötött) hitelesítési szabályaival.

Az első és legkritikusabb hiba a „scope-ot nem definiálunk" hozzáállás: sok magyar szervezet csak a levelezést és a VPN-t vonja be az MFA-projektbe, miközben az ERP, a fejlesztői Git-repo, a felhőalapú tároló (pl. AWS, Azure) és a belső admin-konzolok továbbra is jelszóval védettek. Az NKI 2025-ös incidens-statisztikái szerint a sikeres kompromittálódások 40 százaléka olyan rendszeren történt, amelyet a szervezet „nem tartott fontosnak" — jellemzően egy régi, felhagyott, de nem kikapcsolt admin-fiókon. A scope-ot kockázat-alapon, a „crown jewel" módszerrel kell definiálni.

A második hiba a második faktor erősségének alulbecslése. Számos KKV bevezet SMS- vagy push-alapú második faktort, és ezt „NIS2-kompatibilisnek" tekinti — ez technikailag igaz, de a NIS2 21. cikk (2) bekezdésében foglalt kriptográfiai elvárásnak nem felel meg maradéktalanul. Az ENISA 2025-ös phishing-jelentése szerint az AiTM-támadások 2024-ben 35 százalékkal nőttek, és ezek kifejezetten az SMS-/push-alapú második faktort célozzák. Az audit-szempontú megközelítés: ha a második faktor kriptográfiailag nem kötött a cél-doménhez (mint a FIDO2), akkor a kontroll gyenge, és az auditor ezt jelölni fogja.

A harmadik hiba a recovery-eljárás hiánya. Mi történik, ha az alkalmazott elveszíti a hardverkulcsot? Mi történik, ha a biometrikus szenzor meghibásodik? Ha nincs dokumentált, biztonságos recovery-flow (helyreállítási eljárás), a felhasználó vagy a helpdesk kénytelen „kikapcsolni az MFA-t" — ez a gyakorlatban a teljes kontroll kikerülését jelenti. A Microsoft és a Google ajánlása szerint minden FIDO2-bevezetéshez legalább két regisztrált kulcs szükséges felhasználónként (elsődleges és tartalék), valamint egy out-of-band (független csatornán, pl. személyes azonosítással történő) recovery-eljárás a hitelesítő elvesztése esetére.

A negyedik hiba a felhasználói élmény figyelmen kívül hagyása. Ha a FIDO2-bevezetés lassabb, kényelmetlenebb vagy zavarosabb, mint a jelszó, a felhasználók „megkerülik": megosztják a kulcsot, leírják a PIN-kódot a monitorra, vagy a helpdesktől kérik az MFA kikapcsolását. Az NKI 2025-ös kutatása szerint a shadow IT (a szervezet IT-osztálya által nem engedélyezett, de a munkavállalók által használt eszközök és szolgáltatások) aránya 25-30 százalék a magyar KKV-knál — ez a kontroll-kikerülés egyik fő oka. A sikeres bevezetés feltétele, hogy a biztonságos útvonal legyen a legkönnyebb útvonal.

Az auditálható NIS2-megfelelőség 2026-ban a magyar KKV-k számára három konkrét döntési lépcsőben foglalható össze. Az első lépcső (0-30 nap): készítsen kockázat-alapú scope-dokumentumot, amely azonosítja az összes külső és belső hozzáférési pontot, kockázati szint szerint rangsorolja azokat, és meghatározza a „crown jewel" rendszereket. Ez a dokumentum egyben a SZTFH-audit alapja is lesz. Az ENISA 2025-ös útmutatója szerint a scope-dokumentumot a vezetőtestületnek kell jóváhagynia, nem csupán az IT-osztálynak.

A második lépcső (30-90 nap): válasszon MFA-platformot. Három érett megoldás érhető el a magyar piacon: a Microsoft Entra ID (korábbi nevén Azure AD), a Google Workspace, illetve az Okta. A választás a meglévő IT-ökoszisztémától függ — Microsoft-környezetben az Entra ID, Google-környezetben a Workspace, hibrid környezetben az Okta a legkézenfekvőbb. Mindhárom támogatja a FIDO2-t natívan, és tartalmaz conditional access (feltételes hozzáférés, vagyis a beléptetési döntés kontextus-alapú szabályai) szabályokat is — például hogy VPN-en kívülről csak FIDO2-vel lehessen belépni.

A harmadik lépcső (90-180 nap): indítson 20 fős pilotot, mérje a felhasználói elfogadást és a helpdesk-terhelést, majd indítson teljes szervezeti rollout-ot. A pilot tanulságait dokumentálja — a SZTFH audit során ez lesz a „működő kontroll" bizonyítéka. Az ISO/IEC 27001 tanúsítvány megléte nem kötelező, de a tanúsítási folyamat önmagában strukturált MFA-dokumentációt kényszerít ki, ami auditáláskor előnyt jelent.

A „holnap" konkrét lépése: a KKV döntéshozója hívjon össze egy 90 perces workshopot az IT-csapattal, a jogi tanácsadóval és a beszállítói kapcsolatokért felelős vezetővel. A workshop célja a scope-dokumentum első vázlatának elkészítése, az MFA-platform kiválasztása, és a 2026-os audit-naptár összeállítása. Ez a 90 perc az egyetlen költsége egy olyan döntéssorozatnak, amely az elkövetkező 3-5 évben meghatározza a szervezet kiberbiztonsági pozícióját — és egyben a NIS2 2026-os auditjának sikerét vagy kudarcát.