Microsoft Entra MFA Yapılandırması: Zorunlu MFA ve Doğru Yöntem Seçimi (2026)

MFA artık "açsak mı?" sorusunun konusu değil. Microsoft Entra ID (eski adıyla Azure AD) tarafında çok faktörlü kimlik doğrulama dayatma haline geldi: 2024’ten bu yana yönetici portallarına, 2025’ten bu yana da PowerShell/CLI ve REST ile yapılan Azure kaynak yönetimine MFA zorunlu. Opt-out yok; yalnızca erteleme vardı, o pencereler de kapandı.

O yüzden bu yazıda soruyu değiştiriyoruz: "MFA’yı açar mıyım" değil, "doğru nasıl yapılandırırım?" Çünkü sahada asıl hasar MFA’nın kapalı olmasından değil, yarım yapılandırılmış olmasından çıkıyor — yanlış araçla zorunlu kılmak, zayıf yöntemlere (SMS) güvenmek, acil erişim (break-glass) hesabını yanlış kurmak. Hepsini sırayla ele alacağız.

Önce 2026 gerçeği: zorunlu MFA nerede, ne zaman?

Microsoft’un zorunlu MFA dayatması iki fazda geldi:

• Faz 1 (Ekim 2024): Azure portalı, Microsoft Entra admin center ve Microsoft Intune admin center‘da CRUD işlemleri için MFA zorunlu. Microsoft 365 admin center ise Şubat 2025’ten itibaren kapsamda.
• Faz 2 (1 Ekim 2025): Azure CLI, Azure PowerShell, Azure mobil uygulaması, IaC araçları ve REST API (management.azure.com — control plane) üzerinden yapılan Create/Update/Delete işlemleri için MFA zorunlu. Salt okuma işlemleri kapsam dışı.

Bilmen gereken önemli ayrıntılar:

• Opt-out yok. Erteleme pencereleri (Faz 1 → 30 Eylül 2025, Faz 2 → 1 Temmuz 2026) bugün itibarıyla geçti.
• Break-glass / acil erişim hesapları da MFA’ya tabi — bunları passkey (FIDO2) ya da sertifika tabanlı kimlik doğrulama (CBA) ile kur.
• Workload identity’ler (managed identity, service principal) etkilenmez. Ama kullanıcı hesabını servis hesabı gibi kullanıyorsan, o MFA’ya takılır; bunları workload identity’ye taşı.
• Senkron hizmet hesabı etkilenmez — Entra Connect / Cloud Sync senkronun MFA dayatmasından etkilenmez.
• ROPC akışı MFA ile uyumsuz; eski kullanıcı adı+parola token akışları bozulur.

Ders: Dayatma gelmeden önce MFA’yı sen düzgün kur ki kullanıcı bir gün hata ekranıyla değil, senin planladığın akışla karşılaşsın.

MFA’yı zorunlu kılmanın 3 yolu — hangisi?

1) Security Defaults (Güvenlik Varsayılanları) — Ücretsiz, tek düğme, "hep ya da hiç". Tüm kullanıcılara MFA kaydı dayatır, legacy kimlik doğrulamayı engeller. Conditional Access lisansı (P1/P2) olmayan küçük ortamlar için iyi bir taban. Granularite yok.

2) Conditional Access (Koşullu Erişim) — önerilen — Entra ID P1/P2 gerektirir. Kimin, nereden, hangi uygulamaya, hangi koşulda MFA yapacağını ayrıntılı tanımlarsın. Lisansı olan her kurum için zorunlu MFA’ya hazırlanmanın ve break-glass istisnası tanımlamanın doğru yolu budur. Ayrıntıları Conditional Access temel senaryolar yazısında ele alıyoruz.

3) Legacy per-user MFA (eski, kullanıcı başına) — Kullanıcıyı tek tek "enabled/enforced" yapma yöntemi. Yeni kurulumda buradan başlama. Yönetimi zordur, Conditional Access ile çakışır ve Microsoft bu yönetim deneyimini geride bırakıyor.

Lisansın varsa: Conditional Access. Yoksa: Security Defaults. Per-user MFA’yı yeni bir temel olarak kurma.

Hangi yöntemleri açarsın: Authentication methods policy

MFA’yı zorunlu kılmak (CA/Security Defaults) ile hangi yöntemlerin kullanılabileceğini belirlemek ayrı işlerdir. Yöntemleri yönetmenin bugünkü doğru yeri Authentication methods policy‘dir: Microsoft Entra admin center → Entra ID → Authentication methods → Policies (rol: en az Authentication Policy Administrator).

Kritik geçiş uyarısı: Microsoft, eski MFA service settings ve SSPR politikalarında yöntem yönetimini kullanımdan kaldırdı. 30 Eylül 2025’ten itibaren yöntemler bu eski politikalarda yönetilemiyor. Hâlâ eski ekranlarda yönetiyorsan, Authentication methods policy’deki "Manage migration" akışıyla taşı: Pre-migration → Migration in Progress → Migration Complete. Ayrıca artık tek tek kullanıcı hedefleme kaldırıldı; yöntemleri gruplara ata.

Yöntem seçimi: güçlüyü aç, zayıfa güvenme

2026’da yön net: kimlik avına dayanıklı (phishing-resistant) yöntemler.

• Aç / teşvik et: Microsoft Authenticator (push + number matching — zaten varsayılan açık), passkey (FIDO2), Windows Hello for Business, sertifika tabanlı kimlik doğrulama.
• Azalt / bırak: SMS ve sesli arama. Zayıf ve Microsoft bunları aşamalı olarak geriletiyor. (Teyit edilecek takvim: 1 Eylül 2026’dan itibaren SMS/sesli yöntemi olan kullanıcılar passkey’e otomatik teşvik edilir; 1 Şubat 2027’de yalnızca SMS/sesli yöntemi olanlar zorunlu passkey kaydı ekranıyla karşılaşır.)

Pratik tavsiye: Yeni kurulumda SMS’i baştan tek faktör yapma; Authenticator’ı taban al, passkey’e geçişi planla.

Adım adım: Conditional Access ile MFA (P1/P2)

1. Önce yöntemleri hazırla: Authentication methods policy’de Authenticator ve passkey’i hedef gruplara aç; eski politikalardan göçü tamamla.
2. Break-glass hesaplarını hazırla: En az iki acil erişim hesabı; bunlara passkey/FIDO2 veya CBA ile güçlü MFA kur (tamamen muaf tutma — dayatma zaten muafiyet tanımıyor).
3. Yönetici MFA politikası: Conditional Access’te ayrıcalıklı rolleri (ya da tüm admin portallarını) hedefleyip "require multifactor authentication" (tercihen authentication strength = phishing-resistant) iste.
4. Tüm kullanıcılar MFA politikası: Ayrı bir CA politikasıyla tüm kullanıcılar için bulut uygulamalarına MFA iste; break-glass hesaplarını hariç tut.
5. Önce rapor/pilot: Politikayı report-only modda ya da pilot grupla başlat; oturum açma günlüklerinde etkiyi gör, sonra "On" yap.
6. Doğrula: Sign-in logs’ta MFA’nın hangi uygulama/koşulla tetiklendiğini izle; break-glass hesaplarının güçlü yöntemle girebildiğini bizzat test et.

Lisansın yoksa: Bu adımların yerine Security Defaults‘u aç. Granüler değildir ama korumasız bırakmaktan kat kat iyidir.

Sahadan tuzaklar

• Break-glass hesabını MFA’dan tamamen muaf tutmak. Dayatma muafiyet tanımıyor; doğrusu güçlü yöntemle (passkey/CBA) kurmak.
• SMS’e tek faktör olarak güvenmek. Zayıf ve geriletiliyor. Authenticator/passkey’e geç.
• Per-user MFA ile Conditional Access’i aynı anda, habersiz karıştırmak. Çelişen zorunluluklar beklenmedik istemler çıkarır.
• Eski MFA/SSPR ekranlarında yöntem yönetmeye devam etmek. 30 Eylül 2025 sonrası orada yönetilmiyor; göçü tamamla.
• Kullanıcı gibi davranan servis hesapları. Otomasyonu kullanıcı hesabıyla çalıştırıyorsan MFA’ya takılır; workload identity’ye taşı.
• Report-only’yi atlayıp doğrudan "On" demek. Önce etkiyi gör; yanlış kapsamda zorlamak kilitlenmeye yol açar.

Sonuç

Entra MFA’da iş artık "açmak" değil, doğru kurmak. Üç ayrı kararı ayır: MFA’yı neyle zorunlu kılacaksın (lisansın varsa Conditional Access, yoksa Security Defaults), hangi yöntemlere izin vereceksin (Authentication methods policy — eski politikalardan göçü tamamlayarak) ve hangi güçlü yöntemi taban alacaksın (Authenticator + number matching, passkey; SMS’ten uzaklaş). Üstüne break-glass hesaplarını güçlü yöntemle kur, politikayı önce report-only ile prova et. MFA’yı kime ve hangi koşulda soracağını yöneten katman için Conditional Access temel senaryolar yazısına geç.