AADSTS53003 Koşullu Erişim Engeli Hatası ve Çözümü (2026)

Xen Bilişim ekibi · Microsoft CSP Direct Partner (2016+) · MS-100/MS-102/AZ-104/SC-300 sertifikalı kimlik ve güvenlik danışmanları

Özet (TL;DR): AADSTS53003 — Access has been blocked by Conditional Access policies hatası, kullanıcının oturum açma girişiminin bir Koşullu Erişim (Conditional Access) ilkesi tarafından engellendiği anlamına gelir. Sorun neredeyse her zaman yanlış yapılandırılmış bir ilkedir: cihaz uyumluluğu, güvenilmeyen konum, MFA gereksinimi veya "tüm kullanıcılar / tüm kaynaklar" kapsamına düşen bir engelleme kuralı. Çözüm sırası: (1) hata ekranındaki correlation ID'yi alın, (2) Entra oturum açma günlüklerinde ilgili olayı bulup hangi ilkenin uygulandığını görün, (3) ilkeyi rapor moduna alın veya kullanıcıyı istisna edin, (4) yönetici olarak kilitlendiyseniz acil durum (break-glass) hesabıyla girin. Bu yazı 2026-07 itibarıyla geçerli Microsoft Entra arayüzüne göre adım adım tüm senaryoları kapsar.

Türkiye'de birçok kurum, Microsoft'un 2026 boyunca kademeli olarak zorunlu kıldığı yönetici MFA ve Koşullu Erişim tabanı sonrası bu hatayı ilk kez görmeye başladı. Kötü haber: yanlış kapsamlı tek bir ilke tüm kiracıyı (tenant) dışarıda bırakabilir. İyi haber: doğru tanı akışıyla çoğu vaka 15-30 dakikada çözülür. Aşağıdaki adımlar, hem son kullanıcının "giremiyorum" şikâyetini hem de yöneticinin "kendimi kilitledim" panik senaryosunu ayrı ayrı ele alır.

Kiracınız kilitlendiyse acil Koşullu Erişim müdahalesi için hemen bize ulaşın — Xen ekibi break-glass ve ilke geri alma sürecini uçtan uca yönetir.

Belirtiler ve Hata Varyantları

AADSTS53003 hatası tarayıcıda, masaüstü Office uygulamalarında ve mobil istemcilerde farklı yüzlerle karşınıza çıkar. En sık görülen metinler:

• Tarayıcı: "You cannot access this right now. Your sign-in was successful but does not meet the criteria to access this resource." veya "Access has been blocked by Conditional Access policies. The access policy does not allow token issuance."
• Türkçe arayüz: "Şu anda buraya erişemezsiniz. Oturum açma işleminiz başarılı oldu ancak bu kaynağa erişim ölçütlerini karşılamıyor."
• Outlook / Teams masaüstü: Sürekli tekrar eden kimlik doğrulama penceresi veya "Something went wrong [1001]" benzeri döngü.
• Mobil (Outlook/Authenticator): "More information is required" ya da uygulamanın sessizce oturumu düşürmesi.

Ekranda genellikle bir Correlation ID, Request ID ve Timestamp bulunur. Bu üç değeri not edin — tanının anahtarı bunlardır. "More Details" (Daha Fazla Ayrıntı) bağlantısına tıklamak bu bilgileri açığa çıkarır.

Koşullu Erişim Hata Kodları Tablosu

53003, ailesinin en genel üyesidir. Doğru kök nedeni bulmak için önce hangi 530xx kodunun döndüğüne bakın (Microsoft bu kodları AADSTS ön ekiyle gösterir):

Hata Kodu	Anlamı	Tipik Neden
AADSTS53000	DeviceNotCompliant	Cihaz Intune'da uyumlu değil
AADSTS53001	DeviceNotDomainJoined	Cihaz Entra'ya kayıtlı/birleşik değil
AADSTS53002	ApplicationUsedIsNotAnApprovedApp	Onaylı istemci uygulaması zorunlu, kullanılan uygulama onaysız
AADSTS53003	BlockedByConditionalAccess	Genel engelleme — konum, MFA, kullanıcı riski veya "engelle" kuralı
AADSTS53004	ProofUpBlockedDueToRisk	Risk nedeniyle MFA kaydı engellendi
AADSTS53009	Intune app protection gerekli	Uygulama koruma ilkesi (APP) zorunlu

Kod 53003 ise sorun neredeyse her zaman koşul tarafındadır: güvenilmeyen konum, uyumsuz cihaz, karşılanmayan MFA veya doğrudan "Erişimi engelle (Block access)" verme denetimi. Kaynak: Microsoft Learn — Troubleshoot sign-in problems with Conditional Access.

Hızlı Tanı: Hangi İlke Engelliyor?

Beş dakikalık teşhis akışı. Yönetici erişiminiz hâlâ varsa doğrudan buradan başlayın:

1. Correlation ID'yi alın: Kullanıcıdan hata ekranındaki "More Details" altındaki Correlation ID ve zaman damgasını isteyin.
2. Entra oturum açma günlüklerini açın: Microsoft Entra yönetim merkezi > Entra ID > İzleme ve durum (Monitoring & health) > Oturum açma günlükleri.
3. Filtreleyin: Correlation ID, kullanıcı adı ve tarihe göre daraltın. İlgili başarısız olayı bulun.
4. Conditional Access sekmesine geçin: Olayı açıp Koşullu Erişim (Conditional Access) sekmesinde hangi ilkenin "Başarısız (Failure)" döndüğünü görün. İlke adına tıklayarak hangi denetimin (grant control) tetiklendiğini inceleyin.
5. Sağdaki "…" menüsünden ilke ayrıntısı: Sol tarafta oturumdan toplanan bilgiler, sağ tarafta bu bilgilerin ilke koşullarını karşılayıp karşılamadığı gösterilir. Kırmızı görünen koşul, kök nedendir.

PowerShell ile toplu inceleme yapmak isteyen yöneticiler için (2026-07 itibarıyla Microsoft Graph PowerShell), son başarısız Koşullu Erişim olaylarını listeleme:

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 10 |
  Select-Object CreatedDateTime, UserDisplayName, AppDisplayName, IPAddress, Status

Belirli bir ilkeyi (policy ID ile) hedefleyerek etkilenen oturumları görmek için Microsoft Entra PowerShell modülü de kullanılabilir. Doğrulama komutları için bkz. Uygulanan Koşullu Erişim ilkelerini görüntüleme.

Kök Neden Analizi: 6 Yaygın Senaryo

53003 vakalarının büyük çoğunluğu şu altı kök nedenden birine iner:

• Uyumsuz cihaz koşulu: "Cihazın uyumlu olarak işaretlenmesini gerektir" ilkesi var ama cihaz Intune'a kaydolmamış veya uyumluluk politikasını geçmiyor.
• Güvenilmeyen konum: İlke yalnızca belirli ülke/IP aralıklarından erişime izin veriyor; kullanıcı seyahatte, VPN'de veya evde farklı bir IP'de.
• MFA kaydı eksik: MFA zorunlu ama kullanıcı henüz kimlik doğrulama yöntemi kaydetmemiş; kayıt akışı da başka bir ilkeyle engellenmiş (kısır döngü).
• Onaylı uygulama / uygulama koruma ilkesi: Mobilde yalnızca onaylı istemci (ör. Outlook) izinli; kullanıcı yerel posta uygulamasını kullanıyor.
• Hizmet bağımlılığı (service dependency): Kullanıcı Teams'e giriyor sanıyor ama arka planda SharePoint/Exchange kaynağı çağrılıyor ve o kaynağı engelleyen bir ilke devrede.
• "Tümünü engelle" hatası: "Tüm kullanıcılar + tüm kaynaklar → Erişimi engelle" ya da "uyumlu cihaz gerektir" gibi bir kural yanlışlıkla herkesi (yöneticiler dâhil) dışarıda bırakmış.

Bu son senaryo Türkiye'deki kurumlarda en tehlikelisidir: Microsoft'un zorunlu MFA dalgasıyla aceleyle kurulan geniş kapsamlı ilkeler, break-glass hesabı hariç tutulmadığında tüm kiracıyı kilitleyebilir.

Adım Adım Çözüm (En Kolaydan En Zora)

1. Aşama — Kullanıcı tarafı hızlı kontroller

1. Kullanıcıya kurum ağından/VPN'den yeniden denemesini söyleyin (konum koşulunu eler).
2. Tarayıcı önbelleğini temizleyip gizli pencerede oturum açmayı deneyin (eski token kaynaklı 53003'ü eler).
3. Authenticator uygulamasında MFA isteminin onaylanıp onaylanmadığını doğrulayın.
4. Cihazın Intune'da "uyumlu" göründüğünü Şirket Portalı (Company Portal) üzerinden kontrol ettirin.

2. Aşama — Yönetici tarafı ilke düzeltmesi

1. Oturum günlüğünden tespit ettiğiniz ilkeyi açın.
2. İlkeyi hemen "Yalnızca rapor (Report-only)" moduna alarak engellemeyi durdurun — bu, üretimi kırmadan davranışı gözlemlemenizi sağlar.
3. Etkilenen kullanıcıyı geçici olarak istisna (exclude) listesine ekleyin.
4. Kök neden konum ise güvenilir konumu (Named Location) doğru IP/ülke ile güncelleyin.
5. Kök neden cihaz uyumluluğu ise kullanıcının cihazını Intune'a kaydettirin veya koşulu gevşetin.
6. Düzeltmeyi What If (Ne Olurdu) aracıyla test edin, sonra ilkeyi tekrar "Açık (On)" konumuna alın.

3. Aşama — Yönetici kilitlendiyse (acil kurtarma)

1. İlkeden hariç tutulmuş bir break-glass / acil durum yönetici hesabı varsa onunla girip ilkeyi devre dışı bırakın.
2. Başka bir yönetici hâlâ girebiliyorsa ondan ilkeyi kapatmasını isteyin.
3. Hiçbir yönetici giremiyorsa Microsoft'a destek talebi açın; Microsoft doğrulama sonrası engelleyen ilkeyi geri alır. Bu süreç saatler alabilir — bu yüzden break-glass hesabı hayati önemdedir.

Senaryoya Özel Dallar

• Tek kullanıcı vs. tüm kiracı: Sadece bir kullanıcı etkileniyorsa büyük olasılıkla cihaz/konum koşulu; herkes etkileniyorsa geniş kapsamlı "engelle" kuralı veya MFA tabanı.
• Dış / konuk (guest) kullanıcı: B2B konuk kullanıcılar için ayrı bir ilke devrede olabilir; misafir kullanıcı MFA'sını kendi kiracısında yapmamışsa 53003 alır. Konuk kapsamını ayrı yönetin.
• Masaüstü vs. web: Web'de girebilip Outlook masaüstünde giremiyorsa "onaylı uygulama" veya modern kimlik doğrulama/token sorunu; istemci sürümünü güncelleyin.
• Yeni cihaz / yeni çalışan: Onboarding sırasında cihaz henüz uyumlu değilken uyumluluk koşulu tetiklenir; ilk kayıt için geçici filtre uygulayın.

Türkiye'ye Özel Katman: KVKK, Zorunlu MFA ve Yerel Gerçekler

Zorunlu MFA dalgası: Microsoft 2026 boyunca yönetim portallarına erişim için MFA'yı kademeli olarak zorunlu kıldı. Türkiye'deki birçok KOBİ, hazırlıksız yakalanıp aceleyle geniş kapsamlı Koşullu Erişim ilkeleri kurdu ve 53003 dalgasıyla karşılaştı. Doğru yaklaşım: önce "yalnızca rapor" modunda pilotlayın, break-glass hesabını hariç tutun, sonra üretime alın. Zorunlu MFA'yı hatasız kurmak için bkz. Microsoft Azure zorunlu MFA nasıl yapılandırılır.

KVKK (6698) bağlamı: Koşullu Erişim, KVKK'nın 12. maddesindeki "verilere hukuka aykırı erişimi önleme" yönündeki gerekli teknik tedbirin somut bir uygulamasıdır. Konum tabanlı erişim ve uyumlu cihaz zorunluluğu, kişisel veriyi işleyen sistemlere erişim denetimini belgelenebilir hâle getirir. Ancak ilkeyi aşırı gevşetip 53003'ü "çözmek" için MFA'yı kaldırmak, aynı maddeye aykırı bir güvenlik zafiyeti yaratır — çözüm, kilidi açarken güvenlik seviyesini korumaktır.

TR yerel gerçek: Kullanıcıların cep operatörü (Turkcell/Vodafone/Türk Telekom) IP'leri sık değiştiği için katı "güvenilir IP" listeleri mobilde sürekli 53003 üretebilir. Türkiye'de sabit IP havuzu yerine ülke tabanlı güvenilir konum + uyumlu cihaz kombinasyonu genelde daha az yanlış pozitif verir. Ayrıca Türkiye'de Azure bölgesi bulunmadığından oturum günlükleri West Europe üzerinden akar; günlük gecikmesi birkaç dakika olabilir, olayı hemen görmezseniz 5 dakika bekleyin.

Saha Vakası: 60 Kişilik Üretim Firması Kilitlenmesi

Firma X — 60 kişilik makine imalatçısı — zorunlu MFA sonrası tüm kiracı kilidi

Bir sanayi müşterisi, Microsoft'un yönetici MFA duyurusunun ardından tek bir Koşullu Erişim ilkesi kurdu: "Tüm kullanıcılar + tüm bulut uygulamaları → MFA gerektir + uyumlu cihaz gerektir". Cihazların çoğu henüz Intune'a kayıtlı olmadığı için ertesi sabah 60 kullanıcının tamamı ve iki BT yöneticisi AADSTS53003 ile karşılaştı; kimse portala giremedi.

Süre: Çözüm 2 saat. Karar noktaları: (1) Break-glass hesabı önceden oluşturulmamıştı — Microsoft desteği yerine, geçici olarak MFA yapmış tek bir mobil yöneticinin oturumu üzerinden girildi; (2) İlke "yalnızca rapor" moduna alındı, engelleme anında durdu; (3) "Uyumlu cihaz" koşulu ilkeden çıkarıldı, MFA koşulu korundu; (4) Cihazlar Autopilot ile kademeli Intune kaydına alındı; (5) İki hariç tutulmuş break-glass hesabı oluşturuldu. Sonuç: Aynı gün tüm kullanıcılar üretime döndü, güvenlik seviyesi (MFA) korundu, bir hafta içinde cihaz uyumluluğu %90'a ulaştıktan sonra koşul yeniden etkinleştirildi. Xen ekibinin rolü: Acil kilidi açma, ilke yeniden mimarisi ve break-glass standardının kurulması. Uyarı: Break-glass hesabı olmayan hiçbir kiracıda geniş kapsamlı "engelle/gerektir" ilkesi doğrudan üretime alınmamalı.

Microsoft Güvenlik ve kimlik hizmetlerimizi inceleyin ya da WhatsApp'tan 15 dakikalık ücretsiz teknik görüşme planlayın.

Önleyici Kontroller: 53003'ü Bir Daha Yaşamamak

• Break-glass hesapları: Tüm Koşullu Erişim ilkelerinden hariç tutulmuş, uzun ve güvenli parolalı 2 acil durum hesabı oluşturun ve izleyin.
• Önce rapor modu: Her yeni ilkeyi en az bir hafta "yalnızca rapor" modunda çalıştırıp etki analizini yapın.
• What If aracı: Yayından önce farklı kullanıcı/cihaz/konum kombinasyonlarını simüle edin.
• Kademeli dağıtım: İlkeyi önce pilot gruba, sonra tüm kuruma açın.
• Onboarding filtresi: Yeni cihazların ilk kaydı için uyumluluk koşulunu geçici gevşetin.
• İzleme: Oturum açma günlüklerinde Koşullu Erişim başarısızlıklarını haftalık gözden geçirin.

Sıfırdan sağlam bir ilke kurmak için: Microsoft Entra Koşullu Erişim ilkesi nasıl yapılandırılır rehberimiz adım adım güvenli yapılandırmayı anlatır.

Kiracınız için break-glass + rapor-modu tabanlı güvenli Koşullu Erişim mimarisi kurduralım — ücretsiz değerlendirme talep edin.

Benzer Hatalar ve Farkları

53003'ü akrabalarıyla karıştırmayın: 50105 (kullanıcıya uygulama ataması yok — rol/atama sorunu, ilke değil), 50076/50079 (MFA gerekli ama bu Koşullu Erişim engeli değil, doğrudan MFA istemi), 65001 (kullanıcı onayı gerekli). Outlook'ta sürekli parola sorulması genelde 53003 değil, token/kimlik önbelleği sorunudur — bkz. Outlook sürekli şifre soruyor çözümü.

Sıkça Sorulan Sorular (SSS)

AADSTS53003 hatası tam olarak ne anlama gelir?

Oturum açma işleminizin kimlik doğrulaması başarılı oldu ancak bir Koşullu Erişim ilkesi, karşılanmayan bir koşul (uyumsuz cihaz, güvenilmeyen konum, eksik MFA veya doğrudan engelleme kuralı) nedeniyle token verilmesini engelledi anlamına gelir.

Hangi Koşullu Erişim ilkesinin engellediğini nasıl bulurum?

Microsoft Entra yönetim merkezi > Oturum açma günlükleri'nde kullanıcının başarısız olayını bulun, "Koşullu Erişim" sekmesine geçin ve "Başarısız" görünen ilkeyi inceleyin. Correlation ID ile filtrelemek olayı hızla bulmanızı sağlar.

Yönetici olarak kendimi kilitledim, nasıl girerim?

İlkeden hariç tutulmuş bir break-glass hesabınız varsa onunla girin. Yoksa engellenmeyen başka bir yöneticiden ilkeyi kapatmasını isteyin; hiçbir yönetici giremiyorsa Microsoft desteğine başvurun — bu yüzden önceden break-glass hesabı şarttır.

53003'ü çözmek için MFA'yı kaldırmalı mıyım?

Hayır. MFA'yı kaldırmak güvenlik zafiyeti yaratır ve KVKK'nın gerekli teknik tedbir beklentisine aykırıdır. Doğru çözüm, engelleyen koşulu (ör. yanlış konum veya cihaz gereksinimi) düzeltmek veya kullanıcıyı geçici istisna etmektir.

Sorun neden sadece Outlook masaüstünde çıkıyor, web'de çıkmıyor?

Büyük olasılıkla "onaylı istemci uygulaması" veya "uygulama koruma ilkesi" koşulu ya da eski bir token. İstemciyi güncelleyin, hesabı kaldırıp yeniden ekleyin; sorun sürerse ilgili masaüstü uygulaması koşulunu gözden geçirin.

Yeni bir ilkeyi üretime almadan nasıl test ederim?

İlkeyi "Yalnızca rapor" modunda çalıştırın ve "What If" aracıyla farklı kullanıcı/cihaz/konum senaryolarını simüle edin. En az bir hafta gözlemleyip yanlış pozitif olmadığını doğruladıktan sonra etkinleştirin.

Bu sorunu çözmek Xen ile ne kadar sürer?

Tek kullanıcı vakaları genelde aynı gün, tüm kiracı kilitlenmesi çoğu zaman 1-2 saat içinde çözülür. Ardından break-glass ve rapor-modu tabanlı kalıcı mimariyi kurarız. Ücretsiz ön değerlendirme için iletişime geçin.

Sonuç: Kilidi Açarken Güvenliği Koruyun

AADSTS53003, aslında Koşullu Erişim'in çalıştığının işaretidir — sadece yanlış kapsamda. Panikle MFA'yı veya ilkeyi tamamen kaldırmak yerine, doğru tanı akışını izleyin: correlation ID → oturum günlüğü → engelleyen ilke → rapor modu / istisna → kalıcı düzeltme. Bu yaklaşım kullanıcıyı dakikalar içinde içeri alırken güvenlik duruşunu bozmaz.

Uzun vadede farkı yaratan tek şey hazırlıktır: her kiracıda break-glass hesapları, her yeni ilkede önce rapor modu ve What If testi. Bu üç alışkanlık, 53003'ün bir daha üretimi durdurmasını engeller. Microsoft'un 2026 zorunlu MFA takvimi devam ederken, Koşullu Erişim mimarinizi bugün sağlamlaştırmak en düşük maliyetli sigortadır.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Microsoft Entra Koşullu Erişim ve kimlik güvenliği yolculuğunda ilke mimarisi, acil kilit açma ve KVKK uyumlu yapılandırmada uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın veya Microsoft 365 çözümlerimizi inceleyin.