패스키 도입 2026, 기업 로그인 전환·분실 대응·운영 기준

패스키 도입 기업 전환 회의와 보안키 검토 장면 — 패스키 전환은 인증 방식만 바꾸는 일이 아니라 계정 복구와 운영 통제를 다시 설계하는 일이다.

비밀번호를 없애자는 말은 쉽지만 기업 환경에서는 분실 대응, 예외 계정, 모바일 등록, 헬프데스크 권한까지 같이 정리해야 한다.

패스키 도입은 FIDO2와 WebAuthn 기반의 인증 전환이므로 로그인 UX보다 먼저 신뢰 경계와 복구 절차를 설계해야 한다.

이 글은 Microsoft Entra와 Google, FIDO, NIST 문서를 기준으로 파일럿 순서와 운영 판단표를 정리한 실무 검토 메모다.

핵심 요약

패스키는 서버에 비밀번호 비밀값을 저장하지 않고 공개키 검증으로 로그인 신뢰를 만든다.
이 조건이면 검토 대상은 피싱 피해가 잦은 임직원 계정과 관리자 계정부터 잡는 편이 안전하다.
이 경우는 보류가 낫다: 공용 단말, 계정 공유 관행, 복구 승인권자 부재가 동시에 남아 있는 조직이다.
성공 기준은 등록률보다 분실 신고, 기기 교체, 퇴사자 회수, 예외 계정 로그까지 닫히는지다.

패스키 도입을 먼저 검토할 조직

관리자와 개발자가 여러 SaaS 콘솔에 로그인하고 SMS OTP 피로도가 커진 조직
피싱 메일 훈련에서 비밀번호와 일회용 코드 입력 사고가 반복되는 조직
SSO와 MFA는 이미 쓰지만 계정 복구 절차가 사람 승인에 과도하게 의존하는 조직
고객 로그인에서 비밀번호 재설정 문의와 장바구니 이탈을 줄이고 싶은 서비스팀
보안키, 모바일 인증기, 브라우저 동기화 패스키를 어떤 범위로 허용할지 정해야 하는 IAM 담당자

공식 문서 기준으로 보는 패스키의 경계

Google Developers는 패스키를 웹사이트나 앱 계정에 묶인 디지털 자격 증명으로 설명하며 사용자는 지문, 얼굴, PIN, 패턴 같은 기기 잠금 해제로 로그인한다.

FIDO Alliance는 passkey를 특정 플랫폼 기능명이 아니라 FIDO 표준 기반의 암호학적 자격 증명이라고 정의한다.

W3C WebAuthn은 브라우저와 플랫폼이 공개키 자격 증명 생성과 검증을 다루는 표준 계층을 제공한다.

서버는 비밀번호 원문이나 재사용 가능한 비밀값 대신 공개키와 자격 증명 식별자를 저장하므로 침해 시 공격자가 바로 로그인 재료를 가져가기 어렵다.

브라우저와 운영체제는 등록된 사이트와 앱의 신뢰 경계를 확인하므로 가짜 도메인에서 같은 패스키로 인증시키는 피싱 시나리오를 줄인다.

다만 동기화형 패스키는 비밀번호 관리자와 계정 복구 체계에 의존하므로 조직 정책은 저장 위치와 복구 권한을 함께 정해야 한다.

확인 축	실무 판단	보류 신호	확인 출처
인증 강도	관리자·재무·개발자 계정부터 파일럿을 잡고 SMS OTP 의존을 줄인다.	SMS와 비밀번호 재설정 링크가 여전히 최종 복구 수단이면 범위를 좁힌다.	Google Passkeys, FIDO Alliance
저장 위치	플랫폼 동기화 패스키와 하드웨어 보안키를 계정 등급별로 나눈다.	개인 비밀번호 관리자만 허용하면서 퇴사 회수 흐름이 없으면 보류한다.	Google supported environments
관리 콘솔	Microsoft Entra Authentication methods 정책에서 대상 그룹과 등록 경로를 제한한다.	전사 전체를 첫날 켜고 헬프데스크 시나리오가 없으면 실패 확률이 높다.	Microsoft Learn
감사 증거	등록·로그인·실패 로그와 기기 교체 이력을 월간 리뷰 항목에 넣는다.	등록률만 보고 피싱 저항성이나 복구 리스크를 보지 않으면 안 된다.	NIST SP 800-63B

도입 전 판단표: 바로 켤 계정과 기다릴 계정

패스키 도입의 순서는 기술 준비도보다 계정 위험도와 복구 책임의 명확성으로 정하는 편이 안전하다.

계정 유형	이 조건이면 진행	이 경우는 보류	운영 질문
클라우드 관리자	SSO와 조건부 액세스가 있고 예비 보안키를 배정할 수 있다.	개인 휴대폰 분실 시 즉시 대체 인증을 줄 사람이 없다.	퇴근 후 긴급 복구 승인자는 누구인가.
개발자·DevOps	Git, 클라우드 콘솔, CI 권한이 분리되어 있고 보안키 보관 정책이 있다.	개인 장비와 회사 장비의 브라우저 동기화 경계가 불명확하다.	퇴사 당일 패스키 등록 상태를 어떻게 확인하는가.
일반 임직원	파일럿 부서가 있고 my sign-ins 등록 교육을 짧게 진행할 수 있다.	헬프데스크가 전화 본인확인만으로 복구를 열어준다.	기기 교체 주간에 문의량을 감당할 수 있는가.
고객 로그인	WebAuthn 구현과 계정 복구 UX를 A/B로 검증할 수 있다.	비밀번호 제거만 앞세우고 이메일 복구 보안은 그대로 둔다.	가입 전환율과 복구 악용률을 같이 볼 수 있는가.

이 조건이면 1차 파일럿은 전사 공지보다 관리자 그룹 20~50명 수준의 제한된 집단으로 시작하는 편이 낫다.

이 경우는 보류한다: 공유 계정이 남아 있고 계정 주인이 명확하지 않은 서비스 운영 계정에 먼저 패스키를 붙이는 접근이다.

Microsoft Entra 기준 파일럿 절차

Microsoft Learn의 확인일 기준 흐름은 Authentication methods 정책에서 Passkey (FIDO2)를 켜고 대상 그룹과 세부 제한을 정하는 방식이다.

Entra 관리자는 먼저 테스트 그룹을 만들고 전역 관리자 계정이 아니라 별도 파일럿 관리자 계정으로 정책을 검토한다.
Microsoft Entra admin center에서 Protection, Authentication methods, Policies 경로로 이동해 Passkey (FIDO2) 정책을 확인한다.
정책 상태를 Enable로 바꾸기 전에 Target에서 테스트 그룹만 지정하고 전사 All users는 선택하지 않는다.
하드웨어 보안키를 허용할 경우 허용할 키 종류와 분실 신고 절차를 문서화하고 예비 키 지급 기준을 정한다.
Authenticator 저장 패스키를 허용할 경우 사용자 모바일 등록 조건과 회사 관리 단말 요구 여부를 보안팀이 승인한다.
파일럿 사용자는 mysignins.microsoft.com/security-info에서 sign-in method를 추가하고 등록 완료 화면을 캡처하지 않고 상태만 보고한다.
첫 로그인 검증은 정상 로그인, 새 기기 로그인, 분실 신고, 임시 액세스 패스, 퇴사자 권한 회수 순서로 진행한다.
로그 검토자는 로그인 로그에서 passkey/FIDO2 성공과 실패 원인을 주간으로 확인하고 예외 계정 목록을 남긴다.

공식 콘솔 메뉴와 명칭은 테넌트 정책 상태에 따라 달라질 수 있으므로 변경 전 Microsoft Learn 원문과 현재 관리 센터 화면을 같이 확인한다.

실무 시나리오 1: 피싱 위험이 큰 관리자 그룹

실무 시나리오 첫 번째는 클라우드 관리자와 결재 승인자가 같은 비밀번호 기반 로그인 흐름을 쓰는 조직이다.

이 조건이면 보안키 기반 패스키를 1차로 지급하고 모바일 동기화 패스키는 업무폰 관리 정책이 잡힌 뒤 열어두는 편이 안전하다.

운영팀은 패스키 등록 성공률보다 비상 접근권, 예비 보안키 보관, 야간 장애 대응 승인 흐름을 먼저 점검해야 한다.

관리자 계정은 편의성보다 회수 가능성과 감사 증거가 우선이므로 개인 계정 동기화에 모든 신뢰를 맡기면 안 된다.

실무 시나리오 2: 공유 단말과 고객센터 계정

실무 시나리오 두 번째는 교대 근무자가 같은 단말에서 고객 정보 시스템에 접속하는 콜센터나 현장 운영팀이다.

이 경우는 보류가 낫다: 개인 생체 잠금과 회사 계정의 소유자가 섞이고 근무자 변경 때 등록 해지가 누락될 가능성이 크다.

먼저 해야 할 일은 계정 공유 제거, 개인별 SSO 적용, 세션 타임아웃, 관리자 승인 없는 복구 차단이다.

패스키는 공유 계정을 합법화하는 도구가 아니며 계정 주인을 분리한 뒤 마지막 인증 계층으로 붙여야 한다.

실무 시나리오 3: 고객 서비스의 비밀번호 재설정 감소

실무 시나리오 세 번째는 고객용 웹 서비스에서 비밀번호 재설정 문의와 SMS 코드 실패가 전환율을 갉아먹는 상황이다.

Google 문서 기준으로 패스키는 계정 선택과 기기 잠금 해제를 통해 사용자 입력 부담을 줄이고 SMS 코드 의존도도 낮출 수 있다.

서비스팀은 패스키 등록 버튼을 크게 만드는 것보다 기존 비밀번호 사용자와 신규 패스키 사용자가 함께 통과하는 복구 흐름을 먼저 설계해야 한다.

고객용 서비스는 브라우저, 운영체제, 비밀번호 관리자 조합이 넓으므로 지원 환경 표를 공개 도움말에 별도로 둔다.

지출·보안·운영 리스크 체크리스트

패스키 자체는 표준 인증 방식이지만 기업 도입에서는 장치 지급, 헬프데스크 교육, 로그 검토 시간이 실제 투입 항목으로 남는다.

리스크	확인 질문	놓치면 생기는 문제	담당
분실 대응	보안키와 휴대폰을 잃어버린 사용자는 어떤 증거로 복구하는가.	헬프데스크가 사회공학 공격의 새入口가 된다.	IAM·헬프데스크
동기화 경계	개인 비밀번호 관리자에 회사 계정 패스키를 저장해도 되는가.	퇴사 뒤 개인 장치에 남은 인증 경로를 늦게 발견한다.	보안팀·법무
예외 계정	서비스 계정과 공유 계정은 패스키 대상에서 제외했는가.	사람 인증 정책을 기계 계정에 억지로 적용한다.	운영팀
감사 로그	등록, 삭제, 실패, 복구 이벤트를 월간으로 누가 본다는 원칙이 있는가.	전환 완료 뒤 실제 사고 징후를 놓친다.	보안관제
사용자 교육	등록 화면과 복구 금지 행위를 5분 안에 설명할 수 있는가.	사용자는 새 인증을 불편한 MFA 하나로 받아들인다.	IT 운영

NIST SP 800-63B 관점에서는 인증기는 발급, 유지, 무효화의 전 생애주기를 관리해야 하므로 등록만 성공했다고 끝난 것이 아니다.

보안팀은 피싱 저항성만 보고 전사 적용을 밀어붙이지 말고 복구 이벤트가 공격 표면으로 바뀌는 지점을 별도 리스크로 봐야 한다.

정책 스켈레톤: 파일럿 전에 채울 문서

아래 예시는 그대로 적용하는 설정 파일이 아니라 조직 내부 검토 항목을 빠뜨리지 않기 위한 스켈레톤이다.

# passkey-rollout-policy.yml
rollout_scope:
  phase_1_group: identity-admin-pilot
  max_users: 50
  excluded_accounts:
    - shared_service_accounts
    - break_glass_accounts
allowed_authenticators:
  hardware_security_key:
    enabled: true
    spare_key_required_for_admins: true
  platform_passkey:
    enabled: pilot_only
    managed_device_required: true
recovery_rules:
  helpdesk_phone_only_recovery: blocked
  temporary_access_pass:
    approvers_required: 2
    expiry_hours: 8
audit_events:
  - passkey_registered
  - passkey_removed
  - passkey_signin_failed
  - recovery_method_changed
monthly_review:
  owner: iam_security_team
  evidence_retention_months: 12

개발팀이 고객 서비스에 WebAuthn을 붙일 때는 기술 구현보다 등록 해제와 복구 실패 상태를 먼저 테스트 케이스로 만든다.

// webauthn_rp_inventory.json
{
  "relying_party_id": "login.example.com",
  "user_verification": "required",
  "attestation_policy": "documented_before_enforcement",
  "account_recovery": {
    "email_only_allowed": false,
    "step_up_required": true,
    "manual_review_for_high_risk": true
  },
  "logging": [
    "credential_create_success",
    "credential_create_error",
    "assertion_success",
    "assertion_error",
    "recovery_started"
  ]
}

파일럿 종료 전에는 등록자 수가 아니라 사용 가능한 복구 경로와 로그 가시성을 자동 점검하는 작은 스크립트를 붙이는 편이 좋다.

# passkey_readiness_check.py
required_controls = {
    "pilot_group_defined": True,
    "break_glass_excluded": True,
    "spare_key_for_admins": True,
    "phone_only_recovery_blocked": True,
    "signin_logs_reviewed": True,
    "offboarding_check_added": True,
}

failed = [name for name, ok in required_controls.items() if not ok]
if failed:
    raise SystemExit("passkey rollout blocked: " + ", ".join(failed))
print("passkey pilot can proceed with documented controls")

파일럿 성공 기준과 중단 기준

성공 기준은 등록률 90% 같은 단일 숫자가 아니라 정상 로그인, 기기 교체, 분실 신고, 퇴사자 회수, 예외 계정 로그가 모두 검증되는 상태다.

중단 기준도 미리 써둔다: 복구 요청이 폭증하거나 관리자 계정 예비 인증기가 부족하거나 특정 브라우저 조합에서 실패가 반복되면 확산을 멈춘다.

이 조건이면 2차 확산이 가능하다: 헬프데스크가 전화만으로 인증기를 초기화하지 않고 관리자가 예외 승인을 로그로 남기는 흐름이 정착된 상태다.

이 경우는 보류한다: 등록은 잘됐지만 복구 승인권자가 한 명이고 야간 장애 상황에서 우회 정책을 문서 없이 임시로 여는 조직이다.

단계	통과 기준	중단 기준	증거
1주차	파일럿 그룹 전원이 등록·로그인·삭제 절차를 시연했다.	등록 실패 원인이 브라우저 호환성인지 정책인지 구분하지 못한다.	테스트 체크리스트
2주차	분실 신고와 임시 접근권 발급 절차가 30분 안에 재현됐다.	전화 확인만으로 복구가 열리는 예외가 생긴다.	헬프데스크 티켓
3주차	퇴사·전보 계정에서 패스키 등록 상태 회수 확인이 끝났다.	계정 소유자와 장치 소유자가 일치하지 않는다.	IAM 변경 로그
4주차	보안팀이 실패 로그와 위험 로그인 이벤트를 정례 리뷰에 넣었다.	등록률 보고만 있고 실패 원인 분석이 없다.	월간 보안 리뷰