Microsoft Azure Zorunlu MFA Nasıl Yapılandırılır? (2026)

Özet (TL;DR): Microsoft, Azure ve yönetici portallarına erişimde çok faktörlü kimlik doğrulamayı (MFA) zorunlu hâle getiriyor. Faz 1 (Azure portalı, Entra ve Intune yönetim merkezleri, Microsoft 365 yönetim merkezi) 2024–2025 boyunca; Faz 2 (Azure CLI, Azure PowerShell, Azure mobil uygulaması, IaC araçları ve Azure Resource Manager REST API'leri) ise 1 Ekim 2025'ten itibaren uygulamaya alındı. Karmaşık ortamlar için tanınan son erteleme tarihi 1 Temmuz 2026'ydı ve bu pencere artık kapandı — yani enforcement tüm kiracılara (tenant) yayılıyor. Bu rehber; lisans ve rol ön gereksinimlerinden başlayarak, P1/P2 lisansıyla report-only Koşullu Erişim politikası kurma, ücretsiz lisansta güvenlik varsayılanları (security defaults), Faz 2 için servis hesaplarını iş yükü kimliklerine taşıma, break-glass hesaplarını FIDO2/sertifika ile MFA'ya uygun hâle getirme ve enforcement'ı aka.ms/postponePhase2MFA üzerinden doğrulama adımlarını uçtan uca anlatır.

Zorunlu MFA Nedir ve Neden Şimdi Aksiyon Almalısınız?

Microsoft'un resmi belgelerine göre MFA, hesap ele geçirme saldırılarının %99,2'sinden fazlasını engelleyebiliyor. Bu nedenle Microsoft, Azure oturum açma girişimlerinde MFA'yı kiracı bazında kademeli olarak zorunlu kılan bir program başlattı. Bu, isteğe bağlı bir öneri değil; devre dışı bırakılamayan, tüm kiracıları kapsayan bir güvenlik dayatmasıdır.

Enforcement iki fazda ilerliyor:

• Faz 1 — Yönetici portalları: Ekim 2024'ten itibaren Azure portalı, Microsoft Entra yönetim merkezi ve Microsoft Intune yönetim merkezinde herhangi bir oluşturma/okuma/güncelleme/silme (CRUD) işlemi için MFA gerekir. Microsoft 365 yönetim merkezi (admin.microsoft.com, admin.cloud.microsoft, portal.office.com/adminportal/home) için enforcement Şubat 2025'te başladı.
• Faz 2 — Kaynak yönetim araçları: 1 Ekim 2025'ten itibaren Azure CLI, Azure PowerShell, Azure mobil uygulaması, Infrastructure as Code (IaC) araçları ve Azure Resource Manager REST API uç noktaları üzerinden yapılan oluşturma/güncelleme/silme işlemleri MFA gerektirir. Salt okuma (read) işlemleri MFA gerektirmez — bu ayrım Faz 2'nin en kritik detaylarından biridir.

Faz 2 enforcement, sunucu tarafında Azure Resource Manager katmanında çalışır: https://management.azure.com adresine giden her yönetim isteği kapsam dâhilindedir. Buna karşılık Microsoft Graph API çağrıları genel olarak kapsam dışıdır — yalnızca ARM'a giden istekler tetiklenir. Bu, Microsoft Azure altyapınızı yöneten her ekibin otomasyon ve script envanterini gözden geçirmesini gerektirir.

Aciliyet nedeni: Karmaşık ortamlar veya teknik engeller için Microsoft, Faz 2 enforcement'ını en geç 1 Temmuz 2026'ya kadar erteleme imkânı tanımıştı. Bu tarih geçtiğine göre erteleme penceresi kapandı; enforcement tüm kiracılara yayılıyor. Hâlâ MFA'sız oturum açan yönetici veya otomasyon hesaplarınız varsa, kaynak oluşturma/güncelleme/silme işlemleri hata almaya başlar. Bu yüzden doğrulama ve yapılandırma artık ertelenemez bir görevdir.

Ön Gereksinimler: Lisans, Roller ve Hangi Hesaplar Kapsamda?

Yapılandırmaya başlamadan önce üç boyutu netleştirin:

• Lisans: Kendi kurallarınızı tanımlayan Koşullu Erişim (Conditional Access) politikaları için Microsoft Entra ID P1 veya P2 gerekir (Microsoft 365 E3 P1'i, E5 ise P2'yi içerir). Lisansınız yoksa güvenlik varsayılanları (security defaults) veya kullanıcı başına (per-user) MFA ile ilerlersiniz.
• Roller: Koşullu Erişim politikası oluşturmak için en az Conditional Access Administrator; güvenlik varsayılanlarını açmak için Security Administrator; kullanıcı başına MFA için Authentication Administrator; mevcut durumu okumak için Global Reader rolü gerekir. En az ayrıcalık için bu rolleri Privileged Identity Management (PIM) ile ihtiyaç anında aktive edin.
• Kapsam: Enforcement, ilgili uygulamalarda işlem yapan tüm kullanıcı hesaplarını kapsar — öğrenci hesabı, break-glass hesabı, etkin veya uygun (eligible) rol taşıyan yönetici hesabı ayrımı yoktur. İş yükü kimlikleri (managed identity, service principal) ise kapsam dışıdır. Kullanıcı kimliğiyle çalışan otomasyon hesapları kapsamdadır ve iş yükü kimliğine taşınmalıdır.

Adım 1: Kiracının Mevcut MFA Durumunu Tespit Etme

İlk iş, hangi kullanıcıların MFA ile, hangilerinin MFA'sız oturum açtığını görmektir. Böylece enforcement başladığında kimin etkileneceğini önceden bilirsiniz:

1. Azure portalına Global Reader rolüyle girin, Entra ID > Overview yolundan kiracının lisans tipini (P1/P2 mi, yoksa Free/M365 mi) doğrulayın.
2. MFA'lı ve MFA'sız oturum açan kullanıcıları listelemek için Microsoft'un PowerShell script'iyle (aka.ms/AzMFA) kullanıcıların kimlik doğrulama yöntemlerini dışa aktarın.
3. Oturum açma günlüklerini (sign-in logs) analiz ederken kapsamdaki uygulamaların App ID'lerini filtre olarak kullanın: Azure CLI 04b07795-8ddb-461a-bbee-02f9e1bf7b46, Azure PowerShell 1950a258-227b-4e31-a9cf-717495945fc2, Azure mobil uygulaması 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa, Azure portalı/Entra/Intune yönetim merkezi c44b4083-3bb0-49c1-b47d-974e53cbdf3c.

Bu envanter, özellikle kullanıcı hesabı olarak kullanılan servis hesaplarını (user-based service accounts) ortaya çıkarır. Bunlar Faz 2'de kırılacak ilk şeylerdir; erken tespit, kesinti riskini ciddi biçimde azaltır.

Adım 2: P1/P2 Lisansıyla Koşullu Erişim Politikası (Report-Only)

Microsoft'un önerdiği birincil yöntem, tüm kullanıcılara MFA gerektiren bir Koşullu Erişim politikasıdır. Kritik kural: Politikayı asla doğrudan açık (On) modda oluşturmayın; önce report-only modunda etkisini ölçün, aksi hâlde kendi yöneticilerinizi kilitleyebilirsiniz. Adımlar:

1. Microsoft Entra yönetim merkezine (entra.microsoft.com) en az Conditional Access Administrator rolüyle girin.
2. Entra ID > Conditional Access > Policies yolunu izleyip New policy seçin ve anlamlı bir ad verin (örn. CA01 - All Users: Admin Portals + ARM - Require MFA).
3. Assignments > Users or workload identities > Include altında All users'ı (veya kapsamdaki kullanıcı grubunu) seçin.
4. Exclude sekmesine break-glass acil durum hesaplarınızı ekleyin — bu adım atlanırsa kilitlenme riski en yükseğe çıkar.
5. Target resources > Cloud apps > Include > Select apps altında Microsoft Admin Portals ve Windows Azure Service Management API uygulamalarını seçin. İkincisi, Azure CLI/PowerShell/ARM trafiğini kapsayan anahtar uygulamadır.
6. Access controls > Grant > Grant access altında Require authentication strength > Multifactor authentication'ı seçip onaylayın.
7. Enable policy alanını Report-only yapıp Create deyin.

Politika report-only iken kullanıcı engellenmez veya MFA tetiklenmez; ancak oturum açma günlüğünde "ne olurdu?" verisi toplanır. En az bir hafta veri topladıktan sonra Insights & Reporting workbook'u veya bireysel oturumun Report-only sekmesinden etkiyi doğrulayın; beklenen aralıktaysa politikayı On yapın. Daha güçlü, kimlik avına dirençli (phishing-resistant) MFA gerektiren daha kısıtlayıcı politikalarınız varsa, bunlar bu zorunluluktan bağımsız olarak yürürlükte kalır.

Adım 3: Ücretsiz/M365 Lisansında Güvenlik Varsayılanları veya Per-User MFA

Microsoft Entra ID Free veya yalnızca Microsoft 365 lisansınız varsa Koşullu Erişim yoktur; iki seçenek kalır:

Güvenlik varsayılanları (security defaults) — önerilen

1. Entra yönetim merkezine en az Security Administrator rolüyle girin.
2. Entra ID > Overview > Properties yolunu izleyin.
3. Manage security defaults'a tıklayın.
4. Security defaults'ı Enabled yapıp Save deyin.

Güvenlik varsayılanları tüm kullanıcılar için Microsoft Authenticator tabanlı MFA'yı devreye alır; ancak kendi kurallarınızı (istisna, koşul) tanımlayamazsınız. Not: Koşullu Erişim politikası oluşturduğunuzda güvenlik varsayılanları otomatik devre dışı kalır — ikisi birlikte kullanılamaz.

Kullanıcı başına (per-user) MFA — daha kaba araç

1. Entra yönetim merkezine en az Authentication Administrator rolüyle girin.
2. Entra ID > Users altında bir kullanıcı seçin ve Enable MFA'ya tıklayıp onaylayın.
3. Kullanıcıları etkinleştirdikten sonra e-posta ile bilgilendirin; bir sonraki oturumda kayıt (register) istenir.

Per-user MFA'da kullanıcı her oturumda MFA yapar; esnekliği düşüktür. Mümkünse P1/P2'ye yükselip Koşullu Erişim'e geçmek uzun vadede daha yönetilebilirdir. Alternatif olarak, Koşullu Erişim'e erişimi olmayan kiracılar Azure Policy ile MFA'yı denetleme (Audit) modunda test edip ardından zorlama (Enforcement) moduna alarak etkiyi öngörebilir.

Adım 4: Faz 2'ye Özel Hazırlık — Otomasyon ve Servis Hesapları

Faz 2 kesintilerinin ezici çoğunluğu, kullanıcı kimliğiyle çalışan otomasyondan kaynaklanır. Hazırlık kontrol listesi:

• Kullanıcı tabanlı servis hesaplarını iş yükü kimliklerine taşıyın. Script ve otomasyonlarınız bir kullanıcı adı/parola ile https://management.azure.com'a gidiyorsa, bunları managed identity veya service principal ile kimlik doğrulamaya geçirin. İş yükü kimlikleri MFA zorunluluğunun dışındadır.
• ROPC akışından uzaklaşın. OAuth 2.0 Resource Owner Password Credentials (ROPC) akışı MFA ile uyumsuzdur; MFA etkinleştikten sonra ROPC tabanlı API'ler istisna fırlatır. MSAL ve Azure Identity kütüphanelerindeki UsernamePasswordCredential / AcquireTokenByUsernamePassword çağrıları ile AZURE_USERNAME+AZURE_PASSWORD ortam değişkenlerine dayanan DefaultAzureCredential kullanımlarını gözden geçirin.
• İstemci sürümlerini güncelleyin. En iyi uyumluluk için kullanıcıların Azure CLI 2.76 ve Azure PowerShell 14.3 veya üzeri sürümleri kullandığından emin olun; eski sürümler claims-challenge'ı işleyemeyip hata mesajı döndürebilir.
• Adım-yukarı (step-up) davranışını test edin. MFA'sız oturum açan bir kullanıcı Faz 2 uygulamasını açabilir, ancak kaynak oluşturmaya/güncellemeye/silmeye çalıştığında "MFA gerekli" hatası ve bir claims-challenge alır. Bazı istemciler bu challenge ile kullanıcıyı MFA'ya yönlendirir; bazıları yalnızca hata döndürür. Bu yüzden bir Koşullu Erişim politikası veya güvenlik varsayılanları ile kullanıcıların MFA'yı önceden tamamlaması önerilir.

Adım 5: Break-Glass Hesapları ve Kimlik Sağlayıcı Senaryoları

Acil durum (break-glass) hesapları da enforcement başladığında MFA ile oturum açmak zorundadır — bunlar için bile istisna yoktur. Ancak bu hesapların SMS gibi kırılgan yöntemlere bağlanması istenmez. Microsoft'un önerisi:

• Break-glass hesaplarını passkey (FIDO2) veya sertifika tabanlı kimlik doğrulama (CBA) ile yapılandırın; her iki yöntem de MFA gereksinimini karşılar ve telefon/uygulama bağımlılığı taşımaz.
• Kiracıda en az iki bulut tabanlı break-glass hesabı bulundurun, parolalarını uzun rastgele dizeler olarak fiziksel kasada saklayın ve ayda bir oturum açma testi yapın.

Üçüncü taraf veya federe kimlik sağlayıcı kullanıyorsanız:

• Harici MFA (external MFA): Üçüncü taraf MFA çözümleri, external method provider ile Entra ID'ye doğrudan entegre edilerek MFA gereksinimini karşılayabilir. Eski "Conditional Access custom controls" önizlemesi bu gereksinimi karşılamaz; harici MFA'ya geçmelisiniz.
• Federe IdP (örn. AD FS): MFA'nız doğrudan federe kimlik sağlayıcıya bağlıysa, IdP'nin Entra ID'ye multipleauthn MFA claim'i gönderecek şekilde yapılandırılması gerekir.

Not: Microsoft Entra Connect ve Cloud Sync senkronizasyon servis hesapları bu zorunluluktan etkilenmez; yalnızca listelenen uygulamalara oturum açan hesaplar MFA gerektirir.

Adım 6: Enforcement'ı Doğrulama ve Erteleme Durumunu Kontrol Etme

Yapılandırmayı tamamladıktan sonra kiracıda enforcement'ın hangi fazda olduğunu doğrulayın:

• Faz 1 durumu: Azure portalına Global Administrator olarak girin, aka.ms/managemfaforazure adresine gidin ve Multifactor authentication (Phase 1) sayfasındaki banner'ın enforcement'ın başladığını doğruladığını kontrol edin.
• Faz 2 durumu: aka.ms/postponePhase2MFA adresine gidin; Multifactor authentication (Phase 2) sayfasındaki banner enforcement'ın başlangıç durumunu gösterir. Erteleme penceresi 1 Temmuz 2026'da kapandığı için burada enforcement'ın etkin olduğunu görmelisiniz.
• Oturum açma günlükleri: Microsoft Entra oturum açma günlükleri, MFA gereksinimini uygulayan uygulamayı kaynak olarak gösterir — hangi isteğin MFA'yı tetiklediğini buradan izleyebilirsiniz.

Faz 2 enforcement başladıktan sonra hâlâ kritik bir teknik engeliniz varsa, bir Global Administrator, güvenlik gerekçesiyle Microsoft Yardım ve Destek üzerinden geçici bir kaldırma talebinde bulunabilir. Bu kalıcı bir opt-out değildir; enforcement'tan tamamen çıkış yolu yoktur.

Yaygın 5 Hata ve Çözümleri

1. Break-glass hesabını politikadan hariç tutmayı unutmak. "All users + Require MFA" politikası tüm yöneticileri kapsar; MFA yöntemi bozulduğunda kiracıya girilemez. Çözüm: İki break-glass hesabını her politikadan exclude edin ve bunları FIDO2/CBA ile MFA'ya uygun hâle getirin.
2. Politikayı doğrudan On modda oluşturmak. Report-only fazını atlamak, beklenmedik kilitlenmelerin bir numaralı nedenidir. Çözüm: Her yeni politikayı en az 7 gün report-only'de izleyin, Insights workbook'ta etkiyi doğrulayın, sonra On yapın.
3. Kullanıcı tabanlı servis hesaplarını göz ardı etmek. Bir kullanıcı adı/parola ile ARM'a giden script'ler Faz 2'de kırılır. Çözüm: Bunları managed identity veya service principal'a taşıyın; MFA zorunluluğunun dışında kalırlar.
4. Eski CLI/PowerShell sürümleriyle çalışmak. Claims-challenge işlenemeyince kullanıcı MFA prompt'u yerine yalın hata görür. Çözüm: Azure CLI 2.76 / Azure PowerShell 14.3 veya üzerine yükseltin ve bir Koşullu Erişim politikasıyla MFA'yı önceden tamamlatın.
5. Salt okuma ile yazma işlemlerini karıştırmak. Faz 2'de read işlemleri MFA gerektirmediği için "her şey çalışıyor" sanılır; ilk create/update/delete anında hata gelir. Çözüm: Test senaryolarınıza mutlaka bir kaynak oluşturma/güncelleme adımı ekleyin, sadece listeleme ile test etmeyin.

Sıkça Sorulan Sorular (SSS)

Faz 2 zorunlu MFA hangi hesapları etkiler?

Azure kaynak yönetimi işlemlerini herhangi bir Azure istemcisi (PowerShell, CLI, SDK, REST API) üzerinden yapan tüm kullanıcı hesapları kapsamdadır; enforcement sunucu tarafında olduğu için https://management.azure.com'a giden her istek dâhildir. Managed identity veya service principal kullanan otomasyon hesapları kapsam dışıdır. Kullanıcı kimliği olarak kurulmuş otomasyon hesapları ise enforcement'a takılır.

Salt okuma (read) işlemleri de MFA gerektiriyor mu?

Hayır. Faz 2'de yalnızca oluşturma, güncelleme ve silme işlemleri MFA gerektirir; read işlemleri gerektirmez. Bu nedenle bir kullanıcı MFA'sız oturum açıp kaynak listeleyebilir, ancak bir kaynağı değiştirmeye çalıştığında "MFA gerekli" hatası ve claims-challenge alır.

Microsoft Graph API çağrıları da kapsamda mı?

Genel olarak hayır. Azure MFA enforcement yalnızca https://management.azure.com/'a gönderilen istekleri kapsar. Microsoft Graph API'leri bu Azure kaynak yönetimi enforcement'ının kapsamı dışındadır.

Erteleme tarihini kaçırdım; şimdi ne olur?

Faz 2 için son erteleme tarihi 1 Temmuz 2026'ydı ve bu pencere kapandı. Enforcement kiracınıza yayılıyor; MFA'sız kullanıcılar create/update/delete işlemlerinde hata almaya başlar. Kritik bir teknik engeliniz varsa bir Global Administrator, güvenlik gerekçesiyle Microsoft Yardım ve Destek üzerinden geçici kaldırma talep edebilir — ancak kalıcı bir opt-out yoktur.

Test veya geliştirme kiracıları muaf mı?

Hayır. Yalnızca test amaçlı kullanılsa bile her Azure kiracısı MFA gerektirir; test ortamları için istisna yoktur. Ayrıca enforcement, Azure genel bulutunda uygulanır; Azure for US Government ve diğer egemen (sovereign) bulutlarda şu an uygulanmaz.

Zaten tüm kullanıcılarım için MFA açıksa bir şey yapmam gerekir mi?

Kapsamdaki uygulamalara erişen kullanıcılarınız için MFA'yı zaten zorunlu kılıyorsanız değişiklik hissetmezsiniz. Yalnızca bir kullanıcı alt kümesi için MFA zorunluysa, henüz MFA kullanmayan kullanıcılar bu uygulamalara oturum açtıklarında artık MFA yapmak zorunda kalır. Passwordless veya passkey (FIDO2) gibi daha güçlü yöntemler de gereksinimi karşılar.

B2B misafir hesapları enforcement'a tabi mi?

Evet. MFA'nın ya kaynak kiracısında ya da kullanıcının ana (home) kiracısında karşılanması gerekir; ana kiracı, cross-tenant access ile kaynak kiracıya MFA claim'i gönderecek şekilde doğru yapılandırılmışsa bu koşul sağlanır.

Sonuç: Zorunluluk Değil, Baseline Hijyen

Azure zorunlu MFA, "yapılması iyi olur" listesinden çıkıp devre dışı bırakılamayan bir platform gereksinimi hâline geldi. Faz 1 yönetici portallarını, Faz 2 ise kaynak yönetim araçlarını kapsıyor ve 1 Temmuz 2026 son erteleme tarihinin geçmesiyle artık tüm kiracılara yayılıyor. İşin özü sürpriz yaşamamaktır: kimin MFA'sız oturum açtığını tespit edin, P1/P2 varsa report-only bir Koşullu Erişim politikasıyla başlayın, ücretsiz lisansta güvenlik varsayılanlarını açın ve en kritik adım olarak kullanıcı tabanlı servis hesaplarını iş yükü kimliklerine taşıyın.

Doğru sıralama — önce tespit, sonra report-only test, sonra üretime alma ve break-glass hesaplarını FIDO2/CBA ile sağlamlaştırma — hem güvenliği artırır hem de yardım masasında ilk gün yığılmasını önler. Microsoft güvenlik çözümleri ile MFA'yı, Sıfır Güven mimarisinin daha geniş bir parçası olarak konumlandırmak, tek seferlik bir enforcement görevini kalıcı bir hijyen refleksine dönüştürür.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun zorunlu MFA'ya geçiş yolculuğunda mevcut durum tespitinden Koşullu Erişim politika tasarımına, servis hesaplarının iş yükü kimliklerine taşınmasından break-glass kasası operasyonuna kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.