Merhaba

Microsoft, kimlik doğrulama tarafında yıllardır sinyalini verdiği adımı sonunda resmileştirdi. 13 Temmuz 2026 tarihli MC1426371 numaralı Message Center duyurusu ile Microsoft Entra ID’de passkey’ler varsayılan kimlik doğrulama yöntemi haline geliyor, Microsoft tarafından sağlanan SMS (Short Message Service) ve sesli arama (voice) ile MFA (Multi-Factor Authentication) yöntemleri ise 1 Şubat 2027’de tamamen emekliye ayrılıyor.

Bu, 2024’te başlayan yönetim portallarına erişimde zorunlu MFA (Multi-Factor Authentication) kararından bu yana kimlik tarafında yapılan en kritik değişiklik. Ve hala telefon tabanlı doğrulama kullanan bir tenant’ınız varsa, bu yazıyı sonuna kadar okumanızı öneririm.

Arka Plan: Zorunlu MFA Nereden Geliyor?

Bu duyuruyu doğru konumlandırmak için, Microsoft’un 2024’te başlattığı zorunlu MFA (Multi-Factor Authentication) girişimine kısaca bakmakta fayda var. Çünkü passkey kararı, o çizginin doğal devamı.

Faz 1 – Ekim 2024’ten itibaren: Azure portal, Microsoft Entra admin center ve Microsoft Intune admin center’a giriş yapan hesaplar için herhangi bir CRUD (Create, Read, Update, Delete / Oluştur, Oku, Güncelle, Sil) işleminde MFA (Multi-Factor Authentication) zorunlu hale getirildi. Şubat 2025’ten itibaren Microsoft 365 admin center girişleri de kademeli olarak kapsama alındı. Azure portal tarafındaki zorunluluk Mart 2025’te tüm Azure tenant’larının %100’üne yayıldı.

Faz 2 – 1 Ekim 2025’ten itibaren: Azure CLI (Command-Line Interface), Azure PowerShell, Azure mobil uygulaması, IaC (Infrastructure as Code) araçları ve REST (Representational State Transfer) API uç noktaları üzerinden Create, Update veya Delete işlemi yapan hesaplar da kapsama alındı. Read işlemleri MFA (Multi-Factor Authentication) gerektirmiyor.

Burada sıkça yanlış anlaşılan iki nokta var:

• Kapsam, atanmış role göre değil eyleme göre belirleniyor. Sistem zorunluluğu; öğrenci hesabı, break-glass hesabı, aktif veya eligible rolü olan yönetici hesabı ya da muafiyet tanımlı kullanıcılar dahil tüm kullanıcı hesaplarına uygulanıyor. Yani Global Administrator olmasanız bile, Azure portal üzerinden bir kaynağa dokunuyorsanız kapsamdasınız.
• Her API çağrısı kapsamda değil. Yalnızca https://management.azure.com/ adresine giden istekler kapsamda; Microsoft Graph API’leri genel olarak kapsam dışı. Service principal’lar ve managed identity gibi iş yükü kimlikleri de bu zorunluluktan etkilenmiyor.

Özetle Microsoft önce “MFA yapacaksınız” dedi, şimdi “hangi MFA yöntemini kullanacağınızı da biz belirliyoruz” diyor. Passkey kararı, iki yıllık bu politikanın ikinci perdesi.

Neden Bu Değişiklik?

SMS ve sesli arama, bugün kullanımda olan en zayıf MFA (Multi-Factor Authentication) yöntemleri. Bunu Microsoft da açıkça söylüyor.

Üç temel saldırı vektörüne karşı pratikte hiçbir koruma sağlamıyorlar:

• Phishing / AiTM (Adversary-in-the-Middle / Araya Giren Saldırgan): Kullanıcı, sahte oturum açma sayfasına OTP (One-Time Password) kodunu kendi elleriyle giriyor. Evilginx benzeri araçlarla oturum çerezi anında çalınıyor.
• SIM (Subscriber Identity Module) swap: Operatör tarafında sosyal mühendislikle numara devralınıyor, tüm doğrulama kodları saldırganın telefonuna düşüyor.
• Replay saldırıları: Ele geçirilen kod, geçerlilik süresi içinde tekrar kullanılabiliyor.

Passkey (FIDO2 – Fast IDentity Online 2 tabanlı) ise kriptografik olarak alan adına bağlı çalışıyor. Sahte bir domain üzerinden imza üretilemiyor. Yani kullanıcı isteyerek bile phishing sayfasına “kod veremiyor” verecek bir kod yok.

Microsoft’un gerekçesinde AI (Artificial Intelligence) çağının daha güçlü, phishing’e dayanıklı kimlik doğrulama gerektirdiği vurgusu öne çıkıyor. Otomasyona dayalı, ölçeklenebilir sosyal mühendislik saldırılarının artışı düşünüldüğünde bu gerekçe fazlasıyla makul.

Takvim: Üç Kritik Tarih

Sıklıkla Atlanan Detay: SSPR de Kapsamda

Bu değişikliğin sadece oturum açma akışını etkilediğini düşünmek yaygın bir hata. SMS ve voice emekliliği SSPR (Self-Service Password Reset) süreçlerini de kapsıyor.

(Self-Service Password Reset) politikanızda “Mobile phone (SMS)” veya “Office phone” doğrulama yöntemi tanımlıysa, bunlar da 1 Şubat 2027’de çalışmayı bırakacak. Parola sıfırlama akışınızı Authenticator, e-posta veya güvenlik soruları gibi alternatiflerle yeniden gözden geçirmeniz şart.

Kimler Etkilenmiyor?

Kullanıcılarınız halihazırda aşağıdaki yöntemlerden birini kullanıyorsa doğrudan bir kesinti yaşamayacaklar:

• Passkey (FIDO2 güvenlik anahtarı veya cihaz tabanlı)
• Windows Hello for Business
• Microsoft Authenticator (push / passwordless)
• CBA (Certificate-Based Authentication / Sertifika Tabanlı Kimlik Doğrulama), akıllı kart

Ancak dikkat: SMS/voice için hala etkin durumdaki kullanıcılar, başka yöntemleri olsa bile passkey kayıt istemleriyle karşılaşabilir. Politika seviyesindeki etkinlik durumu belirleyici.

Tenant’ınızda hiç SMS/voice etkin kullanıcı yoksa, bu değişiklik için aksiyon almanıza gerek yok.

Ne Yapmalısınız? Adım Adım Geçiş Planı

1. Envanteri Çıkarın

Burada iki ayrı soruyu karıştırmamak kritik:

• Politika seviyesinde kim etkin? → Bu, tenant’ınızın 1 Eylül otomatik etkinleştirmesi kapsamına girip girmediğini belirler.
• Fiilen telefon numarası kayıtlı ve başka yöntemi olmayan kim? → Bunlar 1 Şubat 2027’de gerçekten kilitlenecek kullanıcılar.

İlk kontrol 30 saniyelik bir iş: Entra admin center → Protection → Authentication methods → Policies altında SMS ve Voice call yöntemlerinin durumuna ve hedef gruplarına bakın.

İkinci soru için Microsoft’un yayınladığı Entra SMS/Voice Policy Scanner PowerShell betiğini kullanabilirsiniz. Betiği çalıştırmak için Global Reader, Authentication Policy Administrator veya Security Reader rollerinden birine sahip olmanız yeterli.

Alternatif olarak Microsoft Graph üzerinden kayıt detaylarını da çekebilirsiniz:

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

Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object { $_.MethodsRegistered -contains "mobilePhone" } |
  Select-Object UserPrincipalName, IsMfaRegistered, MethodsRegistered, IsAdmin |
  Export-Csv .\sms-voice-kullanicilari.csv -NoTypeInformation -Encoding UTF8

Çıkan listeden özellikle tek yöntemi telefon olan ve ayrıcalıklı hesap sahibi olan kullanıcıları ayrı bir kovaya alın. Bu iki grup önceliğiniz.

2. Bu Kullanıcılar İçin Bir Güvenlik Grubu Oluşturun

Hem registration campaign’i hem de son kullanıcı iletişimini bu gruba hedefleyin. Tüm tenant’a genel duyuru yapmak yerine doğru kişilere ulaşmak, hem destek yükünü hem de gürültüyü ciddi biçimde azaltır.

3. Passkey’i Etkinleştirin ve Registration Campaign Başlatın

Authentication Methods Policy altında Passkey (FIDO2) yöntemini etkinleştirin. Kurumsal senaryolarda Attestation enforcement ve AAGUID (Authenticator Attestation Globally Unique Identifier) kısıtlaması ayarlarını gözden geçirmenizi öneririm sadece onaylı güvenlik anahtarlarının veya cihaz tipi passkey’lerin kaydedilmesini istiyorsanız bu ayarlar belirleyici.

Ardından registration campaign’i oluşturduğunuz gruba yönlendirerek, 1 Eylül’deki otomatik etkinleştirmeden önce kendi takviminizle ilerleyin. Bu, en önemli tavsiye: değişikliği siz yönetin, size dayatılmasını beklemeyin.

Passkey’in maliyet tarafında iyi bir haber var: passkey tüm Entra planlarına dahil, ek bir ücreti yok. Conditional Access gibi P1 gerektirmiyor.

4. Kullanıcı İletişimini Planlayın

Cihaz tipine göre ayrı rehberler hazırlayın Windows Hello, iOS, Android kayıt akışları birbirinden farklı. Microsoft’un e-posta ve Teams için hazır iletişim şablonları mevcut, bunları yerelleştirerek kullanabilirsiniz.

Deneyimlerime göre bu tür geçişlerde en büyük direnç teknik değil, algısal oluyor: kullanıcılar “telefonuma gelen kod” alışkanlığından kopmakta zorlanıyor. Passkey’in daha kolay olduğunu (kod beklemek yok, yazmak yok, parmak izi/yüz yeterli) mesajın merkezine koymak, güvenlik argümanından daha etkili sonuç veriyor.

5. Sadece Gerekliyse Telekom Sağlayıcı Değerlendirin

Düzenleyici bir zorunluluk veya operasyonel bir kısıt nedeniyle SMS/voice’u sürdürmeniz gerekiyorsa, Microsoft Security Store üzerinden müşteri yönetimli bir telekom sağlayıcı yapılandırabilirsiniz.

Ancak burada iki noktanın altını çizmek gerekiyor. Birincisi, bu ücretli bir eklenti mesaj başına fiyatlandırılıyor ve sağlayıcıya/bölgeye göre değişiyor. İkincisi ve daha önemlisi: sağlayıcı değiştirmek SMS’i güvenli hale getirmiyor. SIM swap ve phishing riski aynen devam ediyor. Bu yol, bir güvenlik çözümü değil, uyumluluk gereksinimi için bir köprü. Kalıcı mimarinizi bunun üzerine kurmayın.

Değerlendirme

Bu duyuruyu sadece bir “ürün emekliliği” olarak okumak eksik olur. Microsoft, on yıldır sektörde bilinen bir gerçeği telefon tabanlı MFA’nın kırılganlığını nihayet ürün kararına dönüştürüyor. NIST’in (National Institute of Standards and Technology) SP 800-63B’de SMS’i “restricted” olarak işaretlemesinin üzerinden yıllar geçti; bu adım o çizginin doğal sonucu.

2024’teki zorunlu MFA (Multi-Factor Authentication) hamlesiyle birlikte düşünüldüğünde tablo net: Microsoft, kimlik güvenliğini müşterinin isteğine bırakan modelden, varsayılan olarak dayatan modele geçiyor. Bu geçişte gecikenler, kendi takvimlerini değil Microsoft’un takvimini uygulamak zorunda kalıyor.

Pratikte 1 Şubat 2027 uzak görünse de, kurumsal bir kimlik geçişinin gerçek takvimi öyle işlemiyor. Envanter, pilot grup, kullanıcı iletişimi, destek ekibi hazırlığı, kiosk/ortak cihaz gibi kenar senaryolar ve kayıt sırasında yaşanacak destek talepleri derken altı ay hızla eriyor. Kritik eşik Şubat 2027 değil, 1 Eylül 2026 çünkü o tarihten sonra takvim sizin değil, Microsoft’un olacak.

Kısaca: envanteri bu ay çıkarın, pilot grubu yaz sonunda başlatın, Eylül’e hazır girin.

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

---

Kaynaklar

• Microsoft Security Blog — Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID (13 Temmuz 2026)
• Microsoft Learn — Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• Microsoft Learn — Plan for mandatory Microsoft Entra multifactor authentication
• Azure Blog — Azure mandatory multifactor authentication: Phase 2 starting in October 2025
• Microsoft 365 Message Center — MC1426371