Özet (TL;DR): Windows güncellemesinden veya BIOS (bellenim) güncellemesinden sonra bilgisayar 48 haneli BitLocker kurtarma anahtarı istiyorsa, bunun iki bilinen nedeni vardır. Birincisi, 14 Nisan 2026 tarihli KB5083769 güncellemesiyle belgelenen bilinen sorun: TPM (güvenlik çipi) doğrulama ilkesi PCR7 değerini içeren cihazlar ilk yeniden başlatmada anahtar sorar. İkincisi, Secure Boot (güvenli önyükleme) sertifikalarının 2011 sürümünden 2023 sürümüne geçişi: Windows önyükleme sertifikası 19 Ekim 2026'da dolacağı için geçiş şu an en yoğun dönemini yaşıyor. Çözümün sırası şudur: önce anahtarın Intune veya Microsoft Entra'da kayıtlı olduğunu doğrulayın, sonra sorunlu TPM ilkesini kaldırın, BitLocker'ı geçici olarak askıya alıp sertifika güncellemesini çalıştırın ve Olay 1801, 1808 ile 1032 kayıtlarıyla sonucu doğrulayın.
Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-102 ve MD-102 sertifikalı danışmanlar. Bu yazıdaki olay numaraları, kayıt defteri değerleri ve tarihler Microsoft'un resmi destek sayfalarından alınmıştır; kaynaklar metin içinde bağlantılıdır ve 2026-10 itibarıyla geçerlidir.
Filonuzda birden fazla dizüstü bilgisayar sabah mavi kurtarma ekranında kaldıysa vakit kaybetmeyin: Ücretsiz teknik görüşme talep edin, hangi cihazların etkilendiğini ve anahtarların nerede durduğunu birlikte 15 dakikada çıkaralım.
Belirtiler: Bilgisayar Neden Kurtarma Anahtarı İstiyor?
BitLocker, diskin tamamını şifreleyen Windows özelliğidir. Normalde şifre çözme işini bilgisayarın içindeki TPM çipi sessizce yapar; çip, bilgisayarın açılış sırasında hiçbir şeyin değişmediğini görürse diski kullanıcıya hiç sormadan açar. Açılış zincirinde beklenmeyen bir değişiklik fark ederse "bu bilgisayar el değiştirmiş olabilir" diye düşünür ve diski kilitleyip 48 haneli kurtarma anahtarını ister. Kapıdaki güvenlik görevlisinin yüzünü tanıyamayınca kimlik sorması gibi düşünebilirsiniz.
Sahada şu belirtilerle karşılaşılır:
- Aylık Windows güvenlik güncellemesinin ardından ilk yeniden başlatmada mavi "BitLocker kurtarma" ekranı gelir ve 48 haneli anahtar istenir.
- Anahtar bir kez girilir, bilgisayar açılır, ancak her yeniden başlatmada yine sorulur. Bu, tek seferlik bir olay değil, kalıcı bir yapılandırma çakışması anlamına gelir.
- BIOS (bellenim) güncellemesinden veya Secure Boot ayarlarında değişiklikten hemen sonra aynı ekran görünür.
- Olay Görüntüleyicisi'nde (Event Viewer) Sistem günlüğünde TPM-WMI kaynağından 1801, 1795, 1032 gibi olay numaraları görülür.
- Etkilenen cihazlar genelde aynı model veya aynı güvenlik ilkesi grubundadır; rastgele tek cihaz sorunu değildir.
İlk teşhis sorusu her zaman şudur: sorun tek bir cihazda mı, aynı ilkeyi alan bütün cihazlarda mı? Tek cihazsa donanım veya bellenim şüphelidir. Birden fazla cihazsa neredeyse kesinlikle bir ilke (policy) veya güncelleme çakışmasıdır.
Kök Neden: İki Ayrı Olay Aynı Belirtiyi Veriyor
Bu belirtinin arkasında 2026 yılında birbirinden bağımsız iki gelişme var. İkisi de aynı ekranı çıkardığı için karıştırılıyor.
1) Nisan 2026 güncellemesinin bilinen sorunu
Microsoft, KB5083769 destek sayfasında (güncelleme 14 Nisan 2026'da yayımlandı) şu bilinen sorunu belgeledi. Cihaz aşağıdaki koşulların hepsini aynı anda karşılıyorsa ilk yeniden başlatmada kurtarma anahtarı sorabilir:
- BitLocker işletim sistemi sürücüsünde açıktır.
- Grup İlkesi'nde "Configure TPM platform validation profile for native UEFI firmware configurations" ayarı yapılmıştır ve profilde PCR7 bulunur. (PCR7, TPM'in Secure Boot durumunu ölçtüğü kayıt alanıdır; bunu "güvenli önyükleme fotoğrafının yapıştırıldığı hücre" gibi düşünebilirsiniz.)
msinfo32.exeiçinde "Secure Boot State" altındaki "PCR7 Binding" satırı Not Possible (mümkün değil) görünür.- Windows UEFI CA 2023 sertifikası Secure Boot veri tabanında (DB) vardır.
- Cihaz henüz 2023 imzalı Windows önyükleme yöneticisini kullanmıyordur.
Microsoft, anahtarın bu durumda yalnızca bir kez gerekeceğini, ilke ayarı değişmediği sürece tekrar sorulmayacağını belirtiyor. Aynı destek sayfası, sorunun KB5089549 güncellemesiyle ele alındığını söylüyor: bu güncellemeden sonra söz konusu ilkeye sahip cihazlarda 2023 imzalı önyükleme yöneticisinin kurulumu engelleniyor ve Sistem günlüğüne Olay 1032 yazılıyor.
2) Secure Boot sertifikalarının 2011'den 2023'e geçişi
Secure Boot, bilgisayarın yalnızca güvenilir imzalı yazılımla açılmasını sağlayan bellenim özelliğidir. Bu güvenin dayandığı sertifikaların süresi doluyor. Microsoft'un Secure Boot sertifika süresi dolumu duyurusu şu tarihleri veriyor:
| Sertifika | Görevi | Süre dolumu |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | DB ve DBX güncellemelerini imzalar | 24 Haziran 2026 |
| Microsoft UEFI CA 2011 | Üçüncü taraf önyükleyicileri imzalar | 27 Haziran 2026 |
| Microsoft Windows Production PCA 2011 | Windows önyükleyicisini imzalar | 19 Ekim 2026 |
Microsoft'un açıklamasına göre eski sertifikalar süresi dolsa bile cihazlar açılmaya ve Windows güncellemelerini almaya devam eder. Asıl risk başka yerde: 2023 sertifikalarına geçmemiş cihazlar yeni önyükleme düzeyi korumalarını ve iptal listelerini artık alamaz. Yani kurumun yapması gereken iş, süresi dolmadan geçişi planlı ve kontrollü yapmaktır. Kontrolsüz yapılan geçiş ise önyükleme zincirini değiştirdiği için BitLocker'ın kurtarma anahtarı istemesine yol açabilir.
Özetle iki sorun birbirine dokunuyor: Nisan sorunu belirli bir TPM ilkesinin sertifika geçişiyle çakışmasıdır; sertifika geçişi ise 19 Ekim'e doğru zaten tüm filoyu ilgilendiriyor.
Hızlı Tanı: 10 Dakikada Hangi Senaryo Olduğunu Bulun
Etkilenen bir cihazda anahtarı girip Windows'a girdikten sonra yönetici olarak şu kontrolleri yapın.
- BitLocker durumu: yönetici komut isteminde
manage-bde -status C:çalıştırın. "Protection Status" ve koruyucuların (Key Protectors) listesine bakın. - PCR7 bağlama durumu:
msinfo32açın, "Sistem Özeti" altında "Secure Boot State" ve "PCR7 Binding" satırlarını okuyun. "Not Possible" ise Nisan sorununun koşullarından biri sağlanıyor demektir. - İlke kontrolü: yönetici komut isteminde
gpresult /h rapor.htmlile oluşan raporda "TPM platform validation profile" ayarının tanımlı olup olmadığına bakın. Intune kullanıyorsanız aynı ayarın hangi BitLocker profilinde atandığını Intune yönetim merkezinde arayın. - Olay günlüğü: Olay Görüntüleyicisi'nde Windows Günlükleri, Sistem bölümünde kaynak "TPM-WMI" olan kayıtları süzün. 1801, 1808, 1795, 1032 numaralarını arayın.
- Sertifika durumu:
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\ServicingaltındaUEFICA2023Statusdeğerine bakın: NotStarted, InProgress veya Updated.
Olay Numaralarının Anlamı
Microsoft'un Secure Boot DB ve DBX güncelleme olayları (KB5016061) sayfası, Secure Boot güncellemesinin sonucunu Sistem günlüğüne yazılan olay numaralarıyla bildiriyor. Sahada işe yarayan kısmı şu tabloda:
| Olay | Anlamı | Yapılacak |
|---|---|---|
| 1808 | Cihazda güncel Secure Boot sertifikaları var ve 2023 imzalı önyükleme yöneticisi kullanılıyor | Başarılı. İşlem gerekmez. |
| 1801 | Sertifikalar güncellendi ancak henüz cihaz bellenimine uygulanmadı | Yayımlanan yönergeyle güncellemeyi tamamlayın, yeniden başlatın. |
| 1800 | Güncellemenin kurulması için yeniden başlatma gerekiyor | Cihazı yeniden başlatın. |
| 1795 | Bellenim DB, DBX veya KEK güncellemesinde hata döndürdü | Üreticiden bellenim (BIOS) güncellemesi alın; Windows bir sonraki başlatmada yeniden dener. |
| 1796 | Başka bir olayla açıklanmayan beklenmeyen hata | Hata kodunu not edip destek talebine ekleyin. |
| 1802 | Güncelleme bilinen bir bellenim veya donanım sorunu nedeniyle bilerek engellendi | Cihaz üreticisinden bu sorunu gideren bellenimi isteyin. |
| 1803 | Cihaz için PK imzalı KEK bulunamadı | Üreticiden doğru anahtar tanımlamasını isteyin. |
| 1032 | Güncelleme BitLocker'ı kurtarma moduna sokacaktı | BitLocker'ı iki yeniden başlatma için askıya alıp güncellemeyi yeniden deneyin (aşağıda). |
| 1033 | EFI bölümünde savunmasız bir önyükleme yöneticisi bulundu, DBX güncellemesi ertelendi | İlgili modülün üreticisinden güncel sürüm alın. |
Önemli ayrım: 1032, "sorunu önledim" demektir. Güncelleme, kurtarma ekranına neden olacağını görüp kendini durdurmuştur. Kullanıcı kurtarma ekranını görmüşse sorun büyük ihtimalle 1032 aşamasının dışındadır.
Adım Adım Çözüm: En Kolaydan En Zora
Adım 1: Önce anahtarı bulun (kullanıcı kilitliyse)
Kullanıcının ekranında 48 haneli anahtarı isteyen mavi ekran varsa, bilgi işlem anahtarı kurumsal kayıttan çıkarır. Intune ile BitLocker şifreleme belgesi şu yolu veriyor:
- Microsoft Intune yönetim merkezinde Devices (Cihazlar) > All devices (Tüm cihazlar) bölümüne girin.
- Cihazı seçin, Monitor (İzleme) altında Recovery keys (Kurtarma anahtarları) seçeneğine tıklayın.
- Show Recovery Key (Kurtarma anahtarını göster) düğmesine basın. Bu işlem denetim günlüğüne "KeyManagement" etkinliği olarak yazılır.
- Kullanıcının ekranındaki Key ID (anahtar kimliği) ile listedeki kimliğin ilk karakterlerini karşılaştırın; cihazın birden fazla anahtarı olabilir.
Anahtarı görebilmek için hesabın Microsoft Entra tarafında microsoft.directory/bitlockerKeys/key/read iznine sahip olması gerekir. Bu izin Cloud Device Administrator, Helpdesk Administrator ve Global Administrator rollerinde bulunur. Anahtar Entra'da yoksa Intune "No BitLocker key found for this device" (bu cihaz için BitLocker anahtarı bulunamadı) mesajını gösterir. Bu mesajı gören cihazın verisi, anahtar başka bir yerde saklanmadıysa kurtarılamayabilir; bu yüzden anahtar kaydını güncelleme öncesinde denetlemenizi öneririz (Adım 3).
Adım 2: Kullanıcıya self servis yol açın
Aynı Microsoft belgesine göre Entra'ya katılmış cihazlarda kullanıcı, başka bir cihazdan Şirket Portalı (Company Portal) uygulaması veya account.microsoft.com üzerinden kendi anahtarını görebilir. Bu, destek talebi yükünü ciddi biçimde azaltır. Kuruma ait cihazlara erişimi kısıtlamak isterseniz Entra cihaz ayarlarında "yönetici olmayan kullanıcıların BitLocker anahtarını görmesini kısıtla" seçeneği vardır; varsayılan değer kısıtlama yok şeklindedir.
Adım 3: Güncellemeden önce anahtarların kayıtlı olduğunu doğrulayın
Intune yönetim merkezinde Devices > Monitor > Encryption report (Şifreleme raporu) sayfasını açın. Rapor, BitLocker ilkesi alan cihazların şifreleme durumunu ve anahtarlarını gösterir. Anahtarı kayıtlı olmayan cihazlara güncelleme göndermeyin; önce BitLocker'ın anahtarı Entra'ya yedeklemesini sağlayın. Microsoft belgesi ayrıca Entra'nın cihaz başına en fazla 200 anahtar tuttuğunu, sınıra gelinirse sessiz şifrelemenin yedekleme hatasıyla başarısız olacağını belirtiyor.
Adım 4: Sorunlu TPM ilkesini kaldırın
Nisan sorunu için Microsoft'un önerdiği çözüm, ilkeyi güncellemeden önce kaldırmaktır (KB5083769 sayfası):
- Grup İlkesi Yönetimi'nde Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives yolunu açın.
- "Configure TPM platform validation profile for native UEFI firmware configurations" ayarını Not Configured (Yapılandırılmadı) yapın.
- İstemcilerde
gpupdate /forceçalıştırın. - BitLocker koruyucularını C: sürücüsünde
manage-bdeile askıya alıp yeniden etkinleştirin.
İlkeyi Intune üzerinden uyguluyorsanız aynı ayarı Endpoint security > Disk encryption altındaki BitLocker profilinde veya ayar kataloğunda arayın ve profili ilgili cihaz grubundan çıkarın. Intune ayar adı sürüme göre değişebildiği için profilinizdeki gerçek adı kontrol edin.
Adım 5: İlkeyi tutmak zorundaysanız geçici askıya alma
Microsoft, ilkeyi korumanız gerekiyorsa şu sırayı öneriyor: BitLocker'ı askıya alın, Secure-Boot-Update zamanlanmış görevini çalıştırın, cihazı yeniden başlatın, sonra BitLocker'ı yeniden etkinleştirin. Olay 1032 için KB5016061'de verilen komut:
Manage-bde -Protectors -Disable %systemdrive% -RebootCount 2
# Cihazı iki kez yeniden başlatın, ardından:
Manage-bde -Protectors -Enable %systemdrive%Buradaki mantık basit: askıya alma, iki yeniden başlatma boyunca TPM'in "ölçüm uyuşmazlığı" nedeniyle kapıyı kilitlemesini engeller. Korumayı yeniden açmayı unutmak, diskin şifreli ama anahtarsız açılabilir kalması anlamına gelir. Bu yüzden komutu betikle yönetin ve sonucu raporlayın.
Adım 6: Secure Boot sertifika güncellemesini kontrollü başlatın
Microsoft, kurumsal dağıtımda AvailableUpdates değerinin 0x5944 yapılmasını öneriyor; bu değer 2023 CA sertifikalarının eklenmesini, KEK güncellemesini ve yeni önyükleme yöneticisinin kurulmasını tetikliyor. Ayrıntılar Secure Boot için kayıt defteri anahtarları belgesi ve Secure Boot sertifika güncellemesi (KB5068202) sayfalarında. Tek cihazda deneme sırası şöyle (yönetici PowerShell):
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# AvailableUpdates 0x4100 olunca cihazı yeniden başlatın, görevi bir kez daha çalıştırın.
# Beklenen son değer 0x4000.Görev normalde 12 saatte bir kendiliğinden çalışır; komut onu hemen çalıştırır. Güncellemeyi başlatmak yeniden başlatmayı zorlamaz, önyükleme yöneticisi bir sonraki normal yeniden başlatmada tamamlanabilir. Microsoft'un önerdiği sıra BitLocker'ı önce askıya almak, güncellemeyi sonra çalıştırmaktır (Adım 5).
Adım 7: Sonucu doğrulayın
Cihaz yeniden başladıktan sonra şunlara bakın:
UEFICA2023Statusdeğeri Updated olmalı;UEFICA2023Errordeğeri 0 olmalı. Hata değeri sıfırdan farklıysa durum "InProgress" kalır ve değer genelde bellenimin döndürdüğü kodu taşır.- Sistem günlüğünde Olay 1808 görünmeli ve kalıcı bir 1801, 1795 veya 1796 kalmamalı.
manage-bde -status C:çıktısında koruma "Protection On" olmalı.
Senaryoya Özel Dallar
Tek cihaz mı, bütün filo mu?
Yalnızca bir model etkileniyorsa ilk şüpheli bellenimdir (Olay 1795 ve 1802). Üreticinin güncel BIOS sürümünü yükleyin, Secure Boot anahtarlarını bellenim ekranından varsayılana döndürmeyi üretici yönergesine göre deneyin. Bütün cihazlar etkileniyorsa ilke çakışmasına (Adım 4) odaklanın.
Intune ile yönetilen cihazlar
Intune cihazlarda anahtar yedeği genellikle şifreleme sırasında otomatik alınır, ancak cihaz Intune'dan silinirse Microsoft belgesine göre BitLocker koruyucuları kaldırılır ve sürücü askıya alınmış durumda kalır. Sorunlu cihazı çözmeye çalışırken cihaz nesnesini silip yeniden kaydetmeyin; önce anahtarı alın.
Şirket içi etki alanı (Active Directory) cihazları
Grup İlkesi ile yönetilen cihazlarda kurtarma bilgisi Active Directory'ye yazılmıyorsa anahtar bulunamaz. Etki alanında BitLocker kurtarma bilgilerinin Active Directory'ye yedeklendiğini güncelleme öncesinde bir örnek cihazla test edin. Microsoft'un Intune belgesi şirket içi AD senaryosunu ayrıntılı vermediği için bu kısım kurumunuzun ilke yapısına göre doğrulanmalıdır.
Sanal makineler ve eski bellenimli cihazlar
Secure Boot etkin olmayan veya eski bellenimli (Legacy BIOS) cihazlarda bu geçişin kapsamı farklıdır. Önce cihaz envanterinizde Secure Boot durumunu çıkarın; kapalı olan cihazlar için ayrı bir karar verin.
Türkiye'ye Özel Notlar: KVKK ve Yerel Donanım Gerçeği
KVKK boyutu. BitLocker kurtarma anahtarı, çalışan dizüstü bilgisayarındaki kişisel verilere erişim sağlar. 6698 sayılı Kanun'un 12. maddesi, veri sorumlusundan "gerekli teknik tedbirleri" almasını bekler. Anahtarları kağıtta, Excel tablosunda veya ortak klasörde tutmak bu tedbirle çelişir. Entra'da tutulan anahtar, her görüntüleme işleminde denetim kaydı bırakır; Microsoft belgesine göre "Show Recovery Key" ve kullanıcı self servis erişimi günlüğe yazılır. Bir denetimde "anahtara kim, ne zaman eriştiğini" gösterebilmek bu tedbirin kanıtı olur.
Yerel donanım gerçeği. Türkiye pazarında kurumların önemli bir bölümü Casper, Monster gibi yerel markaların dizüstü bilgisayarlarını da kullanıyor. Hangi markadan olursa olsun Secure Boot sertifika geçişi için üreticiden hangi bellenim sürümünün gerektiğini, geçişten önce yazılı olarak sorun. Garanti süresi içindeki cihazlarda bellenimi kendiniz yüklemeden önce yetkili servisin yönergesini alın.
Önleyici Kontroller: Pilotla Başlayın
- Anahtar envanteri: Intune şifreleme raporunda anahtarı olmayan cihaz sayısı sıfır olmadan filoya sertifika güncellemesi göndermeyin.
- Pilot grup: her donanım modelinden 3 ila 5 cihazı içeren bir pilot halka oluşturun; 7 gün olay günlüklerini izleyin.
- Zamanlama: 19 Ekim 2026 tarihini son gün değil, hedef gün olarak planlayın. Cihazların bir kısmı uzak çalışan kullanıcılarda olacağı için dağıtım birkaç hafta sürer.
- İlke temizliği: "TPM platform validation profile" ayarını kimin, neden tanımladığını bulun. Çoğu kurumda eski bir güvenlik ayarından kalmıştır.
- İzleme: 1801, 1795, 1796 ve 1032 olaylarını merkezi günlük toplama aracınızda uyarıya bağlayın.
- Sürüm sağlığı takibi: Microsoft'un Windows sürüm sağlığı (release health) sayfası ve Microsoft 365 yönetim merkezindeki Windows sürüm sağlığı bildirimleri yeni bilinen sorunları ilk burada duyurur.
Üçüncü taraf disk şifreleme veya önyükleme aşamasında çalışan başka bir yazılımınız varsa, üreticisine 2023 sertifikalarıyla uyumlu sürümü sorun (Olay 1033 bu tür bir modül sorununu gösterir). Windows cihaz kaydı ve Autopilot tarafında yaşanan benzer sorunlar için Intune Windows cihaz kaydı başarısız çözümü ve Autopilot ESP takılması rehberimize bakabilirsiniz; cihaz uyumluluğu için ise Intune uyumsuz cihaz rehberimiz tamamlayıcıdır.
Orta aşamadaki bir karar noktasında takılıyorsanız, Windows ve cihaz yönetimi çözümlerimiz kapsamında filonuz için pilot planı, anahtar envanteri ve sertifika geçişini birlikte yürütebiliriz. WhatsApp'tan yazın veya güvenlik çözümlerimizi inceleyin.
Microsoft Desteğine veya İş Ortağınıza Hazırlıklı Gidin
Çözüm sonuç vermezse destek talebi açmadan önce şunları toplayın: cihaz modeli ve BIOS sürümü, Windows sürümü ve yapı numarası, msinfo32 çıktısındaki Secure Boot ve PCR7 satırları, UEFICA2023Status ile UEFICA2023Error değerleri, Sistem günlüğünden TPM-WMI olayları ve ilgili Grup İlkesi veya Intune profil adı. Bu liste, ilk yanıtın günler yerine saatler içinde gelmesini sağlar.
Dolaylı yoldan faydalı bir okuma önerisi: eski cihazlarınız Windows 10'da kalmışsa geçiş planınızı Windows 10'dan Windows 11'e kurumsal geçiş metodolojisi yazımızla birlikte düşünün; iki işi aynı bakım penceresinde birleştirmek maliyeti azaltır.
Sıkça Sorulan Sorular (SSS)
BitLocker kurtarma anahtarını bulamıyorum, ne yapabilirim?
Önce Intune yönetim merkezinde Devices > All devices > cihaz > Recovery keys yolunu, ardından kullanıcının Microsoft hesabı veya Şirket Portalı üzerinden self servis yolunu deneyin. Anahtar Entra'da yoksa ve başka bir yerde de saklanmadıysa verinin kurtarılamayabileceğini Microsoft açıkça belirtiyor; bu yüzden anahtar kaydını güncellemeden önce doğrulamak şarttır.
Kurtarma anahtarı her yeniden başlatmada soruluyorsa sebep nedir?
Tek seferlik sormak normal olabilir; her başlatmada soruyorsa kalıcı bir çakışma vardır. En sık sebepler PCR7 içeren TPM doğrulama ilkesi, tamamlanmamış Secure Boot sertifika güncellemesi veya bellenim hatasıdır. Olay günlüğündeki 1801, 1795 ve 1032 kayıtlarına ve msinfo32 çıktısındaki PCR7 bağlama satırına bakın.
Secure Boot sertifikaları dolunca bilgisayarım açılmaz mı?
Hayır. Microsoft, eski sertifikaların süresi dolsa da cihazların açılmaya ve Windows güncellemelerini almaya devam ettiğini belirtiyor. Kaybedilen şey, yeni önyükleme düzeyi korumalarını ve iptal listelerini alabilmektir. Bu yüzden geçiş yapılması gereken ama panik gerektirmeyen bir işlemdir.
19 Ekim 2026 hangi sertifikanın tarihidir?
Microsoft Windows Production PCA 2011 sertifikasının, yani Windows önyükleyicisini imzalayan sertifikanın süre dolum tarihidir. KEK CA 2011 için 24 Haziran, UEFI CA 2011 için 27 Haziran 2026 tarihleri verilmiştir.
Güncellemeyi başlatmadan önce BitLocker'ı kapatmalı mıyım?
Kapatmak yerine askıya alın. Microsoft, ilke tutulacaksa BitLocker'ı askıya alıp Secure-Boot-Update görevini çalıştırmayı, yeniden başlatmayı ve ardından korumayı yeniden açmayı öneriyor. Olay 1032 için komut: Manage-bde -Protectors -Disable %systemdrive% -RebootCount 2.
Güncellemenin başarılı olduğunu nasıl anlarım?
UEFICA2023Status değeri Updated, UEFICA2023Error değeri 0 olmalı ve Sistem günlüğünde Olay 1808 (cihazda güncel Secure Boot sertifikaları var) görünmelidir. Sürekli bir 1801, 1795 veya 1796 kaydı kalmamalıdır.
Intune'dan cihazı silip yeniden eklersem anahtar kaybolur mu?
Microsoft belgesine göre Entra'ya katılmış cihazın Intune nesnesini silmek, işletim sistemi sürücüsündeki anahtar koruyucularını kaldırır ve BitLocker'ı askıya alınmış durumda bırakır. Bu yüzden sorunlu cihazı silmeden önce anahtarı alın ve koruyucuları kontrol edin.
Sonuç: Panik Değil, Planlı Geçiş
BitLocker kurtarma ekranı, çoğu zaman güvenliğin çalıştığının işaretidir; sorun, onun bu kadar sık tetiklenmesine yol açan ilke ve sertifika çakışmasındadır. Nisan 2026 güncellemesindeki bilinen sorun belirli bir TPM ilkesiyle sınırlıdır ve ilkeyi kaldırarak veya BitLocker'ı geçici askıya alarak aşılır. Secure Boot sertifika geçişi ise 19 Ekim 2026'ya doğru herkesi ilgilendiren, ama süresi dolduğu için cihazları açılmaz hale getirmeyen planlı bir değişikliktir.
Doğru sıra şudur: anahtarları doğrulayın, ilkeyi temizleyin, pilot grupla deneyin, olay günlüklerini izleyin, sonra tüm filoya yayın. Bu sırayı atlayan kurumlar, aynı gün yüzlerce kullanıcının kurtarma anahtarı istemesiyle destek hattını kilitleyebilir. Sıralı yürütülürse işin kendisi birkaç haftalık sakin bir çalışmadır.
Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun cihaz şifreleme ve Secure Boot sertifika geçişi sürecinde envanterden pilota, olay izlemeden kesintisiz yayına kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.
