엔터프라이즈 패스키 배포의 과제와 해결책

1. 소개: 직원을 위한 엔터프라이즈 패스키의 운영 현실#

패스키가 워크포스 환경에 도입되었습니다. 이제 "이 기술이 작동하는가?"라는 질문은 의미가 없습니다. 대신 "이 기술을 어떻게 대규모로 운영할 것인가?"가 핵심 질문입니다. 마찰 지점은 이제 운영 계층으로 이동했습니다. 초기 등록(부트스트랩)의 "닭과 달걀" 문제, 디바이스 바운드 패스키와 동기화된 패스키 간의 차이, 크로스 플랫폼 상호 운용성, 그리고 보안에 취약한 비밀번호로 되돌아가지 않는 복구 메커니즘이 그것입니다.

이 가이드는 Microsoft Entra ID 환경에서 패스키를 배포할 때 발생하는 현실적인 과제를 다루며, 구성상의 함정, 운영 워크플로우 및 복구 전략을 살펴봅니다. 구체적으로 다음 질문들을 다루겠습니다.

1. Entra ID에서 디바이스 바운드 패스키와 동기화된 패스키의 차이점은 무엇인가요?
2. 비밀번호 없이 신규 직원을 위한 패스키를 어떻게 부트스트랩하나요?
3. 사용자가 새 스마트폰을 구매하여 인증 앱에 대한 액세스 권한을 상실한 경우 어떻게 복구하나요?
4. 패스키 등록 실패를 유발하는 구성 오류는 무엇인가요?
5. 피싱 방지 MFA를 요구할 때 B2B 게스트를 어떻게 처리하나요?
6. 하드웨어 보안 키(YubiKey)를 사용해야 할까요, 아니면 모바일 패스키를 사용해야 할까요?
7. 패스키 배포 시 Windows와 함께 macOS 디바이스를 어떻게 처리하나요?
8. 스마트폰 교체로 인한 헬프데스크의 과부하를 방지하기 위한 사전 조치는 무엇인가요?

2. Microsoft Entra의 패스키 이해하기#

Entra에서 "패스키" = FIDO2/WebAuthn 자격 증명입니다. 사용자는 비밀번호 대신 인증 장치(authenticator)에 저장된 **개인 키(private key)**의 소유를 증명합니다. WebAuthn이 자격 증명을 실제 로그인 출처(origin)와 바인딩하므로(즉, 유사하게 생긴 피싱 사이트에서 자격 증명을 재전송할 수 없으므로) 피싱 방지(phishing-resistant) 기능이 있습니다. Microsoft의 Passkeys (FIDO2) 개념 문서에서 개요를 확인하세요.

Entra는 효과적으로 다르게 작동하는 두 가지 "모드"의 패스키를 지원합니다.

2.1 Entra의 디바이스 바운드 패스키#

이 패스키는 하나의 물리적 디바이스에 연결됩니다(동기화 불가). 개인 키는 특정 하드웨어 요소(노트북의 TPM, YubiKey의 Secure Element 등)에 존재하며, 내보낼 수 없습니다.

Entra에서 디바이스 바운드 방식은 일반적으로 다음과 같이 변환됩니다.

• Microsoft Authenticator 패스키
• Windows Hello 또는 비즈니스용 Windows Hello(WHfB) 패스키 (2026년 1월 기준 동기화되지 않음)
• FIDO2 보안 키 (YubiKey와 같은 하드웨어 키)
• 스마트카드(Smartcards)

디바이스 바운드 패스키에 대한 Microsoft의 기본 설정 지침은 여기에서 확인할 수 있습니다: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

적용 사례: 높은 권한 액세스, "브레이크 글래스(break-glass)" 계정, 공유 워크스테이션 환경. 단점: 마찰이 큽니다. 디바이스를 분실하면 자격 증명도 잃게 됩니다. 또한 높은 운영 비용(예: YubiKey 배송)이 발생합니다.

2.2 Entra의 동기화된 패스키#

이는 공급자 생태계에 저장되고 사용자의 디바이스(예: iCloud 키체인, Google 비밀번호 관리자 또는 타사 공급자) 전반에 걸쳐 동기화되는 패스키입니다. 개인 키는 암호화되어 클라우드 공급자의 동기화 패브릭에 저장됩니다.

2026년 1월 기준, Entra에서 동기화된 패스키는 미리 보기(preview) 기능을 통해 처리됩니다: 동기화된 패스키(미리 보기). 동기화된 패스키를 활성화하고 제어하기 위해 Entra는 패스키 프로필(미리 보기)를 사용합니다.

규정 준수: 최근 NIST SP 800-63B Supplement 1에서 AAL2 요구 사항을 충족하는 것으로 검증되었습니다. 이는 동기화된 패스키가 일반적인 워크포스에서 사용할 수 있을 만큼 "피싱 방지" 기능이 충분함을 검증하는 대규모 규제 승인입니다.

적용 사례: 지식 근로자, BYOD 사용자, 경영진의 편의성. 단점: 하드웨어보다 "낮은" 보증을 제공합니다. 클라우드 공급자의 계정 복구 흐름에 대한 보안 의존도가 높습니다.

다음은 Entra에서 지원하는 동기화된 패스키 공급자의 개요입니다.

사용자의 보안 정보 페이지에서 동기화된 패스키와 디바이스 바운드 패스키는 명확하게 구분됩니다. 아래에서 동기화된 패스키(1Password)와 디바이스 바운드 패스키(YubiKey 5C NFC)가 어떻게 나타나는지 볼 수 있습니다.

2.3 규제 조정: NIST AAL 레벨#

• AAL3는 역사적으로 내보낼 수 없는 개인 키를 활용하는 하드웨어 기반, 디바이스 바운드 인증 장치(예: YubiKey 또는 스마트 카드)를 요구했습니다.
• AAL2는 이제 NIST 지침에 따라 동기화된 패스키로 달성할 수 있습니다.
• 뉘앙스: 동기화된 패스키(iCloud의 패스키 등)는 일반 사용자에게는 매우 훌륭하지만, 가장 높은 권한 수준에 대한 AAL3의 "내보내기 불가(non-exportability)" 요구 사항을 엄격하게 충족하지는 못할 수 있습니다. 따라서 세분화된 전략이 필요합니다. 관리자는 하드웨어 키(AAL3)를, 일반 워크포스는 동기화된 패스키(AAL2)를 사용합니다.

2.4 디바이스 준비 요구 사항#

디바이스가 피싱 방지 비밀번호 없는 인증을 지원할 준비가 되려면 다음 최소 버전을 실행해야 합니다.

오래된 운영 체제에서는 피싱 방지 비밀번호 없는 인증을 지원하기 위해 외부 인증 장치(FIDO2 보안 키)가 필요할 수 있습니다.

최소 버전 요구 사항 외에도, 브라우저 측 기능 지원 여부도 플랫폼마다 다릅니다. Corbado Passkey Benchmark 2026 WebAuthn 클라이언트 기능 분석에 따르면, 2026년 1분기 브라우저 지원은 Conditional Get 및 하이브리드 전송(Hybrid Transport)에 대해 97100%에 달하지만, 일반적인 소비자 브라우저 믹스에서 Conditional Create 지원은 8392%에 불과합니다. Windows Hello가 Conditional Create 경로가 아니며 Edge가 동일한 데이터세트에서 매우 낮은 Conditional Create 지원을 보고하기 때문에 이러한 제약은 Windows 환경에서 가장 큰 영향을 미칩니다. 이 벤치마크는 워크포스 환경보다는 B2C 배포를 다루고 있지만, 동일한 기본 브라우저/OS 기능 한계가 Entra ID 배포에도 여전히 적용됩니다. 엔터프라이즈 환경에서 Edge 사용자 비율이 높은 경우 전체 혼합 환경의 83~92% Conditional Create 범위보다 훨씬 낮아질 수 있습니다.

2.5 사용자 페르소나 자격 증명 권장 사항#

Microsoft는 자격 증명 배포에 있어 사용자 페르소나 기반 접근 방식을 권장합니다. 역할에 따라 보안 요구 사항과 허용 가능한 마찰 수준이 다릅니다.

이동식 자격 증명(Portable credentials) (디바이스 간 사용 가능):

로컬 자격 증명(Local credentials) (디바이스별 적용):

최종 목표: 대부분의 사용자는 최소 하나 이상의 이동식 자격 증명과 각 컴퓨팅 디바이스에 대한 로컬 자격 증명을 가져야 합니다.

3. 라이브 패스키 배포 경험#

패스키를 배포한 조직들과 이야기해 보면 몇 가지 실제 마찰 지점과 패턴이 확인됩니다.

3.1 운영상의 변화#

"문제는 기술 스택이 아니라 운영 계층에 있습니다." 이는 "패스키가 등록되지 않음" 오류나 개인 디바이스에서 Windows Hello 옵션이 표시되지 않는 등의 기술적 장애물이 고유한 이상 현상이 아니라 현재 생태계의 성숙도에 내재된 시스템적 마찰 지점임을 확인시켜 줍니다. 엔터프라이즈 운영의 경우 핵심은 모니터링에서 예상된 실패와 예상치 못한 실패를 분리하는 것입니다. WebAuthn 오류를 명시적으로 버킷화하고 NotAllowedError, AbortError 및 Credential Manager 패스키 오류를 고유한 신호로 추적하세요. 인증 분석 플레이북은 이러한 신호를 분류하기 위한 프레임워크를 제공하며, 패스키 분석은 활성화 및 로그인 비율과 같은 패스키별 KPI를 다룹니다.

3.2 등록: 성공과 실패를 가르는 순간#

등록은 배포 과정에서 가장 어려운 단계이며, 상당한 변경 관리가 필요합니다.

• 사전 등록의 복잡성: 이전에 자격 증명이 없는 신규 직원의 온보딩이 주요 병목 현상입니다. 관리자 매개 등록에 대한 의존성은 단절된 사용자 경험을 유발합니다.
• 플랫폼 파편화: 브라우저, 운영 체제 및 비밀번호 관리자의 독립적인 반복 업데이트로 인한 "단계에 대한 사용자 불만"이 발생합니다. 이로 인해 흐름이 Chrome/Windows에서는 작동하지만 Safari/macOS에서는 실패하거나 회사 디바이스에서는 성공하면서 관리되지 않는 개인 디바이스에서는 실패하는 등 일시적인 불일치가 발생합니다.

3.3 멘탈 모델의 격차#

"사용자는 암호화 기술이 아니라 멘탈 모델이 필요합니다." 다음과 같은 용어 혼란은 인지 부하를 야기합니다.

• 패스키 (Passkey)
• 보안 키 (Security Key)
• 하드웨어 키 (Hardware Key)
• YubiKey
• 비밀번호 없는 (passwordless)
• Windows 보안 (Windows Security)
• Windows Hello
• 비즈니스용 Windows Hello (WHfB)
• Microsoft Authenticator
• 휴대폰 로그인 (Phone Sign-in)

기술에 익숙하지 않은 사용자는 물론 기술에 밝은 사용자조차도 이 용어들의 차이점을 명확히 알기 어렵습니다.

최종 사용자 커뮤니케이션에서 "피싱 방지" 또는 "키 쌍(key-pair)"과 같은 전문 용어를 피하는 것을 권장합니다. 대신 스마트폰 잠금을 해제하는 것과 유사하게 "자신의 얼굴을 사용하여 엔터프라이즈 시스템의 잠금을 해제하세요"라는 "잠금 해제" 개념에 집중하세요.

3.4 커뮤니케이션의 한계#

초기에 강력한 채택을 이끌어내는 것이 성공에 매우 중요하지만, 커뮤니케이션만으로는 한계가 있습니다. 사용자에게 인증 방법을 확인하라는 이메일을 정기적으로 보낼 수는 없습니다. 일반적으로 사용자 행동을 잘 계획할 수는 없습니다. 이러한 현실 때문에 사용자 교육에만 의존하기보다는 선제적인 기술적 조치가 필요합니다.

4. Microsoft Entra ID 구성 딥 다이브#

엔터프라이즈 환경에 패스키를 배포하려면 상호 의존적인 정책을 이해하고 설정해야 합니다. 패스키는 모든 직원의 일상 업무에 큰 영향을 미치므로 단순히 켤 수 있는 기능이 아닙니다.

4.1 인증 방법 정책#

기존 MFA 및 SSPR 포털은 사용 중단(deprecated)되었습니다. 모든 FIDO2 구성은 통합된 인증 방법 정책(Authentication Methods Policy) 블레이드에서 수행되어야 합니다.

• FIDO2 보안 키 방식: 이 방법은 활성화되고 대상이 지정되어야 합니다. "모든 사용자(All Users)"를 활성화 대상으로 지정하되, 조건부 액세스를 통해 강제를 제어하는 것을 권장합니다.
• 키 제한(AAGUID): 모든 FIDO2 디바이스(예: YubiKey 5 NFC, iOS의 Microsoft Authenticator, Google 비밀번호 관리자)에는 고유한 **Authenticator Attestation GUID (AAGUID)**가 있습니다. 모범 사례로서 고보안 환경의 경우, "키 제한 적용(Enforce Key Restrictions)" 설정을 사용하여 승인된 특정 AAGUID만 **허용(Allow)**해야 합니다. 이를 통해 사용자가 저렴하고 확인되지 않은 "그레이 마켓(grey market)" 보안 키를 등록하는 것을 방지할 수 있습니다.

4.2 증명(Attestation): 중요한 결정 지점#

가장 중요한 구성 결정 중 하나는 **"증명 강제(Enforce Attestation)"**입니다.

• 기능: 인증 장치가 등록 중에 제조업체와 모델을 암호화 방식으로 Entra ID에 증명하도록 강제합니다.
• 충돌: 소프트웨어 기반이고 플랫폼에 구애받지 않기 때문에 소프트웨어 공급자(iCloud 키체인, Bitwarden 또는 Google 비밀번호 관리자 등)에 저장된 동기화된 패스키는 일반적으로 증명을 지원하지 않습니다. 하드웨어 일괄 인증서(hardware-batch certificate)로 챌린지에 서명할 수 없습니다.
• 트레이드오프:
  • 예(YES)로 설정: 높은 보증(AAL3)에 필요합니다. 키가 하드웨어 바운드임을 보장합니다. 소프트웨어 기반 패스키 공급자를 차단합니다.
  • 아니요(NO)로 설정: 동기화된 패스키를 허용합니다. 보증 수준이 약간 낮아집니다(AAL2). 소프트웨어 기반 패스키 공급자를 활성화합니다.

하드웨어 키가 필요한 권한이 높은 관리자가 있는 경우, 전역적으로 "증명 없음" 정책을 적용할 수 없습니다. 패스키 프로필(미리 보기)를 사용해야 합니다.

• 프로필 A (관리자): 증명 강제 = 예(Yes)
• 프로필 B (일반 직원): 증명 강제 = 아니요(No)

4.3 패스키 프로필 설명#

패스키 프로필은 다음을 정의하는 메커니즘으로 생각하세요.

• "이 사용자들은 동기화된 패스키를 사용할 수 있습니다"
• "이 사용자들은 디바이스 바운드만 사용해야 합니다"
• "증명 필요 대 필요 없음" (결과적으로: 동기화된 패스키 허용 대 제외)
• "특정 인증 장치 유형으로 제한(AAGUID 제한)"

아래에서 패스키 프로필을 구성하는 Microsoft Entra 관리 센터의 패스키(FIDO2) 설정 페이지를 볼 수 있습니다.

패스키 프로필을 편집할 때 증명 적용, 대상 유형(디바이스 바운드, 동기화 됨 또는 둘 다) 및 특정 AAGUID 제한을 구성할 수 있습니다.

4.4 조건부 액세스 및 인증 강도#

강제는 인증 강도(Authentication Strengths)를 활용하는 조건부 액세스(CA) 정책을 통해 처리될 수 있습니다.

• 피싱 방지 MFA 강도: 이 기본 제공 강도에서는 FIDO2, 비즈니스용 Windows Hello(WHfB) 또는 인증서 기반 인증(CBA)이 필요합니다.
• 잠금 함정(Lockout Trap): "모든 클라우드 앱"에 대해 "피싱 방지 MFA"를 요구하고 이를 "모든 사용자"에게 적용하는 CA 정책을 생성하면 아직 패스키를 등록하지 않은 모든 사용자가 즉시 차단됩니다. 패스키를 등록하기 위해 로그인조차 할 수 없게 됩니다.
• "보안 정보 등록" 역설: 이는 CA의 특정 사용자 작업입니다. 작업 보안 정보 등록(Register Security Information)을 수행하기 위해 피싱 방지 MFA를 요구하면 순환 종속성(닭과 달걀)이 생성됩니다. 등록 페이지에 액세스하려면 패스키가 필요하기 때문에 사용자는 첫 번째 패스키를 등록할 수 없습니다.

다음은 어떤 인증 방법이 어떤 강도 요구 사항을 충족하는지에 대한 개요입니다.

4.5 시스템 기본 인증#

Entra ID의 "시스템 기본 다단계 인증(System-preferred multifactor authentication)" 기능은 로그인 엔진이 사용자에게 가장 안전한 등록된 방법으로 인증하도록 유도합니다.

사용자가 SMS와 패스키를 모두 등록한 경우 시스템은 패스키를 기본값으로 설정합니다. 이는 하드 엔포스먼트 없이 유기적으로 패스키 채택을 촉진합니다. 기본적으로 사용자가 자격 증명을 등록하면 사용자의 보안 상태를 자동으로 "업그레이드"합니다.

아래에서 패스키 로그인 환경을 확인할 수 있습니다. 사용자에게 "얼굴, 지문, PIN 또는 보안 키"를 사용하라는 메시지가 표시되며 브라우저 확장 프로그램 또는 시스템 자격 증명 관리자에서 패스키를 선택할 수 있습니다.

4.6 macOS 고려 사항: Platform SSO#

Windows/macOS 혼합 환경을 사용하는 조직의 경우 macOS Platform SSO는 비즈니스용 Windows Hello와 동등한 Apple의 기능을 제공합니다. MDM 솔루션과 결합하면 다음을 달성할 수 있습니다.

• Mac의 Secure Enclave에 연결된 디바이스 바운드 자격 증명
• 네이티브 앱 및 웹 앱 전반에 걸친 SSO 경험
• AAL2/AAL3 요구 사항을 충족하는 피싱 방지 인증

참고: macOS Platform SSO에는 macOS 13 이상과 적절한 MDM 구성이 필요합니다. 설정은 Windows WHfB와 크게 다르므로 별도의 배포 트랙을 계획하세요.

5. 일반적인 구성 오류: 왜 "Microsoft Authenticator에서만 작동"하는가?#

목표가 관리되지 않는 디바이스에서의 동기화된 패스키라면 다음과 같은 요소들이 가장 일반적인 차단 원인입니다.

5.1 동기화된 패스키가 활성화되지 않았거나 대상이 지정되지 않음#

Entra에서 단순히 "FIDO2"를 일반적으로 활성화하는 것만으로는 충분하지 않습니다. 동기화된 패스키의 경우 일반적으로 다음이 필요합니다.

• 동기화된 패스키(미리 보기)에 설명된 미리 보기 기능 경로
• 패스키 프로필을 사용하는 프로필 구성

그룹이 동기화된 패스키를 허용하는 프로필의 대상이 되지 않으면 다시 "디바이스 바운드 전용" 환경으로 돌아가게 됩니다.

5.2 증명 적용(동기화된 패스키 차단)#

이 부분은 보안을 중시하는 조직에서 가장 많은 질문을 유발합니다.

• Entra는 일부 패스키 시나리오에 대해 **증명(attestation)**을 요구할 수 있습니다(인증 장치 유형/출처 확인에 도움).
• 동기화된 패스키는 Entra에서 증명을 지원하지 않으므로, 증명이 적용되면 동기화된 패스키 등록에 실패하고 디바이스 바운드 옵션만 남게 됩니다.

5.3 AAGUID 허용 목록이 공급자를 차단함#

Entra에서는 허용되는 인증 장치를 제한할 수 있습니다(종종 AAGUID 허용/차단 목록을 통해). Microsoft Authenticator(또는 제한된 인증 장치 세트)만 허용 목록에 추가하면 타사 동기화된 공급자가 암시적으로 차단될 수 있습니다. 혼란스러운 부분은 로컬 인증(예: Touch ID, Face ID, Windows 생체 인식 스캔)은 작동하지만 Entra 로그인 페이지에 오류가 표시된다는 것입니다.

5.4 조건부 액세스로 특정 패스키 유형 강제#

패스키가 활성화되어 있더라도 조건부 액세스는 사용자에게 자격 증명의 하위 집합을 강제할 수 있습니다(예: "Authenticator 전용" 또는 의도한 패스키 프로필을 허용하지 않는 강도 구성). 실제로는 계획이 동기화된 패스키임에도 불구하고 "Authenticator 의존성"을 생성하게 됩니다.

5.5 B2B 게스트 대 멤버 계정#

외부 파트너가 리소스 테넌트의 B2B 게스트 사용자인 경우 인증 방법을 등록할 수 있는 위치/방법과 관련하여 알려진 제한 사항이 있습니다. 이것이 파트너가 우리 테넌트에서 패스키를 사용하도록 하려는 의도임에도 "왜 작동하지 않지"라는 숨겨진 불만이 자주 발생하는 원인입니다.

6. 운영상의 과제 및 해결책#

6.1 부트스트랩 역설#

가장 광범위한 문제("등록이 가장 어렵다")는 부트스트랩 문제입니다. 현재 자격 증명이 없는(또는 보증 수준이 낮은 자격 증명만 있는) 사용자에게 어떻게 보증 수준이 높은 자격 증명을 안전하게 발급할 것인가?

6.1.1 임시 액세스 패스(TAP)#

임시 액세스 패스(Temporary Access Pass, TAP)는 비밀번호 없는 온보딩을 위한 아키텍처 접근 방식입니다.

• 개요: Entra ID가 "강력한 인증" 방법으로 취급하는 시간 제한이 있는(예: 1시간) 엔트로피가 높은 패스코드입니다. 비밀번호나 기존 MFA의 필요성을 우회합니다.
• 워크플로우:
  1. 신원 확인: 신규 직원의 신원이 확인됩니다(예: HR 프로세스 또는 관리자 확인을 통해).
  2. 발급: 관리자(또는 자동화된 Logic App)가 사용자를 위해 TAP를 생성합니다.
  3. "매직" 로그인: 사용자가 aka.ms/mysecurityinfo로 이동합니다. 사용자 이름과 TAP를 입력합니다.
  4. 등록: TAP가 "강력한 인증" 요구 사항을 충족하므로 사용자가 보안 정보 블레이드에 액세스할 수 있습니다. "방법 추가"를 클릭하고 패스키를 등록합니다.
  5. 안정 상태: TAP가 만료됩니다. 사용자는 이제 피싱 방지 자격 증명을 가지게 됩니다. 비밀번호는 한 번도 입력하지 않았습니다.

6.1.2 Graph API를 통한 자동화#

대규모 조직의 경우 수동 TAP 발급은 확장이 불가능합니다. 모범 사례는 Microsoft Graph API를 통한 자동화입니다.

• 시나리오: 신규 입사자가 HR 시스템(Workday/SuccessFactors)에서 처리됩니다.
• 트리거: 프로비저닝 이벤트가 Azure Logic App을 트리거합니다.
• 작업: Logic App이 Graph API POST /users/{id}/authentication/temporaryAccessPassMethods를 호출합니다.
• 전달: TAP가 안전하게 사용자의 채용 관리자나 개인 이메일(암호화됨)로 전달되어 출근 첫날 액세스에 사용됩니다.

6.1.3 높은 보증 수준의 온보딩을 위한 Microsoft Entra Verified ID#

원격 온보딩이나 높은 신원 보증이 필요한 시나리오의 경우, Face Check가 포함된 Microsoft의 Entra Verified ID를 사용하면 첫 로그인부터 비밀번호 없는(passwordless-first) 등록 경로를 제공합니다.

1. 신원 증명: 신규 사용자는 IDV 파트너(정부 신분증 스캔)를 통해 신원을 확인합니다.
2. 생체 인식 매칭: Face Check는 Azure AI Vision을 사용하여 실시간 셀피를 신분증 사진과 비교합니다. 일치 신뢰도 점수만 공유됩니다(원시 생체 데이터 없음).
3. 확인된 자격 증명 발급: 사용자는 Verified ID 자격 증명을 받습니다.
4. TAP 발급: 확인이 성공적으로 완료되면 시스템에서 임시 액세스 패스(TAP)를 발급합니다.
5. 패스키 부트스트랩: 사용자는 TAP를 사용하여 첫 번째 패스키를 등록합니다.

Face Check 흐름은 인증(자격 증명 공유), 확인(얼굴 스캔 수행) 및 검토(일치 결과 확인)의 세 단계로 사용자를 안내합니다.

이 흐름을 통해 출근 첫날부터 진정한 비밀번호 없는 계정이 가능합니다. 비밀번호가 생성되지 않습니다.

6.2 스마트폰 교체 문제(숨겨진 규모의 과제)#

이는 패스키 배포에서 가장 큰 헬프데스크 문의의 원인이 되는 경우가 많습니다. 대규모 BYOD 인력을 보유한 조직(예: 10,000대 이상의 디바이스)에서는 사용자가 새 스마트폰을 구매하고 인증 방법을 다시 등록하는 프로세스를 모르는 것만으로도 엄청난 수의 지원 문의를 받을 수 있습니다.

여기에 패스키가 도입되면 상황은 더욱 심각해집니다.

• 사용자가 새 스마트폰에 앱(예: Outlook)을 설치합니다.
• 이 앱에서 인증을 묻는 메시지가 표시됩니다.
• MFA 프롬프트가 이전 스마트폰에 나타납니다(이미 보상 판매를 하거나 초기화했을 수 있음).
• 사용자가 차단되어 헬프데스크에 문의합니다.

6.2.1 스마트폰 교체 시나리오 매트릭스#

목표는 가능한 한 많은 경우를 상위 두 행으로 이동하여 헬프데스크의 개입을 최소화하는 것입니다.

6.2.2 Intune 등록 트릭#

기발한 통찰: Intune 등록에 패스키를 요구하면 사용자가 회사 앱에 액세스하기 전에 즉시 새 휴대폰에서 Microsoft Authenticator 설정을 완료해야 합니다.

• 현재: Intune 등록에는 MFA 승격(step-up)이 필요합니다. 즉, 새 스마트폰에서 로그인하려면 거기에 Outlook을 설치해야 합니다. 그러나 MFA 프롬프트는 이전 스마트폰으로 이동합니다.
• 패스키 요구 시: 등록을 완료하려면 사용자가 먼저 새 스마트폰에서 Microsoft Authenticator 패스키를 설정해야 합니다. 이는 이전 스마트폰이 사라진 몇 달 후가 아니라 즉시(스마트폰 교체 당일) 발생합니다.

이는 복구 문제를 해결하지는 못하지만 타임라인을 앞당깁니다. 사용자는 이전 디바이스에 계속 액세스할 수 있는 동안 새 디바이스를 등록합니다.

6.3 물류 문제가 따르는 하드웨어 보안 키#

하드웨어 키(YubiKey 등)가 보편적인 해결책으로 여겨질 때가 있습니다. 이론적으로는 그렇지만 현실적으로는 더 많은 문제가 발생합니다.

• 물류의 악몽: 과거 물리적 토큰(예: RSA SecurID)을 배포했던 조직들은 이를 제거하기 위해 수년을 보냈습니다. 한 물리적 토큰 프로그램을 다른 프로그램으로 교체하는 것은 매력적이지 않습니다.
• 드롭 쉬핑(Drop-shipping): Yubico는 사용자에게 직접 키를 배송할 수 있으며, 이 키들은 (SecurID와 달리) 몇 년마다 배터리를 교체할 필요가 없습니다. 하지만 누군가 키를 잊어버리면 (공유 데스크톱의 경우) 로그인할 수 없습니다.
• 현지 IT의 부담: 현지 감독자가 분실된 키에 대해 사실상 IT 지원 부서 역할을 해서는 안 됩니다.
• 비용: 하드웨어 키는 인원수에 비례하여 사용자당 비용을 추가합니다.

하드웨어 키가 적합한 경우:

• Tier 0 관리자: 도메인 관리자, "브레이크 글래스(break-glass)" 계정
• 공유 워크스테이션: 키오스크 환경, 공장, 현장 태블릿
• BYOD를 사용하지 않는 계약직 직원: 개인 디바이스를 사용하지 않는 외부 사용자

6.4 관리되지 않는 디바이스의 과제#

많은 사용자가 개인 디바이스에서 패스키 사용 옵션을 볼 수 없다고 불만을 제기합니다. 이는 전형적인 "관리되지 않는 디바이스"의 마찰 지점입니다.

6.4.1 "패스키가 등록되지 않음" 오류 분석#

회사 디바이스에서는 등록이 잘 되는데, 개인 디바이스에서는 사용자가 패스키를 추가하지 못할 수 있습니다. 이는 등록 흐름과 상호 작용하는 Intune 규정 준수 정책(Compliance Policies) 때문일 가능성이 높습니다.

• 메커니즘: 비즈니스용 Windows Hello(WHfB)는 플랫폼 자격 증명입니다. 이는 특정 디바이스의 TPM에 바인딩됩니다(디바이스 바운드 패스키).
• 제약 조건: WHfB를 등록하려면 디바이스가 일반적으로 테넌트에 조인(Entra 조인 또는 하이브리드 조인)되어야 합니다. 단순히 "등록된"(작업 공간 조인) 개인 디바이스는, 완전히 관리되거나 규정을 준수하지 않는 경우 Intune을 통해 적용된 정책 제한으로 인해 WHfB 컨테이너 프로비저닝이 차단될 수 있습니다. FIDO2 보안 키 로그인 요구 사항을 참조하세요.
• "패스키" 옵션: 개인 디바이스의 경우, 사용자는 비즈니스용 Windows Hello가 아니라 FIDO2 보안 키(로밍) 또는 크로스 디바이스 패스키(휴대폰에 있음) 등록을 시도해야 합니다(BYOD 등록이 완전히 지원되는 경우 제외).
• Entra ID 표시 문제: "Windows Hello"가 옵션으로 표시되지 않으면, 디바이스가 필수 MDM 등록을 완료하지 않은 것입니다.

6.4.2 크로스 디바이스 인증(CDA) 실패#

관리되지 않는 디바이스에서 사용자는 종종 크로스 디바이스 인증(CDA) 흐름(휴대폰으로 PC의 QR 코드 스캔)을 시도합니다.

• Bluetooth 종속성: CDA는 PC와 휴대폰 모두에 Bluetooth가 활성화되어 있어야 합니다. 이들을 페어링할 필요는 없지만 인접성을 증명하기 위해 BLE(Bluetooth Low Energy) 핸드셰이크를 수행해야 합니다. 자세한 내용은 Microsoft Authenticator의 디바이스 바운드 패스키를 검토하세요.
• 회사 정책 차단 요인: "보안"을 위해 BIOS나 GPO를 통해 회사 노트북의 Bluetooth가 비활성화된 경우, 로밍 패스키의 기본 메커니즘을 이미 망가뜨린 것입니다.
• Websocket 차단: CDA 흐름은 cable.ua5v.com 또는 cable.auth.com에 대한 websocket 연결을 사용합니다. 공격적인 기업 방화벽이나 Zscaler 구성이 이러한 도메인을 차단하여 QR 코드 스캔이 멈추거나 조용히 실패하는 경우가 많습니다. Microsoft Authenticator 패스키 문서를 참조하세요.

6.5 B2B 및 외부 ID#

엔터프라이즈의 또 다른 고충은 외부 컨설턴트(B2B 게스트)를 처리하는 것입니다.

• 문제: 컨설턴트가 SharePoint 사이트에 액세스하려고 합니다. 테넌트는 "피싱 방지 MFA"를 요구하는 조건부 액세스 정책을 시행합니다.
• 실패: 컨설턴트가 리소스 테넌트에 FIDO2 키를 등록하려고 시도합니다. 이 작업은 실패합니다. Entra ID는 리소스 테넌트에서 FIDO2 키를 등록하는 게스트 사용자를 지원하지 않습니다.
• 수정: 교차 테넌트 액세스 설정
  • 로직: 게스트가 귀하의 테넌트에 자격 증명을 등록하도록 강제하는 대신, 그들의 테넌트에서 사용하는 자격 증명을 신뢰해야 합니다.
  • 구성: _외부 ID > 교차 테넌트 액세스 설정_으로 이동합니다. 파트너 조직을 선택합니다. 인바운드 신뢰에서 **"Microsoft Entra 테넌트의 다단계 인증 신뢰"**를 선택합니다.
  • 결과: 컨설턴트가 홈 테넌트에서 YubiKey를 사용하여 로그인할 때 귀하의 테넌트는 "MFA 충족 + 피싱 방지"라는 클레임을 수신합니다. 사용자가 테넌트에 아무것도 등록할 필요 없이 액세스 권한이 부여됩니다. 이 기능은 파트너에게 자격 증명 수명 주기 관리를 아웃소싱하여 귀하의 책임과 헬프데스크 부하를 줄여줍니다.

7. 복구 전략#

복구에 대한 결정은 실제 배포보다 지연되는 경우가 많습니다. 조직의 요구 사항에 따라 여러 복구 옵션이 존재합니다.

7.1 Verified ID를 통한 셀프 서비스 계정 복구(SSAR)#

Microsoft Entra ID의 새로운 셀프 서비스 계정 복구(SSAR) 흐름(미리 보기)을 사용하면 헬프데스크 개입 없이 높은 수준의 보증 복구가 가능합니다.

1. 트리거: 사용자가 로그인할 수 없습니다. "내 계정 복구"를 선택합니다.
2. 신원 확인: 사용자는 타사 IDV(Identity Verification) 공급자(예: Onfido, IDemia)로 리디렉션됩니다.
3. 문서 확인: 사용자는 모바일 카메라를 사용하여 실제 운전면허증, 주민등록증 또는 여권을 스캔합니다.
4. 라이브니스 체크: 사용자가 셀피 Face Check를 수행합니다. 이 정보는 신분증(및 잠재적으로 Entra ID에 저장된 사진)과 대조됩니다. 매칭에는 Azure AI Vision Face API가 사용되며 신뢰도 점수만 공유됩니다. 애플리케이션에 원시 생체 데이터가 전달되지 않습니다.
5. 복원: 성공하면 시스템은 사용자에게 **임시 액세스 패스(TAP)**를 자동으로 발급합니다.
6. 재등록: 사용자는 TAP를 사용하여 즉시 새 패스키를 등록합니다.

권장 사항: 이 자동화된 생체 인식 기반 복구 경로는 소셜 엔지니어링(딥페이크 음성 공격)에 취약한 "헬프데스크 전화하기"보다 우수합니다.

7.2 My Staff를 사용한 관리자 지원 복구#

서비스 데스크 부하를 줄이고 싶지만 완전한 셀프 서비스를 활성화할 수 없는 경우, Microsoft Entra에는 My Staff라는 기본 위임된 관리 기능이 포함되어 있습니다.

• 작동 방식: Entra의 관리 단위를 통해 "팀 관리자"에게 제한된 권한을 위임합니다.
• 흐름: 사용자가 액세스 권한을 잃은 경우 위임된 로컬 관리자에게 연락할 수 있으며, 이 관리자는 비밀번호 재설정 또는 전화번호 업데이트와 같이 지원되는 복구 작업을 위해 My Staff 포털을 사용할 수 있습니다.
• 도움이 되는 이유: 중앙 헬프 데스크에서 일반적인 계정 복구 작업을 덜어주고 지원 속도를 높여줍니다.

7.3 셀프 서비스 복구 키오스크(인트라넷)#

사용자들은 여전히 신뢰할 수 있고 WHfB로 보호되는 노트북을 가지고 있는 경우가 많으므로, 간단한 "브레이크 글래스" 인트라넷 페이지를 구축할 수 있습니다.

• 구축: WHfB 로그인(강력한 인증)이 필요한 간단한 내부 웹 앱입니다.
• 작업: 인증이 완료되면 사용자는 "새 휴대폰이 있습니다"를 클릭합니다. 앱은 백그라운드 서비스인 Microsoft Graph API를 사용하여 수명이 짧은 임시 액세스 패스(TAP)를 생성하고 화면에 표시합니다.
• 결과: 사용자는 해당 TAP를 새 스마트폰에 입력하여 Microsoft Authenticator 앱을 부트스트랩합니다. 헬프데스크 개입은 전혀 없습니다.

이것은 정책을 약화시키지 않으면서 "명확한 인증 방법" 재설정을 줄이는 핵심 레버입니다. 노트북을 부트스트랩으로 사용하는 강력한 메커니즘이 있다면 사용자가 완벽한 순서를 몰라도 스스로 복구할 수 있으므로 커뮤니케이션 부담이 크게 줄어듭니다.

8. 엔터프라이즈 패스키 배포를 위한 권장 사항#

**성숙도 단계(Maturity Stages)**를 중심으로 롤아웃을 구성하세요. 마찰("기술은 준비되었지만 운영은 어렵다")을 인정하고 이러한 완화 방법을 적용하세요.

8.1 즉각적인 조치 ("수정" 단계)#

1. Bluetooth 및 방화벽 감사: 회사 노트북이 Bluetooth(인접성 확인용)를 허용하는지 확인하고 크로스 디바이스 실패를 수정하기 위해 FIDO/WebAuthn 릴레이 도메인(\*.cable.auth.com)을 허용 목록에 추가합니다.
2. 교차 테넌트 신뢰 활성화: 게스트 패스키를 직접 등록하려고 시도하지 마세요. 주요 파트너의 MFA에 대한 인바운드 신뢰를 구성하여 B2B 액세스 문제를 즉시 해결합니다.
3. 온보딩을 위한 TAP 구현: "닭과 달걀" 등록 차단 문제를 해결하기 위해 모든 신규 사용자 온보딩 시 임시 액세스 패스 사용을 의무화합니다.

8.2 전략적 결정 ("아키텍처" 단계)#

1. "하이브리드 보증" 모델 채택:
   • Tier 0 (관리자): 증명 및 키 제한을 강제합니다. YubiKey/하드웨어만 허용됩니다(AAL3).
   • Tier 1 (워크포스): 패스키 프로필을 통해 증명 강제를 비활성화합니다. 동기화된 패스키를 허용하여 마찰과 비용을 줄입니다(AAL2).
2. macOS 계획: Windows WHfB와 병행하는 트랙으로서 MDM과 함께 Platform SSO를 배포합니다.

8.3 미래 대비 ("최적화" 단계)#

1. SSAR 계획: 헬프데스크를 소셜 엔지니어링 벡터에서 제거하기 위해 Verified ID를 사용한 셀프 서비스 계정 복구(SSAR) 시범 운영을 시작합니다.
2. 시스템 기본 인증: 이 정책을 활성화하여 사용자가 패스키를 등록하는 즉시 자동으로 패스키로 "업그레이드"하여 강제 조치 없이 채택을 유도합니다.
3. 복구 옵션 배포: My Staff를 통한 관리자 지원 TAP 및/또는 셀프 서비스 복구 키오스크를 구현합니다.
4. Intune 패스키 요구 사항: 새 디바이스에서 조기 등록을 강제하기 위해 Intune 등록 시 패스키를 요구하는 것을 고려합니다.

8.4 문제 해결 매트릭스#

9. Phishing-Resistant Passwordless Workbook을 통한 배포 모니터링#

Microsoft는 Azure Monitor에 로그가 있는 조직이 롤아웃 진행 상황을 추적하는 데 사용할 수 있는 Phishing-Resistant Passwordless Workbook을 출시했습니다. Entra 관리 센터의 **모니터링(Monitoring) > 통합 문서(Workbooks)**에서 액세스하세요.

이 통합 문서는 두 가지 주요 섹션으로 나뉩니다.

9.1 등록 준비 단계 (Enrollment Readiness Phase)#

이 탭을 사용하여 로그인 로그를 분석하고 등록 준비가 완료된 사용자 대 차단될 가능성이 있는 사용자를 파악할 수 있습니다. OS 플랫폼(Windows, macOS, iOS, Android) 및 자격 증명 유형(Authenticator 앱 패스키, FIDO2 보안 키, 인증서 기반 인증)별로 필터링할 수 있습니다.

통합 문서에는 다음이 표시됩니다.

• 등록 준비가 된 사용자/디바이스 쌍(User/Device Pairs Ready for Enrollment): 선택한 자격 증명 유형을 등록할 수 있는 사용자
• 준비되지 않은 사용자/디바이스 쌍(User/Device Pairs Not Ready): 등록 문제가 있을 수 있는 사용자(예: 오래된 OS 버전)

해결 조치(예: OS 업그레이드, 디바이스 교체 또는 대체 자격 증명 옵션)가 필요한 사용자 목록을 내보낼 수 있습니다.

9.2 강제 준비 단계 (Enforcement Readiness Phase)#

사용자가 피싱 방지 전용 인증을 사용할 준비가 되면 Enforcement Readiness 탭을 사용합니다. 먼저, 피싱 방지 MFA를 요구하는 보고 전용(Report-Only) 조건부 액세스 정책을 생성합니다. 이렇게 하면 강제가 활성화되었을 경우 액세스가 _차단되었을지 여부_에 대한 데이터로 로그인 로그가 채워집니다.

대시보드에는 다음이 표시됩니다.

• 대상에 포함된 총 사용자(Total users)
• 보고 전용 성공(Report Only Success) - 강제를 통과할 사용자
• 정책이 충족되지 않음(Policy Not Satisfied) - 차단될 사용자(이 부분을 조사하세요!)
• 디바이스 상태, 디바이스 플랫폼 및 클라이언트 앱 세부 정보

추가 데이터 분석(Further Data Analysis) 탭을 사용하여 특정 사용자가 차단되는 이유를 조사합니다. 이 데이터는 강제를 활성화하기 전에 수정 조치를 위한 사용자 타겟팅에 도움이 됩니다.

9.3 헬프 데스크 모니터링을 통한 웨이브 기반 롤아웃#

Microsoft는 유연한 날짜 범위를 가진 웨이브(wave) 형태로 배포를 실행할 것을 권장합니다. 헬프 데스크 티켓 볼륨을 신호로 삼아 모니터링하세요.

• 티켓 볼륨 증가: 배포, 커뮤니케이션 및 강제 조치 속도를 늦춥니다.
• 티켓 볼륨 감소: 활동을 다시 늘립니다.

각 웨이브에 대한 Microsoft Entra ID 보안 그룹을 생성하고 그룹을 정책에 점진적으로 추가합니다. 이렇게 하면 지원 팀이 과부하되는 것을 방지할 수 있습니다.

10. 동기화된 패스키 파일럿 체크리스트#

목표가 Microsoft Authenticator 의존성 없이 동기화된 패스키를 배포하는 것이라면 다음 파일럿 태세를 따르세요.

1. 동기화된 패스키(미리 보기) 활성화 동기화된 패스키(미리 보기)를 따릅니다.

2. 패스키 프로필(미리 보기) 사용 및 파일럿 그룹 지정 패스키 프로필에 설명된 대로 동기화된 패스키를 허용하는 프로필을 생성/할당합니다.

3. 증명을 강제하지 않음(최소한 파일럿 그룹의 경우) 패스키(FIDO2) 개념 문서에 따라 증명을 강제하면 동기화된 패스키가 제외됩니다.

4. 초기에 엄격한 AAGUID 허용 목록 피하기 흐름을 확인하기 위해 허용적으로 시작한 다음, 허용하려는 공급자를 확실히 파악하고 나면 제한을 강화합니다. 패스키(FIDO2) 활성화를 참조하세요.

5. 조건부 액세스가 Microsoft Authenticator를 강제하지 않는지 확인 CA/auth 강도가 사용자가 의도한 패스키 프로필을 여전히 허용하는지 확인합니다(그렇지 않으면 Microsoft Authenticator 의존성처럼 보입니다).

6. ID 모델(멤버 대 게스트) 검증 사용자가 게스트인 경우, 프로필 튜닝에 시간을 소비하기 전에 테넌트 모델에서 예상되는 지원 가능성을 확인합니다.

11. 결론#

엔터프라이즈 패스키 배포는 운영상 복잡하지만, 앞으로 나아갈 길은 잘 정의되어 있습니다. 위에서 제기된 주요 운영 질문들에 맞춰 정리된 핵심 답변은 다음과 같습니다.

1. 디바이스 바운드 대 동기화된 패스키: 디바이스 바운드 자격 증명(예: Microsoft Authenticator, Windows Hello, YubiKey, 스마트카드)은 단일 디바이스에 엄격하게 연결되며 AAL3을 충족합니다. 동기화된 패스키(예: iCloud 키체인, Google 비밀번호 관리자)는 디바이스 전반에 걸쳐 작동하며 AAL2를 충족합니다. 대부분의 조직에는 관리자를 위한 하드웨어 인증 장치(AAL3)와 더 광범위한 직원을 위한 동기화된 패스키(AAL2)가 모두 필요합니다.

2. 신규 직원 부트스트랩: 온보딩 시 닭과 달걀 문제를 해결하기 위해 임시 액세스 패스(TAP)를 사용합니다. 대규모 배포의 경우 Graph API를 통해 이 과정을 자동화합니다. 보증 수준이 높은 사용 사례의 경우 Entra Verified ID 및 Face Check를 통해 온보딩을 보완합니다.

3. 스마트폰 교체 복구: 셀프 서비스 복구 키오스크(노트북을 부트스트랩 디바이스로 사용), My Staff를 통한 관리자 지원 TAP, 예외 사례를 위한 Verified ID를 사용한 SSAR(셀프 서비스 계정 복구) 등 여러 복구 방법을 제공합니다.

4. 구성 오류: 가장 빈번한 오류에는 전역적으로 증명을 강제하는 것, 동기화된 패스키에 대한 미리 보기 기능을 활성화하지 않는 것, 지나치게 엄격한 AAGUID 허용 목록 및 순환 종속성을 생성하는 조건부 액세스(CA) 정책 등이 포함됩니다.

5. B2B 게스트: 귀하의 테넌트에서 B2B 게스트용 패스키를 직접 등록하지 마세요. 대신 교차 테넌트 액세스 신뢰를 활성화하여 게스트 홈 테넌트의 자격 증명을 검증하세요.

6. 하드웨어 키 대 모바일 패스키: 하드웨어 보안 키는 특정 높은 보안 역할(관리자, 공유 워크스테이션)에 필요하지만 대규모에서는 물류상의 장애물을 제시합니다. 모바일 패스키는 일반적으로 워크포스에 더 실용적입니다.

7. Windows와 함께 macOS 사용: JAMF/MDM과 함께 Platform SSO를 사용하여 Windows 배포와 병행하여 macOS에서 패스키 지원을 활성화합니다. 플랫폼별 워크플로우를 계획합니다.

8. 사전 조치: Intune을 사용하여 비활성 디바이스를 식별하고 잠금이 발생하기 전에 사용자가 조치하도록 유도합니다. 조기 채택을 촉진하기 위해 패스키 등록을 Intune 등록의 전제 조건으로 만드는 것을 고려하세요. 노트북을 부트스트랩 디바이스로 사용하는 셀프 서비스 복구 워크플로우를 구축하세요.

기술은 준비되었습니다. 주요 과제는 운영 실행입니다. 복구 계획은 나중에 덧붙이는 것이 아니라 초기부터 필수적인 부분이어야 합니다. 인프라가 견고해지면 패스키가 워크포스 전반의 기본 인증 방법이 되도록 패스키 로그인 채택을 최적화하는 데 집중하세요.

Corbado 소개

Corbado는 대규모로 consumer authentication을 운영하는 CIAM 팀을 위한 Passkey Intelligence Platform입니다. IDP 로그와 일반 analytics 도구가 보여주지 못하는 것을 볼 수 있게 해드립니다: 어떤 디바이스, OS 버전, 브라우저, credential manager가 passkey를 지원하는지, 왜 등록이 로그인으로 이어지지 않는지, WebAuthn 플로우가 어디서 실패하는지, OS나 브라우저 업데이트가 언제 조용히 로그인을 망가뜨리는지 — Okta, Auth0, Ping, Cognito 또는 자체 IDP를 교체하지 않고도 전부 파악할 수 있습니다. 두 가지 제품: Corbado Observe는 passkey 및 다른 모든 로그인 방식에 대한 observability를 더합니다. Corbado Connect는 analytics가 내장된 managed passkey를 제공합니다 (기존 IDP와 함께). VicRoads는 Corbado로 500만+ 사용자에게 passkey를 운영하고 있습니다 (passkey 활성화율 +80%). Passkey 전문가와 상담하기 →

자주 묻는 질문(FAQ)#

조건부 액세스에서 피싱 방지 MFA를 활성화하면 모든 사용자가 잠기는 이유는 무엇인가요?#

모든 클라우드 앱에 대해 피싱 방지 MFA를 요구하는 조건부 액세스 정책을 생성하면 보안 정보 등록 페이지 자체에 대한 액세스 차단을 포함하여 아직 패스키를 등록하지 않은 모든 사용자가 즉시 차단됩니다. '보안 정보 등록(Register Security Info)' 역설이라고 불리는 이 순환 종속성으로 인해, 사용자가 초기 등록을 완료할 수 있도록 강제를 활성화하기 전에 영향을 받는 사용자에게 임시 액세스 패스(Temporary Access Pass)를 발급해야 합니다.

내 테넌트에서 피싱 방지 MFA를 요구할 때 B2B 게스트 사용자를 어떻게 처리하나요?#

Entra ID는 리소스 테넌트에서 FIDO2 키를 등록하는 게스트 사용자를 지원하지 않으므로 게스트에게 패스키 등록을 강제하려고 하면 실패합니다. 올바른 해결 방법은 외부 ID에서 교차 테넌트 액세스 설정을 구성하여 게스트 홈 테넌트의 MFA 클레임을 신뢰하는 것입니다. 즉, 자신의 조직에서 사용되는 YubiKey가 테넌트 내 등록 없이 피싱 방지 MFA 요구 사항을 만족시킵니다.

패스키로 로그인할 때 크로스 디바이스 QR 코드 인증이 조용히 실패하는 원인은 무엇인가요?#

크로스 디바이스 인증(Cross-Device Authentication)은 BLE 인접성 핸드셰이크를 완료하기 위해 PC와 휴대폰 모두에 Bluetooth가 활성화되어 있어야 하므로 Bluetooth를 비활성화하는 모든 회사 정책은 흐름을 완전히 차단합니다. 이 흐름은 또한 cable.auth.com에 대한 WebSocket 연결을 사용하는데, 방화벽이나 Zscaler 구성에서 이를 차단하는 경우가 많아 명확한 오류 메시지 없이 QR 코드 스캔이 중단되거나 실패할 수 있습니다.

피싱 방지 MFA 강제를 켜기 전에 어떤 직원이 준비되었는지 어떻게 모니터링하나요?#

Entra 관리 센터의 모니터링 > 통합 문서(Monitoring > Workbooks)를 통해 액세스할 수 있는 Microsoft의 피싱 방지 비밀번호 없는 통합 문서(Phishing-Resistant Passwordless Workbook)는 플랫폼 및 자격 증명 유형별로 등록할 수 있는 사용자/디바이스 쌍을 보여주는 등록 준비 보기(Enrollment Readiness view)를 제공합니다. 강제 준비를 확인하려면 피싱 방지 MFA가 필요한 보고 전용 조건부 액세스 정책을 생성하여, 라이브 강제를 활성화하기 전에 차단될 사용자를 로그인 로그를 통해 확인하세요.

직원이 새 스마트폰을 구매하여 패스키에 대한 액세스를 잃은 경우 최선의 복구 전략은 무엇인가요?#

권장되는 접근 방식은 계층화되어 있습니다. WHfB로 보호되는 노트북을 사용하는 셀프 서비스 복구 키오스크는 Graph API를 통해 임시 액세스 패스(TAP)를 생성하며 헬프데스크의 개입 없이 대부분의 경우를 커버합니다. 노트북이 없는 사용자의 경우 My Staff 포털을 통한 관리자 지원 TAP는 직속 관리자에게 복구를 위임하며, Entra Verified ID 생체 인식 Face Check를 통한 셀프 서비스 계정 복구(SSAR)는 완전한 신원 재확인이 필요한 엣지 케이스를 처리합니다.

추가 읽기#

엔터프라이즈 FIDO2/패스키 배포에 대한 심층적인 정보를 얻으려면 Microsoft Entra 인증에 대한 실용적인 지침을 정기적으로 게시하는 Merill Fernando 및 **Jan Bakker**와 같은 전문가를 팔로우하세요.