Custom Controls'tan External MFA'ya Geçiş Nasıl Yapılır? (2026)

Özet (TL;DR): Microsoft, Conditional Access (koşullu erişim — cihaz, konum veya risk durumuna göre oturum açma kurallarını belirleyen güvenlik katmanı) içindeki Custom Controls (özel denetimler) özelliğini emekliye ayırıyor: Microsoft Learn'e göre Eylül 2026'dan itibaren yeni bir custom control oluşturulamıyor ve mevcutlar düzenlenemiyor, tam emeklilik ise 2027'nin başında gerçekleşecek. Duo, RSA SecurID gibi üçüncü taraf çok faktörlü kimlik doğrulama (MFA) sağlayıcılarını bu yöntemle Conditional Access'e bağlayan kurumlar, yerine geçen resmi özellik olan External MFA'ya (harici çok faktörlü kimlik doğrulama) geçmek zorunda. Bu yazıda Microsoft'un resmi 7 adımlı geçiş sürecini — envanter çıkarma, External MFA yapılandırma, test kullanıcısı kaydı, report-only test ilkesi, kademeli devreye alma — portal ekran adları, Microsoft Graph PowerShell komutları ve yaygın hatalarıyla uçtan uca anlatıyoruz. Birincil kaynak: Microsoft Learn'ün "Migrate from custom controls to external MFA" rehberi (son güncelleme 2026-07-09) ve "Custom controls" makalesi (son güncelleme 2026-05-19).

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı (2016'dan bu yana) · Microsoft Entra ID ve kimlik güvenliği konusunda SC-300/MS-102 sertifikalı danışmanlar. Bu yazıdaki adımlar, ekran adları ve komutlar Microsoft'un resmi dokümantasyonundan alınmıştır.

Kurumunuzda Custom Controls kullanılıp kullanılmadığından emin değilseniz ücretsiz bir Conditional Access envanteri çıkaralım — mevcut ilkelerinizi tarayıp hangi birimlerin bu değişiklikten etkilendiğini raporlayalım.

Custom Controls Neden Emekliye Ayrılıyor?

Custom Controls, Microsoft Entra ID'nin önizleme (preview) aşamasındaki bir özelliğiydi. Bir Conditional Access ilkesinde Grant (izin) kontrolü olarak seçildiğinde, kullanıcının tarayıcısı Microsoft Entra ID dışındaki uyumlu bir sağlayıcıya (örneğin Duo veya RSA SecurID) yönlendiriliyor, orada doğrulamayı tamamlıyor ve sonucu Microsoft Entra ID'ye geri bildiriyordu. Kurulumu için sağlayıcıdan alınan bir JSON veri bloğunun portala yapıştırılması yeterliydi — bu basitlik, özelliği yıllarca yaygın bir "harici MFA'yı Conditional Access'e bağlama" yöntemi yaptı.

Ancak Custom Controls'un ciddi teknik sınırları vardı. Microsoft Learn'ün resmi karşılaştırması şöyle:

• Conditional Access "MFA gerektir" kontrolünü karşılamıyor — sistem, kullanıcının gerçekten çok faktörlü doğrulama yaptığını "bilmiyor", sadece harici bir adıma yönlendirdiğini biliyor.
• Oturum açma günlüklerinde MFA doğru görünmüyor — denetim ve KVKK uyumluluk raporlarında "MFA yapıldı" kanıtı eksik kalıyor.
• Privileged Identity Management (PIM) ile çalışmıyor — rol yükseltmelerinde ek MFA zorunluluğu kuramazsınız.
• Risk tabanlı Conditional Access'i desteklemiyor — Identity Protection'ın otomatik risk tepkileriyle uyumsuz.
• Intune cihaz kaydını desteklemiyor.

External MFA (önceki adıyla "external authentication methods") genel kullanıma açıldığında, Microsoft bu sınırların tamamını çözen, OpenID Connect (OIDC) tabanlı standart bir entegrasyon sundu ve Custom Controls'u resmen deprecate (kullanımdan kaldırma sürecine alma) etti. Microsoft Learn'ün uyarı kutusu net: "Custom controls are deprecated. Adding new custom controls and editing existing custom controls will not be allowed starting September 2026. Full retirement is scheduled for early 2027." Yani 2026-09 itibarıyla dondurma, 2027 başında tam kaldırma takvimde.

Bu Değişiklik Kimi Etkiliyor?

Yalnızca mevcut Conditional Access ilkelerinde Grant sekmesi altında bir custom control kullanan kurumlar etkileniyor. Hiç kullanmıyorsanız Microsoft Learn'ün kendi ifadesiyle "aksiyon gerekmez". Emin değilseniz aşağıdaki Adım 1'deki tarama komutunu 5 dakikada çalıştırıp kesin cevabı alabilirsiniz — tahmine dayalı karar vermeyin, birçok kurumda bu ilkeler yıllar önce kurulup unutulmuş oluyor.

Ön Gereksinimler

Geçişe başlamadan önce aşağıdakilerin hazır olduğundan emin olun:

• Microsoft Entra ID P1 veya P2 lisansı (External MFA de aynı lisans katmanında çalışıyor; ek lisans maliyeti genelde çıkmaz).
• Authentication Policy Administrator rolü (veya Global Administrator).
• Privileged Role Administrator rolü — sağlayıcının uygulamasına yönetici onayı (admin consent) vermek için.
• Harici MFA sağlayıcınızdan alınacak üç bilgi: Application ID (genelde çok kiracılı/multitenant), Client ID ve Discovery URL (OIDC meta veri uç noktası, örn. https://provider.example.com/.well-known/openid-configuration).
• Test için ayrılmış bir kullanıcı grubu (asla doğrudan tüm kullanıcılarla başlamayın).
• Mevcut custom control kullanan tüm Conditional Access ilkelerinin envanteri.

Adım 1: Mevcut Custom Control İlkelerini Envanterle

Geçişe başlamadan önce mevcut durumu belgeleyin. Portalda kontrol için:

1. Microsoft Entra yönetim merkezi'ne en az Authentication Policy Administrator olarak giriş yapın.
2. Protection > Conditional Access > Policies yoluna gidin.
3. Her ilkeyi inceleyin, Grant kontrolleri altında custom control kullananları not edin.
4. Her ilke için ilke adı/ID'si, hedeflenen kullanıcı/grup, hedeflenen bulut uygulaması, referans verilen custom control sağlayıcısı ve koşulları (konum, cihaz platformu vb.) kaydedin.

Büyük tenant'larda (kiracılarda) onlarca hatta yüzlerce Conditional Access ilkesi olabileceğinden, aşağıdaki Microsoft Graph PowerShell komutuyla taramayı otomatikleştirmek çok daha güvenilir:

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and (
        @($_.GrantControls.CustomAuthenticationFactors) |
        Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }
    ).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }) -join "," }
}

Çıktıyı bir tabloya aktarıp her ilkenin geçiş durumunu (bekliyor / test ediliyor / tamamlandı) takip edin — aksi halde kapsamı hafife alma riski yüksek.

Adım 2: External MFA Kimlik Doğrulama Yöntemi Politikasını Yapılandırma

Bu adım, harici MFA sağlayıcınızı Microsoft Entra ID'de tanınan bir kimlik doğrulama yöntemi olarak kaydeder. Görünürlük ve yönetim kolaylığı için Microsoft Entra yönetim merkezini öneriyoruz, ama Microsoft Graph API veya PowerShell ile otomasyon da mümkün.

Microsoft Entra yönetim merkezinde:

1. Protection > Authentication methods > Policies yoluna gidin.
2. Add external method (veya Add method > External Authentication Method) seçin.
3. Gerekli alanları doldurun: Display Name (oluşturulduktan sonra değiştirilemez, örn. "Xen External MFA - Duo"), Client ID, App ID, Discovery Endpoint.
4. İstendiğinde sağlayıcının uygulaması için yönetici onayı (admin consent) verin — onay verilmezse yöntem devre dışı kalır.
5. Enable and target altında durumu Enabled yapın, başlangıçta yalnızca test grubunuzu hedefleyin ("Tüm kullanıcılar" değil), acil erişim (break-glass) hesaplarınızı isteğe bağlı olarak hariç tutun.
6. Save ile kaydedin.

Otomasyon tercih ederseniz Microsoft Graph API ile:

POST https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations
Content-Type: application/json

{
  "@odata.type": "#microsoft.graph.externalAuthenticationMethodConfiguration",
  "displayName": "Xen External MFA",
  "state": "enabled",
  "appId": "<saglayici-app-id>",
  "openIdConnectSetting": {
    "clientId": "<saglayici-client-id>",
    "discoveryUrl": "https://provider.example.com/.well-known/openid-configuration"
  },
  "includeTargets": [
    { "@odata.type": "microsoft.graph.authenticationMethodTarget", "id": "<test-grup-id>", "targetType": "group" }
  ]
}

Ya da PowerShell ile:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

$params = @{
    "@odata.type"        = "#microsoft.graph.externalAuthenticationMethodConfiguration"
    displayName          = "Xen External MFA"
    state                = "enabled"
    appId                = "<saglayici-app-id>"
    openIdConnectSetting = @{
        clientId     = "<saglayici-client-id>"
        discoveryUrl = "https://provider.example.com/.well-known/openid-configuration"
    }
    includeTargets = @(@{ "@odata.type" = "microsoft.graph.authenticationMethodTarget"; id = "<test-grup-id>"; targetType = "group" })
}

New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -BodyParameter $params

Adım 3: Test Kullanıcılarını Kaydetme ve Doğrulama

External MFA ilkesi test grubunuza hedeflendikten sonra, kullanıcıların bu yöntem için kayıtlı olduğundan emin olun. Belirli bir kullanıcının kayıtlı yöntemlerini kontrol için:

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

$userId = "<kullanici-object-id-veya-upn>"
Get-MgUserAuthenticationMethod -UserId $userId |
    Format-Table Id, @{N='Type'; E={$_.'@odata.type'}}

Kayıt eksikse, yöneticiler portaldan kullanıcı bazında kayıt ekleyebilir: Users > All users, ilgili kullanıcıyı seçin, Authentication Methods > + Add Authentication Method > External authentication method. Test grubunun tamamı için toplu doğrulama raporu almak isterseniz:

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

$groupId = "<test-grup-id>"
$members = Get-MgGroupMember -GroupId $groupId -All

$report = foreach ($member in $members) {
    $methods = Get-MgUserAuthenticationMethod -UserId $member.Id
    $hasExternalMFA = $methods | Where-Object { $_.'@odata.type' -like '*external*' }
    [PSCustomObject]@{
        UPN         = $member.AdditionalProperties.userPrincipalName
        ExternalMFA = if ($hasExternalMFA) { "Evet" } else { "Hayır" }
    }
}
$report | Export-Csv -Path "ExternalMFA-Kayit-Raporu.csv" -NoTypeInformation

Bu adımları kendi tenant'ınızda uygulamak zaman alıyorsa veya sağlayıcı tarafındaki OIDC entegrasyonunda takılırsanız, Xen Bilişim uzmanlarıyla WhatsApp'tan yazışın — 15 dakikalık ücretsiz teknik görüşmede size özel geçiş planını birlikte çıkaralım.

Adım 4: Report-Only Modda Test Conditional Access İlkesi Oluşturma

Custom control yerine standart "Require multifactor authentication" Grant kontrolünü kullanan yeni bir ilke oluşturun — External MFA artık bu kontrolü gerçekten karşılıyor.

1. Protection > Conditional Access > Policies > + New policy.
2. Name: örn. "Test - External Auth ile MFA gerektir".
3. Assignments > Users: yalnızca test grubunuz; Exclude: acil erişim (break-glass) hesaplarınız.
4. Target resources > Cloud apps: mevcut custom control ilkenizin hedeflediği aynı uygulamalar.
5. Conditions: istenirse eski ilkeyle aynı istemci uygulaması / cihaz platformu / konum koşullarını yansıtın.
6. Grant > Grant access > Require multifactor authentication işaretleyin.
7. Report-only modda kaydedin.

Önemli: Microsoft Learn açıkça uyarıyor — "External MFA isn't yet compatible with authentication strength policies"; yani "Require authentication strength" kontrolünü değil, standart "Require multifactor authentication" kontrolünü kullanmalısınız.

Test kullanıcısı hedeflenen bir uygulamaya giriş yaptıktan sonra Protection > Sign-in logs'ta ilgili oturumun Conditional Access sekmesinde ilkenin "Report-only: Success" göründüğünü ve MFA yönteminin harici sağlayıcınız olarak listelendiğini doğrulayın. Sonuçlardan memnunsanız ilkeyi düzenleyip Report-only'den On'a alın.

Adım 5: Kademeli Geçiş ve Eski İlkeyi Kapatma

Test kullanıcılarının hem eski custom control ilkesine hem yeni ilkeye aynı anda tabi olmaması için, eski ilkenin Users > Exclude alanına test grubunuzu ekleyin. Ardından Conditional Access > What If aracıyla bir test kullanıcısı ve hedef uygulama seçip eski ilkenin artık uygulanmadığını, yeni ilkenin uygulandığını doğrulayın.

Doğrulama tamamlandıktan sonra tüm kuruma yayılan 4 fazlı bir plan izleyin:

Faz	Kapsam	Aksiyon
Faz 1	Test grubu (5-10 kullanıcı)	Yukarıdaki 1-4. adımlar
Faz 2	BT ekibi / erken benimseyenler (50-100 kullanıcı)	External MFA hedefini ve CA ilkesi kapsamını genişletin
Faz 3	Departman departman	Grupları kademeli olarak custom control'den MFA ilkesine taşıyın
Faz 4	Tüm kullanıcılar	Tam geçiş; custom control ilkesini kaldırın

Tüm kullanıcılar taşındıktan sonra eski custom control ilkesini devre dışı bırakın (disabled) ama silmeyin; sign-in loglarını 1-2 hafta izleyip gerileme (regression) olmadığını teyit ettikten sonra hem ilkeyi hem tenant'taki custom control tanımını kaldırın. Microsoft Learn'ün uyarısı net: "Don't delete custom control configurations until you confirm the new external MFA policy is stable."

Yaygın Hatalar ve Çözümleri

Sorun	Olası neden	Çözüm
External MFA yöntemi kullanıcılarda görünmüyor	Yöntem etkin değil veya kullanıcı includeTargets'te değil	Authentication Methods'ta hedeflemeyi kontrol edin
Yönetici onayı (admin consent) hatası	Yetersiz rol	Global Admin veya Privileged Role Admin ile onay verin
Sign-in loglarında MFA tanınmıyor	İlke yanlış yapılandırılmış	"Require MFA" grant kullanıldığından emin olun (authentication strength değil)
Kullanıcı MFA istemiyle karşılaşmıyor	CA ilkesi uygulanmıyor	What If aracıyla ilke değerlendirmesini hata ayıklayın
Harici sağlayıcı hatası veriyor	OIDC yapılandırma uyuşmazlığı	Discovery URL, Client ID, App ID'yi sağlayıcıyla teyit edin
Kullanıcılar hem eski hem yeni MFA istemi görüyor	Kullanıcı eski ilkeden hariç tutulmamış	Eski custom control ilkesindeki Exclude grubunu kontrol edin

Türkiye'deki Kurumlar İçin Özel Noktalar

Türkiye'de özellikle bankacılık, sigorta ve finans sektöründeki kurumlarda Duo ve RSA SecurID gibi harici MFA sağlayıcıları yıllardır Conditional Access ile birlikte custom control üzerinden kullanılıyor — bu yazı özellikle bu kurumları etkiliyor. İki yerel gerçek ön plana çıkıyor:

• KVKK açısından: 6698 sayılı Kanun'un 12. maddesindeki "gerekli teknik tedbir" yükümlülüğü kapsamında yapılan denetimlerde, custom control tabanlı MFA'nın oturum açma günlüklerinde "MFA yapıldı" olarak görünmemesi, denetçiler tarafından "çok faktörlü doğrulama kanıtı eksik" bulgusuna yol açabiliyor. External MFA'ya geçiş bu boşluğu resmi olarak kapatıyor; acil erişim (break-glass) hesabı kurulumuyla birlikte ele alınmalı.
• Şube bağlantısı gerçeği: Çok şubeli kurumlarda (sigorta acenteleri, perakende zincirleri) şubelerin mobil şebeke veya düşük bant genişlikli hat üzerinden internete çıktığı senaryolarda, harici sağlayıcının push bildirimi zaman aşımına uğrayabiliyor. Geçiş planında OTP (tek kullanımlık şifre) yedek yöntemini mutlaka test edin, aksi halde şube kullanıcıları kilitli kalabilir.

Saha Vakası: 90 Kişilik Bir Sigorta Acentesi Zinciri

Firma X — 90 kişilik, 6 şubeli bir sigorta acentesi zinciri — 2019'dan beri Duo Security'yi Conditional Access'te custom control olarak kullanıyordu. Yıllık bilgi güvenliği denetiminde, Duo doğrulamasının Microsoft Entra ID sign-in loglarında "MFA tamamlandı" olarak görünmediği, bu yüzden KVKK'nın 12. madde teknik tedbir gerekliliği için yeterli kanıt sunulamadığı tespit edildi.

Süre: Envanterden tam geçişe 5 hafta. Karar noktaları: (1) Duo'nun External Authentication Method entegrasyonu hazır olduğu için sağlayıcı tarafında ek proje gerekmedi; (2) test grubu önce merkez ofisteki BT ekibinden seçildi, şube kullanıcıları en son taşındı çünkü mevcut mobil hat altyapısında push bildirimi zaman zaman gecikiyordu; (3) eski custom control ilkesi tamamen silinmeden önce 2 hafta yalnızca devre dışı bırakılarak geri dönüş seçeneği açık tutuldu.

Sonuç: Sign-in loglarında MFA doğrulama oranı denetim raporlarında görünür hale geldi; ayrıca yönetici rollerine PIM ile geçici yükseltme yapılırken artık External MFA zorunlu kılınabildi — custom control ile bu hiç mümkün değildi. Xen ekibinin rolü: Conditional Access envanteri, Duo tarafında OIDC entegrasyon adımlarının koordinasyonu, 4 fazlı rollout planının uygulanması ve denetim raporuna eklenecek uygunluk kanıtının hazırlanması. Saha notu: Şube bağlantısı zayıfsa push bildirimi yerine OTP fallback'i mutlaka önceden test edin.

Bu geçişi kendi ekibinizle mi yürüteceksiniz yoksa uçtan uca destek mi almak istersiniz? TL faturayla Xen Bilişim'den teklif alın — envanterden tam geçişe kadar süreci biz yönetebiliriz.

Sıkça Sorulan Sorular (SSS)

Custom Controls tam olarak ne zaman kullanılamaz hale gelecek?

Microsoft Learn'e göre Eylül 2026'dan itibaren yeni bir custom control oluşturulamıyor ve mevcutlar düzenlenemiyor. Tam emeklilik (retirement) 2027'nin başında gerçekleşecek.

Şu anda Custom Controls kullanmıyorsak bir şey yapmamız gerekiyor mu?

Hayır. Microsoft Learn rehberi açıkça "bu rehber yalnızca custom control kullanan kurumlar için geçerlidir, kullanmıyorsanız aksiyon gerekmez" diyor. Yine de Conditional Access ilkelerinizin Grant sekmesini hızlıca tarayıp emin olmakta fayda var.

External MFA hangi lisansla geliyor, ek maliyet çıkar mı?

Microsoft Entra ID P1 veya P2 lisansı gerekiyor. Custom Controls de zaten aynı lisans katmanında çalıştığı için, çoğu kurumda ek lisans maliyeti çıkmaz — mevcut lisansınız yeterlidir.

Hangi üçüncü taraf MFA sağlayıcıları External MFA ile çalışıyor?

Sağlayıcının OpenID Connect (OIDC) tabanlı bir External Authentication Method entegrasyonu sunması gerekiyor. Duo ve RSA gibi kurumsal sağlayıcılar bu geçişi destekliyor; kesin destek durumunu kendi sağlayıcınızla teyit edin.

"Require authentication strength" ile External MFA birlikte kullanılabilir mi?

Hayır. Microsoft Learn açıkça External MFA'nın authentication strength ilkeleriyle henüz uyumlu olmadığını belirtiyor. Bunun yerine standart "Require multifactor authentication" grant kontrolünü kullanmanız gerekiyor.

Geçiş sırasında kullanıcılar hem eski hem yeni MFA istemiyle karşılaşabilir mi?

Evet, test veya taşınan kullanıcıları eski custom control ilkesinden Exclude (hariç tutma) ile çıkarmazsanız bu çakışma yaşanır. Bu, troubleshooting tablosundaki en sık karşılaşılan hatalardan biridir.

Bu geçişi ne kadar sürede tamamlayabiliriz?

Microsoft'un 4 fazlı rollout planına göre, orta ölçekli bir kurum (100-500 kullanıcı) için gerçekçi süre 3-6 hafta arasındadır. Saha vakamızdaki 90 kişilik firma bu süreci 5 haftada tamamladı.

Eski custom control ilkesini ne zaman tamamen silebiliriz?

Microsoft Learn, yeni ilkenin stabil çalıştığı onaylandıktan sonra eski ilkeyi en az 1-2 hafta devre dışı (disabled) ama silmeden tutmanızı, geri dönüş (rollback) seçeneği için öneriyor.

Sonuç: Geçişi Şimdi Planlayın, Eylül Baskısını Yaşamayın

Custom Controls'un emekliye ayrılması ani bir kesinti değil, Microsoft'un planlı bir geçiş süreci — ama "dondurma" tarihi Eylül 2026, yani şu an aktif. Elinizde hâlâ birkaç ay var, fakat özellikle çok şubeli veya yoğun denetimli (finans, sigorta) kurumlarda envanterden tam geçişe 4-6 hafta sürebiliyor; son ana bırakmak hem MFA boşluğu hem KVKK denetim riski yaratır.

Pratik özet: önce hangi ilkelerin custom control kullandığını PowerShell ile çıkarın, sonra Microsoft Security çözümlerimiz kapsamında ele aldığımız External MFA'yı test grubunda deneyin, report-only modda doğrulayın ve 4 fazlı planla kademeli olarak tüm kuruma yayın. Eski ilkeyi silmeden önce rollback penceresi bırakmayı unutmayın.

Bu süreç, genel olarak Microsoft Entra ID ve Azure kimlik altyapınızın güncel tutulmasının bir parçası; benzer şekilde Privileged Identity Management (PIM) ile ayrıcalıklı erişim yönetimini de gözden geçirmek iyi bir fırsat olabilir.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Microsoft Entra Conditional Access ve kimlik güvenliği geçişlerinde envanterden kademeli devreye almaya kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın veya WhatsApp'tan yazın.