Microsoft провела 15 липня захід «Office Hours» за участю інженерів Microsoft та представників Acer, Asus, Cisco, Clevo, Dell, Fsas/Fujitsu, Honor, HP, Lenovo, LG, Surface і Xiaomi. Метою зустрічі було відповісти на запитання ІТ-адміністраторів щодо розгортання сертифікатів Secure Boot у Windows 11 у 2023 році.
Раніше видання Windows Latest опублікувало детальну статтю з вичерпними технічними відповідями, отриманими під час цієї сесії, охоплюючи все: від ключа реєстру AvailableUpdates до роботи рейтингів довіри на корпоративних пристроях.
Однак не всі проблеми вдалося вирішити. Значна частина обговорення на зустрічі була присвячена помилкам сертифікатів Secure Boot, які Microsoft та виробники обладнання не змогли пояснити, або виправленням, які, згідно з офіційною документацією, мали працювати, але не спрацювали на їхньому обладнанні.

У березні Ед Тіттель з Windows Latest писав про свою боротьбу за приведення невеликої групи з 10-15 ПК у відповідність до сертифікатів CA-2023. Він дійшов висновку, що проблема носить загальногалузевий характер, а не є суто проблемою Microsoft.
Під час тестування плати ASUS іноді відмовлялися застосовувати список відкликання, якщо Secure Boot не було тимчасово вимкнено. Плати MSI на деяких моделях ігнорували оновлення, хоча в інтерфейсі Secure Boot відображався як увімкнений. ASRock вимагала ручного скидання ключів та повторного введення майже на кожній перевіреній системі, а документація щодо цих процедур була мінімальною або взагалі відсутньою. Пристрої Dell, HP та Lenovo показали кращі результати (що різко контрастує з подальшим описом), але навіть вони мали поетапне розгортання та оновлення BIOS, що вимагали більше одного перезавантаження.

Настільний ПК Тіттеля ASRock B550 Extreme4 застряг у стані, коли кожен перезапуск викликав помилкове попередження про зміну ЦП, пов’язане з оновленням Secure Boot. Зрештою він відмовився від спроб виправити проблему на рівні прошивки та замінив материнську плату.
Минуло чотири місяці…
Якщо ваш ПК або парк ПК з Windows 11 застряг на помилці сертифіката Secure Boot, циклі відновлення BitLocker або KEK, який не оновлюється, цей огляд невирішених проблем з події OEM Secure Boot Office Hours допоможе вам зрозуміти, чи стикаєтеся ви з чимось, про що Microsoft вже знає, чи з чимось, про що ще ніхто не повідомляв.
Де розгортання сертифікатів Secure Boot у Windows 11 все ще викликає проблеми у ІТ-адміністраторів
Кілька адміністраторів описали проблеми, які Microsoft або відповідний виробник обладнання не змогли повністю пояснити, або де виправлення, яке мало б спрацювати згідно з офіційною документацією, виявилося неефективним на їхніх ПК.

Цикл відновлення BitLocker HP зберігається навіть на найновішому BIOS
Найбільш тривожний коментар на зустрічі OEM Secure Boot Office Hours надійшов від користувача epoch71, який керує понад 7000 пристроями HP EliteBooks та ZBooks, від моделей G7 до найновіших. Примусове встановлення сертифіката через ключ реєстру AvailableUpdates спричинило відновлення BitLocker під час тестування. Те ж саме сталося при дотриманні інструкцій HP щодо ручного перемикання чотирьох налаштувань BIOS Secure Boot, описаних американським виробником у статті підтримки.
Windows Latest повідомляв у травні, коли HP вперше визнала, що партія оновлень BIOS від квітня 2026 року може пошкодити вимірювання PCR7, на яких BitLocker шифрує свій ключ, що призводить до появи запиту на відновлення при кожному перезавантаженні до завершення передачі сертифіката.

Юрген Байєр з HP спочатку порадив epoch71 переконатися, що встановлено найновіший BIOS, і не змінювати нові налаштування BIOS, пов’язані з сертифікатами, дозволивши Windows Update самостійно додавати сертифікати.
Epoch71 заперечив, зазначивши, що на його пристроях вже був останній BIOS, отриманий через HP Image Assistant, але відновлення BitLocker все одно відбувалося, без додавання будь-яких налаштувань сертифікатів, які HP радила не змінювати.
Коли він примусово встановив сертифікати через ключ реєстру на своєму EliteBook 640 G10 з BIOS V75 01.12.01, пристрій щоразу переходив у режим відновлення. Повернення до старішої версії BIOS V75 01.11.00 вирішило проблему, але відкат версій BIOS на тисячах розгорнутих пристроїв є вкрай складним для більшості ІТ-команд. Ні HP, ні Microsoft не надали подальших відповідей щодо цієї проблеми до закриття сесії.
Позиція HP щодо застарілих пристроїв викликає пряму критику
Користувач під ніком Shapalapa використав AMA, щоб висловити детальну скаргу щодо розгортання HP. На своєму EliteBook 840 G6 він описав ситуацію, коли пристрій тривалий час перебував у стані Under Observation – More Data Needed. Прогрес з’явився лише після встановлення BIOS 01.35.01, а потім знову виник той самий цикл відновлення BitLocker, про який повідомляв epoch71. Ця проблема вирішилася лише після того, як він виявив, що три специфічні налаштування BIOS були вимкнені за замовчуванням і потребували ручного ввімкнення.

Він також вказав на зміну у списку підтримуваних пристроїв HP. Спочатку на сторінці підтримки HP було зазначено пристрої 2018 року випуску та новіші, включаючи моделі ZBook 14u G5 та ProBook 650 G4, але ці записи були тихо видалені після того, як HP визначила, що NVRAM на цьому обладнанні не вміщує нові сертифікати. За його словами, пакет ручного оновлення HP для пристроїв, що вийшли з обслуговування, був недостатньою заміною належного виправлення BIOS. Ні HP, ні Microsoft не відповіли на цей допис.
Пристрої все ще застрягли зі статусом Secure Boot = Unknown
Оригінальне запитання користувача salmankhan1 щодо пристроїв, які показували Secure Boot Status = Unknown, незважаючи на наявність сертифікатів 2023 року, увімкнений прапорець Secure Boot та справний TPM, отримало лише часткову відповідь.
Прабхакар з Microsoft порадив запустити Get-SecureBootRolloutStatus.ps1 для отримання повної картини, але не визначив першопричину некоректного відображення статусу на пристроях, які в іншому випадку відповідали всім передумовам.
Парк HP компанії Checker-KP все ще не може оновити KEK
Checker-KP повідомив про приблизно 700 пристроїв HP EliteBook G9 і G10, на яких сертифікати DB оновилися успішно після встановлення ключа реєстру на 0x5944, але KEK конкретно не оновлювався, неодноразово повертаючись до стану Not Started після кожного перезавантаження.
Дюен Гатлін та Юрген Байєр з HP відреагували, запропонувавши кроки з усунення несправностей, зокрема спробу використання значення 0x4 в реєстрі для явного примусового оновлення KEK та підтвердження найновіших версій BIOS для обох моделей.
Однак після оновлення одного тестового пристрою до найновішого BIOS, KEK все ще не оновився. Обговорення завершилося без підтвердженого виправлення, і Checker-KP залишився з припущенням, чи не належать його конкретні пристрої до тих, що постраждали від відомого блокування Microsoft для певних версій прошивок. Про це Windows Latest детально повідомляв на початку місяця, коли Microsoft почала призупиняти розгортання на певних комбінаціях пристроїв та прошивок, замість того, щоб дозволяти розгортання відомої несправної оновленої версії.
Два запитання від Dell та HP залишилися без відповіді
ІТ-адміністратор під псевдонімом pbormet описав відносно успішне оновлення сертифікатів на парку пристроїв Dell, але з одним винятком: пристрої Optiplex 5000 відмовляються оновлювати ключ реєстру при виконанні команди. Жоден представник Dell не відповів під час сесії.
На запитання Shapalapa до HP щодо причин такої складності переходу на сертифікати для клієнтів HP, яке охоплювало ту ж проблему з ємністю NVRAM та цикл відновлення BitLocker, також не було відповіді від компанії.

Проблеми з Secure Boot є закономірністю для всіх виробників, а не лише для одного постачальника
Клієнти HP та Dell повідомили про найскладніший досвід роботи з Secure Boot серед усіх представлених виробників, що відповідає тому, що ми документуємо з березня. Наш початковий звіт про ширшу проблему прошивок, що стоїть за Secure Boot 2023, показав, що непослідовні реалізації прошивок у галузі ПК (не помилка окремого постачальника) були причиною того, що звичайна зміна сертифіката перетворилася на стрес-тест для UEFI.
У порівняльному посібнику для виробників обладнання, опублікованому Windows Latest у червні, зазначено, що Dell застосувала найконсервативніший підхід, постачаючи як сертифікати 2011, так і 2023 років на новому обладнанні з кінця 2024 року. Розгортання HP, порівняно з цим, вже призвело до двох окремих хвиль скарг на BitLocker протягом трьох місяців: спочатку у квітні, а потім на зустрічі в липні, причому друга партія з’явилася на версіях BIOS, які мали виправити початкову проблему.

Windows Latest також відстежив, як проблеми з прошивками HP та Dell вплинули на загальну надійність Windows 11, а пізніше виявив пристрої HP серед ПК, які постраждали від циклів відновлення BitLocker та збоїв завантаження, що виникли з оновленням Patch Tuesday від червня 2026 року.
Якщо ви ІТ-адміністратор, який досі працює над цим розгортанням, найбезпечніший підхід, який ми рекомендуємо, полягає в тому, щоб спочатку протестувати на репрезентативному обладнанні перед масовим розгортанням, підтвердити резервне копіювання ключів відновлення BitLocker перед зміною будь-яких налаштувань реєстру або BIOS, і якщо пристрій застряг на статусі, який не відповідає його стану сертифіката, запустіть Detect-SecureBootCertUpdateStatus.ps1 з %systemroot%SecureBootExampleRolloutScripts, перш ніж припускати, що щось зламано.
Що робити, якщо проблему з сертифікатом Secure Boot у Windows 11 досі не вирішено
Невирішені випадки в цій темі не є такими вже й рідкісними, з якими ви навряд чи зіткнетеся. Цикли відновлення BitLocker, завислі оновлення KEK та показники статусу Secure Boot, які не відповідають стану сертифіката пристрою, тепер з’являються на пристроях HP, Dell та змішаних корпоративних парках, як на старому обладнанні, так і на версіях BIOS, випущених цього року.
Якщо ви спостерігаєте будь-яке з цих явищ на своєму ПК або в парку пристроїв, ви маєте справу з задокументованим набором проблем, що може викликати як впевненість, так і сумніви, залежно від вашої точки зору.
Отже, що вам потрібно знати з цієї теми: розглядайте оновлення BIOS та розгортання сертифікатів Secure Boot як окремі ризики, які зараз перетинаються. Пристрій, який пройшов перевірку сертифіката, не гарантує безпеки оновлення BIOS, а свіжий BIOS не гарантує успішного завершення оновлення сертифіката, як це на власному досвіді зрозуміли epoch71 та Checker-KP.
Перед масштабними втручаннями в будь-який з цих процесів створіть резервну копію ключів відновлення BitLocker та перегляньте специфічні рекомендації вашого виробника обладнання, не покладаючись лише на загальні вказівки Microsoft.

Посібник Windows Latest щодо OEM Secure Boot є найкращим місцем для перевірки опублікованих інструкцій виробника. Якщо ви ще не визначили стан вашого парку пристроїв, посібник Windows Latest з перевірки статусу Secure Boot та дій у разі пропущеного оновлення детально розглядає кожен крок.
Щодо виправлень, які Microsoft та виробники обладнання підтвердили під час цієї ж сесії, включаючи правильний ключ реєстру, вплив оновлень прошивок на рейтинги довіри та те, що відбувається з пристроями, які пропустили термін, у супутній статті Windows Latest охоплено все це.
Нарешті, якщо ваш пристрій постраждав від відомого блокування прошивки, Microsoft підтвердила призупинення розгортання для певних комбінацій пристроїв та прошивок, і це може пояснити, чому ваші ПК навмисно стримуються, поки компанія та виробники обладнання працюють над виправленням.
