Октябрьское обновление безопасности Windows 2026 по умолчанию включает блокировку NTLMv1 для сценариев единого входа. Для компаний, где в сетевой инфраструктуре ещё живы старые схемы аутентификации, это может обернуться отказом подключения к Wi‑Fi, проводной сети или VPN — без привычного «Windows всё починит после перезагрузки».
Изменение касается параметра реестра BlockNtlmSSO, сообщает The Register. До обновления Windows при отсутствии явно заданного значения работала в режиме аудита: система позволяла использовать учётные данные, производные от NTLMv1, но фиксировала предупреждения в журналах. После установки октябрьского пакета режимом по умолчанию становится Enforce со значением 1: такие запросы блокируются.
Это не очередная ошибка патча и не случайный побочный эффект усиления защиты. Microsoft последовательно выводит NTLM из эксплуатации: протокол добавили в список устаревающих компонентов в 2024 году, а в конце августа 2025-го компания добавила журналы аудита для использования NTLMv1. Ещё в 2023 году Microsoft формулировала конечную цель без особой дипломатии: устранить необходимость в NTLM вообще.
Проблема в возрасте технологии и длине её хвоста. NTLM появился ещё в Windows NT 3.1 в 1993 году, поэтому за три десятилетия успел встроиться в корпоративные сети, старые приложения, устройства и схемы доступа, которые никто не трогает, пока они не перестают работать. Сам NTLM Microsoft уже убрала из Windows 11 24H2 и Windows Server 2025, но отдельные зависимости остаются. В частности, они могут возникать при доменных подключениях на базе MS-CHAPv2 — включая PEAP-MSCHAPv2 и EAP-MSCHAPv2.
Для администратора это означает, что расследование внезапно отвалившегося Wi‑Fi или VPN стоит начинать не только с контроллера, RADIUS-сервера, сертификатов и драйверов. Нужно проверить, не пытается ли клиент получить Single Sign-On через учётные данные NTLMv1. Если причина в этом, временный обход существует: задать для BlockNtlmSSO значение 0 и вернуть режим аудита. Но Microsoft прямо предупреждает, что это должно быть ограниченным по времени исключением, а не новой постоянной настройкой инфраструктуры.
В практическом плане блокировка NTLMv1 превращает накопленные журналы аудита в список технического долга. Командам эксплуатации стоит сопоставить события NTLMv1 с конкретными устройствами, сетевыми профилями и владельцами сервисов; командам ИБ — определить срок и условия для исключений; владельцам старых систем — подготовить замену аутентификации. Особенно неприятны «серые» зависимости: сетевой принтер, промышленный терминал или внутренний клиент, который годами переживал миграции Active Directory и внезапно оказывается единственным потребителем старого протокола.
Для разработчиков и продуктовых команд здесь тоже есть сигнал. Корпоративные клиенты всё чаще будут требовать современные схемы идентификации не потому, что это красиво выглядит в чек-листе безопасности, а потому что поддержка устаревшего механизма начинает ломать базовое сетевое подключение после штатного обновления ОС. Если продукт зависит от доменной аутентификации или корпоративного Wi‑Fi, совместимость со старыми NTLM-сценариями уже нельзя считать безобидной особенностью.
Microsoft не выключает весь NTLM одним переключателем, но меняет баланс: раньше компания предупреждала о риске, теперь заставляет инфраструктуру показать, где миграция так и не состоялась. В ближайших циклах обновлений число подобных исключений, вероятно, будет только сокращаться — и самый дешёвый момент найти зависимость от NTLMv1 уже прошёл.