Conditional Access Kilitlenmesi: Acil Erişim Hesabı Kurulumu (2026)

Özet (TL;DR): Microsoft Entra Conditional Access (koşullu erişim — cihaz, konum veya risk durumuna göre giriş kurallarını belirleyen güvenlik katmanı) politikaları yanlış kapsamla ("tüm kullanıcılar, tüm kaynaklar" gibi) yayına alındığında, sistem yöneticileri dahil tüm kurum tenant'ın (kiracı — kurumun tek bir Microsoft 365/Azure ortamı) dışında kalabilir. Microsoft Q&A'da 2026'da "URGENT: Global Administrator locked out after enabling Conditional Access" başlıklı bildirimler bu senaryonun gerçek ve tekrar eden bir risk olduğunu gösteriyor. Microsoft'un resmi çözümü nettir: en az iki acil erişim (break-glass) hesabı, parola yerine FIDO2 güvenlik anahtarı veya sertifika tabanlı kimlik doğrulamayla korunmalı ve Conditional Access politikalarından açıkça muaf tutulmalı. Bu yazıda kilitlenmenin belirtilerinden hata kodu tablosuna, şu anda kilitliyseniz izleyeceğiniz adımlardan kalıcı acil erişim hesabı kurulumuna kadar tüm süreci; Türkiye'de mobil şebeke bağımlılığı riski ve KVKK'ya uygun izleme dahil ele alıyoruz. 2026-06 itibarıyla geçerli birincil kaynak: Microsoft Learn'ün acil erişim hesapları rehberi (son güncelleme 2026-06-04) ve Conditional Access sorun giderme makalesi (son güncelleme 2026-03-24).

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

Belirtiler: Conditional Access Kilitlenmesi Nasıl Görünür?

Bir Conditional Access kilitlenmesi genelde iki şekilde ortaya çıkar. Birincisi, tek bir kullanıcının (çoğu zaman yeni bir cihazdan giriş yapan biri) tarayıcıda "You can't get there from here" ya da "Sign-in was blocked" gibi bir engelleme ekranıyla karşılaşmasıdır — can sıkıcıdır ama düzeltilebilir. İkincisi ve asıl tehlikeli olanı: politika "tüm kullanıcılar, tüm kaynaklar" gibi geniş bir kapsamla yayına alındığında, politikayı yayınlayan yöneticinin kendisi dahil hiç kimse tenant'a giriş yapamaz hale gelir. Microsoft Q&A'da "URGENT: Global Administrator locked out after enabling Conditional Access" başlığıyla bildirilen vaka tam olarak bu ikinci senaryodur — ve arama motorlarında benzer başlıkların sık tekrar etmesi, bunun izole bir kaza değil, Conditional Access dağıtımının bilinen bir riski olduğunu gösteriyor.

Microsoft'un kendi sorun giderme dokümantasyonu (Microsoft Learn, güncelleme 2026-03-24) da bu riski açıkça uyarıyor: "tüm kullanıcılar, tüm kaynaklar" kapsamında Block access, Require device to be marked as compliant, Require Hybrid Microsoft Entra domain joined device veya Require app protection policy gibi kontrollerden herhangi biri, cihazı henüz kayıtlı olmayan bir yönetici için de geçerli olur — ve o yönetici kendi hatasını düzeltmek için ihtiyaç duyduğu Intune veya Entra ID panellerine bile giremez.

Kurumunuzda henüz Conditional Access politikası yoksa ya da mevcut politikalarınızın böyle bir kilitlenmeye yol açıp açmayacağından emin değilseniz, canlıya almadan önce ücretsiz bir Conditional Access risk taraması isteyin — politikalarınızı report-only modda simüle edip riski görünür hale getiririz.

Hata Kodu ve Anlamı Eşleme Tablosu

Conditional Access engellemesi tarayıcıda genelde bir AADSTS ön ekiyle başlayan bir hata koduyla birlikte görünür. Microsoft'un resmi eşleme tablosuna göre en sık karşılaşılan kodlar şunlardır:

Hata Kodu	Anlamı	Muhtemel neden
AADSTS53000	DeviceNotCompliant	Cihaz, Intune uyumluluk politikasını karşılamıyor
AADSTS53001	DeviceNotDomainJoined	Cihaz, kurumsal (hibrit) domain'e katılmamış
AADSTS53002	ApplicationUsedIsNotAnApprovedApp	Onaylı olmayan bir istemci uygulaması kullanılıyor
AADSTS53003	BlockedByConditionalAccess	Genel engelleme — en az bir politika koşulu sağlanmadı
AADSTS53004	ProofUpBlockedDueToRisk	Risk tespiti nedeniyle MFA (çok adımlı kimlik doğrulama) kaydı engellendi
AADSTS53009	Application needs to enforce Intune protection policies	Uygulama, gerekli Intune uygulama koruma politikasını desteklemiyor

Tarayıcıda görünen hata sayfasındaki "More details" bağlantısı, bu kodun yanına bir Request ID (istek kimliği) ve zaman damgası da ekler — bir sonraki bölümdeki tanı ve destek talebi adımlarında bu ikisine ihtiyacınız olacak.

Hızlı Tanı: Oturum Açma Günlükleri ve What If Aracı

Elle tahmin etmeden önce Microsoft'un iki resmi tanılama yolunu kullanın:

1. Oturum açma günlükleri (sign-in logs): Microsoft Entra yönetim merkezi > Monitoring & health > Sign-in logs bölümünde ilgili girişi (Correlation ID veya kullanıcı adıyla filtreleyerek) bulun, ardından Conditional Access sekmesine geçin. Bu sekme hangi politikanın devreye girdiğini ve hangi koşulun sağlanmadığını satır satır gösterir.
2. What If aracı: Entra yönetim merkezinde Conditional Access > What If, belirli bir kullanıcı/uygulama/cihaz kombinasyonu için hangi politikaların uygulanacağını canlıya almadan önce simüle etmenizi sağlar — yeni bir politikayı yayınlamadan önce mutlaka bu araçla test edin.
3. Sign-in diagnostic: Sign-in logs'ta bir olayı seçip "Troubleshoot Event"e tıkladığınızda Microsoft'un otomatik tanı motoru olası nedeni ve önerilen çözümü sıralar.

Sorunu netleştirmek dakikalar sürebilir ama tenant genelinde bir kilitlenme yaşıyorsanız bu araçlara erişiminiz de yoktur — o durumda bir sonraki iki bölüm sizi ilgilendiriyor.

Kök Neden Analizi: Kilitlenmeye Yol Açan Yapılandırmalar

Microsoft'un resmi uyarı listesine göre, aşağıdaki kombinasyonlar "tüm kullanıcılar + tüm kaynaklar" kapsamında yayınlandığında kilitlenmeye yol açar:

• Block access (tüm kullanıcı, tüm kaynak): Tüm kurumu doğrudan engeller — en açık ve en tehlikeli hata.
• Require device to be marked as compliant: Cihazını henüz Intune'a kaydettirmemiş kullanıcılar (yöneticiler dahil) engellenir; kayıtsız bir yönetici, kendi cihazını kaydetmesi gereken Intune portalına bile giremez.
• Require Hybrid Microsoft Entra domain joined device: Hibrit domaine katılı olmayan tüm cihazları (uzaktan çalışan, kişisel cihaz kullanan yöneticiler dahil) engeller.
• Require app protection policy: İlgili Intune uygulama koruma politikası tanımlı olmayan istemcilerde tüm erişimi keser.
• Onaylayıcısız PIM (Privileged Identity Management) etkinleştirmesi: Tüm Global Administrator ve Privileged Role Administrator atamaları "eligible" (uygun ama aktif değil) yapılmış, etkinleştirme onay gerektiriyor ama onaylayıcı olarak seçilen kişiler dizinden silinmiş veya rolden çıkarılmışsa, kimse rolünü etkinleştiremez — bu da fiilen bir kilitlenmedir.

Bu beş senaryonun ortak noktası şu: politika, test edilmeden ve report-only (yalnızca rapor) modu atlanarak doğrudan "On" durumunda yayına alınmış olmasıdır. Conditional Access politikası nasıl yapılandırılır rehberimizde üç fazlı (report-only → pilot grup → genel dağıtım) güvenli devreye alma sürecini adım adım anlattık; bu yazı ise politika zaten yayında ve kilitlenme yaşanmışsa ne yapılacağına odaklanıyor.

Şu Anda Kilitliyseniz: Adım Adım Kurtarma (En Kolaydan En Zora)

Panik yapmadan sırayla ilerleyin:

1. Başka bir yönetici deneyin: Kuruluşunuzda henüz engellenmemiş, farklı bir cihazdan veya konumdan giriş yapabilen başka bir Global Administrator veya Conditional Access Administrator var mı kontrol edin. Varsa, o kişi Entra yönetim merkezinden sorunlu politikayı devre dışı bırakabilir (Conditional Access > ilgili politika > Enable policy: Off).
2. Acil erişim (break-glass) hesabınızı kullanın: Eğer önceden bir acil erişim hesabı kurduysanız (aşağıdaki bölümde nasıl kurulacağını anlatıyoruz), bu hesap Conditional Access politikalarından muaf olduğu için tam da bu senaryoda çalışır. FIDO2 anahtarınızla giriş yapıp sorunlu politikayı kapatın.
3. Hiçbir yönetici erişemiyorsa Microsoft destek talebi açın: Microsoft'un resmi destek talebi süreci (Microsoft Learn) üzerinden başvurun. Microsoft, kimlik doğrulaması yapılmış talep sahibi için, engelleyici Conditional Access politikalarını inceleyip günceller — ama bu süreç saatler alabilir, bu yüzden acil erişim hesabı önleyici tedbir olarak çok daha hızlıdır.
4. Federasyon (AD FS benzeri) kaynaklı bir kesinti mi, politika hatası mı ayırt edin: Eğer kurumunuz federe kimlik kullanıyorsa (on-premises Active Directory Federation Services gibi) ve kesinti kimlik sağlayıcınızdan kaynaklanıyorsa, sorun Conditional Access'te değil federasyon bağlantısındadır — bulut-yalnız (cloud-only) bir acil erişim hesabı bu senaryoda da tek çalışan yoldur, çünkü federasyona bağımlı değildir.

Bu senaryoyla şu anda karşı karşıyaysanız ve içeride kimse ilerleyemiyorsa, WhatsApp'tan hemen yazın — kimlik ve erişim yönetimi konusunda deneyimli ekibimiz, hangi adımı önce atmanız gerektiğini telefon başında birlikte netleştirir.

Kalıcı Çözüm: Acil Erişim (Break-Glass) Hesabı Kurulumu

Microsoft'un resmi acil erişim hesapları rehberine (Microsoft Learn, güncelleme 2026-06-04) göre her Conditional Access dağıtımından önce şu adımlar tamamlanmalı — bu, kurulumdan sonra tekrar kilitlenmemenin tek garantili yoludur:

1. En az iki hesap oluşturun: Her ikisi de bulut-yalnız (cloud-only), *.onmicrosoft.com alan adını kullanan, herhangi bir şirket içi (on-premises) dizinle senkronize edilmeyen veya federe olmayan hesaplar olmalı. Hiçbir çalışana kişisel olarak bağlanmamalı — kimlik bilgileri, yetkili birden fazla kişinin erişebileceği güvenli bir yerde tutulmalı.
2. Her ikisine de Global Administrator rolü atayın ve Privileged Identity Management'ta bu atamayı "eligible" (etkinleştirmesi gereken) değil, kalıcı olarak aktif (permanent active) yapın — acil durumda onay bekleyecek zaman olmaz.
3. Şifresiz (passwordless), kimlik avına dayanıklı bir doğrulama yöntemi seçin: Microsoft, FIDO2 güvenlik anahtarını (parmak izi/PIN ile çalışan fiziksel bir USB anahtar) öncelikli olarak öneriyor; kurumunuzda zaten bir sertifika altyapısı (PKI) varsa sertifika tabanlı kimlik doğrulama da kullanılabilir. Bu yöntem, normal yönetici hesaplarınızın kullandığı yöntemden (örn. telefon uygulaması) farklı olmalı — aynı kimlik doğrulama zinciri aynı anda çökebilir.
4. Bu iki hesabı, erişimi bloke eden TÜM Conditional Access politikalarından muaf tutun: Bunun için ayrı bir güvenlik grubu (örn. "EmergencyAccess") oluşturup her politikanın "Exclude" (hariç tut) bölümüne bu grubu ekleyin. Yalnızca rapor modundaki (report-only) politikalar bu muafiyete ihtiyaç duymaz, çünkü zaten erişimi engellemezler.
5. Kimlik bilgilerini güvenli, ayrı fiziksel konumlarda saklayın: Örneğin yanmaz iki ayrı kasa, farklı binalarda. FIDO2 anahtarlarını da aynı mantıkla ayrı saklayın.
6. Oturum açma ve denetim günlüklerini izleyin: Azure Monitor veya Microsoft Sentinel ile bu iki hesabın kullanıcı kimliğine (Object ID) bağlı bir uyarı kuralı kurun; hesaplardan biri giriş yaptığında anında e-posta/SMS bildirimi gelsin. Bu, hem yanlış kullanım hem de gerçek bir acil durumun kaç dakikada fark edildiğini gösterir.
7. Düzenli olarak doğrulayın: Microsoft, en az 90 günde bir bu hesapların gerçekten giriş yapabildiğini test etmenizi, yetkili kullanıcı listesini gözden geçirmenizi ve izleme/uyarı kurallarının tetiklendiğini kontrol etmenizi öneriyor.

Türkçe terminolojiyle karşılaştırmak isterseniz Microsoft'un bu rehberin Türkçe sürümüne de bakabilirsiniz — İngilizce "emergency access account" karşılığı olarak "acil durum erişimi yönetici hesabı" terimini kullanıyor.

Senaryoya Özel Dallar

• Tek yönetici vs. tüm kiracı: Sorun yalnızca sizde ve cihazınız yeni değiştiyse muhtemelen cihaz uyumluluğu (device compliance) meselesidir — başka bir yönetici sizi hariç tutabilir. Herkes aynı anda engelleniyorsa politika kapsamı hatalıdır, tenant genelindeki kurtarma adımlarına geçin.
• Federe (hibrit) kimlik vs. bulut-yalnız (cloud-only): Kimlik sağlayıcınız (AD FS gibi) kesintideyse ve kullanıcılarınız federe ise, sorun Conditional Access'te değil federasyon bağlantısındadır. Bulut-yalnız acil erişim hesabı burada da tek çalışan yol — bu yüzden acil erişim hesabını asla federe kimlik sağlayıcınıza bağımlı kurmayın.
• Türkiye'ye özgü risk — mobil şebeke bağımlılığı: Yöneticilerin çoğu MFA'yı (çok adımlı kimlik doğrulama) telefon uygulaması veya SMS ile alıyor. Türkiye'de baz istasyonu yoğunluğu, bölgesel şebeke kesintileri veya bir doğal afet sonrası mobil ağların aşırı yüklenmesi gibi durumlarda bu doğrulama yöntemine erişim de kesilebilir. Acil erişim hesabınızı FIDO2 fiziksel anahtarla kurmanız, tam da telefon şebekesinin çalışmadığı anlarda işe yarar — bu yüzden "SMS ile MFA yeter" varsayımı acil erişim hesabı için kabul edilmez.
• Son Global Administrator'ın ayrılması: Bir kurumda tek Global Administrator olan kişi işten ayrılırsa ve hesabı şirket içi dizinden (on-premises) silinir/devre dışı bırakılırsa, bulut tarafında hesap teknik olarak kalsa bile kuruluş fiilen yönetimsiz kalabilir. İki ayrı acil erişim hesabından biri tam olarak bu senaryo için tutulur.

Yönetici Tarafı Kontroller: İzleme ve Doğrulama

Acil erişim hesabı kurduktan sonra iş bitmiyor — Microsoft'un güvenlik kontrol listesine göre şu üç süreç kalıcı olmalı:

• Uyarı kuralı (alert rule): Azure Monitor'da Log Analytics çalışma alanınıza bağlı, acil erişim hesaplarının Object ID'lerini arayan bir custom log search uyarı kuralı kurun; eşik değerini 0'ın üzerinde herhangi bir giriş olarak, önem derecesini 0 - Critical olarak ayarlayın. Bu kural tetiklendiğinde e-posta/SMS/sesli arama ile bir eylem grubuna (action group) bildirim gitsin.
• Kullanım sonrası inceleme (post-mortem): Hesap her kullanıldığında (planlı tatbikat, gerçek acil durum veya yetkisiz kullanım fark etmez) bir inceleme yapın: kim, ne zaman, hangi işlemi yaptı, bu yetkili miydi?
• 90 günlük doğrulama tatbikatı: Yetkili kullanıcı listesini güncel tutun, hesapların hâlâ giriş yapabildiğini test edin, personel değişikliği sonrası kasa kombinasyonlarını değiştirin.

Destek Talebi Hazırlığı

Kendi acil erişim hesabınız yoksa ve Microsoft desteğine başvurmanız gerekiyorsa, ilk yanıt süresini kısaltmak için şunları hazır bulundurun:

• Kiracı (tenant) kimliğiniz (Directory/Tenant ID)
• Engellenen sign-in olayının Request ID'si ve tam zamanı (Türkiye saatiyle)
• Hata sayfasındaki tam kod (örn. AADSTS53003) ve ekran görüntüsü
• Kilitlenmeden önce yayına aldığınız politikanın adı ve yaptığınız son değişiklik
• Kurumda hâlâ erişimi olan başka bir yönetici olup olmadığı bilgisi

Bu süreci kendi başınıza yönetmek yerine, Conditional Access dağıtımını baştan güvenli kurmak isteyen kurumlar için ücretsiz bir kimlik ve erişim güvenliği denetimi sunuyoruz — acil erişim hesabı kurulumu dahil, mevcut politikalarınızı report-only modda test ederek riski önceden görürüz.

Benzer Kilitlenme Durumları ve Farkları

• PIM onaylayıcısı kalmadığı için etkinleştirme yapılamıyor: Bu bir Conditional Access hatası değil, bir Privileged Identity Management yapılandırma boşluğudur — çözüm, en az bir rolü kalıcı aktif tutmak veya birden fazla onaylayıcı tanımlamaktır.
• MFA cihazı kayıp/değişmiş, kullanıcı doğrulama yapamıyor: Conditional Access politikası doğru çalışıyor ama kullanıcının doğrulama yöntemi yok. Çözüm, bir yöneticinin Entra ID'den kullanıcı için doğrulama yöntemlerini sıfırlamasıdır — acil erişim hesabı gerektirmez.
• Servis kesintisi (Microsoft tarafı arıza): Nadiren Microsoft'un kendi kimlik doğrulama altyapısında yaşanan genel bir kesinti, Conditional Access'ten bağımsız olarak girişleri engelleyebilir. Bu durumda Microsoft 365 Service Health panelini kontrol edin — kendi politikanızda hata aramadan önce servis durumunu doğrulamak zaman kazandırır.

Saha vakası: 85 kişilik bir hukuk bürosunda tenant genelinde kilitlenme

İstanbul'da 85 kişilik bir hukuk bürosu, KVKK uyumluluğu kapsamında "tüm kullanıcılar için uyumlu cihaz zorunlu" politikasını hafta sonu bir bakım penceresinde devreye aldı. Politika Pazartesi sabahı canlıya geçtiğinde, henüz Intune'a kayıtlı olmayan üç yönetici de dahil olmak üzere hiçbir kullanıcı giriş yapamadı. Süre: kilitlenme 40 dakika sürdü. Karar noktaları: (1) politika hiç report-only modda test edilmemişti; (2) kurumda önceden kurulmuş bir acil erişim hesabı yoktu; (3) tek çözüm, ofis dışından erişebilen bir ortak kurucunun kişisel Microsoft hesabı üzerinden Microsoft desteğine acil talep açması oldu — bu da kimlik doğrulama sürecinde ek 25 dakika kaybettirdi. Sonuç: politika geri alındı, ardından iki acil erişim hesabı FIDO2 anahtarlarla kuruldu ve tüm gelecekteki politikalar için üç fazlı (report-only → pilot → genel) devreye alma süreci zorunlu hale getirildi. Xen ekibinin rolü: kilitlenme sonrası kök neden analizini yapmak, acil erişim hesaplarını Microsoft'un güvenlik kontrol listesine birebir uygun kurmak ve izleme uyarılarını devreye almaktı. Uyarı: bu senaryo KVKK'ya uyum amacıyla hız yapılan projelerde sık tekrarlanıyor — uyumluluk baskısı, test adımını atlatmamalı.

Sıkça Sorulan Sorular (SSS)

Acil erişim hesabı için gerçekten iki hesap mı gerekiyor, bir tane yetmez mi?

Microsoft'un resmi kılavuzu en az iki hesap öneriyor. Tek hesapta, o hesabın kendisinde bir sorun (kimlik bilgisi kaybı, cihaz arızası) yaşanırsa yedek kalmaz. İki ayrı hesap, ayrı kimlik doğrulama yöntemleriyle bu tek nokta arızasını ortadan kaldırır.

Acil erişim hesabında neden şifre yerine FIDO2 anahtar kullanılmalı?

Çünkü acil erişim hesabının senaryosu tam olarak "normal kimlik doğrulama yöntemleri çalışmıyor" anıdır. Telefon uygulaması internet/şebeke bağlantısına, SMS mobil şebekeye bağımlıdır — ikisi de aynı kesintide çökebilir. FIDO2 fiziksel bir anahtar bu bağımlılıklardan hiçbirine sahip değildir.

Acil erişim hesabını Conditional Access'ten hariç tutmak güvenlik açığı yaratmaz mı?

Hayır, çünkü hesap zaten kimlik avına dayanıklı, şifresiz bir yöntemle korunuyor ve kullanımı sürekli izleniyor. Riski asıl artıran, hesabı hiç kurmayıp kilitlenme anında çaresiz kalmaktır. Microsoft, doğru izleme ve saklama koşullarıyla bu muafiyeti resmi olarak öneriyor.

Conditional Access politikasını report-only modda test etmek neden yeterli değil, ayrıca acil erişim hesabı da mı gerekiyor?

İkisi farklı katmanlar. Report-only mod, bir politikanın canlıya alınmadan önce kimleri nasıl etkileyeceğini görmenizi sağlar — ama insan hatası veya öngörülemeyen bir senaryo (ör. bir grup üyeliğinin yanlışlıkla değişmesi) yine de kilitlenmeye yol açabilir. Acil erişim hesabı, test sürecinden bağımsız olarak her zaman devrede duran son bir güvenlik ağıdır.

Zaten kilitliyim, hiçbir yönetici giremiyor ve acil erişim hesabım da yok — ne yapmalıyım?

Microsoft'un resmi destek talebi sürecini kullanın. Kimlik doğrulaması yapılmış talep sahibi için Microsoft, engelleyici politikayı inceleyip günceller. Bu süreç saatler sürebileceğinden, kilitlenme çözüldükten hemen sonra acil erişim hesabı kurmanızı öneririz — aynı durumun tekrarlanmaması için.

Acil erişim hesabının kullanıldığını nasıl anlarım, birisi kötüye kullanırsa?

Azure Monitor veya Microsoft Sentinel üzerinde bu hesapların Object ID'lerine bağlı bir uyarı kuralı kurarsanız, her girişte anında bildirim alırsınız. Her bildirim sonrası kısa bir inceleme yaparak girişin planlı bir tatbikat mı, gerçek bir acil durum mu, yoksa yetkisiz kullanım mı olduğunu belgeleyin.

KVKK açısından acil erişim hesabının izlenmesiyle ilgili bir yükümlülük var mı?

Acil erişim hesabının oturum açma ve denetim günlükleri, 6698 sayılı KVKK'nın 12. maddesindeki "gerekli teknik tedbir" yükümlülüğü kapsamında değerlendirilebilir — özellikle bu hesap, kişisel veri barındıran sistemlere de erişebiliyorsa. Günlüklerin düzenli tutulması ve her kullanımın belgelenmesi, hem güvenlik hem de olası bir denetimde hesap verebilirlik açısından önerilir.

Sonuç: Kilitlenme Riski Conditional Access'in Bir Kusuru Değil, Yönetilmesi Gereken Bir Gerçeği

Conditional Access, kimlik güvenliğinde en etkili katmanlardan biri — ama bu güç, yanlış kapsamla yayına alındığında yöneticiler dahil herkesi dışarıda bırakacak kadar keskin. Microsoft'un resmi çözümü karmaşık değil: politikayı önce report-only modda test etmek ve en az iki FIDO2 korumalı acil erişim hesabını, tüm engelleyici politikalardan muaf tutarak önceden kurmak. Bu iki adım, saatler süren bir kriz yönetimini dakikalar içinde çözülen rutin bir prosedüre indirger.

Henüz acil erişim hesabınız yoksa, bir sonraki Conditional Access değişikliğini yapmadan önce bunu kurmak — kilitlendikten sonra çözmeye çalışmaktan çok daha az maliyetli. Microsoft Security çözümlerimiz ve Microsoft 365 yönetilen hizmetlerimiz kapsamında bu kurulumu, izleme uyarılarıyla birlikte standart bir güvenlik denetimi olarak sunuyoruz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun kimlik ve erişim güvenliği yolculuğunda Conditional Access tasarımından acil erişim hesabı kurulumuna kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın ya da PIM ayrıcalıklı erişim rehberimizden Global Administrator rolünüzü nasıl daha güvenli yöneteceğinizi inceleyin.