Многофакторная аутентификация 2026

В начале 2026 года МФА в большинстве организаций уже не “проект на будущее”, а обязательный слой контроля доступа для ключевых точек входа: VPN/VDI и удалёнки, административных учёток, почты и критичных бизнес-систем. Эти каналы остаются первоочередной целью атакующих, потому что дают быстрый путь к инфраструктуре и привилегиям.

При этом запрос сместился: важно не просто включить второй фактор, а обеспечить понятный уровень доверия к аутентификации и управляемую эксплуатацию — единые политики в гибридной среде (on-prem + облака + SaaS), аудит, корректные резервные процедуры и жизненный цикл факторов. Дополнительно выросла актуальность обходов, которые бьют не “в фактор”, а в процесс: MitM/AiTM-прокси, перехват и повтор сессионных данных, имитация проверяющей стороны, атаки на восстановление доступа и интеграции. Поэтому МФА в 2026 — это в первую очередь про архитектуру и устойчивость, а уже потом про удобство выбранного метода.

Ключевые вопросы дискуссии:

1. Требования к МФА в 2026
   
   • Чем в корпоративной практике отличается идентификация от аутентификации, и почему именно это различие влияет на то, как мы проектируем доступ и права в системах?
   • Какие виды аутентификации на практике имеет смысл разделять (простая / усиленная / строгая)
   • Как по-взрослому определить “насколько мы доверяем входу” (assurance level по ГОСТ-подходу): какие меры реально повышают доверие, а какие просто создают видимость защиты?
   • Как выбирать сочетание факторов (пароль + устройство + биометрия) под разные уровни риска, и где действительно нужен “железный” фактор — токен/смарт-карта или криптографический ключ?
   • Когда вы сравниваете решения МФА, что важнее проверять в первую очередь, кроме “удобного интерфейса”: какие технические свойства делают метод аутентификации устойчивым и пригодным для эксплуатации?
   • В каких сценариях 2026 года вы бы сознательно оставили токен/смарт-карту как лучший вариант (особенно для админов и критичных контуров), даже если “хочется всё упростить смартфоном”?
   • Что вы обязаны проверить заранее, чтобы токены/смарт-карты не “сломались” в инфраструктуре: совместимость с ОС, криптопровайдерами (CSP/СКЗИ) и целевыми сервисами?
   • Если второй фактор — смартфон, какие варианты вы считаете наиболее надёжными (TOTP, push, ключи) и какие риски надо закрыть сразу, чтобы потом не бороться с фишингом и “усталостью от пушей”?
   • Почему СМС считается слабым фактором, и что нужно сделать, если SMS всё же остаётся временным решением, чтобы не получить дырку в безопасности?
   • В каких случаях passkeys/passwordless и биометрия реально подходят для корпоративной среды, и какие условия должны быть выполнены, чтобы это было управляемо (восстановление доступа, аудит, политика для устройств)?
2. Внедрение и эксплуатация
   
   • Что вы фиксируете на старте проекта, чтобы МФА не осталась “только на VPN”, а закрыла все основные входы — домен, PKI, почту и привилегированные учётки?
   • Как вы проверяете до пилота, что выбранная МФА реально поддерживает ваши ключевые точки входа и пользовательские сценарии, и не “сломается” на протоколах/криптотребованиях?
   • Когда часть сервисов on-prem, часть в облаке и SaaS, что чаще всего идёт не так при внедрении МФА, и как удержать единые правила и аудит во всех контурах?
   • В каких случаях “МФА как сервис” действительно подходит, а в каких вы бы не пошли в этот подход из-за контроля, рисков зависимости и требований к доказуемости?
   • Когда open source-решение для МФА может быть нормальным выбором, и какие условия должны быть у команды (поддержка, мониторинг, обновления, ответственность), чтобы это не стало риском?
   • Что чаще всего остаётся “без владельца” в жизни факторов: выдача, перевыпуск, отзыв при увольнении, действия при компрометации. Какие минимальные правила и роли вы считаете обязательными, чтобы МФА не разваливалась?
   • Как вы организуете “аварийный вход”, если пользователь потерял устройство или недоступен УЦ/сеть, чтобы бизнес не остановился, но и не появилось обходного входа для атакующего?
   • Какие обходы МФА вы считаете самыми опасными в 2026 (AiTM/MitM-фишинг, захват сессий, атаки на восстановление доступа), и какие требования к методу МФА вы ставите, чтобы эти сценарии не проходили?
   • В каких случаях достаточно усилить “фактор и канал”, а когда без криптографических ключей и взаимной проверки сторон не обойтись — и как это увязать с использованием СКЗИ и ГОСТ-алгоритмов (ГОСТ 28147-89, ГОСТ 34.12-2018 «Магма/Кузнечик») и классами КС1/КС2/КС3?
   • Если в проекте есть компонент с сертификатом ФСТЭК (например, №4411, УД-4, действует до 20.05.2026), как вы заранее планируете контроль сроков, продление/замену и совместимость, чтобы проект не “встал” посреди года?
3. Итоги эфира и планы на 2026
   
   • Какие технологии аутентификации, по вашему прогнозу, будут сильнее всего масштабироваться в 2026 и что станет “де-факто стандартом” для критичных доступов?
   • Как будут развиваться облачные и гибридные схемы МФА в 2026, и по каким признакам вы определяете “можно в облако” или “нужен только внутренний контур”?
   • Если организация идёт по импортозамещению, как в 2026 выбирать МФА-стек так, чтобы он выдерживал требования совместимости с отечественными ОС/PKI/СКЗИ и требования реестра отечественного ПО/сертификаций, не превращаясь в “зоопарк”?
   • Какие “новые старые” атаки будут чаще всего бить по МФА в 2026 (AiTM-прокси, атаки на восстановление доступа, компрометация устройств, push-fatigue), и какие меры вы бы заложили заранее в архитектуру и политику?
   • Если бы вы начинали проект МФА в 2026 с нуля, какие 3–5 шагов вы считаете обязательными, чтобы быстро получить эффект и не построить хрупкую систему, которая ломается в эксплуатации?

Приглашенные эксперты:

Модераторы: