Microsoft Entra ID'de MFA Yapılandırması ve Uygulama Yöntemleri

Geleneksel kimlik doğrulama, bir oturum açma talebini yalnızca parolayla doğrular. Parola ise paylaşılabilir ve yeniden kullanılabilir bir gizli bilgidir. Bir saldırgan parolayı ele geçirdiğinde, başka hiçbir engelle karşılaşmadan oturum açabilir. Phishing, Password Spray, Credential Stuffing ve Token Replay gibi saldırı yöntemlerinin tamamı sonuçta tek bir gizli bilgiyi, parolayı hedef alır ve onu ele geçirdiğinde savunmanın tamamını aşar. Böyle bir modelde güvenlik, kırıldığı anda tüm erişimi açan tek bir noktaya bağlıdır.

İşte Multi-Factor Authentication (MFA) tam da bu tek noktaya bağımlılığı ortadan kaldırmak için devreye girer. MFA, bir oturum açma talebini birbirinden bağımsız en az iki faktör kategorisiyle doğrular. Faktörler üç ana kategoride toplanır. Bilgi faktörü kullanıcının bildiği bir unsurdur ve Parola ve PIN bu kategoridedir. Sahiplik faktörü, kullanıcının sahip olduğu bir unsurdur ve Authenticator uygulaması, FIDO2 güvenlik anahtarı ve OTP Token bu kategoridedir. Biyometrik faktör ise kullanıcıya ait fiziksel bir özelliktir ve Fingerprint (parmak izi) ve Facial Recognition (yüz tanıma) bu kategoridedir. İkinci ve bağımsız bir faktör devreye girdiğinde, ele geçirilmiş bir parola tek başına oturum açmaya yetmez ve saldırganın, uzaktan elde edemeyeceği fiziksel ya da cihaza bağlı bir unsuru da aşması gerekir.

Güvenlik kazanımı, faktörlerin farklı kategorilerden gelmesinden doğar. Aynı kategoriden iki unsur, örneğin parola ve güvenlik sorusu, gerçek anlamda çok faktörlü sayılmaz, çünkü ikisi de bilgi faktörüdür. Faktör ne kadar güçlü ve Phishing-Resistant olursa koruma o kadar etkilidir. Microsoft'un verileri, MFA'nın hesap ele geçirme saldırılarının büyük çoğunluğunu engellediğini gösterir ve bu nedenle MFA, modern kimlik güvenliğinin en temel kontrollerinden biri olarak kabul edilir.

Microsoft Entra ID üzerinde MFA, tek bir yerden yönetilen tek bir özellik değildir. MFA'nın hangi kullanıcılar için, hangi koşullarda ve hangi yöntemle zorunlu kılınacağı, yıllar içinde birbirini izleyen farklı kontrol katmanları üzerinden belirlenir. Tarihsel olarak üç MFA kontrol katmanı bulunur ve bunlara yakın zamanda dördüncü bir Enforcement katmanı eklenmiştir. Aşağıda bu dört katmanı tek tek ele alıyor, nereden yapılandırıldıklarını, aralarındaki farkları ve Conditional Access ile olan ilişkilerini açıklıyorum.

1- Per-User MFA

Per-User MFA, Azure AD ve sonrasında Microsoft Entra ID üzerindeki en eski MFA mekanizmasıdır. Conditional Access ve Security Defaults henüz ortada yokken, çok faktörlü doğrulamayı zorunlu kılmanın tek yolu buydu ve kökleri Azure Multi-Factor Authentication'ın ilk dönemine dayanır. Bu modelde MFA zorunluluğu merkezi bir politika üzerinden değil, doğrudan kullanıcı nesnesine atanan bir durum üzerinden tanımlanır. Zorunluluk, her hesaba tek tek işlenen bir özellik olarak tutulur ve bir kullanıcıya atanan durum, o hesabın oturum açma davranışını doğrudan belirler. Bu nedenle yönetim, kullanıcı sayısı arttıkça hesap hesap yürütülen ve ölçeklenmesi zorlaşan bir işe dönüşür. Her kullanıcı bu kapsamda üç durumdan birine sahip olabilir.

Per-User MFA hesap düzeyinde çalışır ve kullanıcının tüm girişleri için geçerlidir. Herhangi bir koşul mantığı içermez. Sadece dış ağdan giriş yapıldığında ya da yalnızca belirli bir uygulamaya erişildiğinde MFA iste gibi senaryolar tanımlanamaz. Konum, cihaz durumu veya risk gibi bağlamsal sinyallerden de habersizdir.

Per-User MFA Yapılandırması

Per-User MFA yönetimi, Microsoft Entra admin center içinde doğrudan görünür bir blade olarak yer almaz. Yapılandırmaya başlamak için Entra ID > Users > All users ekranına gidilir. Üst araç çubuğunun sağ ucundaki üç nokta biçimindeki ek işlemler menüsü açıldığında Per-user MFA seçeneği görünür. Bu seçeneğin ana menüde değil, ikinci bir menünün altında konumlandırılmış olması, Microsoft'un yöneticileri bilinçli olarak Conditional Access yönüne yönlendirmesinin bir göstergesidir. İzlenecek yol aşağıdaki gibidir.

Per-user MFA seçildiğinde açılan ekran, klasik Azure MFA yönetim arayüzüdür. Bu arayüz geçmişte account.activedirectory.windowsazure.com adresinde ayrı bir portal olarak açılırken, bugün Microsoft Entra admin center içine gömülü bir ReactView olarak gelir. Sayfada iki sekme bulunur. Users sekmesi kullanıcıların Per-User MFA durumlarını yönetir.

Service settings sekmesi ise doğrulama yöntemleri, App Password ve Trusted IP gibi servis genelindeki ayarları barındırır. Microsoft bu sayfanın üst kısmında, MFA'yı zorunlu kılmak için önerilen yaklaşımın uyarlanabilir Conditional Access politikaları olduğunu açıkça belirtir. Varsayılan olarak listedeki tüm kullanıcılar Disabled durumundadır. Üst araç çubuğunda Enable MFA, Disable MFA, Enforce MFA ve User MFA settings işlemleri yer alır. Bu işlemler sırasıyla kullanıcının durumunu Enabled, Disabled ve Enforced değerlerine taşır. User MFA settings ise seçili kullanıcının kayıtlı yöntemlerini yönetmeye ve yeniden kayıt zorunlu kılmaya yarar.

Bir kullanıcının durumunu değiştirmek için önce satırının başındaki onay kutusu işaretlenir. Kullanıcı seçildiğinde, o ana kadar pasif olan Enable MFA işlemi etkinleşir. Disabled durumundaki bir kullanıcı için yalnızca Enable MFA mantıklı bir başlangıç adımıdır. Enforce MFA, kullanıcı henüz MFA kaydı yapmadan doğrudan uygulanırsa tarayıcı dışı ve Legacy istemcilerde oturum açma sorunlarına yol açabileceği için, önce Enabled adımının geçilmesi önerilir.

Enable MFA tıklandığında Enable multifactor authentication onay penceresi açılır. Bu pencere, tarayıcı üzerinden düzenli oturum açmayan kullanıcıların MFA kaydını önceden tamamlayabilmesi için https://aka.ms/mfasetup kayıt bağlantısını sunar. Enabled durumu, kullanıcının bir sonraki etkileşimli oturum açmasında MFA kaydına yönlendirileceği, ancak kayıt tamamlanana kadar her girişte zorlanmayacağı anlamına gelir. Bu nedenle kayıt bağlantısı, kullanıcıların kaydı kendi başlarına yapabilmesi açısından kullanışlıdır. Enable butonu ile işlem onaylanır.

Onaylama sonrasında seçili kullanıcının Status değeri Enabled olarak güncellenir. Diğer kullanıcılar Disabled durumunda kalmaya devam eder. Kullanıcının her oturum açmada MFA'ya zorlanması isteniyorsa, Enabled durumdaki kullanıcı seçilip Enforce MFA işlemi uygulanır ve durum Enforced değerine taşınır. Enforce işlemi yalnızca kullanıcı kayıt sürecini tamamladıktan sonra uygulanmalıdır, aksi halde kayıt yapmamış kullanıcılar oturum açamaz hale gelebilir.

2- Security Defaults

Security Defaults, Microsoft'un 2019 yılında devreye aldığı, Tenant geneline uygulanan ve Microsoft tarafından yönetilen bir baseline güvenlik paketidir. Tek tek politikalar tanımlamak yerine, Microsoft'un belirlediği bir dizi temel kimlik güvenliği önlemini tek bir paket halinde sunar. Bu paket özelleştirilemez ve tek bir Toggle ile bütünüyle açılıp kapatılır. İçindeki kurallar Microsoft tarafından bakımı yapılan sabit bir set olarak gelir ve tehdit ortamı değiştikçe Microsoft tarafından güncellenir.

Security Defaults, Conditional Access lisansı bulunmayan organizasyonların korumasız kalmaması için tasarlanmıştır. Conditional Access, Entra ID P1 gerektirdiği için, P1 lisansı olmayan küçük organizasyonların makul bir güvenlik temeline ücretsiz biçimde sahip olmasını bu paket sağlar. Microsoft, belirli bir tarihten sonra oluşturulan yeni Tenant'larda Security Defaults'ı varsayılan olarak açık getirir. Per-User MFA'nın aksine denetim, kullanıcı nesnesine değil doğrudan Tenant düzeyine bağlıdır ve tüm kullanıcıları aynı anda kapsar.

Security Defaults Yapılandırması

Conditional Access kullanmayan bir organizasyonda Security Defaults, Entra ID > Overview ekranındaki Properties sekmesinden yönetilir. Sekme aşağı kaydırıldığında Security defaults bölümü görünür ve buradaki Manage security defaults bağlantısı tıklanır. Sağ tarafta açılan panelde Security defaults değeri Enabled yapılır ve Save ile kaydedilir. İzlenecek yol aşağıdaki gibidir.

Ancak bu makaledeki Tenant'ta Manage security defaults bağlantısı baştan görünmez. Properties sekmesindeki Security defaults bölümünde yalnızca bir bilgi notu ve Manage Conditional Access bağlantısı bulunur. Bunun nedeni, Tenant'ta etkin bir Conditional Access politikasının bulunmasıdır. Microsoft, Security Defaults ile Conditional Access'in aynı anda etkin olmasına izin vermez. Bir Conditional Access politikası mevcut olduğu sürece Security Defaults engellenir ve yönetim kontrolü gizlenir.

Burada sık karşılaşılan bir noktayı netleştirmek gerekir. Bir Tenant'ta hazır bir Conditional Access Policy bulunurken Security Defaults'ın kapalı ve gizli görünmesi tesadüf değildir. Conditional Access ile Security Defaults aynı temel amaca, kimlikleri korumaya hizmet eder; ancak farklı olgunluk seviyelerindedir ve Microsoft bu ikisinin aynı anda etkin olmasına izin vermez. Modern Tenant'lar, giderek daha sık Conditional Access ile gelir. Bu örnekteki Tenant'ta kullanıcı tarafından oluşturulmuş bir politika bulunur; ayrıca Microsoft, birçok Tenant'a Microsoft-managed Conditional Access politikalarını varsayılan olarak ekler. Etkin tek bir Conditional Access politikası bile bulunduğunda Security Defaults, otomatik olarak devre dışı sayılır ve yönetim kontrolü gizlenir. Dolayısıyla Security Defaults'ın kapalı görünmesi bir eksiklik değil, ortamın zaten daha üst seviye bir kontrolle korunuyor olmasının doğal sonucudur.

Aynı nedenle, Security Defaults'ı görmek ya da kullanmak için Conditional Access'i kapatmak gerçek bir ortamda doğru bir hamle değildir. Conditional Access; kullanıcıya, gruba, uygulamaya, konuma, cihaz durumuna ve oturum açma riskine göre koşullu kararlar verebilen granular bir kontroldür ve belirli hesapların muaf tutulmasına imkan tanır.

Security Defaults ise sabit, All-Or-Nothing (ya hep ya hiç) çalışan ve hiçbir muafiyete izin vermeyen bir Baseline durumundadır. Conditional Access'ten Security Defaults'a dönmek, koşullu ve bağlama duyarlı bir korumayı sabit bir tabana indirgeyerek güvenliği geriye götürmek anlamına gelir.

Bu nedenle Security Defaults, yalnızca Conditional Access lisansı bulunmayan ortamlar için anlamlıdır. Entra ID P1 ve üstü bir lisansa sahip, dolayısıyla Conditional Access kullanabilen bir organizasyon ise Security Defaults'a yönelmez; korumasını doğrudan Conditional Access politikalarıyla, kullanıcı, uygulama, konum, cihaz ve risk koşullarına göre kurar. Kısacası lisansı olmayan Security Defaults ile korunur, lisansı olan Conditional Access'te kalır.

Security Defaults kontrolünü görebilmek için önce etkin Conditional Access politikası kapatılır. Entra ID > Protection > Conditional Access > Policies ekranında politikalar listelenir. Bu Tenant'ta Microsoft-managed politika sayısı sıfır, kullanıcı tarafından oluşturulan politika sayısı birdir. Tek politika olan Multifactor authentication for Microsoft partners and vendors politikasının State değeri On görünür.



Politika açıldığında üst kısımda atamalar yer alır. Users or agents kısmında tüm kullanıcılar dahil edilmiş, belirli kullanıcılar hariç tutulmuştur. Target resources tüm kaynakları kapsar ve Network yapılandırılmamıştır. Sayfanın en altındaki Enable policy kontrolü Report-only, On ve Off seçeneklerini sunar ve bu politikada On konumundadır.



Politikayı devre dışı bırakmak için Enable policy değeri Off konumuna alınır. Bu sırada portal, yöneticinin kendini kilitlemesini önlemek için bir uyarı gösterir ve en az bir yöneticinin politikadan hariç tutulmasını önerir. Burada Exclude current user seçeneği işaretlenir ve Save ile kaydedilir.



Kaydetme işleminin ardından Policies listesine dönüldüğünde, politikanın State değeri artık Off görünür. Böylece Tenant'ta etkin bir Conditional Access politikası kalmaz.



Bu noktada Entra ID > Overview > Properties ekranına geri dönülür. Security defaults bölümündeki ifade değişmiştir. Conditional Access'in engellediğini söyleyen not yerini, organizasyonun Security Defaults ile korunmadığını belirten bir uyarıya bırakmıştır ve artık Manage security defaults bağlantısı görünür hale gelmiştir. Yani Conditional Access politikası kapatıldığında Manage security defaults gerçekten açılır.



Manage security defaults bağlantısı tıklandığında sağ tarafta bir panel açılır. Panelde Security defaults değeri için Enabled ve Disabled seçeneklerini içeren bir liste bulunur. Panel ayrıca Microsoft'un verilerini gösterir; hesap ele geçirme vakalarının büyük bölümünün MFA ile engellenebileceği ve Security Defaults etkinleştirildiğinde ele geçirme oranında belirgin bir düşüş görüldüğü belirtilir. Security defaults değeri Enabled seçilir.



Save ile kaydedildiğinde işlemin başarılı olduğunu bildiren bir bildirim görünür. Security defaults bölümündeki uyarı kalkar ve yerini, organizasyonun artık Security Defaults ile korunduğunu belirten bir ifadeye bırakır. Demo tamamlandıktan sonra önerilen duruma dönmek için Security Defaults yeniden Disabled yapılır ve kapatılan Conditional Access politikası tekrar On konumuna alınır.



Security Defaults hangi Tenant'ta etkinleştirilirse etkinleştirilsin, paketin içerdiği temel önlemler otomatik olarak ve bir bütün halinde devreye girer.

Bu önlemler aşağıdaki gibidir:

✔ Tüm kullanıcıları MFA Register olmaya zorlar. 29 Temmuz 2024 tarihinden itibaren 14 günlük erteleme süresi kaldırılmıştır ve kayıt, Security Defaults açıldıktan sonraki ilk oturum açmada zorunludur.

✔ Admin hesaplarında her girişte MFA ister.

✔ IMAP, POP ve SMTP gibi Basic Authentication kullanan Legacy Authentication protokollerini bloklar.

✔ Riskli görünen girişlerde ve Azure portal gibi ayrıcalıklı erişimlerde MFA ister.

Security Defaults Tenant geneli ve All-Or-Nothing bir yapıdır; ya tümüyle açıktır ya da tümüyle kapalıdır. Kapsamlandırılamaz ve hiçbir kullanıcı muaf tutulamaz. Ücretsizdir ve herhangi bir lisans gerektirmez, ancak özelleştirilemez.

Bu noktada, Security Defaults'ın hangi etkiyi hedeflediğini gösteren bir ayrıntı vardır. Manage security defaults panelinde Microsoft'un paylaştığı verilere göre, hesap ele geçirme vakalarının %99,9'u MFA kullanılarak engellenebilir ve Microsoft'un güvenlik ekipleri Security Defaults etkinleştirildiğinde ele geçirme oranında %80 düşüş gözlemler. Bu rakamlar, Conditional Access lisansı olmayan bir ortamda bile en temel Baseline korumanın kimlik güvenliğine ciddi katkı sağladığını ve Microsoft'un tüm katmanlarda MFA'yı neden bu kadar öne çıkardığını gösterir.

3- Conditional Access

Conditional Access, Microsoft Entra ID'nin politika tabanlı erişim kontrol motorudur ve bugün MFA'yı zorunlu kılmanın önerilen yöntemidir. Önceki iki katmanın aksine sabit bir durum ya da hazır bir yapı değildir; yöneticinin tanımladığı koşullu kurallar üzerinden çalışır. Her oturum açma talebi gerçek zamanlı olarak değerlendirilir ve talep, politikada tanımlanan koşulları karşılıyorsa belirlenen kontroller uygulanır. Bu mantık, belirli koşullar sağlandığında belirli bir kontrolü devreye sokan bir If-Then yapısı olarak işler.

Conditional Access'in gücü, kararını tek bir ölçüte değil, bir arada değerlendirdiği çok sayıda sinyale dayandırmasından gelir. Koşul tarafında kullanıcı ve grup, hedef uygulama ve kaynak, konum, istemci uygulaması, cihaz durumu ile Identity Protection üzerinden gelen Sign-in Risk ve User Risk yer alır. Kontrol tarafında ise MFA zorunluluğu, erişimin tümüyle engellenmesi, Compliant ya da Hybrid Joined cihaz şartı, Authentication Strength ve oturum açma sıklığı ile kalıcı tarayıcı oturumu gibi Session Control özellikleri bulunur. Bu sayede koruma, herkese aynı anda uygulanan tek bir kural yerine, belirli kullanıcıların belirli uygulamalara belirli koşullarda erişimine göre incelikle ayarlanır.

Bu model, Microsoft'un Zero Trust yaklaşımının kimlik ayağını oluşturur; hiçbir erişim baştan güvenilir kabul edilmez ve her talep bağlamına göre yeniden doğrulanır. Conditional Access'in temel kullanımı Entra ID P1 ve üstü bir lisans gerektirir. Yalnızca, koşul tarafında yer alan Sign-in Risk ve User Risk gibi risk tabanlı sinyaller Identity Protection'a dayandığı için bunların kullanılması Entra ID P2 lisansı gerektirir. Politikalar belirli kullanıcıları ya da grupları kapsam dışında bırakabildiği için acil durum hesapları muaf tutulabilir. Ayrıca bir politika, gerçek bir etki yaratmadan davranışını gözlemlemek üzere Report-only modunda çalıştırılabilir.

Aşağıdaki şema, Conditional Access'in bir oturum açma talebini baştan sona nasıl değerlendirdiğini özetler. Konumuz açısından önemli olan nokta dördüncü adımdaki Grant Controls kısmıdır. MFA, Conditional Access içinde tam burada, erişim kararı verilmeden önce uygulanan bir Grant Control olarak devreye girer. Politika MFA istiyorsa, Entra ID kullanıcıyı aynı oturum açma akışı içinde MFA'ya yönlendirir ve nihai erişim kararını bundan sonra verir.

Diyagramdaki bu kavramsal akış, pratikte Microsoft Entra admin center üzerindeki tek bir yönetim alanında hayata geçirilir. Koşulların tanımlanması, değerlendirilen sinyaller ve atanan kontroller, hepsi Conditional Access ekranındaki politikalar üzerinden yapılandırılır. Politikalar aşağıdaki yol izlenerek oluşturulur ve yönetilir.

Conditional Access yapılandırması, Policies ekranındaki New policy ile başlar. Bu ekranda Tenant'ta zaten bulunan politikalar da listelenir.

Burada sık sorulan bir noktayı netleştirmek gerekir. Security Defaults için zaten bir politika varken neden yeni bir Conditional Access politikası oluşturulur? Önce sorunun içindeki varsayımı düzeltmek gerekir, çünkü Security Defaults'a ait bir Conditional Access politikası diye bir şey yoktur. Security Defaults ile Conditional Access birbirinden tamamen ayrı iki mekanizmadır. Security Defaults, Microsoft tarafından yönetilen, önceden tanımlı ve sabit bir güvenlik ayarları kümesidir ve Policies listesinde hiçbir zaman bir politika olarak görünmez. Listede görünen politika ise Tenant'ta zaten bulunan ve Security Defaults'tan tamamen bağımsız bir Conditional Access politikasıdır.

İki mekanizma arasında yine de sistem düzeyinde bir ilişki vardır. Security Defaults ile Conditional Access aynı anda etkin olamaz. Ortamda etkin en az bir Conditional Access politikası bulunması Microsoft tarafından Conditional Access kullanılıyor olarak değerlendirilir ve bu durumda Security Defaults engellenir.

Daha önce o politikayı kapattığımızda Manage security defaults bağlantısının görünür hale gelmesinin nedeni de budur. O politika etkin olduğu sürece ortamda Conditional Access kullanılıyor sayıldığı için Security Defaults bloklanıyor ve Manage security defaults gizli kalıyordu. Politikayı kapattığımızda ortamda etkin hiçbir Conditional Access politikası kalmadı ve kontrol yeniden erişilebilir hale geldi. Bunu yapan, o politikanın kimliği değil, ortamda etkin bir politikanın kalıp kalmamasıdır; etkin başka herhangi bir politika da aynı engeli yaratırdı.

Yeni bir politika oluşturmamızın nedeni ise bambaşkadır. Bir önceki bölümde gördüğümüz politika, Tenant'ta zaten bulunan dar kapsamlı bir politikaydı ve orada yalnızca Security Defaults'ı bloklayan bu davranışı göstermek için kullanıldı. Bu bölümde amaç farklıdır. Conditional Access'in sıfırdan nasıl kurulduğunu, New policy ile başlayıp atamaları, koşulları ve kontrolleri adım adım tanımlama akışını temsil gücü yüksek ve temiz bir örnek üzerinden göstermek için yeni bir politika oluşturulur.

New policy ile açılan ekranda politikanın koşulları ve kontrolleri tanımlanır. Bir politikada koşullar ve kontroller birbirinden bağımsız olarak seçilir; aralarında satır satır bir eşleşme yoktur ve herhangi bir koşul kümesi herhangi bir kontrol kümesini tetikleyebilir.

📌 Koşul tarafında şunlar yer alır.

✔ Kullanıcı ve Grup
✔ Uygulama
✔ Konum ve Named Locations
✔ Cihaz Durumu
✔ Sign-in Risk ve User Risk

📌 Kontrol tarafında ise şunlar bulunur.

✔ Require MFA
✔ Block Access
✔ Require Compliant Device
✔ Require Hybrid Joined Device
✔ Session Controls

Örneğin belirli bir gruptaki kullanıcıların, belirli bir uygulamaya dış ağdan eriştiklerinde MFA kullanmasını şart koşan bir politika bu yapı üzerinden tanımlanabilir.

4- Mandatory MFA Enforcement

Microsoft, yukarıdaki üç katmandan bağımsız olarak işleyen dördüncü bir enforcement katmanını yakın zamanda devreye almıştır. Bu katman, Azure portal, Microsoft Entra admin center, Microsoft Intune admin center ve Microsoft 365 admin center gibi yönetim yüzeylerine yönetimsel erişim için MFA'yı zorunlu kılar. Bu zorunluluk, Conditional Access'ten ve Security Defaults'tan tamamen bağımsızdır.

Bu enforcement, tek bir yerden açılıp kapatılan bir Toggle değildir. Doğrudan yönetim portallarının kendisinde Microsoft tarafından uygulanır ve aşamalı olarak tüm Tenant'lara yayılmıştır. İlk aşama Ekim 2024'te Azure portal, Microsoft Entra admin center ve Microsoft Intune admin center oturum açmalarında, Create, Read, Update ve Delete işlemlerinin tamamı için MFA zorunluluğu ile başlamış ve Mart 2025 itibarıyla tüm Azure Tenant'larına yayılmıştır.

Microsoft 365 admin center için MFA zorunluluğu Şubat 2025 tarihinde başlamış, MFA bulunmayan hesapların oturum açmasının engellenmesi ise 9 Şubat 2026 tarihinde tam olarak devreye girmiştir. İkinci aşama ise 1 Ekim 2025 tarihinde Azure CLI, Azure PowerShell, Azure mobile app, Infrastructure as Code araçları ve REST API uç noktalarını kapsamıştır. Bu aşamada yalnızca Create, Update ve Delete işlemleri MFA gerektirir, salt okunur işlemler muaf tutulmuştur.

Karşılaştırma Tablosu

Günümüzde Hangi Katman Kullanılır

Hangi katmanın kullanılacağını belirleyen temel etken lisanstır ve bu üç katman gelişigüzel bir arada kullanılmaz. Entra ID P1 ya da üstü bir lisansa sahip organizasyonlar için standart yöntem Conditional Access'tir. Granular, koşullu ve Zero Trust ile uyumlu yapısı nedeniyle modern MFA yönetiminin temelini bu katman oluşturur ve Microsoft'un bugün önerdiği yaklaşım budur. P1 lisansı bulunmayan küçük işletmeler ise ücretsiz baseline olan Security Defaults ile korunur. Bu iki katman birbirini dışladığı için bir organizasyon baseline korumasını ya Conditional Access ile ya da Security Defaults ile kurar, ikisini birden çalıştırmaz.

Per-User MFA, bu tablonun dışında kalan Legacy bir katmandır. Yeni kurulumlarda kullanılmaz ve genellikle yalnızca Azure AD MFA döneminden devralınan eski Tenant'larda karşımıza çıkar. Per-User MFA teknik olarak Conditional Access ile aynı anda çalışabilir, çünkü bir Tenant baseline'ı değil hesap düzeyinde işleyen bir zorunluluktur; yine de Conditional Access kullanılan bir ortamda, aynı kullanıcı için iki ayrı MFA değerlendirmesinin çakışmaması için Per-User MFA Disabled bırakılır. Ayrıca Microsoft, Legacy MFA ve SSPR Policy üzerinden Authentication Method yönetimini 30 Eylül 2025 itibarıyla emekliye ayırmış ve bu yönetimi Authentication Methods Policy yapısına taşımıştır. Bu nedenle hala Per-User MFA durumlarına dayanan organizasyonların modern yapıya geçmesi beklenir.

Pratikte hedeflenen yapı nettir. Entra ID P1 ve üstü bir lisansa sahip bir organizasyon Conditional Access kullanır, Security Defaults'ı kapalı ve Per-User MFA'yı Disabled tutar. P1 lisansı olmayan bir organizasyon ise Security Defaults'ı açık bırakır. Yeni oluşturulan Tenant'lar, Conditional Access yapılandırılana kadar Security Defaults açık olarak gelir. Hangi baseline tercih edilirse edilsin, yönetim portallarına uygulanan zorunlu MFA enforcement katmanı bunların tümünün üzerinde ayrıca yürürlüktedir; bu konuyu yukarıda Mandatory MFA Enforcement bölümünde ele aldım.

Özet ve Zihinsel Harita

Per-User MFA Legacy bir yapıdır ve bugün kullanılmamalıdır. Conditional Access kullanılan ortamlarda Disabled bırakılır. Security Defaults ücretsiz bir baseline'dır, Tenant geneli ve All-Or-Nothing çalışır ve Conditional Access ile aynı anda aktif olamaz. Conditional Access modern standarttır, P1 lisansı gerektirir, granular kontrol sunar ve bugün her organizasyonun hedeflemesi gereken yöntemdir. Granular ve koşula bağlı bir MFA yönetimi için Security Defaults kapatılır, Conditional Access kullanılır ve Per-User MFA Disabled bırakılır.

Tüm bu katmanlardan bağımsız olarak, yönetim yüzeylerine uygulanan Mandatory MFA Enforcement katmanı her zaman yürürlüktedir ve özellikle Break-Glass hesaplarının tasarımında mutlaka dikkate alınmalıdır.

Faydalı olması dileğiyle...