KB5127648과 NTLMv1: PEAP-MSCHAPv2 Wi-Fi, LAN, VPN 연결이 끊긴 이유와 영구적 해결 방법

간단한 요약

KB5127648, 즉 Windows 11 24H2, 25H2, 26H2를 위한 2026년 10월 누적 업데이트가 설치된 이후, Windows는 기본적으로 싱글 사인온(SSO)에서 NTLMv1 기반 자격 증명을 차단합니다. Windows Server 2025도 2026년 10월 업데이트에서 동일한 변경이 적용됩니다. Credential Guard가 비활성화된 기기에서 Windows 자격 증명으로 PEAP-MSCHAPv2 또는 EAP-MSCHAPv2를 사용하는 Wi-Fi, 이더넷(유선 802.1X), VPN 연결이 더 이상 자동으로 연결되지 않습니다.

레지스트리 값 BlockNtlmv1SSO를 0으로 설정하면 현재로서는 기존 동작을 복원할 수 있습니다. Microsoft가 권장하는 영구적 해결책은 EAP-TLS를 사용한 인증서 기반 인증입니다.

TL;DR

• 변경 사항: 관리자가 별도로 설정하지 않은 모든 기기에서 Windows가 BlockNtlmv1SSO를 강제 적용합니다. Microsoft는 이 내용을 메시지 센터 게시물 MC1508562에서 발표했으며, KB5066470에서 자세히 설명합니다.
• 영향 대상: Credential Guard 없이 MS-CHAPv2 기반 싱글 사인온을 사용하는 기기, 주로 도메인에 가입된 Windows 클라이언트입니다.
• 빠른 임시 해결책: BlockNtlmv1SSO를 0으로 설정합니다. Microsoft 자체적으로도 이 설정을 장기적으로 사용하지 말 것을 권고합니다.
• 영구적 해결책: EAP-TLS로 전환합니다. SCEPman을 사용하면 온프레미스 PKI 구축 없이 전환할 수 있습니다.

KB5127648에서 무엇이 바뀌었나

Microsoft는 단계적으로 NTLM을 폐지해 왔습니다. 이번 단계는 많은 네트워크가 여전히 매일 의존하는 프로토콜인 MS-CHAPv2에 영향을 미칩니다. MS-CHAPv2는 NTLMv1 기반 자격 증명을 사용하는데, Windows는 이제 싱글 사인온을 위해 해당 자격 증명을 더 이상 제공하지 않습니다.

Microsoft는 이 강제 적용을 메시지 센터 게시물 MC1508562, "조치 필요: NTLMv1 강화 변경으로 Credential Guard 없는 기기의 네트워크 연결에 영향이 있을 수 있습니다"를 통해 발표했습니다. 기술적 배경은 KB5066470에서 확인할 수 있습니다.

Microsoft는 이를 알려진 업데이트 문제가 아닌 계획된 보안 강화 변경 사항으로 규정합니다. 즉, 이 변경은 영구적입니다.

영향을 받는지 확인하기

다음 조건이 모두 해당되면 영향을 받을 가능성이 높습니다.

• 기기가 Windows 11 24H2 이상 또는 Windows Server 2025를 실행 중이며, 2026년 10월 업데이트(Windows 11의 경우 KB5127648)가 설치되어 있습니다.
• 해당 기기에서 Credential Guard가 비활성화되어 있습니다.
• Wi-Fi, 이더넷(유선 802.1X) 또는 VPN이 싱글 사인온과 함께 PEAP-MSCHAPv2 또는 EAP-MSCHAPv2를 사용합니다. 일반적으로 "내 Windows 로그온 이름 및 암호를 자동으로 사용"이 활성화된 도메인 가입 기기가 해당됩니다.
• BlockNtlmv1SSO 레지스트리 값이 한 번도 설정된 적이 없습니다.

인증서 기반 인증(EAP-TLS)을 이미 사용 중인 기기는 이 변경에 영향을 받지 않습니다. Credential Guard가 활성화된 기기는 이미 해당 동작을 차단하고 있었으므로, 비밀번호 기반 SSO는 이미 작동하지 않고 있었습니다. 이번 변경은 Windows에만 적용되므로 macOS, iOS, Android, Linux 클라이언트는 영향을 받지 않습니다.

어떤 증상이 나타나는가

• 기기가 자동으로 연결되지 않고 사용자에게 자격 증명 입력 창이 표시됩니다.
• 비밀번호를 수동으로 입력하면 연결은 되지만, Windows가 다음 번을 위해 저장할 수 없습니다.
• 사용자 개입 없이 연결되던 워크플로가 중단됩니다. 예를 들어 공유 기기나 키오스크 기기, 자동으로 연결되는 VPN 프로필이 해당됩니다.
• 클라이언트가 Microsoft-Windows-NTLM/Operational에 Event ID 4025("차단됨")를 기록합니다. 감사 모드에서는 Event ID 4024가 기록됩니다.

연결 실패는 클라이언트에서 발생하므로 RADIUS 또는 NPS 로그에는 관련 내용이 거의 나타나지 않을 수 있습니다. 엔드포인트에서부터 문제를 진단하십시오.

기기 확인 방법

# BlockNtlmv1SSO가 구성되어 있는가? (값 없음 = Windows가 새로운 강제 기본값 사용)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

# Windows가 NTLMv1 기반 자격 증명을 감사(4024)하거나 차단(4025)했는가?
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50

빠른 임시 해결책: BlockNtlmv1SSO를 0으로 설정

영향을 받는 기기를 감사 모드로 되돌릴 수 있습니다. 이렇게 하면 Windows가 NTLMv1 기반 자격 증명을 다시 허용하고, 각 사용을 Event ID 4024로 기록합니다.

명령줄

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Intune 수정 스크립트 (시스템 컨텍스트에서 실행)

# 감지 스크립트: BlockNtlmv1SSO가 명시적으로 0으로 설정된 경우에만 준수
$v = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($v -eq 0) { exit 0 } else { exit 1 }

# 수정 스크립트
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -PropertyType DWord -Value 0 -Force | Out-Null

도메인 가입 기기의 경우, 동일한 키, 값 이름, 형식, 데이터를 사용하는 그룹 정책 기본 설정 레지스트리 항목을 사용하십시오.

이것이 임시 해결책에 불과한 이유

• 취약한 경로를 다시 열어 둡니다. Microsoft는 MS-CHAPv2 기반 엔드포인트가 "NTLMv1에 영향을 미치는 위험과 유사한 위험에 노출된다"고 명시하며, 이 설정은 "신중하게 평가해야 하며 장기적으로 사용해서는 안 된다"고 권고합니다.
• Credential Guard가 있는 기기에는 효과가 없습니다. 이 설정에 관계없이 MS-CHAPv2 SSO를 차단합니다.
• 오프라인 기기는 정책을 받을 수 없습니다. 네트워크 접근이 이미 끊긴 기기는 유선 또는 게스트 네트워크를 통해 설정을 받아야 할 수 있습니다.
• 업데이트 제거는 대안이 될 수 없습니다. 제거하면 해당 월의 보안 수정 사항이 적용되지 않은 상태로 기기가 남게 됩니다.

임시 해결책은 시간을 버는 용도로만 사용하되, 종료 시한을 문서화하고 그 기간을 마이그레이션에 활용하십시오.

영구적 해결책: 비밀번호 대신 EAP-TLS

Microsoft는 MS-CHAPv2에 대한 의존성을 제거하고 Wi-Fi 및 VPN 연결을 EAP-TLS를 사용한 인증서 기반 인증으로 전환할 것을 권장합니다. 기기 또는 사용자가 비밀번호 대신 인증서와 개인 키로 신원을 증명하며, 개인 키는 TPM으로 보호할 수 있습니다.

연결 중단을 해결하는 것 외에도, 더 나은 사용자 경험과 강화된 보안 태세를 얻을 수 있습니다.

많은 네트워크가 여전히 비밀번호를 사용하는 이유

프로토콜 자체가 문제가 아닙니다. PKI가 문제입니다. 기존 설정에는 AD CS, NDES, Intune Certificate Connector, 애플리케이션 프록시, CRL 게시, 고가용성, 패치 관리가 포함됩니다. 노트북 한 대에 인증서를 배포하기 위해 움직이는 부품이 너무 많고, 이것이 많은 팀이 전환을 수년간 미뤄온 이유입니다. 자세한 내용은 2026년 Microsoft ADCS 대안을 참고하십시오.

SCEPman이 PKI 복잡성을 없애는 방법

SCEPman은 Azure 네이티브 인증 기관으로, Azure 키 자격 증명 모음에 키를 저장하여 사용자의 Azure 테넌트 내에서 완전히 운영됩니다.

• 빠른 시작: Azure Marketplace, ARM 템플릿 또는 Terraform을 통해 배포합니다. 대부분의 팀이 한 시간 이내에 첫 번째 인증서를 발급합니다.
• 관리 기기: Microsoft Intune, Jamf Pro 및 기타 MDM이 SCEP를 통해 기기 및 사용자 인증서를 자동으로 발급하고 갱신합니다.
• 실시간 유효성 검사: 인증서가 사용자 또는 기기 개체에 바인딩되고 OCSP를 통해 확인됩니다. 신원이 변경되면 액세스가 자동으로 철회됩니다.
• 기존 네트워크와 호환: SCEPman은 Cisco, Meraki, HPE Aruba, Fortinet, Juniper 등을 지원하며 기존 RADIUS 서버와 함께 작동합니다.
• RADIUS 서버 불필요: RADIUSaaS와 결합하면 인증서 기반 Wi-Fi, LAN, VPN 액세스를 위한 완전한 클라우드 네이티브 솔루션을 구성할 수 있습니다.

6단계 마이그레이션 경로

1. 현황 파악. 여전히 MS-CHAPv2를 사용하는 SSID, 유선 802.1X 정책, VPN 프로필을 확인합니다. Event ID 4024 및 4025를 통해 어떤 기기가 의존하고 있는지 파악할 수 있습니다.
2. 필요한 곳에서 시간을 확보합니다. 중요한 기기에 BlockNtlmv1SSO를 0으로 설정하되, 문서화하고 종료 시한을 지정합니다.
3. SCEPman을 배포하고 루트 CA 인증서를 배포합니다. Intune 신뢰할 수 있는 인증서 프로필 또는 그룹 정책을 통해 배포할 수 있습니다.
4. 인증서를 롤아웃합니다. Intune, Jamf Pro 또는 기타 MDM SCEP 프로필을 통해 기기 인증서(필요한 경우 사용자 인증서)를 발급합니다.
5. 단계적으로 전환합니다. RADIUS 서버(NPS, 기존 RADIUS 또는 RADIUSaaS)에서 PEAP와 함께 EAP-TLS를 활성화합니다. 그런 다음 Wi-Fi, 802.1X, VPN 프로필을 그룹 단위로 EAP-TLS로 전환합니다.
6. 정리합니다. MS-CHAPv2 정책을 제거한 다음, BlockNtlmv1SSO를 다시 1로 설정하거나 값을 삭제하여 Windows가 다시 보안 기본값을 사용하도록 합니다.

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /f

결론

Microsoft의 결정은 명확합니다. MS-CHAPv2를 통한 비밀번호 기반 네트워크 SSO는 Windows에서 미래가 없습니다. KB5127648을 몇 주 동안 우회할 수도 있지만, 이 시점을 인증서 기반 액세스로 완전히 전환하는 기회로 활용하는 것이 낫습니다.

단순한 PKI. 안정적인 인증서.

SCEPman 무료 체험

FAQ