Passwordless Kullanıcılar Artık Eski Parolayı Bilmeden Parola Değiştirebilecek

Merhaba

Microsoft, Entra ID tarafında küçük ama pratikte epey iş kolaylaştıracak bir değişiklik duyurdu. MC1437671 numaralı Message Center kaydına göre, passwordless kimlik doğrulamaya geçmiş kullanıcılar artık My Sign-Ins üzerinden, mevcut parolalarını bilmeden ve SSPR (Self-Service Password Reset) kaydı olmadan parola değiştirebilecek.

Duyuru ilk bakışta rutin görünüyor. Ancak Microsoft’un bu özelliği hayata geçirme biçiminde, pilot uygulama planlayan kurumları doğrudan ilgilendiren kritik bir kısıt var.

Bu Değişikliğin Çözdüğü Sorun

Passkey ve Windows Hello for Business’a geçmiş kurumlarda hala parola isteyen bir yerler kalıyor. Kerberos’a bağımlı eski bir line-of-business uygulaması, parola ile kimlik doğrulayan bir servis, ya da modern kimlik doğrulamayı desteklemeyen bir üçüncü taraf entegrasyon.

Kullanıcı passwordless’a geçtikten sonra o parolayı aylarca kullanmıyor ve doğal olarak hatırlamıyor. Bugün önünde iki yol var:

  • Eski parolayı hatırlamak. Pratikte çoğu zaman mümkün değil.
  • SSPR kullanmak. Ama kullanıcı passwordless’a geçmeden önce SSPR (Self-Service Password Reset)’a kayıt olmadıysa, bu yol da kapalı.

Geriye tek seçenek kalıyor: helpdesk çağrısı. Microsoft’un beyan ettiği amaç tam olarak bu boşluğu kapatmak ve buradan doğan destek taleplerini azaltmak.

Burada dikkat çekmek istediğim nokta şu: bu özellik parolasız kimlik doğrulamayı ilerletmiyor. Kullanıcının günlük oturum açma deneyiminde hiçbir şey değişmiyor. Sadece legacy bağımlılık nedeniyle var olmaya devam eden parolanın yönetimini kolaylaştırıyor.

Takvim ve Varsayılan Durum

  • Genel kullanıma açılma: Ekim 2026 sonu (worldwide ve GCC (Government Community Cloud))
  • Tamamlanma: Aynı ay içinde
  • Varsayılan durum: Kapalı

Bu son madde önemli. Özellik tenant’ınıza ulaştığında kendiliğinden devreye girmiyor; bir yönetici açık şekilde etkinleştirene kadar kullanıcılar için hiçbir şey değişmiyor.

Microsoft, yönetici kontrollerinin ve ayarı yönetmeye yarayacak API desteğinin sürümle birlikte hazır olacağını, Microsoft Learn dokümantasyonunun da aynı anda yayımlanacağını belirtiyor. Yani şu an için resmi bir Learn makalesi henüz yok.

Akış Nasıl İşleyecek?

Uygun durumdaki bir kullanıcı My Sign-Ins üzerinden Change password seçeneğini seçecek ve kimliğini şu yöntemlerden biriyle doğrulayacak:

  • Kayıtlı bir passkey
  • FIDO2 güvenlik anahtarı
  • Windows Hello for Business

Doğrulama tamamlandıktan sonra eski parolayı girmeden yeni parolasını belirleyebilecek. Bu akış için SSPR (Self-Service Password Reset) kaydı gerekmiyor.

Microsoft’un phishing-resistant olarak sınıflandırdığı yöntemlerle bir parola değişikliğini yetkilendirmek, güvenlik açısından tutarlı bir yaklaşım. Ayda bir kez bile kullanılmayan bir parolayı hatırlamak zorunda bırakmak yerine, kullanıcının zaten sahip olduğu güçlü kimlik doğrulama yöntemini kullanmak makul.

En Kritik Nokta: Ayar Tenant Genelinde

Bu özelliğin en dikkat edilmesi gereken tarafı burası. Microsoft’un açıklamasına göre ayar tenant seviyesinde uygulanıyor. Sürümle birlikte kullanıcı bazlı veya grup bazlı hedefleme bulunmuyor.

Yani:

  • Pilot grup oluşturamıyorsunuz.
  • Küçük bir departmanla test edip yaygınlaştıramıyorsunuz.
  • Açtığınız anda uygun durumdaki tüm kullanıcılar bu seçeneği görüyor.

Kademeli geçiş alışkanlığı olan kurumlar için bu ciddi bir planlama kısıtı. Karar ikili: ya herkes, ya hiç kimse.

Etki Analizi: Kaç Kullanıcı Kapsamda?

Açma kararını vermeden önce kapsamı ölçmek gerekiyor. Aradığınız profil şu: passwordless yeteneğine sahip, ancak hesabında hala kayıtlı bir parolası olan kullanıcılar.

Entra Authentication Methods raporlaması üzerinden bu filtreyi çalıştırarak, özelliği açtığınız gün kaç kişinin bu seçeneği göreceğini net olarak görebilirsiniz. Bu sayı aynı zamanda kullanıcı iletişimi hazırlamanız gerekip gerekmediğini de belirler.

Microsoft Graph üzerinden benzer bir kapsam analizi için /reports/authenticationMethods/userRegistrationDetails endpoint’i ile isPasswordlessCapable ve kayıtlı yöntem listesi üzerinden filtreleme yapılabilir.

Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"

Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
    Where-Object { $_.IsPasswordlessCapable -eq $true } |
    Select-Object UserPrincipalName, UserDisplayName, IsAdmin,
                  @{N='Yontemler';E={ $_.MethodsRegistered -join ', ' }} |
    Sort-Object UserPrincipalName |
    Export-Csv .\passwordless-capable-users.csv -NoTypeInformation -Encoding UTF8

Gözden Kaçırılmaması Gereken Güvenlik Boyutu

Duyuruda öne çıkarılmayan ama değerlendirilmesi gereken bir taraf var. Bu özellik açıldığında, ele geçirilmiş bir passkey veya kaybedilmiş bir FIDO2 anahtarı yalnızca oturum açma değil, parola sıfırlama yetkisi de kazanmış oluyor.

Passkey’in kriptografik olarak phishing’e dirençli olması, cihazın fiziksel olarak ele geçirilmesi senaryosunu ortadan kaldırmıyor. Bu nedenle:

  • Conditional Access politikalarınızda kimlik doğrulama gücü (authentication strength) ve cihaz uyumluluğu koşullarını gözden geçirin.
  • Parola değişikliği olaylarının denetim loglarına düştüğünden ve SIEM tarafında izlendiğinden emin olun.
  • Kayıp/çalıntı cihaz süreçlerinizde passkey iptal adımının tanımlı olduğunu doğrulayın.

Ekim Öncesi Yapılması Gerekenler

1. Hala parola gerektiren uygulamalarınızı envanterleyin. Bu özelliğin size gerçekten değer katıp katmayacağını belirleyen asıl soru bu.
2. Passwordless yeteneğine sahip kullanıcı sayısını çıkarın ve etki alanını netleştirin.
3. Mevcut helpdesk yükünüzü ölçün. Parola sıfırlama kaynaklı çağrı sayınız düşükse, bu özelliği açmanın getirisi sınırlı kalabilir.
4. Parola politikanızın bu yeni akışla uyumlu olduğunu doğrulayın.
5. Tenant geneli açılacağı için kullanıcı iletişim metnini önceden hazırlayın.

Kısaca: bu, kimlik mimarinizi değiştiren bir duyuru değil. Passwordless geçişinde ortaya çıkan pratik bir sürtünmeyi ortadan kaldıran, opsiyonel bir kolaylık. Ancak tenant geneli çalışması nedeniyle “önce bir deneyelim” yaklaşımına izin vermiyor. Bu yüzden karar Ekim’de değil, şimdi verilmeli.

Başka bir yazımızda görüşmek dileğiyle…


Kaynak:

Kaynak: Microsoft 365 Message Center MC1437671

Bir yanıt yazın

Başa Dön