Windows Hello: Lösenordslös autentisering förklarad

Windows Hello är Microsofts inbyggda lösenordsfria autentiseringsramverk för Windows 10 och 11, vilket gör det möjligt för användare att logga in med biometri (ansikte, fingeravtryck eller iris) eller en PIN-kod som backas upp av kryptografiska nycklar lagrade i enhetens Trusted Platform Module (TPM). Till skillnad från lösenord lämnar Windows Hello-inloggningsuppgifter aldrig enheten och är kryptografiskt bundna till den lokala hårdvaran, vilket gör dem motståndskraftiga mot nätfiske, stöld av inloggningsuppgifter och replay-attacker. Windows Hello för företag utökar denna funktion till företagsmiljöer och stöder Microsoft Entra ID, Active Directory och FIDO2-lösenordsautentisering via tre distributionsförtroendemodeller.

Key Takeaways

• Det finns ingen direkt migreringsväg från en certifikatförtroendedistribution till Cloud Kerberos Trust. Den befintliga Windows Hello-behållaren måste tas bort innan en enhet kan flyttas till Cloud Kerberos Trust.
• Windows Hello ersätter lösenord med ett TPM-baserat asymmetriskt nyckelpar. Den privata nyckeln lämnar aldrig enheten, så det finns ingen delad hemlighet att nätfiska, stjäla eller spela upp.
• Windows Hello för företag (WHfB) stöder tre företagsförtroendemodeller: Cloud Kerberos Trust, Key Trust och Certificate Trust. Cloud Kerberos Trust är Microsofts rekommenderade standard för hybriddistributioner.
• Konton i privilegierade Active Directory-grupper, inklusive domänadministratörer, kan inte autentiseras via Cloud Kerberos Trust avsiktligt, eftersom lösenordsreplikeringsprincipen på AzureADKerberos-objektet blockerar dem.
• Microsoft Entra-lösenord på Windows blev allmänt tillgängliga 2026, vilket gör att Windows Hello fungerar som en FIDO2-lösenordsautentiserare på enheter som inte är Entra-anslutna.

Varför lösenord inte längre är tillräckliga

Enligt Microsofts rapport om digitalt försvar 2024 blockerar flerfaktorsautentisering över 99 % av identitetsbaserade attacker, men lösenordssprayning, inloggningsuppgifter och nätfiskekampanjer fortsätter att stå för majoriteten av de initiala åtkomsthändelserna i Microsofts globala telemetri, som registrerade mer än 7 000 lösenordsattacker per sekund under det senaste året. Kärnproblemet är strukturellt: lösenord är delade hemligheter. De färdas över nätverk, lagras i databaser och återanvänds rutinmässigt mellan tjänster. Varje enskild kompromiss kan leda till flera kontoövertaganden.

De fem fellägena för lösenordsbaserad autentisering är väl dokumenterade och ihållande:

• Brute-force- och dictionary-attacker som utnyttjar svaga eller återanvända inloggningsuppgifter.
• Nätfiskekampanjer som lurar användare att ange inloggningsuppgifter till förfalskade webbplatser.
• Inloggningsuppgifter som utnyttjar lösenord som läckt från orelaterade intrång.
• Lösenordsdatabasstöld som exponerar hashade inloggningsuppgifter för offline-knäckning.
• Tillgänglighetshinder som missgynnar användare med synnedsättningar eller motoriska begränsningar.

Windows Hello åtgärdar alla fem fellägen genom att ersätta den delade hemlighetsmodellen med en enhetsbunden, asymmetrisk kryptografisk autentiseringsuppgift som inte kan phishas, ​​replikeras eller överföras.

Vad är Windows Hello?

Windows Hello är Microsofts biometriska och PIN-baserade autentisering ramverket, introducerat i Windows 10 och utökat avsevärt i Windows 11. Det ersätter lösenordsinmatning med en av tre biometriska gester: ansiktsigenkänning, fingeravtrycksskanning eller irisskanning, beroende på enhetens hårdvarukapacitet. En PIN-kod stöds också som en reservmetod eller primär metod; kritiskt nog skiljer sig denna PIN-kod från ett lösenord genom att den är enhetsspecifik och backas upp av TPM snarare än att överföras till en server.

Windows Hello finns i två nivåer:

Leverans	Windows Hello (Konsument)	Windows Hello för företag (WHfB)
Målanvändare	Personligt konto / Microsoft-konto	Företags-/Entra-ID eller AD
Inloggningstyp	Enhetsbunden nyckel (programvara om ingen TPM)	TPM-stödda asymmetriska nyckelpar (krävs enligt policy)
Identitetsleverantör	Microsoft-konto (MSA)	Microsoft Entra ID, Active Directory, AD FS
FIDO2-stöd	Ja, FIDO Alliance-certifierad sedan Windows 10 1903	Ja, gäller även Entra-lösenordet (FIDO2) från 2026
Företagspolicy (Intune/GPO)	Begränsad	Fullständigt stöd för MDM/Grupppolicy
Resursåtkomst på plats	Stöds inte	Ja, via Cloud Kerberos Trust eller Certifikat Litar

Så här fungerar Windows Hello: Kryptografiska stiftelsen

För att förstå Windows Hello krävs det att man förstår hur lösenordsmodellen ersätts med kryptografi med offentlig nyckel. Under registreringen genererar enheten ett asymmetriskt nyckelpar.

Nyckelgenerering och lagring

• TPM genererar ett privat och ett offentligt nyckelpar för användaren på den enheten.
• Den privata nyckeln är förseglad inuti TPM:n och exporteras aldrig. Den kan inte extraheras, inte ens av operativsystemet.
• Den offentliga nyckeln är registrerad hos identitetsleverantören (Microsoft Entra ID, Active Directory eller AD FS) och associerad med användarkontot.
• Biometriska data (mall för ansiktsuttryck, fingeravtryck) lagras lokalt i en krypterad databas på C:\Windows\System32\WinBioDatabase. De lämnar aldrig enheten och överförs aldrig till Microsofts servrar.

Autentiseringsflöde

När en användare loggar in är sekvensen:

1. Användaren presenterar en biometrisk gest eller PIN-kod för Windows Hello-behållaren.
2. Gesten låser upp åtkomst till den privata nyckeln som lagras i TPM:n. PIN-koden eller biometriska koden fungerar som en lokal upplåsningsfaktor och lämnar aldrig enheten.
3. Enheten använder den privata nyckeln för att signera en kryptografisk utmaning från identitetsleverantören.
4. Identitetsleverantören verifierar signaturen med den registrerade publika nyckeln och utfärdar en autentiseringstoken.
5. Användaren får åtkomst till Windows, Microsoft 365, Entra-skyddade appar och, under WHfB, lokala resurser.

Eftersom den privata nyckeln är bunden till TPM:n och PIN-koden eller biometrin aldrig lämnar enheten, eliminerar den här autentiseringsmodellen attackvektorer som riktar sig mot lösenord. Det finns ingen autentiseringsuppgift för nätfiske, ingen databas att bryta sig in i och ingen nätverksöverförd hemlighet att avlyssna.

Förbättrad inloggningssäkerhet (ESS)

Windows 11 introducerar Enhanced Sign-in Security (ESS), som isolerar matchning av ansikten och mallar inuti en virtualiseringsbaserad säkerhetsenklav (VBS) som etablerar en säker kanal till TPM 2.0 under start. För fingeravtryck förlitar sig ESS på matchningshårdvara på sensorer som utför matchning och malllagring på själva sensormodulen.

Under ESS kan inte ens en komprometterad operativsystemkärna komma åt biometriska malldata eller injicera förfalskade biometriska signaler. ESS kräver specialbyggda biometriska sensorer och verkställs via en policy för miljöer med hög säkerhet.

Windows Hello för företag: Modeller för företagsdistribution

För organisationer som distribuerar Windows Hello för företag stöder Microsoft tre förtroendemodeller. Att välja rätt modell beror på katalogtopologi, befintlig PKI-infrastrukturoch krav för åtkomst på plats.

Trust Model	Så fungerar det	bäst för
Moln Kerberos-förtroende	Använder Microsoft Entra Kerberos för att utfärda partiella TGT:er. Ingen PKI- eller nyckelsynkronisering krävs.	Hybrida och rena Entra-anslutna miljöer. Microsofts rekommenderade standard för nya distributioner.
Viktigt förtroende	Publik nyckel lagrad i Active Directory. Dominokontroller kräver Kerberos-autentiseringscertifikat; Entra Connect synkroniserar nycklar.	Hybridmiljöer med en befintlig företags-PKI som kan utfärda DC-certifikat.
Certifikat Litar	AD FS utfärdar inloggningscertifikat till WHfB-behållaren. Fullständig PKI-infrastruktur krävs lokalt.	Organisationer som kräver certifikatbaserad smartkortsekvivalens eller RDP/VDI-scenarier som behöver användarcertifikat.

Cloud Kerberos Trust: Den rekommenderade vägen

Cloud Kerberos Trust, som introducerades 2022, tar bort de två största hindren för WHfB-implementering: behovet av en fullständig lokal PKI och behovet av att synkronisera publika nycklar till Active Directory. Istället utnyttjar det samma Entra Kerberos-infrastruktur som redan möjliggör lösenordsfri FIDO2-inloggning för hybridmiljöer. Administratörer konfigurerar det med ett enda PowerShell-kommando för att skapa AzureADKerberos-objektet, följt av två Intune-policyer eller GPO:er.

Autentiseringsflödet under Cloud Kerberos Trust: när en användare låser upp sin enhet med en PIN-kod eller biometrisk kod, släpper TPM:n den privata WHfB-nyckeln, som signerar en autentiseringsbegäran till Entra ID. Entra ID returnerar en partiell TGT, en molnutfärdad Kerberos-biljett, som domänkontrollanten byter mot en fullständig lokal Kerberos TGT, vilket beviljar SSO till lokala resurser som filresurser och intranätapplikationer utan en andra inloggningsfråga. Inget lösenord är involverat i något skede.

Två operativa begränsningar gäller. För det första kan konton som är direkta eller indirekta medlemmar i privilegierade inbyggda säkerhetsgrupper, inklusive domänadministratörer, inte autentisera via Cloud Kerberos Trust. AzureADKerberos-objektet fungerar som en skrivskyddad domänkontrollant, och dess standardpolicy för lösenordsreplikering blockerar privilegierade konton från att använda det, samma begränsning som gäller för vanliga RODC:er.

Microsoft avråder från att lätta på denna policy på grund av den attackväg den skulle öppna mellan Entra ID och Active Directory. För det andra stöder Cloud Kerberos Trust inte RDP- eller VDI-inloggning med angivna autentiseringsuppgifter; organisationer som behöver certifikatbaserad smartkortsekvivalens för dessa scenarier bör istället använda Certificate Trust eller Remote Credential Guard.

Distributioner av certifikatförtroende kräver en fungerande företags-PKI för att utfärda både domänkontrollantcertifikat och valfria användarinloggningscertifikat. Encryption Consultings PKI-tjänster tillhandahåller heltäckande PKI-design, implementering och hanterade tjänster för IT-miljöer, inklusive CA-hierarkin, certifikatmallar och Intune-integration som krävs för en WHfB-distribution av certifikatförtroende.

Windows Hello-, FIDO2- och Entra-lösenord

Windows Hello har varit FIDO2-certifierat av FIDO Alliance sedan Windows 10 version 1903. Det innebär att Windows Hello fungerar som en plattformsautentiserare som är kompatibel med WebAuthn- och CTAP2-specifikationerna, samma öppna standarder som ligger till grund för lösennycklar i webbläsare, operativsystem och identitetsleverantörer.

Windows Hello som en FIDO2-plattformsautentiserare

När en webbplats eller applikation begär FIDO2 autentiseringWindows Hello fungerar som lokal autentiserare. Den genererar ett FIDO2-nyckelpar i Windows Hello-nyckelbehållaren, skyddar den privata nyckeln med TPM och släpper den först efter att användaren har uppfyllt den lokala biometriska kontrollen eller PIN-kontrollen. Resultatet är en enhetsbunden lösennyckel som inte kan nätfiskas eftersom den är kryptografiskt bunden till ett specifikt ursprung, webbplatsens domän, vilket förhindrar att den fungerar på någon förfalskad inloggningssida.

Windows Hello har varit FIDO2-certifierat av FIDO Alliance sedan Windows 10 version 1903. Det innebär att Windows Hello fungerar som en plattformsautentiserare som är kompatibel med WebAuthn- och CTAP2-specifikationerna, samma öppna standarder som ligger till grund för lösennycklar i webbläsare, operativsystem och identitetsleverantörer.

Ange lösenord via Windows Hello (2026)

Microsoft påbörjade en stegvis utrullning av Microsoft Entra-lösenord på Windows i offentlig förhandsvisning i mars 2026, vilket förlängde lösenordsfri autentisering till Windows-enheter som inte är Entra-anslutna eller hanterade. Funktionen har sedan dess blivit allmänt tillgänglig och rullas ut över hela världen under första halvan av 2026 och till amerikanska myndigheters molnmiljöer (GCC, GCC High och DoD) under de följande månaderna. Vid den allmänna tillgängligheten tog Microsoft bort kravet på den offentliga förhandsgranskningen att administratörer uttryckligen skulle tillåta att Windows Hello AAGUID:er listas i en lösenordsnyckelprofil; organisationer vars lösenordsprofiler redan tillåter enhetsbundna, icke-attesterade lösenord har nu Entra-lösenord på Windows aktiverade som standard.

Med den här konfigurationen registrerar användare en enhetsbunden lösenkod som lagras i Windows Hello-behållaren, autentiserad med ansikte, fingeravtryck eller PIN-kod. Lösenordet är kryptografiskt bunden till enheten och överförs aldrig över nätverket, vilket gör den immun mot nätfiske och attacker med inloggningsuppgifter.

Viktiga detaljer om Entra-lösenordsintegrationen:

• Varje Entra-konto registrerar sin egen lösenordsnyckel per enhet. Flera konton kan samexistera på en och samma maskin.
• Lösenord är enhetsbundna och kan inte synkroniseras mellan enheter. Varje enhet kräver separat registrering.
• Windows Hello för företag är fortfarande den rekommenderade metoden för hanterade, Entra-anslutna enheter. Entra-lösenord på Windows kompletterar ohanterade enhetsscenarier och stöder inte enhetsinloggning.
• En WHfB-autentiseringsuppgift och en Entra-lösenordsnyckel kan inte samexistera i samma behållare för samma konto. Om en WHfB-autentiseringsuppgift finns blockeras registreringen av lösenordet tills den tas bort, så WHfB prioriteras på hanterade enheter. Microsoft noterar att denna blockering kan upphävas när en användares sammanlagda antal lösenord, WHfB-autentiseringsuppgifter och Mac-plattformsautentiseringsuppgifter på enheten överstiger 50, ett marginalfall med hög volym som sannolikt inte påverkar typiska enheter med ett konto eller få konton.

Windows Hello kontra FIDO2-säkerhetsnycklar

Dimensionera	Windows Hello (plattformsautentiserare)	FIDO2-säkerhetsnyckel (roamingautentiserare)
Portabilitet	Enhetsbunden. Användaren måste registrera sig på nytt på varje enhet.	Bärbar mellan enheter via USB, NFC eller Bluetooth
Ideal användare	Tilldelade enhetsarbetare, kunskapsarbetare	Frontlinjearbetare, miljöer med delade enheter
Infrastrukturkostnad	Ingen hårdvaruköp krävs (använder befintlig TPM)	Köp av fysisk nyckel krävs per användare
PKI-krav	Valfritt (endast certifikatförtroendemodell)	Ingen
RDP/VDI-inloggning	Stöds med Remote Credential Guard eller Certificate Trust	Stöds via webbinloggning på Windows 11 24H2 och Windows Server 2025

Säkerhets- och driftsfördelar

Nätfiskemotstånd

Windows Hello-autentiseringsuppgifter är kryptografiskt bundna till den förlitande partens ursprung, webbplatsens domän eller identitetsleverantören. En autentiseringsuppgift som är registrerad för login.microsoftonline.com svarar inte på en utmaning från en förfalskad lookalike-domän. Denna ursprungsbindande egenskap, som definieras i WebAuthn-specifikationen, är den främsta anledningen till att nätfiskeattacker är ineffektiva mot FIDO2- och Windows Hello-autentisering.

Ingen risk med referensdatabasen

Eftersom ingen delad hemlighet lagras på serversidan finns det ingen lösenordshash eller autentiseringsuppgifter att stjäla från identitetsleverantören. Servern lagrar endast användarens offentliga nyckel, vilken är värdelös för en angripare utan åtkomst till motsvarande privata nyckel som är förseglad i enhetens TPM.

Masterexamen genom design

Windows Hello är i sig multifaktoriellt. Det kombinerar något du har, den registrerade enheten med den TPM-bundna nyckeln, med något du är, en biometrisk enhet, eller något du vet, en enhetslokal PIN-kod. Detta uppfyller MFA-kraven enligt NIST SP 800-63B Authenticator Assurance Level 2 (AAL2) för de flesta företagsanvändningsfall. Miljöer med hög assurans som kräver AAL3 kan framtvinga TPM-attestering via policy och verifiera att nyckeln finns i certifierad hårdvara.

Nätfiskemotstånd

Tillgänglighet och användarupplevelse

Biometrisk inloggning tar bort hinder för användare som kämpar med lösenordsinmatning. Ansiktsigenkänning möjliggör handsfree-autentisering, och den enhetslokala karaktären hos Windows Hello innebär att inga servrar kan vara otillgängliga under ett avbrott. Microsoft rapporterar att organisationer som har gått över till Windows Hello ser mätbara minskningar av helpdesksamtal relaterade till lösenordsåterställningar, en av de IT-supportkategorier som har störst volym.

FIDO2 SSO över applikationer

Windows Hello-inloggningsuppgifter fungerar i alla applikationer eller webbplatser som stöder FIDO2/WebAuthn, inklusive Microsoft 365, Azure-skyddade appar, GitHub, Dropbox, finansiella tjänsteplattformar och ett växande ekosystem av SaaS-applikationer för företag. I företagsdistributioner tillhandahåller WHfB enkel inloggning till både moln- och lokala resurser via Kerberos, utan att användare behöver autentisera om för varje tjänst.

Tillgänglighet och användarupplevelse

Biometrisk inloggning tar bort hinder för användare som kämpar med lösenordsinmatning. Ansiktsigenkänning möjliggör i synnerhet handsfree-autentisering, och den enhetslokala karaktären hos Windows Hello innebär att inga servrar kan vara otillgängliga under ett avbrott. Microsoft rapporterar att organisationer som har gått över till Windows Hello ser mätbara minskningar av helpdesksamtal relaterade till lösenordsåterställningar, en av de IT-supportkategorier som har störst volym.

FIDO2 SSO över olika applikationer

Windows Hello-inloggningsuppgifter fungerar i alla program eller webbplatser som stöder FIDO2/WebAuthn, inklusive Microsoft 365, Azure-skyddade appar, GitHub, Dropbox, finansiella tjänsteplattformar och ett växande ekosystem av SaaS-program för företag. I företagsdistributioner tillhandahåller WHfB enkel inloggning till både moln- och lokala resurser (via Kerberos) utan att användare behöver autentisera om för varje tjänst.

Implementera Windows Hello för företag: Vad IT-avdelningen behöver veta

Att distribuera Windows Hello för företag kräver planering över fyra områden: hårdvara, katalog, policy och användarintroduktion.

Förutsättningar för hårdvara

• TPM 2.0 krävs för nyckelskydd på företagsnivå. TPM 1.2 stöds men rekommenderas inte på grund av policyvariationer.
• För ansiktsigenkänning krävs en infraröd kamera med anti-spoofing-funktion. Standardwebkameror är inte tillräckliga för Windows Hello Face.
• För förbättrad inloggningssäkerhet (ESS) krävs specialiserade ESS-kompatibla biometriska sensorer och en VBS-kompatibel enhet med TPM 2.0.

Förutsättningar för katalog och identitet

• Cloud Kerberos Trust: en Microsoft Entra ID-klient, Entra Connect-synkronisering, Windows Server 2016 eller senare DC:er och Intune för policyleverans.
• Key Trust: en företags-PKI för att utfärda DC Kerberos-autentiseringscertifikat (minst RSA 2048 / SHA-256, nyckellagringsleverantör krävs).
• Certifikatförtroende: lokal AD FS, en företags-PKI med användarcertifikatmallar och Intune eller GPO för policy.

Principkonfiguration via Intune

För molnbaserad Kerberos-förtroende kräver Intune-inställningskatalogen tre viktiga policyinställningar: Använd Windows Hello för företag (aktiverat), Använd molnförtroende för lokal autentisering (aktiverat) och Kräv säkerhetsenhet (aktiverat, vilket tvingar fram TPM-nyckellagring). Principer för certifikatförtroende får inte konfigureras samtidigt, eftersom certifikatförtroende åsidosätter molnförtroende när båda finns.

Användarregistrering

När policyn har distribuerats och enheten uppfyller kraven startas etableringen av Windows Hello för företag automatiskt efter användarens första inloggning. Användaren anger en PIN-kod, som tillämpas för komplexitet och längd enligt policyn, och registrerar sedan eventuellt biometri. PIN-koden är enhetsspecifik, överförs aldrig över nätverket och tillämpas av TPM-utelåsningspolicyn, vilket gör brute-force-försök mot den opraktiska utan fysisk åtkomst till enheten.

Windows Hello och PKI: Kopplingen

Medan Cloud Kerberos Trust minskar PKI-beroendet för de flesta distributioner, är PKI fortfarande relevant för Windows Hello i flera scenarier:

• Distributioner av certifikatförtroende utfärdar användarinloggningscertifikat till Windows Hello-behållaren via en företags-CA, vilket ger smartkortsekvivalens för scenarier som kräver certifikatbaserad autentisering.
• Domänkontrollantcertifikat krävs under både Key Trust- och Certifikatförtroende-modellerna. Dessa mallar måste använda modern kryptografi (RSA 2048+, SHA-256, kategori Key Storage Provider), inte äldre v1-mallar.
• TPM-nyckelatestering, när det tillämpas via en policy, kräver att CA verifierar att WHfB-nyckeln genererades inuti en certifierad TPM, vilket tillhandahåller en hårdvarusäkringskedja.
• Certifikatförtroende stöder RDP/VDI-scenarier och S/MIME-e-postsignering, användningsfall som inte täcks av nyckelbaserade eller molnbaserade Kerberos-förtroendemodeller.
• Förtroendemodeller är inte fritt utbytbara när de väl har distribuerats. Migrering från nyckelförtroende till moln Kerberos-förtroende stöds direkt via grupprincip eller Intune. Det finns ingen motsvarande direkt väg från certifikatförtroende till moln Kerberos-förtroende: den befintliga Windows Hello-behållaren måste tas bort innan enheten kan distribueras om under moln Kerberos-förtroende. Organisationer som planerar att övergå från certifikatförtroende bör ta hänsyn till detta omregistreringssteg snarare än att behandla det som en policyändring.

För organisationer med en äldre PKI som föregår Windows Hello är modernisering av mallar en förutsättning. Äldre domänkontrollantmallar (v1) saknar Kerberos-autentiserings-EKU och använder inte CNG Key Storage Providers, vilka båda krävs för att WHfB-certifikatförtroendet ska fungera.

Överväganden gällande regelanpassning och efterlevnad

Windows Hello för företag anpassas till flera aktuella regelverk och standardramverk:

Ramverk / Förordning	Windows Hello-relevans
NIST SP 800-63B	WHfB med TPM-baserade nycklar och biometri uppfyller AAL2. TPM-attestering och ESS kan stödja AAL3-krav.
CISA-riktlinjer för nätfiskebeständighet (MFA)	FIDO2-baserad autentisering, som WHfB implementerar, listas uttryckligen som en phishing-resistent MFA-metod i CISA:s riktlinjer för federala myndigheter.
Microsofts initiativ för säker framtid	Microsofts SFI, som lanserades i november 2023, kräver MFA för alla Microsoft-molnkonton. Windows Hello är den primära leveransmekanismen för konsumenter och företag.
Zero Trust Architecture	WHfB uppfyller pelaren för verifierad identitet i NIST SP 800-207 Zero Trust genom att binda autentisering till en specifik enhet och användarbiometri, inte en delad autentiseringsuppgift.
NIS2-direktivet (EU)	NIS2 Artikel 21 kräver flerfaktorsautentisering för enheter som omfattas. WHfB uppfyller detta krav för Windows-baserade miljöer.

Framtidsutsikter: Överväganden efter kvantmekanism och den lösenordslösa framtiden

Microsofts riktning är otvetydig: i maj 2025 meddelade företaget att alla nya Microsoft-konton är lösenordsfria som standard, och lösenordet tas bort som inloggningsalternativ vid kontoskapande. Detta påskyndar en övergång som Windows Hello har möjliggjort sedan 2015. För IT-team inom stora företag är frågan inte längre om man ska driftsätta Windows Hello för företag, utan vilken förtroendemodell, i vilken skala och enligt vilken tidslinje.

Postkvantkryptografi och Windows Hello

De asymmetriska nyckelparen som genereras av Windows Hello förlitar sig för närvarande på elliptiska kurvor eller RSA algoritmer, vilka båda är teoretiskt sårbara för kryptografiskt relevanta kvantdatorer. NIST slutförde sina postkvantkryptografistandarder den 13 augusti 2024 (FIPS 203, FIPS 204 och FIPS 205), och Microsoft har uttalat sitt åtagande att PCC migrering över sin autentiseringsinfrastruktur. Organisationer som distribuerar Windows Hello för företag idag bör övervaka NIST PQC-migreringsriktlinjerna och Microsofts färdplan för algoritmagilitet i WHfB-nyckelbehållaren, eftersom detta kommer att bli en aktiv planeringsfråga inom en fem- till tioårsperiod.

Encryption Consultings kryptografiska inventering och agilitetsprogram, byggda kring CBOM-säkerhet, hjälper organisationer att kartlägga befintliga kryptografiska beroenden, inklusive autentiseringsinfrastruktur, innan en migrering krävs snarare än efter.

Lösenord som konvergenspunkt

FIDO2/lösenordsnyckel-ekosystemet konvergerar mot en enhetlig modell där plattformsautentiserare som Windows Hello, Apples lösenord och Androids FIDO2-implementering erbjuder en konsekvent, nätfiskeresistent inloggningsupplevelse över operativsystem. Windows Hellos nu allmänt tillgängliga Entra-lösenordsnyckelintegration är ett steg mot denna konvergens, vilket gör det möjligt för organisationer att standardisera FIDO2 över sina heterogena enhetsflottor utan att hantera separata autentiseringsmekanismer per plattform.

Hur krypteringskonsulting hjälper

Att distribuera Windows Hello för företag, oavsett om det är på Cloud Kerberos Trust, Key Trust eller Certificate Trust, beror på identitetens och PKI-infrastrukturens tillstånd bakom den. Encryption Consultings PKI-tjänster Tillhandahålla heltäckande konsultation för företag som planerar eller felsöker en WHfB-utrullning: utforma CA-hierarkin och certifikatmallar som en Certificate Trust-distribution behöver, modernisera äldre domänkontrollantmallar för att stödja Key Trust och validera Entra Connect- och Entra Kerberos-konfigurationen för Cloud Kerberos Trust.

För organisationer som vill ta bort PKI-driftskostnader helt och hållet, PKI-som-en-tjänst levererar en hanterad, molnbaserad CA så att IT-team kan stödja implementeringar av Key Trust eller Certificate Trust utan att behöva använda en lokal PKI-infrastruktur direkt. När WHfB har driftsatts, CertSecure-hanterare ger IT- och säkerhetsteam insyn och livscykelautomatisering över de certifikat som Key Trust- och Certifikatförtroende-modellerna är beroende av, inklusive domänkontrollantcertifikat och användarinloggningscertifikat, vilket minskar risken för att ett utgånget eller felkonfigurerat certifikat bryter mot autentiseringen för en hel webbplats.

Vanliga frågor om partihandel med mat och dryck

Vad är Windows Hello och hur skiljer det sig från ett lösenord?

Windows Hello är Microsofts lösenordsfria autentiseringssystem för Windows 10 och 11. Istället för att överföra en delad hemlighet, ett lösenord, till en server använder det ett TPM-baserat asymmetriskt nyckelpar där den privata nyckeln aldrig lämnar enheten. Användaren låser upp den privata nyckeln lokalt med en biometrisk kod eller PIN-kod, och enheten signerar en kryptografisk utmaning från identitetsleverantören. Servern verifierar signaturen med hjälp av användarens offentliga nyckel. Inget lösenord överförs eller lagras någonsin på serversidan.

Är Windows Hello tillräckligt säkert för företagsmiljöer?

Ja. Windows Hello för företag med TPM-baserade nycklar uppfyller NIST SP 800-63B Authenticator Assurance Level 2 (AAL2), standarden som krävs för de flesta företagsapplikationer. Den listas uttryckligen som en phishing-resistent MFA-metod i CISA-riktlinjer för federala myndigheter. För scenarier med högre säkerhetskrav kan TPM-attestering och Enhanced Sign-in Security (ESS) höja säkerhetsnivån ytterligare. Organisationer inom reglerade branscher, inklusive finans, hälso- och sjukvård och myndigheter, har implementerat WHfB som sin primära autentiseringsmekanism.

Vad är skillnaden mellan Windows Hello för företag och Windows Hello för konsumenter?

Konsumentversionen av Windows Hello är konfigurerad för personliga Microsoft-konton och stöder inte företagsidentitetsleverantörer, grupprinciper, Intune-hantering eller lokal resursåtkomst. Windows Hello för företag (WHfB) är företagsvarianten, integrerad med Microsoft Entra ID och/eller Active Directory, hanterad via Intune eller GPO och kapabel att tillhandahålla SSO till både moln- och lokala resurser via Cloud Kerberos Trust eller Certificate Trust.

Behöver jag en PKI för att distribuera Windows Hello för företag?

Inte nödvändigtvis. Cloud Kerberos Trust, Microsofts rekommenderade standarddistributionsmodell, kräver inte en företags-PKI eller certifikatinfrastruktur för slutanvändarenheter. Det kräver bara ett Microsoft Entra Kerberos-objekt, skapat med ett enda PowerShell-kommando, och leverans av Intune- eller GPO-policy. Certifikatförtroende, som kräver PKI, är reserverat för miljöer som behöver certifikatbaserad autentiseringsekvivalens, RDP/VDI-scenarier eller S/MIME-signering.

Kan alla konton använda Cloud Kerberos Trust?

Nej. Konton som är direkta eller indirekta medlemmar i privilegierade inbyggda säkerhetsgrupper, inklusive domänadministratörer, kan inte autentisera via Cloud Kerberos Trust. AzureADKerberos-objektet omfattas av samma begränsningar för lösenordsreplikeringspolicyn som en vanlig skrivskyddad domänkontrollant, som blockerar privilegierade konton avsiktligt. Microsoft rekommenderar inte att man lättar på denna policy, eftersom det introducerar en attackväg mellan Entra ID och Active Directory. Organisationer som behöver WHfB för privilegierade konton bör istället använda Key Trust eller Certificate Trust för dessa konton.

Kan jag migrera direkt från certifikatförtroende till molnbaserad Kerberos-förtroende?

Nej. Det finns ingen direkt migreringsväg från certifikatförtroende till molnbaserad Kerberos-förtroende. Den befintliga Windows Hello-behållaren måste tas bort innan en enhet kan distribueras om under molnbaserad Kerberos-förtroende. Att migrera från nyckelförtroende till molnbaserad Kerberos-förtroende är enklare och kan göras via grupprincip eller Intune utan att behållaren tas bort.

Vad händer om en användares enhet förloras eller blir stulen?

Eftersom Windows Hello-inloggningsuppgifter är enhetsbundna kan de inte användas på en annan enhet. Om en enhet förloras kan en administratör omedelbart ta bort den registrerade offentliga nyckeln från användarens Entra-ID eller Active Directory-konto, vilket ogiltigförklarar alla autentiseringsförsök från den enheten. De biometriska uppgifter som lagras på enheten är krypterade och kan inte rekonstrueras till ett användbart biometriskt exempel. De har inget värde för en tjuv utan enhetens egen biometriska sensor.

Hur relaterar sig Windows Hello till FIDO2-lösenord?

Windows Hello är en FIDO2-certifierad plattformsautentiserare, vilket innebär att den implementerar WebAuthn- och CTAP2-specifikationerna. Alla autentiseringsuppgifter som skapas via Windows Hello för en FIDO2-aktiverad webbplats eller applikation är tekniskt sett en lösenkod, en enhetsbunden FIDO2-autentiseringsuppgift. Windows Hello stöder även Entra ID-lösenkodsregistrering, som nu är allmänt tillgänglig, vilket gör det möjligt för organisationer att använda Windows Hello som en FIDO2-lösenkodsautentiserare för Microsoft Entra-konton, inklusive på enheter som inte är Entra-anslutna.

Kan Windows Hello användas för RDP- eller VDI-sessioner?

Detta beror på distributionsmodellen. Cloud Kerberos Trust stöder inte RDP med angivna autentiseringsuppgifter. Certificate Trust stöder RDP/VDI genom att registrera ett användarcertifikat i WHfB-behållaren. Alternativt kan Remote Credential Guard skydda RDP-sessioner utan att kräva Certificate Trust. Från Windows 11 24H2 och Windows Server 2025 kan FIDO2-autentisering, inklusive Windows Hello, användas för RDP via webbinloggning när den är aktiverad på både klient och värd.

Välj rätt autentiseringsmodell med förtroende

Är du redo att planera en utrullning av Windows Hello för företag eller lösa ett problem med en hybrid förtroendemodell? PKI-tjänster i aktion, eller läs om Bästa praxis för Windows Hello.