Microsoft, Azure yönetim hizmetleri ve yönetici portallarına erişimde çok faktörlü kimlik doğrulamayı (MFA) platform düzeyinde zorunlu hale getirdi. Kimlik tabanlı saldırılara karşı güvenliği artırmayı amaçlayan bu uygulama, Microsoft’un paylaştığı verilere göre hesap ele geçirme girişimlerinin %99,2’den fazlasını engelleyebilen MFA’yı tüm uygun Azure kiracıları için temel bir güvenlik standardına dönüştürüyor. İlk aşamada Azure Portal, Microsoft Entra Yönetim Merkezi, Microsoft Intune Yönetim Merkezi ve Microsoft 365 Yönetim Merkezi kapsam altına alınırken, ikinci aşamada Azure CLI, Azure PowerShell, Azure mobil uygulaması, Infrastructure as Code (IaC) araçları ve Azure Resource Manager (ARM) REST API’leri üzerinden gerçekleştirilen kaynak yönetimi işlemleri de zorunlu MFA kapsamına dahil edildi. Karmaşık BT altyapılarına sahip kuruluşlara tanınan son erteleme süresinin 1 Temmuz 2026 tarihinde sona ermesiyle birlikte uygulama, uygun Azure kiracılarına kademeli olarak uygulanmaya devam ediyor.

Bu rehberde, Azure zorunlu MFA geçişine hazırlanırken dikkate alınması gereken tüm teknik adımları ayrıntılı şekilde ele alıyoruz. Lisans ve yönetici rolü gereksinimlerinden başlayarak Koşullu Erişim (Conditional Access) politikalarının Report-only modunda test edilmesi, Microsoft Entra ID P1/P2 lisansı bulunmayan ortamlarda Security Defaults yapılandırılması, kullanıcı tabanlı otomasyon hesaplarının Workload Identity mimarisine dönüştürülmesi, break-glass hesaplarının FIDO2 güvenlik anahtarı veya Certificate-Based Authentication (CBA) ile korunması ve zorunlu MFA uygulamasının doğrulanması gibi kritik konuları adım adım açıklıyoruz. Ayrıca geçiş sürecinde en sık karşılaşılan yapılandırma hatalarını, olası hizmet kesintilerini önlemeye yönelik önerileri ve başarılı bir geçiş için uygulanabilecek en iyi yöntemleri de detaylı olarak paylaşıyoruz.

Microsoft Zorunlu MFA Uygulaması Neleri Değiştiriyor?

Kimlik tabanlı saldırılar, kurumsal BT ortamlarında en sık karşılaşılan güvenlik tehditleri arasında bulunuyor. Ele geçirilen parolalar, kimlik avı (phishing) saldırıları ve oturum çalma yöntemleri, yalnızca kullanıcı adı ile parola kullanan hesapların kolayca istismar edilmesine neden olabiliyor. Microsoft tarafından paylaşılan verilere göre çok faktörlü kimlik doğrulama (MFA), hesap ele geçirme girişimlerinin %99,2’den fazlasını engelleyebiliyor. Bu nedenle şirket, Azure yönetim hizmetlerinde MFA kullanımını isteğe bağlı bir güvenlik önerisi olmaktan çıkararak zorunlu bir platform gereksinimi haline getirdi. Uygulama kapatılamıyor ve kapsam içerisindeki tüm Azure kiracılarını (tenant) doğrudan etkiliyor.

💡Microsoft, zorunlu MFA geçişini iki farklı aşamada uygulamaya aldı:

İlk Aşama – Yönetim Merkezleri: Geçişin ilk bölümünde Azure Portal, Microsoft Entra Yönetim Merkezi ve Microsoft Intune Yönetim Merkezi üzerinden gerçekleştirilen yönetim işlemlerinde MFA zorunlu hale getirildi. Daha sonraki süreçte Microsoft 365 Yönetim Merkezi de aynı kapsama alınarak yönetici hesaplarının ek doğrulama katmanıyla korunması sağlandı.

İkinci Aşama – Azure Kaynak İşlemleri: İkinci aşamayla birlikte Azure CLI, Azure PowerShell, Azure mobil uygulaması, Infrastructure as Code (IaC) araçları ve Azure Resource Manager (ARM) REST API’leri kullanılarak gerçekleştirilen kaynak oluşturma, güncelleme ve silme işlemlerinde Azure MFA zorunlu hale geldi. Kaynakları listeleme veya görüntüleme gibi yalnızca okuma (read) yetkisi gerektiren işlemler ise uygulamanın kapsamına dahil edilmedi.

Bu aşamanın en kritik teknik noktası, MFA denetiminin istemci uygulamalarında değil Azure Resource Manager katmanında gerçekleştirilmesidir. Başka bir ifadeyle, https://management.azure.com adresine iletilen tüm yönetim istekleri Azure tarafından sunucu tarafında değerlendirilir ve gerekli görülen durumlarda MFA doğrulaması talep edilir. Buna karşılık Microsoft Graph API üzerinden gerçekleştirilen işlemler genel olarak bu zorunluluğun dışında kalmaktadır. Bu nedenle Azure ortamlarını PowerShell betikleri, Azure CLI komutları, REST API’leri veya otomasyon araçlarıyla yöneten kuruluşların mevcut otomasyonlarını ve kullanıcı tabanlı servis hesaplarını yeniden değerlendirmesi önem taşımaktadır.

Zorunlu MFA’ya geçiş için tanınan erteleme süreci artık sona ermiştir. Özellikle karmaşık BT altyapılarına sahip kuruluşlara sağlanan son erteleme tarihi olan 1 Temmuz 2026 geride kalmış olup, Azure MFA enforcement uygun Azure kiracılarına kademeli olarak uygulanmaktadır. Bu süreçte MFA kullanmayan yönetici veya otomasyon hesapları, kaynak oluşturma, güncelleme ve silme işlemlerinde erişim hatalarıyla karşılaşabilir. Bu nedenle gerekli hazırlıkların daha fazla ertelenmesi mümkün değildir.

Kuruluşların öncelikle MFA etkin olmayan hesaplarını belirlemesi, Koşullu Erişim (Conditional Access) politikalarını kontrollü biçimde devreye alması, kullanıcı tabanlı otomasyon hesaplarını Workload Identity mimarisine dönüştürmesi ve acil durum (break-glass) hesaplarını FIDO2 güvenlik anahtarları veya sertifika tabanlı kimlik doğrulama yöntemleriyle güvence altına alması önerilmektedir. Bu hazırlıklar, hem hizmet sürekliliğinin korunmasını hem de Microsoft’un zorunlu MFA gereksinimlerine sorunsuz uyum sağlanmasını destekleyecektir.

Yapılandırmaya Başlamadan Önce Bilmeniz Gereken Gereksinimler

Zorunlu MFA yapılandırmasına geçmeden önce lisans gereksinimlerini, yetkili yönetici rollerini ve uygulamanın hangi hesap türlerini etkilediğini netleştirmeniz gerekir. Bu üç başlığın doğru değerlendirilmesi, geçiş sürecinde yaşanabilecek erişim sorunlarının önüne geçilmesini sağlar.

Lisans Gereksinimi: Kendi Koşullu Erişim (Conditional Access) ilkelerinizi oluşturabilmek için Microsoft Entra ID P1 veya P2 lisansına sahip olmanız gerekir. Microsoft 365 E3 paketleri Entra ID P1’i, Microsoft 365 E5 paketleri ise Entra ID P2’yi içerir. Bu Azure MFA lisans gereksinimlerine sahip olmayan kuruluşlar, MFA yapılandırmasını yalnızca Security Defaults veya kullanıcı bazlı (per-user) MFA seçenekleriyle gerçekleştirebilir.

Yetkili Roller: Koşullu Erişim ilkeleri oluşturabilmek için en az Conditional Access Administrator rolü gereklidir. Security Defaults özelliğini yönetmek için Security Administrator, kullanıcı bazlı MFA ayarlarını yapılandırmak için Authentication Administrator ve mevcut yapılandırmayı görüntülemek için Global Reader rolü yeterlidir. En az ayrıcalık (Least Privilege) ilkesini koruyabilmek adına bu rollerin Microsoft Entra Privileged Identity Management (PIM) üzerinden yalnızca ihtiyaç duyulduğunda etkinleştirilmesi önerilir.

Kapsama Giren Hesaplar: Zorunlu MFA denetimi, ilgili yönetim uygulamalarında işlem gerçekleştiren tüm kullanıcı hesaplarını kapsar. Öğrenci hesapları, acil durum (break-glass) hesapları ile etkin (active) veya uygun (eligible) yönetici rollerine sahip kullanıcılar arasında herhangi bir ayrım yapılmaz. Buna karşılık Managed Identity ve Service Principal gibi iş yükü kimlikleri bu zorunluluğun dışında tutulur. Kullanıcı kimliğiyle çalışan otomasyon hesapları ise uygulama kapsamındadır ve mümkün olan en kısa sürede Workload Identity tabanlı yapıya dönüştürülmelidir.

Bu ön koşulların eksiksiz şekilde doğrulanması, zorunlu MFA geçişinin planlı ilerlemesini sağlayarak yetkilendirme hatalarının, otomasyon kesintilerinin ve beklenmeyen erişim problemlerinin önüne geçilmesine yardımcı olacaktır.

Adım 1: Azure Kiracısındaki Mevcut MFA Durumunu Analiz Edin

Yapılandırma sürecine başlamadan önce kiracınızdaki mevcut MFA kullanımını ayrıntılı şekilde analiz etmeniz gerekir. Böylece zorunlu MFA uygulaması devreye girdiğinde hangi kullanıcıların ve hesapların etkileneceğini önceden belirleyebilir, gerekli hazırlıkları planlı şekilde gerçekleştirebilirsiniz.

💡İlk değerlendirme için aşağıdaki kontrolleri yapın:

✅ Lisans durumunu doğrulayın: Azure portalına Global Reader rolüyle giriş yapın ve Microsoft Entra ID > Overview bölümünden kiracınızın Microsoft Entra ID P1/P2 veya Free/Microsoft 365 lisansına sahip olup olmadığını kontrol edin.

✅ Kimlik doğrulama yöntemlerini raporlayın: Microsoft’un aka.ms/AzMFA adresinde sunduğu PowerShell betiğini kullanarak kullanıcıların kayıtlı kimlik doğrulama yöntemlerini dışa aktarın. Bu Azure MFA raporlama aracı, MFA kullanan ve kullanmayan hesapları hızlı şekilde belirlemenizi sağlar.

✅ Oturum açma günlüklerini filtreleyin: Sign-in Logs kayıtlarını incelerken yalnızca zorunlu MFA kapsamındaki uygulamaların App ID değerlerini 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) ile Azure Portal, Microsoft Entra Yönetim Merkezi ve Microsoft Intune Yönetim Merkezi (c44b4083-3bb0-49c1-b47d-974e53cbdf3c) bu analizde öncelikli olarak incelenmelidir.

Bu envanter çalışması, özellikle kullanıcı hesabıyla çalışan servis hesaplarını (user-based service accounts) ortaya çıkarmak açısından kritik öneme sahiptir. Faz 2 kapsamında ilk etkilenecek hesaplar genellikle bunlar olacağından, önceden tespit edilip gerekli dönüşümler planlandığında erişim sorunları ve hizmet kesintileri önemli ölçüde azaltılabilir.

Adım 2: Koşullu Erişim Politikasını Report-Only Modunda Oluşturun

Microsoft, Microsoft Entra ID P1 veya P2 lisansına sahip kuruluşlar için zorunlu MFA geçişinde Koşullu Erişim (Conditional Access) politikalarının kullanılmasını önerir. Ancak bu politikanın doğrudan On durumunda etkinleştirilmesi önerilmez. İlk aşamada Report-only modunda çalıştırılarak kullanıcılar üzerindeki etkisi analiz edilmeli, olası erişim sorunları tespit edildikten sonra üretim ortamında etkinleştirilmelidir.

💡Politikayı oluşturmak için aşağıdaki adımları izleyin:

1. Microsoft Entra Yönetim Merkezi’ne giriş yapın: entra.microsoft.com adresinden, en az Conditional Access Administrator rolüne sahip bir hesapla oturum açın.
2. Yeni bir Koşullu Erişim politikası oluşturun: Microsoft Entra ID > Conditional Access > Policies yolunu izleyin, ardından New policy seçeneğini kullanarak yeni bir politika oluşturun. Daha sonra kolay yönetebilmek için CA01 – All Users: Admin Portals + ARM – Require MFA benzeri açıklayıcı bir ad belirleyin.
3. Kapsama alınacak kullanıcıları seçin: Assignments > Users or workload identities > Include bölümünde All users seçeneğini veya MFA uygulanmasını istediğiniz kullanıcı grubunu belirleyin.
4. Break-glass hesaplarını hariç tutun: Exclude sekmesinden acil durum (break-glass) hesaplarını mutlaka dışarıda bırakın. Bu hesapların kapsam dışında tutulmaması, yönetici hesaplarının tamamının erişimini kaybetmesine neden olabilir.
5. Hedef uygulamaları belirleyin: Target resources > Cloud apps > Include > Select apps bölümünde Microsoft Admin Portals ile Windows Azure Service Management API uygulamalarını seçin. Özellikle Windows Azure Service Management API, Azure CLI, Azure PowerShell ve Azure Resource Manager trafiğini kapsadığı için kritik öneme sahiptir.
6. Erişim denetimini yapılandırın: Access controls > Grant > Grant access bölümüne gidin ve Require authentication strength > Multifactor authentication seçeneğini işaretleyerek MFA zorunluluğunu tanımlayın.
7. Politikayı Report-only modunda kaydedin: Son olarak Enable policy alanında Report-only seçeneğini belirleyin ve Create düğmesiyle politikayı oluşturun.

Report-only modunda çalışan bir Koşullu Erişim politikası kullanıcıların erişimini engellemez ve MFA istemez. Bunun yerine oturum açma denemelerini analiz ederek politika etkinleştirildiğinde hangi kullanıcıların etkileneceğini gösterir. Bu değerlendirme tamamlandıktan sonra politikanın güvenli şekilde etkin moda alınması çok daha düşük riskle gerçekleştirilebilir. 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: Koşullu Erişim Lisansı Olmayan Ortamlarda MFA’yı Etkinleştirin

Microsoft Entra ID Free veya yalnızca Microsoft 365 lisansına sahip kuruluşlarda Koşullu Erişim (Conditional Access) kullanılamaz. Bu durumda zorunlu MFA hazırlıkları için iki farklı yöntem tercih edilebilir. Microsoft’un önerdiği seçenek Security Defaults olsa da, ihtiyaç halinde kullanıcı bazlı MFA yapılandırması da uygulanabilir.

✅ Güvenlik Varsayılanlarını (Security Defaults) Etkinleştirin — Önerilen Yöntem

• Microsoft Entra Yönetim Merkezi’ne en az Security Administrator rolüne sahip bir hesapla giriş yapın.
• Microsoft Entra ID > Overview > Properties yolunu izleyin.
• Manage security defaults seçeneğini açın.
• Security defaults ayarını Enabled konumuna getirip değişiklikleri Save ile kaydedin.

Security Defaults etkinleştirildiğinde tüm kullanıcılar için Microsoft Authenticator tabanlı çok faktörlü kimlik doğrulama devreye alınır. Ancak bu yöntem, kullanıcı veya grup bazında istisna tanımlama ya da koşullu kurallar oluşturma imkânı sunmaz. Ayrıca Koşullu Erişim politikaları oluşturulduğunda Security Defaults otomatik olarak devre dışı bırakılır. Bu nedenle iki özellik aynı kiracı üzerinde birlikte kullanılamaz.

✅ Kullanıcı Bazlı MFA’yı (Per-User MFA) Yapılandırın — Alternatif Yöntem

• Microsoft Entra Yönetim Merkezi’ne en az Authentication Administrator rolüyle oturum açın.
• Microsoft Entra ID > Users bölümüne gidin.
• MFA etkinleştirilecek kullanıcıyı seçin.
• Enable MFA seçeneğini kullanarak işlemi onaylayın.
• Etkinleştirmenin ardından kullanıcıları e-posta ile bilgilendirin. Bir sonraki oturum açma sırasında MFA kayıt (registration) süreci otomatik olarak başlatılacaktır.

Per-user MFA, temel düzeyde koruma sağlayan bir yöntemdir ancak kullanıcı, belirlenen koşullardan bağımsız olarak her oturum açma işleminde MFA doğrulaması yapmak zorunda kalır. Bu nedenle yönetim esnekliği sınırlıdır ve mümkün olduğunda Microsoft Entra ID P1 veya P2 lisansına geçilerek Koşullu Erişim tabanlı MFA mimarisinin tercih edilmesi önerilir.

Adım 4: Faz 2 Öncesinde Otomasyon ve Servis Hesaplarını Hazırlayın

Zorunlu MFA’nın ikinci aşamasında yaşanan erişim sorunlarının büyük bölümü, kullanıcı hesabıyla çalışan otomasyonlardan kaynaklanır. Bu nedenle Azure kaynaklarını yöneten betikler, uygulamalar ve servis hesapları gözden geçirilmeli, MFA gereksinimlerine uygun hale getirilmelidir.

💡Hazırlık sürecinde aşağıdaki kontrolleri gerçekleştirin:

✅ Kullanıcı tabanlı servis hesaplarını Workload Identity mimarisine taşıyın: Kullanıcı adı ve parola kullanarak https://management.azure.com adresine kimlik doğrulaması yapan betik ve otomasyonları Managed Identity veya Service Principal kullanacak şekilde güncelleyin. İş yükü kimlikleri zorunlu MFA kapsamına girmediği için otomasyonların kesintisiz çalışmasını sağlar.

✅ ROPC tabanlı kimlik doğrulamayı kaldırın: OAuth 2.0 Resource Owner Password Credentials (ROPC) akışı MFA ile uyumlu değildir. MFA zorunluluğu devreye alındığında bu yöntemi kullanan API çağrıları başarısız olacaktır. Bu nedenle MSAL ve Azure Identity kütüphanelerindeki UsernamePasswordCredential ile AcquireTokenByUsernamePassword kullanımlarını, ayrıca AZURE_USERNAME ve AZURE_PASSWORD ortam değişkenlerine dayanan DefaultAzureCredential yapılandırmalarını gözden geçirerek daha modern kimlik doğrulama yöntemlerine geçin.

✅ Kullanılan istemci sürümlerini doğrulayın: Azure CLI ve Azure PowerShell sürümlerinin güncel olduğundan emin olun. Microsoft, en iyi uyumluluk için Azure CLI 2.76 ve Azure PowerShell 14.3 veya daha yeni sürümlerin kullanılmasını önerir. Daha eski sürümler, MFA sırasında gönderilen claims challenge yanıtlarını işleyemeyebilir ve kimlik doğrulama hataları oluşturabilir.

✅ Step-up MFA senaryolarını test edin: MFA ile doğrulanmamış bir kullanıcı, Azure yönetim araçlarına erişebilir ancak kaynak oluşturma, güncelleme veya silme işlemi başlattığında MFA gerekli uyarısı ve bir claims challenge ile karşılaşır. Bazı istemciler bu isteği otomatik olarak işleyerek kullanıcıyı MFA doğrulamasına yönlendirirken, bazıları yalnızca hata mesajı döndürür. Bu nedenle Koşullu Erişim politikaları veya Security Defaults kullanılarak kullanıcıların MFA kayıt ve doğrulama sürecini önceden tamamlaması önerilir.

Bu hazırlıkların tamamlanması, özellikle otomasyon süreçlerinde beklenmeyen kesintilerin önüne geçilmesini sağlar ve Faz 2 uygulaması devreye alındığında Azure yönetim işlemlerinin sorunsuz şekilde devam etmesine yardımcı olur.

Adım 5: Break-Glass Hesaplarını ve Harici Kimlik Doğrulama Yapısını Gözden Geçirin

Zorunlu MFA uygulaması devreye alındığında acil durum (break-glass) hesapları da diğer kullanıcı hesapları gibi MFA doğrulamasına tabi olur. Bu nedenle yalnızca hesabın var olması yeterli değildir; kullanılan kimlik doğrulama yönteminin de güvenli ve sürekliliği destekleyecek şekilde yapılandırılması gerekir. Aynı yaklaşım, üçüncü taraf MFA çözümleri veya federe kimlik sağlayıcı kullanan kuruluşlar için de geçerlidir.

💡Aşağıdaki kontrolleri tamamlamanız önerilir:

✅ Break-glass hesaplarında güçlü kimlik doğrulama yöntemleri kullanın: Bu hesapları SMS veya telefon tabanlı doğrulama yerine Passkey (FIDO2) ya da Certificate-Based Authentication (CBA) ile yapılandırın. Her iki yöntem de MFA gereksinimini karşılar ve mobil cihaz bağımlılığı oluşturmadan güvenli erişim sağlar. FIDO2 MFA ile break-glass hesapları daha güvenli hale gelir.

✅ Yedek acil durum hesapları oluşturun: Kiracı içerisinde en az iki bulut tabanlı break-glass hesabı bulundurun. Hesap parolalarını uzun ve rastgele oluşturulmuş değerler olarak güvenli bir fiziksel kasada saklayın ve hesapların çalıştığını doğrulamak amacıyla düzenli olarak, tercihen ayda bir kez oturum açma testi gerçekleştirin.

✅ Harici MFA çözümlerini doğrulayın: Üçüncü taraf MFA ürünleri kullanıyorsanız, çözümünüzün External Authentication Method Provider mimarisi üzerinden Microsoft Entra ID ile bütünleştiğinden emin olun. Eski Conditional Access Custom Controls önizleme yapısı zorunlu MFA gereksinimini karşılamadığından desteklenen harici MFA yöntemine geçiş yapılmalıdır.

✅ Federe kimlik sağlayıcı yapılandırmasını kontrol edin: Kuruluşunuz AD FS gibi federe bir kimlik sağlayıcı üzerinden MFA uyguluyorsa, kimlik sağlayıcının Microsoft Entra ID’ye multipleauthn MFA talebini (claim) iletecek şekilde yapılandırıldığını doğrulayın. Aksi halde gerçekleştirilen MFA doğrulaması Entra ID tarafından geçerli kabul edilmeyebilir.

Microsoft Entra Connect ve Cloud Sync senkronizasyon hizmetlerinde kullanılan sistem hesapları zorunlu MFA kapsamına dahil değildir. Buna rağmen ortamınızda kullanıcı kimliğiyle çalışan özel senkronizasyon veya entegrasyon hesapları bulunuyorsa, bunların da gözden geçirilerek modern kimlik doğrulama yöntemlerine taşınması önerilir.

Bu kontrollerin tamamlanması, acil durum erişim senaryolarının güvenli şekilde çalışmasını sağlarken üçüncü taraf kimlik doğrulama altyapılarının da zorunlu MFA gereksinimleriyle uyumlu hale getirilmesine yardımcı olacaktır. 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: Zorunlu MFA Uygulamasının Etkinliğini Doğrulayın

Yapılandırma tamamlandıktan sonra zorunlu MFA’nın kiracınızda hangi aşamada uygulandığını doğrulamanız gerekir. Bu kontrol, hem geçiş sürecinin başarılı şekilde tamamlandığını hem de kullanıcıların yeni MFA gereksinimlerine uygun çalıştığını doğrulamanıza yardımcı olur.

💡 Doğrulama sürecinde aşağıdaki adımları izleyin:

✅ Faz 1 durumunu kontrol edin: Global Administrator rolüne sahip bir hesapla Azure portalına oturum açın ve aka.ms/managemfaforazure adresini ziyaret edin. Multifactor authentication (Phase 1) sayfasındaki bilgilendirme alanı (banner), Faz 1 zorunlu MFA uygulamasının kiracınız için etkin olup olmadığını gösterir.

✅ Faz 2 durumunu doğrulayın: aka.ms/postponePhase2MFA adresine giderek Multifactor authentication (Phase 2) sayfasındaki bilgilendirme alanını inceleyin. Microsoft’un tanıdığı MFA erteleme süresi 1 Temmuz 2026 tarihinde sona erdiği için uygun kiracılarda Faz 2 zorunlu MFA uygulamasının etkin olduğunu görmeniz beklenir.

✅ Oturum açma günlüklerini inceleyin: Microsoft Entra oturum açma günlükleri (Sign-in Logs), MFA gereksinimini tetikleyen uygulamayı ve ilgili kimlik doğrulama akışını ayrıntılı olarak gösterir. Bu kayıtlar sayesinde hangi uygulama veya isteğin MFA doğrulaması istediğini kolayca analiz edebilirsiniz.

Zorunlu MFA’nın ikinci aşaması etkinleştirildikten sonra kritik bir teknik engel ile karşılaşılması durumunda, Global Administrator rolüne sahip bir yönetici Microsoft Yardım ve Destek üzerinden geçici bir kaldırma talebinde bulunabilir. Ancak bu işlem yalnızca istisnai durumlar için sunulan geçici bir uygulamadır ve zorunlu MFA kapsamından kalıcı olarak çıkılmasını sağlamaz. Microsoft, enforcement mekanizmasını devre dışı bırakmaya yönelik kalıcı bir seçenek sunmamaktadır.

Bu doğrulama adımlarının tamamlanması, yapılandırmanın beklendiği şekilde çalıştığını teyit etmenizi ve olası sorunları kullanıcıları etkilemeden önce tespit ederek gerekli düzeltmeleri yapmanızı sağlayacaktır.

Zorunlu MFA Geçişinde En Sık Karşılaşılan Hatalar ve Çözüm Önerileri

Zorunlu MFA geçiş sürecinde yapılan bazı yapılandırma hataları, yönetici hesaplarının kilitlenmesine veya otomasyon süreçlerinin beklenmedik şekilde durmasına neden olabilir. Aşağıdaki yaygın hatalar ve çözüm önerileri, geçiş sürecini daha güvenli ve sorunsuz yönetmenize yardımcı olacaktır.

✅ Break-glass hesaplarını kapsam dışında bırakmamak: “All users + Require MFA” ilkesinin tüm yönetici hesaplarını kapsaması nedeniyle acil durum hesapları da politikaya dahil edilebilir. Bu durumda MFA yönteminde yaşanacak bir sorun, kiracıya erişimin tamamen kaybedilmesine neden olabilir. Çözüm olarak en az iki break-glass hesabını tüm Koşullu Erişim politikalarından hariç tutun ve bu hesaplarda FIDO2 güvenlik anahtarı veya Certificate-Based Authentication (CBA) kullanın.

✅ Koşullu Erişim politikasını doğrudan etkinleştirmek: Yeni oluşturulan politikanın doğrudan On modunda devreye alınması, beklenmeyen erişim sorunlarının en yaygın nedenlerinden biridir. Bu riski azaltmak için politikayı önce Report-only modunda oluşturun, en az yedi gün boyunca etkisini izleyin ve Insights raporlarını değerlendirdikten sonra etkin duruma geçirin.

✅ Kullanıcı tabanlı servis hesaplarını dönüştürmemek: Kullanıcı adı ve parola ile Azure Resource Manager’a bağlanan otomasyonlar, Faz 2 sonrasında kimlik doğrulama hatalarıyla karşılaşabilir. Bu nedenle kullanıcı tabanlı servis hesaplarını Managed Identity veya Service Principal tabanlı kimlik doğrulama yöntemlerine taşıyarak MFA gereksiniminin dışında çalışmasını sağlayın.

✅ Güncel olmayan istemci sürümlerini kullanmak: Eski Azure CLI ve Azure PowerShell sürümleri, claims challenge mekanizmasını desteklemeyebilir. Sonuç olarak kullanıcı MFA ekranı yerine doğrudan hata mesajı görebilir. Azure CLI 2.76, Azure PowerShell 14.3 veya daha yeni sürümlere yükseltme yaparak bu uyumsuzlukların önüne geçebilir, kullanıcıların MFA kayıtlarını önceden tamamlamasını sağlayabilirsiniz.

✅ Okuma ve yazma işlemlerini aynı şekilde değerlendirmek: Faz 2 kapsamında yalnızca kaynak oluşturma, güncelleme ve silme işlemleri MFA gerektirirken, okuma işlemleri normal şekilde devam eder. Bu nedenle yalnızca listeleme işlemleriyle yapılan testler yanıltıcı sonuçlar verebilir. Test senaryolarına mutlaka kaynak oluşturma veya güncelleme adımlarını dahil ederek gerçek üretim senaryolarını doğrulamanız önerilir.

Bu hataların önceden belirlenmesi ve gerekli düzeltmelerin uygulanması, zorunlu MFA geçişi sırasında oluşabilecek erişim problemlerini önemli ölçüde azaltır ve Azure yönetim süreçlerinin kesintisiz şekilde devam etmesini sağlar.

Microsoft’un zorunlu MFA uygulaması, Azure yönetim hizmetleri ve yönetici portalları için çok faktörlü kimlik doğrulamayı standart hale getiren kalıcı bir güvenlik yaklaşımıdır. İlk aşama yönetim portallarını kapsarken, ikinci aşama Azure CLI, Azure PowerShell, Azure Resource Manager (ARM) API’leri ve Infrastructure as Code (IaC) araçları üzerinden gerçekleştirilen yönetim işlemlerini de zorunlu MFA kapsamına dahil etmektedir. Erteleme sürecinin 1 Temmuz 2026 tarihinde sona ermesiyle birlikte uygulama uygun Azure kiracılarına kademeli olarak uygulanmaya başlamıştır.

Sorunsuz bir geçiş için kuruluşların öncelikle mevcut MFA kullanım durumunu analiz etmesi, lisans yapısına uygun olarak Koşullu Erişim veya Security Defaults yapılandırmasını devreye alması, kullanıcı tabanlı otomasyon hesaplarını Workload Identity mimarisine taşıması ve break-glass hesaplarını FIDO2 güvenlik anahtarı ya da sertifika tabanlı kimlik doğrulama yöntemleriyle güvence altına alması büyük önem taşımaktadır. Bununla birlikte yeni politikaların önce Report-only modunda test edilmesi, istemci araçlarının güncel sürümlerde çalıştırılması ve okuma işlemleriyle kaynak değişikliği yapan işlemlerin ayrı senaryolar olarak değerlendirilmesi olası kesintilerin önüne geçecektir.

Planlı ve kontrollü bir geçiş süreci, yalnızca Microsoft’un zorunlu MFA gereksinimlerine uyum sağlamayı değil, aynı zamanda Azure ortamlarının güvenliğini artırırken yönetim ve otomasyon süreçlerinin kesintisiz şekilde devam etmesini de mümkün kılacaktır.

Zorunlu Bir Gereklilikten Daha Fazlası: Yeni Güvenlik Standardı

Azure için zorunlu MFA uygulaması artık isteğe bağlı bir güvenlik önerisi değil, devre dışı bırakılamayan bir platform gereksinimi haline gelmiştir. İlk aşamada yönetim portallarını kapsayan uygulama, ikinci aşamayla birlikte Azure Resource Manager üzerinden gerçekleştirilen kaynak yönetimi işlemlerine de genişletildi. Erteleme sürecinin 1 Temmuz 2026 tarihinde sona ermesiyle birlikte zorunlu MFA uygulaması tüm uygun Azure kiracılarına kademeli olarak uygulanmaktadır. Bu nedenle kurumların geçiş sürecini sorunsuz tamamlayabilmesi için mevcut kullanıcı hesaplarını gözden geçirmesi, MFA kullanmayan hesapları belirlemesi ve kullanıcı tabanlı servis hesaplarını iş yükü kimliklerine (Workload Identity) dönüştürmesi kritik önem taşımaktadır.

Başarılı bir geçiş süreci için en doğru yaklaşım; önce mevcut durumun analiz edilmesi, ardından Report-only modunda Koşullu Erişim (Conditional Access) politikalarının test edilmesi ve son aşamada üretim ortamına alınmasıdır. Aynı zamanda acil durum (break-glass) hesaplarının FIDO2 güvenlik anahtarları veya Sertifika Tabanlı Kimlik Doğrulama (CBA) gibi güçlü yöntemlerle korunması, hem güvenlik seviyesini yükseltir hem de geçiş sırasında yaşanabilecek kullanıcı kaynaklı kesintileri en aza indirir. MFA’yı yalnızca zorunlu bir güvenlik adımı olarak değil, Microsoft’un Sıfır Güven (Zero Trust) mimarisinin temel bileşenlerinden biri olarak değerlendirmek, uzun vadeli ve sürdürülebilir bir güvenlik yaklaşımı oluşturulmasını sağlar.

ITSTACK olarak, kurumların Azure zorunlu MFA geçiş süreçlerini uçtan uca planlıyor ve yönetiyoruz. Mevcut ortamın analizinden Koşullu Erişim politika tasarımına, kullanıcı tabanlı servis hesaplarının Workload Identity mimarisine taşınmasından acil durum hesaplarının güvenli şekilde yapılandırılmasına kadar tüm süreçlerde uzman danışmanlık sunuyoruz. Microsoft güvenlik çözümleri konusundaki deneyimimizle, Azure ortamınızı en güncel güvenlik gereksinimlerine uyumlu hale getirirken operasyonel sürekliliğinizi korumanıza ve Zero Trust mimarisine güvenle geçiş yapmanıza yardımcı oluyoruz. Daha fazla bilgi almak ve kurumunuza özel çözüm önerilerimizi değerlendirmek için ITSTACK ekibiyle iletişime geçebilirsiniz.

Sıkça Sorulan Sorular (SSS)

Faz 2 zorunlu MFA hangi hesapları etkiler?

Faz 2 zorunlu MFA uygulaması, Azure kaynak yönetimi işlemlerini kullanıcı hesabıyla gerçekleştiren tüm hesapları kapsar. Azure Portal’ın yanı sıra PowerShell, Azure CLI, SDK ve REST API gibi istemciler üzerinden https://management.azure.com uç noktasına gönderilen oluşturma, güncelleme ve silme işlemleri bu kapsamda değerlendirilir. Managed Identity ve Service Principal kullanan otomasyon senaryoları kapsam dışındadır. Ancak kullanıcı hesabıyla çalışan otomasyon süreçleri MFA zorunluluğundan etkilenir.

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

Hayır. Faz 2 kapsamında yalnızca kaynak oluşturma (create), güncelleme (update) ve silme (delete) işlemleri için MFA doğrulaması zorunludur. Kaynak listeleme ve görüntüleme gibi yalnızca okuma işlemleri MFA gerektirmez. Kullanıcı, MFA olmadan oturum açabilir ancak değişiklik yapmaya çalıştığında Azure tarafından MFA doğrulaması istenir.

Microsoft Graph API çağrıları da bu zorunluluk kapsamında mı?

Hayır. Bu MFA zorunluluğu yalnızca Azure Resource Manager (ARM) üzerinden gerçekleştirilen yönetim işlemlerini kapsar. Microsoft Graph API çağrıları bu enforcement mekanizmasının dışında kalır ve Azure Resource Manager için uygulanan MFA politikalarından etkilenmez.

Erteleme süresini kaçırdıysam ne olur?

Faz 2 için tanımlanan son erteleme tarihi 1 Temmuz 2026 itibarıyla sona ermiştir. Bu tarihten sonra MFA yapılandırılmamış kullanıcılar, Azure kaynakları üzerinde oluşturma, güncelleme veya silme işlemleri gerçekleştirmeye çalıştıklarında doğrulama hatası alırlar. Kritik teknik engeller bulunması halinde Global Administrator yetkisine sahip yöneticiler Microsoft Destek üzerinden geçici istisna talebinde bulunabilir. Ancak bu uygulama için kalıcı bir muafiyet seçeneği bulunmamaktadır.

Test veya geliştirme amaçlı Azure kiracıları muaf tutuluyor mu?

Hayır. Test, geliştirme veya laboratuvar amaçlı oluşturulan Azure kiracıları da MFA zorunluluğu kapsamındadır. Azure genel bulutunda (Azure Global Cloud) bulunan tüm kiracılar için politika geçerlidir. Azure Government ve diğer egemen (sovereign) bulut ortamları ise bu uygulamanın kapsamı dışında değerlendirilmektedir.

Kuruluşumuzda zaten MFA kullanılıyorsa ek işlem yapmamız gerekir mi?

Kapsam dahilindeki Azure yönetim işlemlerini gerçekleştiren tüm kullanıcılar için MFA zaten zorunluysa ek bir yapılandırma yapılmasına gerek yoktur. Ancak yalnızca belirli kullanıcı gruplarında MFA etkinse, Azure kaynak yönetimi yapan diğer kullanıcıların da MFA kullanması gerekir. FIDO2 güvenlik anahtarları, passkey ve passwordless oturum açma yöntemleri de bu gereksinimi karşılayan kimlik doğrulama yöntemleri arasında yer alır.

B2B misafir kullanıcı hesapları da MFA zorunluluğuna tabi mi?

Evet. Azure B2B misafir kullanıcıları da MFA gereksiniminden etkilenir. Kimlik doğrulaması, kullanıcının bulunduğu ana kiracıda (home tenant) veya erişim sağlanan kaynak kiracısında gerçekleştirilebilir. Cross-tenant Access ayarları doğru yapılandırıldığında ana kiracı tarafından sağlanan MFA doğrulaması kaynak kiracı tarafından da geçerli kabul edilir.