Windows Hello for Business Nasıl Kurulur? Kurumsal Rehber (2026)

Özet (TL;DR): Windows Hello for Business, kurumsal cihazlarda şifreyi TPM'de saklanan bir anahtar çiftine bağlı PIN veya biyometriyle değiştiren Microsoft'un resmi şifresiz kimlik doğrulama teknolojisidir. Microsoft Learn'e göre önerilen dağıtım modeli, ek bir PKI (sertifika altyapısı) gerektirmeyen cloud Kerberos trust'tır. Kurulum üç adımdan oluşur: Microsoft Entra Kerberos nesnesinin oluşturulması, Intune veya GPO ile politika yapılandırması ve kullanıcı kaydının doğrulanması. Varsayılan PIN geçerlilik süresi 41 gün, minimum uzunluk 4 karakterdir. Doğru planlanmadığında en sık görülen hata "That option is temporarily unavailable" mesajıdır — çoğunlukla anahtar senkronizasyon gecikmesinden kaynaklanır.

> Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-102, AZ-104 ve kimlik yönetimi konusunda sertifikalı danışmanlar. Bu rehber, resmi Microsoft Learn dokümantasyonu esas alınarak hazırlanmıştır.

Kurumunuz için ücretsiz Windows Hello for Business uygunluk değerlendirmesi alın — hangi trust modelinin sizin Active Directory ve Intune altyapınıza uygun olduğunu 15 dakikalık görüşmede netleştirelim.

Windows Hello for Business Nedir ve Neden Şimdi Gündemde?

Windows Hello for Business (WHfB), kullanıcı adı-şifre ikilisini, cihaza bağlı (device-bound) bir asimetrik anahtar çiftiyle korunan PIN veya biyometrik kimlik doğrulamayla değiştiren Microsoft'un kurumsal şifresiz oturum açma teknolojisidir. Şifrelerin aksine bu kimlik bilgisi asla ağ üzerinden taşınmaz; özel anahtar cihazın TPM'inde (Trusted Platform Module) kilitli kalır, bu yüzden kimlik avı, keylogger ve "pass-the-hash" saldırılarına karşı önemli ölçüde daha dayanıklıdır.

2026 itibarıyla konu üç nedenden dolayı öncelikli hale geldi: Microsoft, SMS ve sesli arama tabanlı MFA yöntemlerini kademeli olarak devre dışı bırakıyor (bkz. SMS/sesli MFA kapanış takvimimiz), Windows 10 desteğinin sona ermesiyle filoların büyük kısmı Windows 11'e geçiyor ve bu geçiş yeni Autopilot/Intune kayıt akışlarını tetikliyor, üçüncüsü de saldırı yüzeyini azaltmak isteyen kurumlar artık "passwordless" hedefini somut bir proje olarak IT yol haritasına koyuyor. Windows Hello for Business bu üç ihtiyacın kesişiminde duruyor.

Bu rehber; hangi dağıtım modelini seçmeniz gerektiğini, Microsoft Entra Kerberos nesnesinin nasıl oluşturulacağını, Intune ile politika yapılandırmasını, doğrulama adımlarını ve en sık karşılaşılan hataları — tamamı Microsoft Learn'ün resmi dağıtım kılavuzuna dayanarak — adım adım anlatıyor.

Ön Gereksinimler: Lisans, Cihaz ve Altyapı

Kuruluma başlamadan önce yedi alanda karar vermeniz gerekiyor; Microsoft Learn bu planlama sürecini "yedi ana alan" olarak tanımlıyor: dağıtım modeli, PKI gereksinimleri, Microsoft Entra ID'ye kimlik doğrulama şekli, cihaz yapılandırma seçenekleri, bulut hizmetleri lisanslaması, işletim sistemi gereksinimleri ve kullanıcı hazırlığı.

• Lisans: Windows Hello for Business'ın kendisi bir Microsoft Entra ID P1/P2 aboneliği gerektirmez. Ancak MDM otomatik kaydı ve Koşullu Erişim gibi bağımlı özellikler P1/P2 ister. Sertifika güveni (certificate trust) modeli ile AD FS device write-back kullanacaksanız Entra ID P1 zorunludur.
• Cihaz: TPM 2.0 önerilir (politika "Required" veya "Preferred" olarak ayarlanabilir), Secure Boot etkin olmalı, cihaz Microsoft Entra join, Microsoft Entra hybrid join veya (on-premises modelde) Active Directory domain join olmalı.
• İşletim sistemi: Cloud Kerberos trust için istemcide en az Windows 10 21H2 (KB5010415) veya Windows 11 21H2 (KB5010414) yüklü olmalı.
• Domain controller: Windows Server 2016 (KB3534307+), Windows Server 2019 (KB4534321+), Windows Server 2022 veya Windows Server 2025 — her Active Directory sitesinde yeterli sayıda okuma-yazma (read-write) domain controller bulunmalı.
• Dizin senkronizasyonu: Hybrid dağıtımda Microsoft Entra Connect Sync (veya Cloud Sync) aktif olmalı; kullanıcı ve cihaz nesneleri hem Active Directory hem Microsoft Entra ID'de senkron olmalı.

Altyapınızda halihazırda Entra Connect Sync'i güncel sürüme taşıdıysanız ve Microsoft Entra MFA'yı zaten devrede tutuyorsanız, WHfB kurulumunun büyük kısmı için altyapı zaten hazır demektir. Kimlik ve cihaz yönetimini tek elden kurgulamak isteyen kurumlar için Microsoft 365 çözümlerimiz kapsamında Intune ve Entra ID entegrasyonunu birlikte planlıyoruz.

Dağıtım Modelini Seçin: Cloud-Only, Hybrid veya On-Premises

Microsoft Learn üç dağıtım modeli tanımlıyor ve seçim büyük ölçüde mevcut kimlik altyapınıza göre kendiliğinden belirleniyor:

• Cloud-only: Yalnızca bulut kimlikleri kullanan, on-premises kaynağa erişmeyen kuruluşlar için. Cihazlar Microsoft Entra'ya join/register edilir; SharePoint Online, OneDrive gibi tamamen bulut kaynaklara erişilir.
• Hybrid: Active Directory'den Microsoft Entra ID'ye kimlik senkronize eden, hem on-premises hem bulut kaynaklarda tek oturum açma (SSO) isteyen kurumlar için — Türkiye'deki orta-büyük ölçekli şirketlerin çoğu bu kategoridedir.
• On-premises: Bulut kimliği olmayan, tamamen kapalı/izole ortamlar için (Microsoft'un asıl kullanım senaryosu "Enhanced Security Administrative Environment" yani "Red Forest" dediği yüksek güvenlikli yönetim ortamlarıdır).

Not: On-premises modelden hybrid modele geçiş, Windows Hello for Business'ın yeniden dağıtılmasını gerektirir — bu kararı erken netleştirmek önemlidir.

Trust Tipi Kararı: Cloud Kerberos Trust mı, Key Trust mı, Certificate Trust mı?

Hybrid ve on-premises dağıtımlarda "trust type" kullanıcının Active Directory'ye nasıl kimlik doğrulayacağını belirler (Microsoft Entra ID'ye kimlik doğrulama her zaman anahtar tabanlıdır, trust tipinden etkilenmez):

Trust tipi	PKI gerekir mi?	Ne zaman seçilir
Cloud Kerberos trust	Hayır	Microsoft'un önerdiği model. Sertifika tabanlı kimlik doğrulama senaryosuna ihtiyacınız yoksa varsayılan seçim budur.
Key trust	Yalnızca domain controller sertifikası için	Mevcut bir kurumsal PKI'nız varsa ve cloud Kerberos trust'a geçmeden önce mevcut altyapıyı korumak istiyorsanız.
Certificate trust	Evet, tam PKI + kayıt yetkilisi (CRA)	VPN gibi sertifika tabanlı kimlik doğrulama gerektiren on-premises senaryolarınız varsa.

Cloud Kerberos trust'ın öne çıkma nedeni somut: PKI dağıtmanıza veya değiştirmenize gerek kalmaz, Microsoft Entra ID ile Active Directory arasında genel anahtar senkronizasyonu beklemeniz gerekmez (provisioning ile kimlik doğrulama arasında gecikme olmaz) ve FIDO2 güvenlik anahtarı girişi minimum ek kurulumla devreye alınabilir. Key trust modelinde yaşanan klasik "anahtar senkron olana kadar giriş başarısız" sorunu cloud Kerberos trust'ta ortadan kalkar — bu, aşağıdaki "Yaygın Hatalar" bölümünde detaylandırdığımız bir noktadır.

Saha vakası: 220 kişilik bir üretim firmasında geçiş

Ankara merkezli, 220 kullanıcılı bir üretim firması — hibrit Active Directory + Microsoft Entra ID ortamı, mevcut PKI yok. İhtiyaç: şifre sıfırlama taleplerini azaltmak ve kimlik avı riskini düşürmek. Süre: 3 hafta (pilot grup + kademeli rollout). Karar noktaları: (1) PKI yatırımı yapılmak istenmediği için cloud Kerberos trust seçildi, (2) dağıtım Intune Settings Catalog üzerinden yapıldı çünkü cihazların tamamı Intune'a kayıtlıydı, (3) pilot grup BT ekibi + 15 gönüllü kullanıcıdan oluşturuldu. Sonuç: rollout sonrası ilk ayda şifre sıfırlama taleplerinde belirgin bir düşüş gözlendi, kullanıcı memnuniyeti PIN'in cihaza özel olmasından dolayı yüksekti. Xen ekibinin rolü: Entra Kerberos nesnesinin oluşturulması, Settings Catalog politikasının tasarımı ve pilot grup sonrası genel rollout planının hazırlanması. Uyarı: OEM cihazlarda (bkz. aşağıdaki TR-özel not) TPM 2.0'ın BIOS'ta kapalı gelmesi rollout'u bir hafta geciktirdi — donanım envanterini önceden çıkarmak bu riski ortadan kaldırır.

Adım Adım Kurulum (1/3): Microsoft Entra Kerberos Nesnesini Oluşturun

Cloud Kerberos trust'ı etkinleştirmeden önce, Active Directory domain'inizde bir Microsoft Entra Kerberos nesnesi oluşturmanız gerekir. Bu nesne bir "AzureADKerberos" bilgisayar hesabı olarak görünür; hiçbir fiziksel sunucuyla ilişkili değildir ve yalnızca Microsoft Entra ID'nin Active Directory domain'i için TGT (ticket-granting-ticket) üretmesi amacıyla kullanılır. Eğer daha önce on-premises FIDO2 güvenlik anahtarı SSO'sunu devreye aldıysanız bu nesne muhtemelen zaten oluşturulmuştur ve bu adımı atlayabilirsiniz.

1. Bir domain controller üzerinde Microsoft Entra Kerberos PowerShell modülünü (AzureADHybridAuthenticationManagement) yükleyin.
2. Kiracınıza ve hedef domain'e bağlanarak Entra Kerberos server nesnesini oluşturun (modül, yetkili bir Genel Yönetici/Hibrit Kimlik Yöneticisi hesabı ister).
3. İşlem tamamlandığında Active Directory Users and Computers (ADUC) konsolunda Domain Controllers organizasyon biriminde AzureADKerberos adlı bir bilgisayar nesnesi görünür; DC Type alanı "Read-only Domain Controller" olarak listelenir (aşağıdaki ekran görüntüsü).

Dikkat: Bu nesneye uygulanan varsayılan Password Replication Policy, yüksek yetkili (privileged) hesapların cloud Kerberos trust veya FIDO2 ile on-premises kaynaklara oturum açmasına izin vermez — Microsoft bu politikayı gevşetmemenizi, çünkü Microsoft Entra ID'den Active Directory'ye olası saldırı vektörlerini artıracağını özellikle belirtiyor.

Adım Adım Kurulum (2/3): Intune ile Politika Yapılandırma

Entra Kerberos nesnesi hazır olduğunda sırada politika yapılandırması var. İki yol var: Intune'daki tenant-wide kayıt politikası (tüm organizasyonu hedefler, Windows Autopilot OOBE ile uyumludur) veya Settings Catalog ile hedeflenmiş, grup bazlı dağıtım. Microsoft, kademeli rollout için Settings Catalog'u öneriyor.

Yöntem A — Tenant-wide politika (tüm organizasyon)

1. Microsoft Intune yönetim merkezine oturum açın (bu işlem için Intune Hizmet Yöneticisi rolü gerekir, diğer roller yalnızca salt okunur erişime sahiptir).
2. Cihazlar > Kayıt yolunu izleyin.
3. Windows sekmesinde, Kayıt seçenekleri altında Windows Hello for Business'ı seçin.
4. Configure Windows Hello for Business alanında Enabled'ı seçin.
5. TPM kullanımı ("Required" önerilir), minimum/maksimum PIN uzunluğu (varsayılan 6, minimum zorunlu 4, maksimum 127 karakter), büyük/küçük harf ve özel karakter kuralları, PIN geçerlilik süresi (varsayılan 41 gün), PIN geçmişi (varsayılan son 5 PIN tekrar kullanılamaz) ve biyometrik doğrulama izni ayarlarını ihtiyacınıza göre yapılandırıp Kaydet'e tıklayın.

Yöntem B — Settings Catalog (cloud Kerberos trust için önerilen, hedefli rollout)

1. Intune'da Devices > Configuration profiles > Create profile yolunu izleyin.
2. Platform: Windows 10 and later, Profile type: Settings catalog.
3. Add settings'e tıklayıp "Windows Hello for Business" kategorisini arayın ve ekleyin.
4. Aşağıdaki üç ayarı yapılandırın:
   • Use Windows Hello For Business → true
   • Use Cloud Trust For On Prem Auth → Enabled
   • Require Security Device → true (TPM zorunluluğu; önerilir ama zorunlu değil)
5. Politikayı hedef cihaz veya kullanıcı grubuna atayın.

Önemli çakışma uyarısı: Settings Catalog yöntemini kullanıyorsanız, tenant-wide ayarın Not configured bırakılması gerekir — aksi halde iki politika çakışır. Aynı cihazda hem GPO hem Intune yapılandırması varsa Group Policy ayarları önceliklidir ve Intune ayarları yok sayılır; bu yüzden hibrit ortamlarda GPO ve Intune'u aynı anda aynı cihaz grubuna uygulamayın.

PowerShell/CLI ile toplu doğrulama için, yönetici bir istemcide şu komutla Entra Kerberos yapılandırmasını sorgulayabilirsiniz (Microsoft Graph PowerShell SDK gerektirir):

Connect-MgGraph
$DomainId = "kurumunuz.onmicrosoft.com"
Get-MgDomainFederationConfiguration -DomainId $DomainId | fl

Xen Bilişim'in Microsoft Security çözümleri kapsamında bu iki yöntemden hangisinin sizin Intune/GPO karışık ortamınıza uygun olduğunu birlikte değerlendirebiliriz — 15 dakikalık ücretsiz teknik görüşme planlayın.

Adım Adım Kurulum (3/3): Doğrulama ve Test Adımları

Politika dağıtıldıktan sonra kullanıcı ilk oturum açtığında WHfB kayıt (provisioning) akışı otomatik başlar:

1. Cihaz biyometrik doğrulamayı destekliyorsa kullanıcıya biyometrik jest kurulumu sorulur (isteğe bağlı, atlanabilir).
2. Kullanıcı "kuruluş hesabıyla Windows Hello kullan" adımında Tamam'ı seçer.
3. Çok faktörlü kimlik doğrulama (MFA) tetiklenir; başarısız veya zaman aşımına uğrayan MFA kayıt sürecini durdurur ve kullanıcıdan tekrar denemesini ister.
4. MFA başarılı olduğunda kullanıcı bir PIN oluşturur ve doğrular (politika ile tanımlanan karmaşıklık kurallarına uymalıdır).
5. Cihaz, tercihen TPM'den bir asimetrik anahtar çifti üretir ve genel anahtarı kimlik sağlayıcısına (Microsoft Entra ID) kaydeder. Kayıt tamamlandığında kullanıcı PIN ile oturum açabileceği bilgisini alır.

Dağıtımı doğrulamak için iki kaynağa bakın:

• Olay günlüğü: İstemcide Uygulama ve Hizmet Günlükleri > Microsoft > Windows > User Device Registration > Admin altında ön koşul kontrol sonuçlarını görebilirsiniz.
• Komut satırı: Bir konsoldan dsregcmd.exe /status komutunu çalıştırarak cihazın join durumunu ve cloud Kerberos trust ön koşul kontrolünün sonucunu (Yes/No/Not Tested) doğrudan görebilirsiniz.

Cloud Kerberos trust'ta kullanıcı kayıt tamamladığı anda Windows Hello jestini hemen kullanabilir — key trust modelindeki senkronizasyon beklemesi burada yoktur. Microsoft Entra hybrid join cihazlarda ilk PIN kullanımı bir domain controller'a görüş hattı (line of sight) gerektirir; sonraki kilit açmalar için önbelleğe alınmış oturum kullanılabilir.

Yaygın Hatalar ve Çözümleri

Resmi Microsoft Learn "known deployment issues" dokümantasyonunda listelenen ve sahada en sık karşılaşılan sorunlar:

"That option is temporarily unavailable. For now, please use a different method to sign in."

Kim etkilenir: Hybrid key trust dağıtımları. Kök neden: Kullanıcının WHfB genel anahtarı henüz Microsoft Entra ID'den Active Directory'ye senkronize olmamış (msDS-KeyCredentialLink özniteliği güncellenmemiş). Çözüm: Bir sonraki Microsoft Entra Connect delta sync döngüsünü bekleyin veya manuel senkronizasyon tetikleyin; kalıcı çözüm için cloud Kerberos trust'a geçmektir — bu model senkron beklemesini tamamen ortadan kaldırır.

PIN sıfırlama "We can't open that page right now" hatası veriyor

Kim etkilenir: Microsoft Entra joined cihazlarda web sign-in akışı. Kök neden: PIN sıfırlama akışı yalnızca izin verilen alan adlarına yönlendirme yapabilir; federe kimlik sağlayıcınız (AD FS veya üçüncü taraf) ya da Azure US Government bulutu bu listede değilse hata verir. Çözüm: ConfigureWebSignInAllowedUrls ilkesiyle izin verilen alan adları listesini genişletin.

Windows Server 2019 domain controller'larda "KDC_ERR_CLIENT_NAME_MISMATCH"

Kim etkilenir: Erken sürüm Windows Server 2019 domain controller'ları çalıştıran key trust dağıtımları. Çözüm: Domain controller'ları build 17763.316 (KB4487044) veya üzerine yükseltin.

Intune tenant-wide politika ile Settings Catalog çakışıyor

Kök neden: Her ikisi de aynı anda "Enabled/Configured" durumundaysa PIN ile ilgili ayarlar çakışır. Çözüm: Settings Catalog kullanıyorsanız tenant-wide politikayı "Not configured" bırakın; her iki politika türünü de aynı cihaz grubuna uygulamayın.

İleri Yapılandırma ve En İyi Uygulamalar

• Kademeli rollout: Tenant-wide politika yerine önce küçük bir pilot güvenlik grubuna Settings Catalog ile dağıtın; sorun çıkmazsa kademeli olarak genişletin.
• FIDO2 güvenlik anahtarları: Cloud Kerberos trust altyapısı zaten FIDO2 anahtarlarıyla ortak olduğu için, WHfB'yi devreye aldıktan sonra FIDO2'yi minimum ek yapılandırmayla eklemek mümkündür — özellikle paylaşımlı cihaz kullanan saha/üretim çalışanları için değerlidir.
• Gelişmiş oturum açma güvenliği (Enhanced Sign-in Security): Uyumlu donanımda etkinleştirildiğinde harici çevre birimlerinin cihaza Windows Hello ile oturum açmasını engeller; varsayılan olarak destekleyen donanımda etkindir.
• Telefonla oturum açma: Etkinleştirilirse kullanıcılar masaüstü kimlik doğrulaması için uzak bir "companion device" olarak telefonlarını kullanabilir (masaüstü Microsoft Entra join olmalı).
• PIN karmaşıklığı: Büyük/küçük harf ve özel karakter zorunluluğu güvenliği artırır ama kullanıcı direncini de artırır; sahada en dengeli uygulama minimum 6 karakter + en az bir rakam + bir özel karakterdir.

Geri Alma (Rollback) Notu

Bir sorun çıkarsa veya trust modelini değiştirmeniz gerekirse: Intune/GPO politikasını devre dışı bırakmak mevcut kayıtlı kimlik bilgilerini otomatik silmez — kullanıcı cihazında yerel olarak PIN ile oturum açmaya devam edebilir, ancak yeni cihazlarda provisioning tetiklenmez. Certificate trust'tan cloud Kerberos trust'a geçişte "Windows Hello container" komutla (certutil.exe -deletehellocontainer) kullanıcı bağlamında silinmeli ve kullanıcı oturumu kapatıp açmalıdır — bu iki trust tipi arasında doğrudan geçiş yolu yoktur, yeniden kayıt (re-provisioning) gerekir. Key trust'tan cloud Kerberos trust'a geçiş ise daha basittir: Entra Kerberos'u kurup politikayı değiştirdikten sonra kullanıcı yalnızca oturumu kapatıp açar.

Türkiye'de Saha Gerçekleri: OEM Donanım ve KVKK Boyutu

OEM cihazlarda TPM ve Autopilot hash: Türkiye'de yaygın kullanılan Casper ve Monster OEM iş istasyonlarının bir kısmında TPM 2.0 modülü donanımsal olarak mevcut olsa da BIOS'ta varsayılan kapalı gelebiliyor; WHfB dağıtımına başlamadan önce cihaz envanterinde TPM durumunu (tpm.msc veya Intune donanım envanteri üzerinden) topluca doğrulamak, rollout gecikmelerinin en sık nedenini baştan ortadan kaldırır. Aynı envanter çıkarma adımı, Windows Autopilot dağıtımı planlıyorsanız zaten yapmanız gereken bir adımdır — iki projeyi birlikte planlamak zaman kazandırır.

KVKK boyutu: Biyometrik veri (parmak izi, yüz tanıma) 6698 sayılı KVKK'nın 6. maddesi kapsamında özel nitelikli kişisel veri sayılır ve işlenmesi için ek hukuki dayanak/açık rıza gerekebilir. Windows Hello biyometrik verisi cihazdan dışarı çıkmaz, TPM içinde şifrelenmiş olarak kalır ve Microsoft sunucularına gönderilmez — bu mimari, KVKK madde 12'de aranan "uygun güvenlik düzeyini temin etmeye yönelik gerekli teknik tedbirler" açısından olumlu bir başlangıç noktasıdır. Yine de kurumunuzun aydınlatma metninde biyometrik Windows Hello kullanımını açıkça belirtmesi ve isteyen kullanıcılara PIN-only seçeneğinin sunulması (biyometri asla zorunlu tutulmamalı) önerilir.

Sıkça Sorulan Sorular (SSS)

Windows Hello for Business kurulumu için ek lisans satın almam gerekiyor mu?

Hayır, Windows Hello for Business'ın kendisi Microsoft Entra ID P1/P2 gerektirmez ve Entra ID Free katmanıyla dağıtılabilir. Ancak MDM otomatik kaydı, Koşullu Erişim veya certificate trust + AD FS device write-back kullanacaksanız P1/P2 lisansı şarttır. Kurumunuzun mevcut M365/Entra lisans karmasına göre hangi senaryonun ek maliyet gerektirdiğini ücretsiz lisans envanteri çıkararak netleştirebiliriz.

Cloud Kerberos trust mı yoksa key trust mı seçmeliyim?

Microsoft Learn, sertifika tabanlı bir kimlik doğrulama senaryonuz (örn. VPN sertifikası) yoksa cloud Kerberos trust'ı öneriyor: PKI gerektirmiyor, senkron gecikmesi yok ve FIDO2 ile ortak altyapı kullanıyor. Mevcut bir PKI'nız varsa ve certificate trust'a geçmeyecekseniz key trust'ta kalmak da geçerli bir seçenektir.

Windows Hello for Business kaç günde kurulur?

Altyapı hazırsa (Entra Connect senkron, TPM'li cihazlar, Intune kaydı tamamlanmış) teknik kurulum — Entra Kerberos nesnesi + Intune politikası — 1-2 iş günü sürer. Pilot grup testi ve kademeli rollout dahil, orta ölçekli bir kurum için gerçekçi toplam süre 2-4 haftadır.

Kullanıcılar biyometrik veri paylaşmak zorunda mı?

Hayır. Biyometri isteğe bağlıdır; kullanıcı PIN kurulumunu tamamlayıp biyometrik adımı atlayabilir. Biyometrik kullanılsa bile veri cihazın TPM'inde şifreli kalır, buluta veya Microsoft sunucularına gönderilmez.

Mevcut Group Policy tabanlı bir WHfB dağıtımım varken Intune'a geçebilir miyim?

Evet, ancak aynı cihazda ikisi birden yapılandırılmışsa Group Policy ayarları öncelik kazanır ve Intune ayarları yok sayılır. Geçiş sırasında GPO ilkesini "Not Configured"a çekip cihazları kademeli olarak Intune Settings Catalog politikasına taşımanız gerekir.

RDP veya sanal masaüstü (VDI) senaryolarında Windows Hello for Business çalışır mı?

Sağlanan kimlik bilgileriyle (supplied credentials) klasik RDP/VDI senaryoları cloud Kerberos trust ile desteklenmiyor. Remote Credential Guard kullanımı veya cihazda ayrıca bir sertifika kayıtlıysa alternatif yollar mevcuttur — Windows 365 Cloud PC gibi senaryolar için ayrı bir değerlendirme gerekir.

Kurulumu kendi ekibimiz mi yapmalı yoksa dışarıdan destek mi almalıyız?

Tek bir trust modeli ve sınırlı sayıda cihaz için iç ekip resmi Microsoft Learn rehberini takip ederek kurulumu tamamlayabilir. Hibrit AD + çoklu OU yapısı, mevcut bir PKI'dan geçiş veya GPO/Intune karışık yönetim gibi karmaşık senaryolarda deneyimli bir Microsoft İş Ortağı ile planlama, rollout süresini kısaltıp geri dönüşleri azaltır.

Sonuç: Şifresiz Kimlik Doğrulama Artık Ertelenecek Bir Proje Değil

Windows Hello for Business, doğru trust modeli seçildiğinde — çoğu kurum için bu cloud Kerberos trust anlamına geliyor — ek bir PKI yatırımı olmadan, mevcut Intune ve Active Directory altyapınız üzerine kurulabilen, kimlik avına karşı somut bir savunma katmanıdır. Kurulumun teknik kısmı (Entra Kerberos nesnesi + Intune politikası) birkaç saat sürse de, gerçek başarı kademeli rollout, doğru PIN politikası ve kullanıcı iletişiminde saklı.

SMS/sesli MFA'nın kapanma takvimi, Windows 11 geçişi ve artan kimlik avı saldırıları göz önüne alındığında, WHfB'yi 2026 IT güvenlik yol haritanızın erken bir maddesi haline getirmek — geç kalıp acil bir "uyumluluk projesi" olarak yapmaktan çok daha ucuz ve az riskli.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun şifresiz kimlik doğrulamaya (Windows Hello for Business, FIDO2, passkey) geçiş yolculuğunda planlama, pilot dağıtım ve tam rollout aşamalarında uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın veya WhatsApp'tan yazın.