TPM 인증서 증명 실패 해결 방법 | Windows TPM Attestation 오류 완전 정리

이 글의 목적은 Windows 환경에서 TPM 인증서 증명(Attestation) 실패가 발생할 때 원인 분석부터 펌웨어·OS·네트워크·관리 서버(예: Intune, Azure AD)까지 단계별로 점검하여 현장에서 재현·해결할 수 있도록 실무 중심으로 정리하는 것이다.

1. TPM 인증서 증명(Attestation) 개념 이해

TPM(Trusted Platform Module)은 PC나 서버의 보안 관련 키를 안전하게 저장하고, 부팅 상태와 같은 플랫폼 무결성을 검증하기 위한 보안 칩이다.

TPM 인증서 증명(Attestation)은 단순히 키를 보관하는 수준을 넘어, “이 장비가 신뢰할 수 있는 상태로 부팅되었는지, OS와 부트 체인이 변조되지 않았는지”를 외부 서비스(클라우드, 도메인, MDM 등)에 증명하는 절차를 의미한다.

대표적으로 다음과 같은 시나리오에서 TPM Attestation이 활용된다.

엔터프라이즈 환경의 장치 준수 체크(Intune, MDM)에서 디바이스 상태 검증
Windows Hello for Business 키 기반 인증에서 디바이스 신뢰도 확인
VPN, Wi-Fi, 엔터프라이즈 애플리케이션에서 기기 기반 인증 강화

Attestation 과정에서 TPM은 다음과 같은 정보를 바탕으로 신뢰성을 검증한다.

EK(Endorsement Key) 및 관련 인증서
AIK(Attestation Identity Key) 및 관련 인증서
PCR(Platform Configuration Register) 값 – 부팅 구성 요소 해시
Secure Boot, 부팅 모드(UEFI/Legacy), OS 무결성 정보

이 중 하나라도 예상과 다르거나, 서버 측 정책·인증서·네트워크 조건이 맞지 않으면 TPM Attestation 실패로 표시된다.

2. TPM Attestation 실패 증상 유형 정리

현장에서 자주 마주치는 TPM 인증서 증명 실패 증상은 다음과 같이 정리할 수 있다.

Intune 또는 MDM 콘솔에서 “TPM attestation failed” 또는 유사 메시지 표시
장치 준수 상태가 “비준수”로 나타나며, 이유에 TPM 관련 항목이 포함됨
Windows Hello for Business 등록 또는 로그인 시 보안 키/장치 신뢰 오류가 발생함
이벤트 뷰어에서 Device Health Attestation 또는 TPM 관련 오류 이벤트 기록

상황	대표 메시지 예시	주요 영향
Intune 장치 준수 평가	TPM attestation failed, device health attestation not available	장치 준수 비준수, 회사 리소스 접근 제한
Windows Hello for Business 구성	Device is not meeting the security requirements for key trust	PIN/생체인증 등록 실패 또는 사용 제한
VPN/Wi-Fi 디바이스 인증	Device certificate not trusted / TPM-based key not validated	네트워크 접속 제한
로컬 이벤트 로그	DeviceHealthAttestation CSP operation failed / DHA service error	클라우드 기반 건강 상태 증명 실패

3. TPM Attestation 실패 원인 구조

TPM 인증서 증명 실패는 단일 원인이 아니라, 아래 영역 중 하나 또는 여러 개가 동시에 문제를 일으킨 결과인 경우가 많다.

하드웨어/펌웨어 영역
- TPM 버전/펌웨어 문제(펌웨어 업데이트 누락, 비표준 구현)
- UEFI 대신 Legacy BIOS 부팅, CSM 활성화
- Secure Boot 비활성화로 인한 PCR 값 mismatch
OS 및 서비스 영역
- TPM 초기화 문제, OS에서 TPM 인식 안 됨
- Device Health Attestation 서비스 장애
- 시스템 시간·날짜 불일치로 인증서 체인 검증 실패
Windows 10 네트워크 연결됨 인터넷 없음 0x800704cf 완벽 해결 방법 →
네트워크/보안 인프라 영역
- 클라우드 DHA 서비스 또는 MDM 서버에 대한 네트워크 차단(프록시, 방화벽)
- SSL/TLS 검사용 중간 프록시 장비가 트래픽을 변형
관리 서버·정책 영역
- Intune/MDM 정책에서 요구하는 보안 기준과 실제 디바이스 상태 불일치
- CA 인증서 체인 구성 오류, CRL/OCSP 등 검증 실패
- 디바이스 등록·조인 상태 오류(Azure AD Join, Hybrid Join 등)

주의 : TPM Attestation 실패를 단순 소프트웨어 버그로만 보고 무작정 재설치·초기화하면 BitLocker 복구 키 분실, Windows Hello for Business 키 무효화 등 추가 피해가 발생할 수 있다. 반드시 구조적으로 원인을 구분하여 순서대로 점검해야 한다.

4. 1단계 – TPM 및 펌웨어 상태 점검

첫 번째 단계는 장치의 TPM이 정상 동작 가능한 상태인지, 펌웨어 설정이 Attestation에 적합한지 확인하는 것이다.

4.1 TPM 버전과 준비 상태 확인

Windows에서 TPM 상태를 확인하는 기본 방법은 다음과 같다.

Win + R 키를 눌러 실행 창을 열고 tpm.msc 입력 후 실행한다.
“TPM 제조사 정보”, “상태” 항목을 확인한다.
- TPM 버전이 2.0인지 확인한다.
- 상태가 “TPM을 사용할 준비가 되었습니다” 또는 이와 유사한 정상 상태인지 확인한다.

PowerShell로도 TPM 상태를 스크립트화하여 확인할 수 있다.

PowerShell Get-Tpm
주요 속성 예시
TpmPresent : True
TpmReady : True
ManagedAuthLevel: Full
OwnerAuth : System.String

TpmPresent가 False이거나 TpmReady가 False이면 펌웨어 설정 또는 하드웨어 레벨에서 TPM이 비활성화되어 있거나, 초기화가 필요하다는 의미이다.

4.2 UEFI, Secure Boot, CSM 설정 확인

Attestation에서 중요하게 보는 값 중 하나가 부팅 경로(PCR)이다. 다음 항목을 BIOS/UEFI 설정에서 점검한다.

부팅 모드가 UEFI 모드인지 확인한다.
CSM(Compatibility Support Module)이 활성화되어 있다면 비활성화하는 것을 권장한다.
Secure Boot가 비활성화되어 있으면, 가능한 경우 활성화한다.
- Secure Boot 활성화 조건을 만족하지 못하는 구형 장치나 특수 OS는 정책에서 예외 처리해야 한다.

주의 : 부팅 모드 변경(예: Legacy → UEFI)이나 Secure Boot 활성화 전에는 반드시 OS가 해당 설정을 지원하는지 확인하고, 전체 디스크 백업을 준비하는 것이 안전하다.

4.3 TPM 초기화·재설정 시 주의사항

TPM을 재설정(Clear)하면 TPM 내부에 저장된 키가 모두 삭제되므로, BitLocker 키나 Windows Hello for Business 키가 더 이상 사용할 수 없게 될 수 있다.

BitLocker가 사용 중인 경우, 각 드라이브의 복구 키를 안전한 위치(예: AD, Azure AD, Intune, 종이 문서)에 미리 확보한다.
Windows Hello for Business를 사용하는 계정이 있는 경우, 재등록 절차가 필요하다는 점을 사용자에게 안내한다.
위 준비가 완료된 뒤 BIOS/UEFI 또는 tpm.msc에서 TPM 초기화를 수행한다.

주의 : TPM 초기화는 최후 수단에 가깝다. 먼저 펌웨어 업데이트, OS 패치, 서비스·네트워크 문제를 검토한 후 다른 방법으로 해결되지 않을 때 선택하는 것이 바람직하다.

5. 2단계 – Windows 서비스 및 OS 상태 점검

하드웨어와 펌웨어가 정상이어도 OS가 TPM과 Attestation 서비스를 적절히 활용하지 못하면 실패가 발생한다. 다음 항목을 점검한다.

5.1 Device Health Attestation 서비스 확인

클라이언트는 “Device Health Attestation” 서비스를 통해 클라우드 DHA 서버 또는 관리 서버와 통신하여 Attestation을 수행한다.

Win + R → services.msc 실행
서비스 목록에서 “Device Health Attestation Service” 또는 유사한 이름의 서비스를 찾는다.
시작 유형이 “수동” 또는 “자동”인지 확인하고, 필요 시 서비스를 수동으로 시작한 뒤 오류 메시지를 확인한다.

이벤트 뷰어에서는 다음 경로에서 관련 로그를 확인할 수 있다.

이벤트 뷰어 → 응용 프로그램 및 서비스 로그 → Microsoft → Windows → DeviceHealthAttestation

게임 프레임 드랍 심할 때 노트북 배터리 전원 모드와 성능 모드 최적 설정 방법 →

여기에서 TLS 오류, 네트워크 연결 실패, TPM 값 읽기 오류 등의 추가 단서를 얻을 수 있다.

5.2 시스템 시간·날짜·시간대 점검

Attestation 과정에서 서버와의 TLS 핸드셰이크 및 인증서 검증이 필수이다. 클라이언트 시스템 시간이 실제 시간과 크게 어긋나 있으면 인증서 유효 기간 검증이 실패하여 Attestation이 거부될 수 있다.

Windows 설정 → 시간 및 언어에서 날짜·시간·시간대를 확인한다.
도메인 환경이면 도메인 컨트롤러와의 NTP 동기화 상태를 점검한다.
장비 BIOS/UEFI의 시간도 함께 확인하여 큰 차이가 없도록 한다.

5.3 최신 Windows 업데이트 및 TPM/칩셋 드라이버 적용

TPM 관련 버그·호환성 문제는 Windows 누적 업데이트나 펌웨어/드라이버 업데이트로 해결되는 경우가 많다.

Windows 업데이트를 최신 상태로 유지한다.
제조사 제공 관리 도구(예: Dell Command, HP Image Assistant)를 활용하여 BIOS·칩셋·TPM 펌웨어 업데이트를 적용한다.
드라이버 업데이트 후에는 반드시 한 번 이상 완전 재부팅(완전 종료 후 전원 켜기)을 수행한다.

6. 3단계 – 네트워크 및 SSL/TLS 인프라 점검

장치가 Device Health Attestation 클라우드 서비스 또는 관리 서버에 접근할 수 없으면 TPM이 정상이어도 Attestation이 실패한다.

6.1 프록시·방화벽·SSL 검사 장비 확인

기업 네트워크에서는 보통 다음 요소들이 Attestation에 영향을 줄 수 있다.

HTTP/HTTPS 프록시 서버
웹 필터링 방화벽
SSL/TLS 교차 검사 장비(중간 인증서 삽입)

점검 포인트는 다음과 같다.

Attestation에 필요한 엔드포인트(클라우드 DHA 서비스, Intune, Azure AD 등)에 대한 443 포트 통신이 차단되지 않았는지 확인한다.
SSL 검사 장비가 클라이언트와 서버 사이의 TLS 체인을 변경하여 클라이언트가 서버 인증서를 신뢰하지 못하는 상황이 없는지 확인한다.
프록시 인증이 필요한 환경에서는 컴퓨터 계정 기반 통신에 적절히 예외가 설정되어 있는지 확인한다.

윈도우10 부팅 안됨 자동 복구 무한루프 완전 해결 방법 →

주의 : Attestation 트래픽은 OS 내부 서비스 계정 및 컴퓨터 계정으로 동작하는 경우가 많다. 사용자 로그인 기반 프록시 인증 정책만 고려하면, 장치 수준 통신이 차단될 수 있다.

6.2 WinHTTP 프록시 설정 점검

Windows 내부 서비스는 브라우저 프록시 설정이 아니라 WinHTTP 프록시 구성을 사용하기도 한다. 다음 명령으로 상태를 확인한다.

관리자 권한 PowerShell 또는 명령 프롬프트
netsh winhttp show proxy

필요 시 프록시 초기화
netsh winhttp reset proxy

프록시 사용이 필요 없는 환경이라면 프록시를 초기화하고, 필요한 환경이라면 시스템 계정에서도 Attestation 서버에 접근 가능하도록 네트워크 팀과 협의해야 한다.

7. 4단계 – Intune / Azure AD / MDM 환경에서의 Attestation 실패 해결

엔터프라이즈 환경에서는 Attestation 실패가 장치 준수 정책과 직접 연결되므로, 관리 서버 측 구성을 함께 검토해야 한다.

7.1 디바이스 조인 상태 및 등록 방식 확인

Attestation을 활용하는 정책은 보통 다음과 같은 디바이스 상태를 전제로 한다.

Azure AD Join 또는 Hybrid Azure AD Join 상태가 정상
MDM(예: Intune) 등록이 완료되어 있으며, 장치가 올바른 장치 레코드와 매핑
중복된 디바이스 오브젝트가 존재하지 않음

중복 오브젝트나 비정상 조인 상태는 장치 식별과 키 매핑에 문제를 야기하여 Attestation 평가가 실패할 수 있다.

7.2 장치 준수 정책(Compliance Policy) 검토

Intune 기준으로, 장치 준수 정책에서 다음과 같은 조건이 설정되어 있는지 확인한다.

TPM 기반 보안 요구 여부
Secure Boot 필수 여부
BitLocker 또는 장치 암호화 필수 여부

장치의 실제 구성과 정책 요구 사항이 맞지 않으면 Attestation이 실패한 것으로 간주되거나, TPM 관련 오류로 표기될 수 있다. 정책을 장치 현실에 맞게 조정하거나, 단계적으로 강화하는 전략이 필요하다.

7.3 인증서 인프라 및 체인 점검

Windows Hello for Business, 디바이스 인증서, VPN/Wi-Fi EAP 인증 등에서 TPM Attestation과 함께 인증서 인프라가 사용되는 경우 다음을 점검해야 한다.

루트·중간 CA 인증서가 클라이언트와 서버 양쪽에서 모두 신뢰되는지 확인한다.
CRL(인증서 폐기 목록) 또는 OCSP 응답 서버에 접근 가능한지 점검한다.
템플릿 설정에서 TPM 기반 키 스토어를 활용하는지, 키 내보내기 허용 여부가 적절한지 확인한다.

주의 : SSL 검사 장비가 엔터프라이즈 내부 PKI 트래픽까지 중간자 역할을 하는 경우, 인증서 체인이 의도치 않게 변경되어 Attestation이나 인증서 기반 인증이 실패할 수 있다.

8. 5단계 – 로컬에서 TPM Attestation 연관 상태 점검 스크립트 활용

여러 장비를 동시에 점검해야 하는 경우 PowerShell 스크립트로 TPM·부팅·서비스 상태를 한 번에 수집하면 원인 분류에 도움이 된다. 예시 스크립트는 다음과 같다.

PowerShell # TPM 기본 정보 $tpminfo = Get-Tpm
부팅 정보 (UEFI 여부)
$firmwareType = (Get-CimInstance -ClassName Win32_ComputerSystem).BootupState

Device Health Attestation 서비스 상태
$dhaService = Get-Service -Name "HealthAttestation" -ErrorAction SilentlyContinue

Secure Boot 상태 (UEFI 환경에서만)
$secureBoot = $null
try {
$secureBoot = Confirm-SecureBootUEFI -ErrorAction Stop
} catch {
$secureBoot = "NotSupportedOrLegacy"
}

[PSCustomObject]@{
TpmPresent = $tpminfo.TpmPresent
TpmReady = $tpminfo.TpmReady
TpmVersion = $tpminfo.ManagedAuthLevel
FirmwareInfo = $firmwareType
DhasvcStatus = $dhaService.Status
SecureBoot = $secureBoot
}

이 스크립트 결과를 여러 장비에서 수집하여 비교하면, 특정 모델·펌웨어 버전·부팅 설정에서만 Attestation 실패가 발생하는지 빠르게 파악할 수 있다.

9. 6단계 – 문제 재현 및 로그 기반 원인 확정

TPM Attestation 문제는 “한 번 고쳐진 것처럼 보였다가 다시 발생하는” 식으로 재발하는 경우가 많다. 따라서 문제 해결 과정에서 반드시 다음 절차를 수행하는 것이 좋다.

문제가 발생하는 시점(예: Intune 준수 평가, Windows Hello 등록 시도)을 명확히 재현한다.
재현 직후 이벤트 뷰어에서 TPM·DeviceHealthAttestation·Winlogon·DeviceEnrollment 관련 로그를 수집한다.
네트워크 팀과 협조하여 해당 시간대의 프록시·방화벽 로그를 함께 확인한다.
펌웨어/OS/네트워크 등 각 레이어별로 변경 사항이 있었는지 변경 이력을 정리한다.

이 과정을 통해 “펌웨어 업데이트 이후부터만 발생”, “특정 VLAN이나 지점에서만 발생”, “특정 OEM 모델에서만 발생” 등 패턴을 찾아낼 수 있으며, 이를 바탕으로 근본 원인(Root Cause)을 확정할 수 있다.

10. 재발 방지를 위한 운영 전략

TPM 인증서 증명 실패를 장기적으로 줄이기 위해서는 개별 PC 단위 대응이 아니라, 조직 차원의 표준과 절차를 정립하는 것이 중요하다.

하드웨어 표준화
- TPM 2.0, UEFI, Secure Boot를 안정적으로 지원하는 모델을 표준 장비로 선정한다.
- 제조사별로 권장 TPM/BIOS 펌웨어 버전을 정의하고, 신규 배포 이미지는 해당 버전을 기준으로 구성한다.
이미지 및 정책 표준화
- OS 배포 이미지는 Secure Boot·TPM을 활성화한 상태를 기본값으로 설계한다.
- Intune/MDM의 장치 준수 정책을 단계적으로 강화하여, 초기에는 모니터링 모드로 운영한 뒤 충분한 데이터 확보 후 필수 조건으로 전환한다.
모니터링·로그 수집 체계
- Attestation 실패 이벤트를 중앙에서 수집·대시보드화하여 특정 모델/지역/버전에서의 이상 징후를 조기에 탐지한다.
- 변경 관리(Change Management)와 연계하여, 펌웨어·네트워크 정책 변경 시 Attestation 관련 영향 평가를 포함한다.

주의 : TPM Attestation은 단순한 옵션 기능이 아니라, 향후 비밀번호 없는 로그인과 제로 트러스트 아키텍처의 핵심 기반이 된다. 초기 도입 단계에서 충분히 구조를 이해하고 운영체계를 설계하는 것이 중요하다.

FAQ

TPM이 1.2 버전인데도 Attestation을 사용할 수 있는가?

일부 구형 환경에서는 TPM 1.2 기반 Attestation이 가능하지만, 최신 Windows 및 클라우드 서비스는 TPM 2.0을 전제로 설계되는 경우가 많다. 장기적으로는 TPM 2.0 장비로 전환하는 것이 바람직하다.

Secure Boot를 끄면 반드시 Attestation이 실패하는가?

환경에 따라 다르지만, 많은 정책에서 Secure Boot 상태를 신뢰 기준으로 활용한다. Secure Boot가 꺼져 있으면 PCR 값이 기대값과 달라지고, 정책상 비준수로 처리될 수 있다. 정책 요구사항을 확인한 뒤 가능하면 Secure Boot를 사용하는 것이 좋다.

TPM을 초기화하면 TPM Attestation 문제가 자동으로 해결되는가?

TPM 초기화는 내부 키와 상태를 초기화할 뿐이며, 펌웨어 설정·네트워크·정책 문제가 남아 있다면 Attestation 실패는 계속 발생할 수 있다. TPM 초기화는 모든 다른 원인을 검토한 뒤에 선택해야 하는 최후 수단에 가깝다.

Intune에서만 TPM Attestation 실패가 보이고, 로컬에서는 별 문제 없어 보이는 경우 무엇을 봐야 하는가?

이 경우 관리 서버 측 정책·디바이스 레코드·네트워크 경로 문제일 가능성이 높다. 장치 조인 상태(Azure AD Join/Hybrid Join), 중복 디바이스 오브젝트, 네트워크 프록시·방화벽 로그를 우선적으로 확인하는 것이 좋다.

VPN이나 Wi-Fi 인증 오류가 TPM Attestation과 직접 연관되어 있는가?

VPN·Wi-Fi가 TPM 기반 디바이스 인증서나 Windows Hello for Business 키를 사용하는 경우 Attestation 결과가 간접적 영향을 줄 수 있다. 디바이스 신뢰도가 낮다고 판단되면 특정 네트워크에 대한 접근이 제한될 수 있다.

ZeroError_holic

이 블로그 검색

Office 파일 손상되었습니다 오류 완전 해결 가이드(Word·Excel·PowerPoint 복구)