Passkeys za firme (2026): kako preći na phishing-resistant MFA bez haosa

Većina napada ne počinje „naprednim hakovanjem“. Počinje kompromitovanim kredencijalima—ukradenim, prevarenim ili ponovo korišćenim lozinkama. Klasičan MFA pomaže, ali phishing kampanje i proxy napadi sve češće uspevaju da zaobiđu slabije druge faktore.

Passkeys su najpraktičniji korak ka phishing-resistant autentifikaciji. Kada su dobro uvedeni, smanjuju rizik krađe naloga, rasterećuju helpdesk i olakšavaju korisničko iskustvo. Kada su loše uvedeni, prave lockout-e, stvaraju shadow IT i na kraju vraćaju firmu na lozinke.

U ovom vodiču objašnjavamo šta passkeys znače u enterprise okruženju i kako da ih uvedete uz plan: politike, uređaji, recovery, legacy sistemi i merljivi efekat.

Šta su passkeys (u poslovnom smislu)

Passkey je moderan kredencijal zasnovan na public-key kriptografiji. Umesto lozinke koja se kuca (pa može da se „ukrade“ preko phishing-a), korisnik dokazuje posed privatnog ključa na uređaju (ili bezbedno sinhronizovanog ključa), i potvrđuje login lokalno—biometrijom ili PIN-om uređaja.

• Ne kuca se deljeni „tajni“ string u web formu, što smanjuje klasičan phishing
• Autentifikacija je vezana za legitiman domen servisa
• Korisnici ne moraju da pamte i recikliraju lozinke za passkey-enabled aplikacije

Passkeys nisu samo „jedna opcija u meniju“. One dodiruju identitet, device management, access politike i podršku. Zato migracija mora biti strukturisana.

Zašto su passkeys aktuelne baš sada

Mnoge firme već imaju MFA preko SMS-a, TOTP aplikacija ili push potvrda. To je bolje nego ništa, ali ostavlja rupe: neki faktori se i dalje mogu isposlovati phishing-om ili socijalnim inženjeringom, a push potvrde često stradaju zbog „prompt fatigue“.

Passkeys uklanjaju najveći problem: nema kucanja tajne u web stranicu. U praksi to znači manje account takeover-a, manje resetova, i veće poverenje u admin pristup.

Dva modela u firmama: synced i device-bound passkeys

U praksi postoje dva glavna modela:

• Synced passkeys: dostupne na više uređaja korisnika (odlično UX, ali zahteva jasne politike).
• Device-bound passkeys / hardware keys: vezane za konkretan uređaj ili fizički ključ (jača kontrola, idealno za admin-e).

Najčešće najbolja praksa je hibrid: synced za većinu zaposlenih, a hardware/device-bound za administratore i break-glass scenarije.

Gde rollout najčešće pukne

Passkeys ne pucaju zbog kriptografije. Pucaju zbog operativnih detalja. Najčešći problemi su:

• Mešovit fleet uređaja (managed/unmanaged, deljeni računari, BYOD, stariji OS)
• Legacy aplikacije koje ne podržavaju modern auth
• Recovery: izgubljen telefon/laptop, zamena uređaja, putovanja
• Helpdesk nije spreman (identity proofing, procedure, audit trail)
• Privileged access: admin-i moraju biti jače zaštićeni nego standardni korisnici

Kako izgleda dobar rollout: passkeys kao politika, ne kao „feature“

Cilj nije „sutra svi koriste passkeys“. Cilj je kontrolisana migracija gde jačina autentifikacije raste, rizik pada merljivo, a korisnici imaju pouzdan način povratka bez slabljenja bezbednosti.

Dobar rollout stoji na 5 stubova: politike identiteta, uređaji, recovery, privileged access i observability.

Stub 1: Politike identiteta (Conditional Access logika)

Definišite gde su passkeys obavezne, gde su opcione i koje izuzetke dozvoljavate. Politike moraju biti realne.

• Krenite od high-risk aplikacija (email, VPN/remote access, admin portali, finansijski alati)
• Za privilegovane role zahtevajte phishing-resistant metode
• Postepeno uklanjajte slabe faktore (npr. SMS) gde poslovanje može da izdrži
• Definišite pravila za unmanaged uređaje (ograničenja ili jači faktori)

Stub 2: Uređaji (MDM, enrollment, deljeni računari)

Passkeys pretpostavljaju uređaj koji može bezbedno da čuva ključeve. Zato treba da imate jasan stav o device management-u:

• Managed uređaji: MDM baseline, politika update-a, obavezno zaključavanje ekrana
• Unmanaged uređaji: limitirajte na niži rizik ili tražite jači faktor
• Deljeni uređaji/kiosci: preferirajte hardware keys ili specifične enterprise tokove prijave
• Admin uređaji: tretirajte kao privilegovane endpoint-e sa strožim kontrolama

Stub 3: Recovery bez slabljenja bezbednosti

Recovery je tačka gde rollout najčešće puca. Ako je jedini recovery „isključi passkeys“ ili „resetuj sve“, korisnici gube poverenje. Recovery mora postojati pre enforcement-a.

• Definišite identity proofing za helpdesk (šta je dovoljno jak dokaz identiteta)
• Obezbedite bar dve opcije oporavka (sekundarni uređaj, hardware key, recovery kodovi)
• Koristite vremenski ograničen „temporary access“ umesto trajnog downgrade-a politika
• Auditujte svaki recovery (ko, kada, zašto, odobrenje)

Stub 4: Privileged access i break-glass

Admin-i i emergency pristup moraju biti jači od standardnog logina. To je ključ u incidentima.

• Za admin role obavezno phishing-resistant autentifikovanje
• Za kritične sisteme koristite hardware keys ili device-bound passkeys
• Break-glass nalozi: stroge kontrole, sigurno skladištenje, monitoring, minimalna upotreba
• Ograničite stalne admin privilegije; koristite privremenu eskalaciju gde je moguće

Stub 5: Observability – kako da dokažete napredak

Program postaje ozbiljan kada možete da pokažete rezultate. Pratite i adoption i ishode.

• Stopa usvajanja passkeys po timovima i rolama
• Broj resetova lozinke i lockout-a (pre/posle)
• Sumnjivi login pokušaji i phishing incidenti (pre/posle)
• Broj izuzetaka (exception) i zahteva za bypass
• Vreme oporavka naloga (time-to-recover)

Tabela: metode autentifikacije u rollout strategiji

Praktičan plan: 0–30 / 31–60 / 61–120 dana

Fazni pristup smanjuje rizik, sprečava helpdesk „špic“ i čuva kontinuitet.

• 0–30 dana (Dizajn): inventar aplikacija, politike, pilot grupa, recovery procesi, obuka helpdesk-a
• 31–60 dana (Pilot): aktivacija passkeys, merenje lockout-a, popravka device gap-ova, dokumentovanje problema
• 61–120 dana (Skaliranje): širenje po timovima, enforcement za high-risk aplikacije, jačanje admin pristupa, smanjenje legacy MFA

Legacy aplikacije: ne dozvoli da stari stack blokira ceo program

Skoro svaka firma ima aplikacije koje ne podržavaju moderan auth. Greška je čekati „savršeno stanje“. Umesto toga: segmentacija i izolacija.

• Stavite legacy iza modernog identiteta (SSO gateway, VPN/ZTNA, proxy gde ima smisla)
• Ograničite pristup po device posture i lokaciji
• Povećajte monitoring i logovanje oko legacy auth-a
• Napravite backlog migracije sa vlasnicima biznisa i rokovima

Najčešće greške

• Enforcement pre recovery procesa
• Admin pristup tretiran isto kao običan korisnik
• Ignorisanje deljenih uređaja i terenskih radnika
• Neograničeni izuzeci (npr. SMS zauvek) bez plana uklanjanja
• Merenje samo adoption-a, a ne ishoda (manje resetova, manje sumnjivih login-a)

Zaključak: passkeys su i bezbednosni upgrade i operativni projekat

Passkeys mogu značajno smanjiti phishing rizik, ali enterprise uspeh zavisi od discipline: politike, uređaji, recovery, privileged access i dokaziv napredak.

Ako passkeys tretirate kao migraciju (kao email security ili endpoint hardening), dobićete i jaču bezbednost i manje svakodnevnih problema sa logovanjem.