Cloudflare Access 패스키 지원: 로그인 전환 전에 정책·복구·세션을 점검하기

본인 확인과 애플리케이션 접근 정책을 두 관문으로 표현한 생성형 에디토리얼 이미지. 실제 제품 화면이나 인증 프로토콜을 나타내지는 않는다.

사내 도구에 들어갈 때마다 이메일 코드를 찾는 일이 번거로웠다면 새로운 선택지가 생겼다. Cloudflare는 November 6, 2026 Access로 보호한 애플리케이션과 App Launcher에 패스키 로그인을 추가했다고 발표했다. 기기·보안 키·비밀번호 관리자에 저장한 패스키를 이용하며, 등록 전에 기존 로그인 수단으로 본인을 확인한다. 공식 발표

운영자가 먼저 확인할 것은 로그인 속도보다 기존 접근 정책과 복구 경로다. 로그인 화면에 새 버튼이 보인다는 이유만으로 기존 SSO를 없애면 안 된다.

1. IdP 그룹 조건을 먼저 찾는다

공식 문서는 패스키 인증이 다른 IdP의 그룹이나 사용자 지정 속성을 가져오지 않는다고 설명한다. 패스키 등록·인증 후에도 Access 정책 평가를 통과해야 한다. 패스키 문서

예를 들어 테스트용 관리 도구가 회사 IdP의 Engineering 그룹을 요구한다고 하자. 같은 사람이 같은 이메일로 패스키를 등록했더라도, 이전 IdP 로그인과 동일한 그룹 정보가 전달된다고 가정할 수 없다. 이를 확인하지 않고 로그인 수단을 바꾸면 정상 사용자가 거절되는 상황이 생길 수 있다.

이때 해결책을 이메일 도메인 전체 허용으로 단순화하지 않는다. 로그인 문제를 고치려다 접근 대상을 넓힐 수 있기 때문이다. 먼저 정책에서 그룹·사용자 속성에 의존하는 항목을 찾아 현재 로그인 방식과 함께 기록한다. 해당 조건이 필요한 앱은 기존 IdP 경로를 유지한 채 별도로 검토하는 편이 안전하다.

2. 작은 앱에서 두 설정을 확인한다

설정 경로는 Zero Trust → Integrations → Identity providers → Passkeys다. 제공자를 추가한 뒤 대상 앱의 Login methods도 확인한다. 모든 IdP를 허용하지 않는 앱은 Passkeys를 선택해야 하며, App Launcher는 Authentication 탭에서 허용한다. 자동 브라우저 프롬프트는 선택 사항이다. 설정 안내

첫 적용 대상으로는 복구가 쉬운 테스트 앱 하나가 적당하다. 아래 내용은 제품의 필수 절차가 아니라 운영 전 검증을 위한 제안이다.

• 변경 전 로그인 방법과 접근 정책을 기록한다.

• 허용 사용자와 거절 대상인 테스트 사용자를 구분한다.

• 기존 로그인 경로를 남겨 둔 상태에서 패스키를 시험한다.

• 자동 프롬프트보다 수동 선택 흐름을 먼저 확인한다.

• 정책을 바꾸는 작업과 로그인 수단을 추가하는 작업을 나누어 결과를 비교한다.

둘을 동시에 바꾸면 실패 원인이 인증 수단인지 정책인지 구분하기 어렵다.

3. 등록 성공과 앱 접근 성공을 따로 검증한다

인증기는 discoverable credential과 사용자 확인을 지원해야 한다. 패스키만 허용한 앱에서는 등록 중 이메일 확인 코드가 사용된다. 따라서 기존 메일 접근과 복구 절차까지 검토해야 한다. 등록 조건

한 번의 성공 화면보다 다음 네 가지 결과가 더 유용하다.

1. 정상 접근: 허용 사용자가 새 로그인으로 의도한 앱에 들어가는지 확인한다.

2. 거절 유지: 허용하지 않은 사용자가 패스키를 등록했더라도 앱에는 들어가지 못하는지 확인한다.

3. 그룹 의존 경로: 그룹 기반 앱을 기존 IdP와 패스키로 각각 시험하고 정책 판단 차이를 기록한다.

4. 복구 경로: 패스키를 사용할 수 없는 테스트 상황에서 대체 로그인이나 관리자 지원 경로가 실제로 작동하는지 확인한다.

기존 브라우저 세션이 남아 있으면 새 인증을 시험했다고 착각할 수 있다. 새 로그인 시험과 이미 로그인된 세션 시험을 구분하고, 어떤 계정·앱·방법으로 확인했는지 남긴다. 원문 토큰이나 복구 코드를 기록할 필요는 없다.

이 목록은 실행할 검증 계획이다. 이 글에서 실제 계정의 패스키 등록이나 운영 앱 접근 시험을 수행한 것은 아니다.

4. 분실 대응에서는 세션도 확인한다

등록된 패스키 삭제는 이후 로그인을 막는다. 이미 열린 Access 세션을 끝내려면 세션 회수가 별도로 필요하다. 패스키 삭제의 범위

Access는 앱 단위 또는 사용자 단위의 세션 회수를 제공한다. 공식 세션 문서는 인증 주체가 여전히 유효하면 새 세션을 만들 수 있다고 설명한다. 세션 회수 문서

분실한 테스트 기기를 가정하면 확인할 질문은 세 가지다. 해당 패스키로 다시 로그인할 수 있는가, 기존 세션으로 계속 접근할 수 있는가, 다른 허용 로그인 수단으로 새 세션을 만들 수 있는가. 각각 다른 결과이므로 하나의 “차단 완료” 표시로 합치지 않는다.

실제 사고 대응에서는 영향 범위를 확인한 뒤 자격 증명·세션·접근 정책을 함께 검토해야 한다. 패스키 하나를 삭제한 것과 특정 사용자의 모든 접근을 차단한 것은 별도 작업이다.

5. 전환 완료의 기준을 정한다

내부 도구의 이메일 코드 입력을 줄이는 데는 유용한 변화다. 다만 기업 IdP의 그룹 정책에 의존하는 앱은 전환 판단이 더 복잡하다. 새 로그인 성공률뿐 아니라 정상 사용자의 거절, 비인가 접근 차단, 분실 복구와 세션 회수까지 확인한 뒤 적용 범위를 늘리는 것이 좋다.

브라우저·운영체제·인증기 조합은 실제 사용 환경에서 확인해야 한다. 공식 발표만으로 모든 환경의 호환성이나 기존 MFA 규칙 충족을 단정하지 않는다. 이 글은 MFA 정책 변경을 권하는 안내도 아니다.

확인 기준: November 7, 2026 한국 시간. 공개된 Cloudflare 공식 발표와 문서를 바탕으로 작성했다. 계정 설정 변경, 자격 증명 생성, 결제 또는 운영 서비스 검증은 수행하지 않았다.