---
url: 'https://www.corbado.com/vi/blog/thach-thuc-trien-khai-passkey-doanh-nghiep'
title: 'Các Thách Thức & Giải Pháp Triển Khai Passkey Trong Doanh Nghiệp'
description: 'Triển khai passkey trên quy mô lớn trong Microsoft Entra ID. Bao gồm các thách thức đăng ký, passkey đồng bộ vs gắn liền thiết bị, chiến lược khôi phục và khắc phục lỗi.'
lang: 'vi'
author: 'Vincent Delitz'
date: '2026-05-22T13:43:37.659Z'
lastModified: '2026-10-03T06:06:17.227Z'
keywords: 'passkey đồng bộ entra, fido2 doanh nghiệp, temporary access pass'
category: 'Passkeys Strategy'
---

# Các Thách Thức & Giải Pháp Triển Khai Passkey Trong Doanh Nghiệp

## Key Facts

- **NIST SP 800-63B Supplement 1** xác nhận các passkey đồng bộ (synced passkey) đáp ứng
  các yêu cầu AAL2, giúp chúng có khả năng chống phishing đủ tốt để sử dụng cho lực lượng
  lao động phổ thông mà không cần khóa phần cứng.
- **Temporary Access Pass (TAP)** giải quyết nghịch lý bootstrapping (khởi tạo): một mật
  mã có thời hạn giúp nhân viên mới đăng ký passkey mà không bao giờ cần đặt mật khẩu.
- Việc bắt buộc **attestation (chứng thực)** trong Microsoft Entra ID sẽ chặn tất cả các
  passkey đồng bộ. Hãy sử dụng Passkey Profiles để áp dụng nó một cách có chọn lọc: bắt
  buộc đối với quản trị viên, vô hiệu hóa đối với nhân viên thông thường.
- Một **mô hình bảo đảm phân lớp (segmented assurance model)** là rất cần thiết: khóa phần
  cứng đáp ứng AAL3 cho quản trị viên và các vai trò đặc quyền, trong khi passkey đồng bộ
  cung cấp AAL2 cho toàn bộ lực lượng lao động.

## 1. Giới thiệu: thực tế vận hành passkey cho nhân viên trong doanh nghiệp

Passkey đã chính thức có mặt trong lực lượng lao động. Câu hỏi không còn là "công nghệ này
có hoạt động không?". Câu hỏi bây giờ là "chúng ta vận hành nó ở quy mô lớn như thế nào?".
Các điểm nghẽn đã chuyển sang lớp vận hành: vấn đề "con gà và quả trứng" của việc đăng ký
ban đầu (bootstrapping), sự khác biệt giữa passkey gắn liền với thiết bị (device-bound) và
passkey đồng bộ (synced), khả năng tương tác chéo nền tảng và các cơ chế khôi phục không
quay lại sự kém an toàn của mật khẩu.

Hướng dẫn này giải quyết những thách thức thực tế khi triển khai passkey trong môi trường
Microsoft Entra ID, bao gồm các cạm bẫy cấu hình, quy trình vận hành và chiến lược khôi
phục. Cụ thể, chúng tôi sẽ giải quyết các câu hỏi sau:

1. Sự khác biệt giữa passkey gắn liền thiết bị và passkey đồng bộ trong Entra ID là gì?
2. Làm cách nào để khởi [tạo passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) cho nhân
   viên mới mà không cần mật khẩu?
3. Người dùng khôi phục như thế nào khi họ có điện thoại mới và mất quyền truy cập vào
   trình [xác thực](https://www.corbado.com/vi/blog/trien-khai-webauthn-server) của mình?
4. Những lỗi cấu hình nào gây ra việc đăng ký
   [passkey thất bại](https://www.corbado.com/vi/blog/tai-sao-trien-khai-passkey-that-bai)?
5. Làm cách nào để xử lý người dùng khách B2B khi yêu cầu
   [MFA](https://www.corbado.com/vi/faq/superannuation-funds-passkeys) chống [phishing](https://www.corbado.com/glossary/phishing)?
6. Tôi có nên sử dụng
   [khóa bảo mật phần cứng](https://www.corbado.com/vi/blog/khoa-bao-mat-phan-cung-fido2-tot-nhat-2025) (YubiKey)
   hay passkey trên thiết bị di động?
7. Làm cách nào để xử lý các thiết bị macOS song song với Windows trong đợt triển khai
   passkey?
8. Những biện pháp chủ động nào giúp ngăn chặn bộ phận helpdesk bị quá tải do việc thay
   đổi điện thoại?

## 2. Hiểu về passkey trong Microsoft Entra

Trong Entra, **"passkey" = chứng danh FIDO2/WebAuthn**. Thay vì mật khẩu, người dùng chứng
minh quyền sở hữu một **khóa riêng tư (private key)** được lưu trữ trong một trình xác
thực. Nó có khả năng **chống phishing** vì WebAuthn liên kết chứng danh với nguồn gốc đăng
nhập thực tế (do đó một trang web lừa đảo trông giống hệt không thể phát lại nó). Xem tổng
quan của Microsoft trong
[tài liệu khái niệm Passkeys (FIDO2)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2).

Entra hỗ trợ hiệu quả **hai "chế độ" của passkey** hoạt động khác nhau.

### 2.1 Passkey gắn liền thiết bị (Device-bound) trong Entra

Các passkey này được **gắn với một thiết bị vật lý duy nhất** (không thể đồng bộ). Khóa
riêng tư tồn tại trên một thành phần phần cứng cụ thể (TPM trên laptop, Secure Element
trên [YubiKey](https://www.corbado.com/glossary/yubikey)). Nó không thể xuất ra ngoài.

Trong Entra, câu chuyện gắn liền thiết bị thường chuyển thành:

- **Passkey trong Microsoft Authenticator**
- Passkey **Windows Hello** hoặc **Windows Hello for Business (WHfB)** (không đồng bộ kể
  từ tháng 1 năm 2026)
- **Khóa bảo mật FIDO2** (khóa phần cứng như [YubiKey](https://www.corbado.com/glossary/yubikey))
- **Thẻ thông minh (Smartcard)**

Hướng dẫn thiết lập cơ bản của Microsoft cho passkey gắn liền thiết bị có thể được tìm
thấy tại đây:
[https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2)

**Các trường hợp sử dụng:** Truy cập quyền cao, tài khoản "phá vỡ rào cản" (break-glass),
môi trường máy trạm dùng chung. **Nhược điểm:** Ma sát cao. Mất thiết bị đồng nghĩa với
mất chứng danh. Chi phí vận hành cao (ví dụ: vận chuyển [YubiKey](https://www.corbado.com/glossary/yubikey)).

### 2.2 Passkey đồng bộ (Synced) trong Entra

Đây là các passkey được lưu trữ trong hệ sinh thái của một nhà cung cấp và được đồng bộ
trên các thiết bị của người dùng (ví dụ: [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain),
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) hoặc các nhà cung cấp
[bên thứ ba](https://www.corbado.com/vi/blog/nha-cung-cap-passkey)). Khóa riêng tư được mã hóa và lưu trữ trong
cơ sở hạ tầng đồng bộ của nhà cung cấp đám mây.

Kể từ tháng 1 năm 2026, trong Entra, các passkey đồng bộ được xử lý thông qua **tính năng
xem trước (preview)**:
[Synced passkeys (preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys).
Để kích hoạt và kiểm soát passkey đồng bộ, Entra sử dụng
[Passkey Profiles (preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles).

**Mức độ phù hợp với quy định:** Gần đây đã được
[NIST SP 800-63B](https://www.corbado.com/faq/nist-sp-800-63b-supplement-passkey-adoption) Supplement 1 xác nhận
là đáp ứng các yêu cầu **AAL2**. Đây là một chiến thắng lớn về mặt quy định xác nhận rằng
các passkey đồng bộ đủ "chống [phishing](https://www.corbado.com/glossary/phishing)" cho việc sử dụng rộng rãi
trong lực lượng lao động.

**Các trường hợp sử dụng:** Nhân viên văn phòng (knowledge worker), người dùng BYOD, sự
tiện lợi cho cấp điều hành. **Nhược điểm:** Mức độ đảm bảo "thấp hơn" so với phần cứng.
Phụ thuộc vào tính [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) của luồng
[khôi phục tài khoản](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) của nhà cung cấp
đám mây.

Dưới đây là tổng quan về các
[nhà cung cấp passkey](https://www.corbado.com/vi/blog/nha-cung-cap-xac-thuc-passkey-giup-tiet-kiem-100000-usd)
đồng bộ được Entra hỗ trợ:

| Nhà cung cấp passkey                                     | Windows                               | macOS                                 | iOS                            | Android                                                    |
| -------------------------------------------------------- | ------------------------------------- | ------------------------------------- | ------------------------------ | ---------------------------------------------------------- |
| Apple Passwords (iCloud Keychain)                        | Không hỗ trợ                          | Được tích hợp sẵn. macOS 13+          | Được tích hợp sẵn. iOS 16+     | Không hỗ trợ                                               |
| Google Password Manager                                  | Tích hợp trong Chrome                 | Tích hợp trong Chrome                 | Tích hợp trong Chrome. iOS 17+ | Được tích hợp sẵn (ngoại trừ thiết bị Samsung). Android 9+ |
| Các nhà cung cấp passkey khác (VD: 1Password, Bitwarden) | Kiểm tra tiện ích mở rộng trình duyệt | Kiểm tra tiện ích mở rộng trình duyệt | Kiểm tra ứng dụng. iOS 17+     | Kiểm tra ứng dụng. Android 14+                             |

Trong trang Security Info của người dùng, passkey đồng bộ và passkey gắn liền thiết bị
được phân biệt rõ ràng. Dưới đây bạn có thể thấy cách một passkey đồng bộ (từ
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)) và một passkey gắn liền
thiết bị (YubiKey 5C NFC) hiển thị:

![cài đặt tài khoản passkey](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_account_settings_946c956180.png)

### 2.3 Điều chỉnh theo quy định: Các cấp độ AAL của NIST

- **AAL3** theo lịch sử yêu cầu các trình [xác thực](https://www.corbado.com/vi/blog/trien-khai-webauthn-server)
  **dựa trên phần cứng, gắn liền thiết bị** (như YubiKey hoặc
  [Smart Card](https://www.corbado.com/glossary/smart-card)) sử dụng một khóa riêng tư không thể xuất.
- **AAL2** hiện nay có thể đạt được với passkey đồng bộ theo hướng dẫn của
  [NIST](https://www.corbado.com/blog/nist-passkeys).
- **Sự khác biệt tế nhị:** Mặc dù các passkey đồng bộ (như trong iCloud) rất tuyệt vời cho
  người dùng tiêu chuẩn, nhưng chúng có thể không đáp ứng nghiêm ngặt yêu cầu "không thể
  xuất" của [AAL3](https://www.corbado.com/blog/nist-passkeys) đối với các cấp độ đặc quyền cao nhất. Do đó, một
  **chiến lược phân lớp** là cần thiết: Khóa phần cứng cho Quản trị viên (AAL3), Passkey
  đồng bộ cho lực lượng lao động (AAL2).

### 2.4 Yêu cầu về độ sẵn sàng của thiết bị

Để đảm bảo các thiết bị đã sẵn sàng cho [xác thực không mật khẩu](https://www.corbado.com/vi/glossary/ctap) chống
[phishing](https://www.corbado.com/glossary/phishing), chúng phải chạy các phiên bản tối thiểu này:

| Nền tảng | Phiên bản Tối thiểu                                   | Ghi chú                                                    |
| -------- | ----------------------------------------------------- | ---------------------------------------------------------- |
| Windows  | 10 22H2 (cho WHfB), 11 22H2 (cho UX passkey tốt nhất) | Các phiên bản cũ hơn có thể yêu cầu khóa bảo mật FIDO2     |
| macOS    | 13 Ventura                                            | Yêu cầu cho Khóa Secure Enclave Platform SSO               |
| iOS      | 17                                                    | Yêu cầu cho đồng bộ passkey và luồng chéo thiết bị         |
| Android  | 14                                                    | Yêu cầu cho passkey đồng bộ; phiên bản cũ cần khóa bảo mật |

Các hệ điều hành cũ hơn có thể yêu cầu trình
[xác thực](https://www.corbado.com/vi/blog/trien-khai-webauthn-server) bên ngoài (khóa bảo mật
[FIDO2](https://www.corbado.com/glossary/fido2)) để hỗ trợ [xác thực không mật khẩu](https://www.corbado.com/vi/glossary/ctap) chống
phishing.

Ngoài các yêu cầu về phiên bản tối thiểu, hỗ trợ khả năng từ phía trình duyệt cũng khác
nhau tùy theo nền tảng. Theo
[phân tích khả năng máy khách WebAuthn của Corbado Passkey Benchmark 2026](https://www.corbado.com/passkey-benchmark-2026/webauthn-client-capabilities),
trong Quý 1 năm 2026, hỗ trợ của trình duyệt đạt 97–100% cho Conditional Get và Hybrid
Transport nhưng chỉ đạt 83–92% cho [Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys)
trên các trình duyệt tiêu dùng thông thường — một hạn chế tác động mạnh nhất đến Windows
vì [Windows Hello](https://www.corbado.com/glossary/windows-hello) không phải là đường dẫn
[Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys), và đặc biệt là Edge báo cáo hỗ
trợ [Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys) rất thấp trong cùng tập dữ
liệu. Benchmark này bao gồm các đợt triển khai B2C hướng tới người tiêu dùng thay vì môi
trường doanh nghiệp, nhưng các giới hạn khả năng trình duyệt/HĐH cơ bản đó vẫn áp dụng cho
các đợt triển khai Entra ID; các nhóm người dùng Edge
[nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ều trong doanh nghiệp có thể rơi xuống
dưới mức 83–92% của Conditional Create.

### 2.5 Các khuyến nghị về chứng danh theo persona người dùng

Microsoft khuyến nghị một **cách tiếp cận dựa trên persona (chân dung) người dùng** cho
việc triển khai chứng danh. Các vai trò khác nhau có các yêu cầu
[bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) và mức độ ma sát chấp nhận được khác
nhau:

**Chứng danh di động (Portable credentials)** (có thể được sử dụng trên
[nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ều thiết bị):

| Persona Người Dùng                          | Được Khuyến Nghị   | Lựa Chọn Thay Thế                                         |
| ------------------------------------------- | ------------------ | --------------------------------------------------------- |
| Quản trị viên và người dùng bị quản lý chặt | Khóa bảo mật FIDO2 | Passkey trong Microsoft Authenticator, Smart Card         |
| Lực lượng lao động không phải quản trị viên | Passkey đồng bộ    | Khóa bảo mật FIDO2, Passkey trong Microsoft Authenticator |

**Chứng danh cục bộ (Local credentials)** (cụ thể cho từng thiết bị):

| Persona Người Dùng       | Windows       | macOS                                     | iOS                                  | Android                              |
| ------------------------ | ------------- | ----------------------------------------- | ------------------------------------ | ------------------------------------ |
| Quản trị viên            | WHfB hoặc CBA | Khóa Secure Enclave Platform SSO hoặc CBA | Passkey trong Authenticator hoặc CBA | Passkey trong Authenticator hoặc CBA |
| Không phải quản trị viên | WHfB          | Khóa Secure Enclave Platform SSO          | Passkey đồng bộ                      | Passkey đồng bộ                      |

Mục tiêu cuối cùng: Hầu hết người dùng nên có ít nhất một chứng danh **di động** cùng với
các chứng danh **cục bộ** trên mỗi thiết bị máy tính.

## 3. Kinh nghiệm từ các đợt Triển Khai Passkey thực tế

Khi trao đổi với các tổ chức đã triển khai passkey, một số điểm nghẽn và mô hình thực tế
đã được ghi nhận.

### 3.1 Sự dịch chuyển trong vận hành

**"Những thách thức không nằm ở stack công nghệ mà ở lớp vận hành."** Điều này xác nhận
rằng các rào cản kỹ thuật như lỗi "Passkey chưa được đăng ký" hoặc sự biến mất của các tùy
chọn [Windows Hello](https://www.corbado.com/glossary/windows-hello) trên thiết bị cá nhân không phải là những
điểm bất thường độc nhất mà là những điểm nghẽn hệ thống vốn có của sự trưởng thành hiện
tại của hệ sinh thái. Đối với hoạt động doanh nghiệp, điều cốt lõi là tách biệt các thất
bại được dự đoán trước và các thất bại không mong đợi trong giám sát. Nhóm các lỗi
WebAuthn một cách rõ ràng và theo dõi `NotAllowedError`, `AbortError` và các
[lỗi passkey](https://www.corbado.com/vi/blog/khac-phuc-su-co-passkey-giai-phap) của Credential Manager như những
tín hiệu riêng biệt. Cẩm nang phân tích xác thực của chúng tôi cung cấp một khuôn khổ để
phân loại các tín hiệu này, và
[phân tích passkey](https://www.corbado.com/vi/blog/kha-nang-quan-sat-xac-thuc-ciam) bao gồm các KPI dành riêng
cho passkey như tỷ lệ kích hoạt và đăng nhập.

### 3.2 Đăng ký: thời điểm "thành bại"

Đăng ký là giai đoạn khó khăn nhất của việc triển khai, đòi hỏi quản lý thay đổi (change
management) đáng kể.

- **Sự phức tạp trước khi đăng ký:** Đào tạo nhân viên mới những người không có chứng danh
  trước đó là nút thắt cổ chai chính. Việc phụ thuộc vào đăng ký do quản trị viên làm
  trung gian tạo ra một trải nghiệm người dùng rời rạc.
- **Sự phân mảnh nền tảng:** "Sự thất vọng của người dùng với các bước" do các bước lặp
  lại độc lập của trình duyệt, Hệ điều hành và
  [trình quản lý mật khẩu](https://www.corbado.com/vi/blog/kiem-thu-trinh-quan-ly-mat-khau-ben-thu-ba-cho-passkey-tren-ung-dung-goc).
  Điều này dẫn đến sự không nhất quán tạm thời, nơi một quy trình hoạt động trên
  Chrome/Windows nhưng lại thất bại trên Safari/macOS hoặc thất bại trên các thiết bị cá
  nhân không được quản lý trong khi thành công trên các thiết bị của công ty.

### 3.3 Khoảng trống về mô hình tư duy

"Người dùng không cần mật mã học, họ cần một mô hình tư duy". Sự nhầm lẫn về thuật ngữ tạo
ra tải trọng nhận thức:

- Passkey
- [Khóa bảo mật](https://www.corbado.com/vi/glossary/ctap) (Security Key)
- Khóa phần cứng (Hardware Key)
- YubiKey
- Không mật khẩu (passwordless)
- Windows Security
- [Windows Hello](https://www.corbado.com/glossary/windows-hello)
- Windows Hello for Business (WHfB)
- Microsoft [Authenticator](https://www.corbado.com/glossary/authenticator)
- Đăng nhập bằng điện thoại (Phone Sign-in)

Đối với những người dùng không rành công nghệ hoặc thậm chí cả những người am hiểu công
nghệ, sự khác biệt của những thuật ngữ này không hề rõ ràng.

Chúng tôi khuyên bạn nên tránh các thuật ngữ chuyên môn như "chống phishing" hoặc "cặp
khóa" trong giao tiếp với người dùng cuối. Thay vào đó, hãy tập trung vào khái niệm "mở
khóa": "Sử dụng khuôn mặt của bạn để mở khóa các hệ thống của doanh nghiệp," tương tự như
cách mở khóa điện thoại của họ.

### 3.4 Giới hạn của giao tiếp

Sự đón nhận mạnh mẽ ngay từ đầu là rất quan trọng để thành công, nhưng giao tiếp chỉ có
thể giải quyết được một phần. Bạn không thể gửi email thường xuyên yêu cầu người dùng kiểm
tra các phương pháp xác thực của họ. Nói chung, **bạn không thể lập kế hoạch tốt cho hành
vi của người dùng.** Thực tế này thúc đẩy sự cần thiết phải có các biện pháp kỹ thuật chủ
động thay vì chỉ dựa vào việc giáo dục người dùng.

## 4. Đi sâu vào cấu hình Microsoft Entra ID

Triển khai passkey trong môi trường doanh nghiệp đòi hỏi phải hiểu và thiết lập các chính
sách phụ thuộc lẫn nhau. Passkey không chỉ là một tính năng mà bạn có thể đơn giản bật
lên, vì nó có tác động khổng lồ đến mọi nhân viên trong công việc hàng ngày của họ.

### 4.1 Chính sách phương thức xác thực

Các cổng [MFA](https://www.corbado.com/vi/faq/superannuation-funds-passkeys) và SSPR cũ không còn được dùng nữa.
Tất cả cấu hình [FIDO2](https://www.corbado.com/glossary/fido2) phải diễn ra trong blade
[Authentication Methods Policy](https://www.threatscape.com/cyber-security-blog/common-entra-id-mfa-mistakes-you-might-be-making/)
thống nhất.

- **Phương thức Khóa Bảo Mật FIDO2:** Phải được bật và nhắm mục tiêu. Khuyến nghị nhắm mục
  tiêu "Tất cả Người Dùng" để kích hoạt nhưng kiểm soát việc thực thi thông qua
  Conditional Access.
- **Hạn chế Khóa (AAGUID):** Mỗi thiết bị [FIDO2](https://www.corbado.com/glossary/fido2) (ví dụ: YubiKey 5 NFC,
  Microsoft [Authenticator](https://www.corbado.com/glossary/authenticator) trên
  [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios),
  [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)) đều có một
  **Authenticator Attestation GUID (AAGUID)** duy nhất. Như một phương pháp hay nhất, đối
  với các môi trường [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) cao, hãy sử dụng
  cài đặt "Enforce Key Restrictions" để chỉ **Cho phép (Allow)** các
  [AAGUID](https://www.corbado.com/glossary/aaguid) cụ thể, đã được phê duyệt. Điều này ngăn người dùng đăng ký
  các [khóa bảo mật](https://www.corbado.com/vi/glossary/ctap) "chợ đen" rẻ tiền, chưa được xác minh.

### 4.2 Chứng thực (Attestation): điểm quyết định quan trọng

Một trong những quyết định cấu hình quan trọng nhất là **"Enforce Attestation" (Bắt buộc
Chứng thực)**.

- **Chức năng:** Buộc trình xác thực phải chứng minh về mặt mật mã hóa kiểu dáng và mẫu mã
  của nó với Entra ID trong quá trình đăng ký.
- **Xung đột:** **Passkey đồng bộ** (được lưu trữ trong các nhà cung cấp phần mềm như
  [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain),
  [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024) hoặc
  [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)) thường **không** hỗ
  trợ [chứng thực](https://www.corbado.com/vi/glossary/attestation) vì chúng dựa trên phần mềm và không phụ thuộc
  vào nền tảng. Chúng không thể ký một thử thách bằng một chứng chỉ theo lô phần cứng
  (hardware-batch certificate).
- **Đánh đổi:**
    - **Đặt là YES (Có):** Bắt buộc đối với mức độ bảo đảm cao (AAL3). Đảm bảo khóa được
      gắn liền với phần cứng. **Chặn các nhà cung cấp passkey dựa trên phần mềm.**
    - **Đặt là NO (Không):** Cho phép Passkey đồng bộ. Giảm nhẹ mức độ bảo đảm (AAL2).
      **Kích hoạt các nhà cung cấp passkey dựa trên phần mềm.**

Bạn không thể áp dụng một chính sách "Không [Chứng thực](https://www.corbado.com/vi/glossary/attestation)" (No
[Attestation](https://www.corbado.com/glossary/attestation)) toàn cầu nếu bạn có các quản trị viên đặc quyền cao
yêu cầu khóa phần cứng. Bạn phải sử dụng
[Passkey Profiles (Preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys):

- _Profile A (Quản trị viên):_ Enforce [Attestation](https://www.corbado.com/glossary/attestation) = **Yes**
- _Profile B (Nhân viên chung):_ Enforce [Attestation](https://www.corbado.com/glossary/attestation) = **No**

### 4.3 Giải thích về Passkey Profiles

Hãy coi
[Passkey Profiles](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles)
như một cơ chế để xác định:

- "Những người dùng này có thể sử dụng **passkey đồng bộ**"
- "Những người dùng này chỉ được sử dụng **gắn liền thiết bị**"
- "Yêu cầu [chứng thực](https://www.corbado.com/vi/glossary/attestation) vs không yêu cầu chứng thực" (và do đó:
  cho phép vs loại trừ passkey đồng bộ)
- "Hạn chế đối với một số loại trình xác thực nhất định (hạn chế
  [AAGUID](https://www.corbado.com/glossary/aaguid))"

Dưới đây, bạn có thể thấy trang cài đặt Passkey (FIDO2) trong trung tâm quản trị Microsoft
Entra nơi bạn cấu hình các passkey profile:

![passkey fido2 settings selected profiles](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_selected_profiles_8fad7bfc7a.png)

Khi chỉnh sửa một passkey profile, bạn có thể định cấu hình việc bắt buộc chứng thực, các
loại mục tiêu (gắn liền thiết bị, đồng bộ hoặc cả hai) và các hạn chế
[AAGUID](https://www.corbado.com/glossary/aaguid) cụ thể:

![passkey fido2 settings](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_800cee0438.png)

### 4.4 Conditional Access & độ mạnh xác thực

Việc thực thi có thể được xử lý qua các chính sách Conditional Access (CA) sử dụng
[Authentication Strengths (Độ mạnh Xác thực)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths).

- **Độ mạnh MFA Chống Phishing:** Độ mạnh tích hợp sẵn này yêu cầu FIDO2, Windows Hello
  for Business (WHfB) hoặc Xác thực dựa trên chứng chỉ (Certificate-Based Authentication -
  CBA).
- **Cạm bẫy khóa (Lockout Trap):** Nếu bạn tạo một chính sách CA yêu cầu
  "Phishing-Resistant [MFA](https://www.corbado.com/vi/faq/superannuation-funds-passkeys)" cho "Tất cả các ứng
  dụng đám mây (All Cloud Apps)" và áp dụng nó cho "Tất cả người dùng (All Users)," bạn sẽ
  ngay lập tức khóa mọi người dùng chưa đăng ký passkey. Họ thậm chí sẽ không thể đăng
  nhập để đăng ký.
- **Nghịch lý "Đăng ký Thông tin Bảo mật":** Đây là một User Action cụ thể trong CA. Nếu
  bạn yêu cầu Phishing-Resistant MFA để thực hiện hành động
  [Register Security Information](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration),
  bạn tạo ra một sự phụ thuộc vòng tròn (con gà và quả trứng). Người dùng không thể đăng
  ký passkey đầu tiên của họ vì họ cần passkey để truy cập vào trang đăng ký.

Dưới đây là tổng quan về phương thức xác thực nào thỏa mãn yêu cầu về độ mạnh nào:

| Kết hợp phương thức xác thực                         | Độ mạnh MFA | Độ mạnh MFA không mật khẩu | Độ mạnh MFA chống phishing |
| ---------------------------------------------------- | :---------: | :------------------------: | :------------------------: |
| Khóa bảo mật FIDO2                                   |     ✅      |             ✅             |             ✅             |
| Windows Hello for Business hoặc chứng danh nền tảng  |     ✅      |             ✅             |             ✅             |
| Xác thực dựa trên chứng chỉ (đa yếu tố)              |     ✅      |             ✅             |             ✅             |
| Microsoft Authenticator (đăng nhập bằng điện thoại)  |     ✅      |             ✅             |                            |
| Temporary Access Pass (sử dụng một lần và nhiều lần) |     ✅      |                            |                            |
| Mật khẩu cộng với một thứ người dùng có              |     ✅      |                            |                            |
| Đơn yếu tố liên kết cộng với một thứ người dùng có   |     ✅      |                            |                            |
| Đa yếu tố liên kết                                   |     ✅      |                            |                            |
| Xác thực dựa trên chứng chỉ (đơn yếu tố)             |             |                            |                            |
| Đăng nhập qua SMS                                    |             |                            |                            |
| Mật khẩu                                             |             |                            |                            |
| Đơn yếu tố liên kết                                  |             |                            |                            |

### 4.5 Xác thực ưu tiên của hệ thống (System-preferred authentication)

Tính năng "Xác thực đa yếu tố ưu tiên của hệ thống" của Entra ID buộc công cụ đăng nhập
phải
[nhắc người dùng sử dụng phương thức an toàn nhất đã đăng ký](https://www.token2.com/site/page/default-mfa-method-for-microsoft-entra-id-users).

Nếu một người dùng đã đăng ký cả SMS và passkey, hệ thống sẽ mặc định chọn passkey. Điều
này thúc đẩy việc áp dụng passkey một cách tự
[nhi](https://www.corbado.com/blog/agentic-non-human-identity-eic-2026)ên mà không cần phải thực thi cứng nhắc.
Nó về cơ bản tự động "nâng cấp" tình trạng bảo mật của người dùng ngay khi họ đăng ký
chứng danh.

Dưới đây, bạn có thể xem trải nghiệm đăng
[nhập passkey](https://www.corbado.com/vi/blog/giao-thuc-trao-doi-thong-tin-xac-thuc-cxp-dinh-dang-cxf). Người
dùng được nhắc sử dụng "Khuôn mặt, dấu vân tay, mã PIN hoặc
[khóa bảo mật](https://www.corbado.com/vi/glossary/ctap)" và có thể chọn passkey của họ từ một tiện ích mở rộng
trình duyệt hoặc trình quản lý chứng danh hệ thống:

![1password passkey entra](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/1password_passkey_entra_e261b05849.png)

### 4.6 Các lưu ý đối với macOS: Platform SSO

Đối với các tổ chức có môi trường hỗn hợp Windows/macOS, **macOS Platform SSO** cung cấp
cấu hình tương đương với Windows Hello for Business của Apple. Kết hợp với các giải pháp
MDM, bạn có thể đạt được:

- Chứng danh gắn liền thiết bị được liên kết với
  [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) của Mac
- Trải nghiệm [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) trên các ứng dụng gốc và ứng dụng
  web
- Xác thực chống phishing đáp ứng các yêu cầu
  [AAL2](https://www.corbado.com/blog/nist-passkeys)/[AAL3](https://www.corbado.com/blog/nist-passkeys)

**Lưu ý:** macOS Platform [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) yêu cầu macOS 13+ và
cấu hình MDM thích hợp. Quá trình thiết lập khác biệt đáng kể so với Windows WHfB, do đó
hãy lập kế hoạch cho các luồng triển khai riêng biệt.

## 5. Những sai lầm cấu hình phổ biến: tại sao "nó chỉ hoạt động với Microsoft Authenticator"

Nếu mục tiêu của bạn là **passkey đồng bộ trên các thiết bị không được quản lý**, đây là
những tác nhân chặn phổ biến nhất:

### 5.1 Passkey đồng bộ chưa được kích hoạt/nhắm mục tiêu

Việc chỉ bật "FIDO2" chung chung trong Entra là chưa đủ. Đối với passkey đồng bộ, bạn
thường cần:

- Đường dẫn tính năng preview được mô tả trong
  [Synced passkeys (preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys)
- Cấu hình profile sử dụng
  [Passkey Profiles](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles)

Nếu một nhóm không được nhắm mục tiêu bởi một profile cho phép passkey đồng bộ, bạn sẽ bị
kéo trở lại thế giới "chỉ gắn liền thiết bị".

### 5.2 Bắt buộc Chứng thực (chặn passkey đồng bộ)

Điều này gây ra hầu hết các câu hỏi trong các tổ chức có ý thức về bảo mật:

- Entra có thể yêu cầu **chứng thực (attestation)** cho một số trường hợp passkey (giúp
  xác thực loại trình xác thực/nguồn gốc)
- **Passkey đồng bộ không hỗ trợ chứng thực trong Entra**, vì vậy nếu chứng thực bị bắt
  buộc, passkey đồng bộ sẽ đăng ký không thành công và bạn sẽ chỉ còn lại các tùy chọn gắn
  liền thiết bị

### 5.3 Danh sách cho phép AAGUID chặn các nhà cung cấp

Entra cho phép bạn hạn chế các trình xác thực nào được cho phép (thường thông qua danh
sách cho phép/chặn AAGUID). Nếu bạn chỉ đưa vào danh sách cho phép (allow-list) Microsoft
[Authenticator](https://www.corbado.com/glossary/authenticator) (hoặc một tập hợp hẹp các trình xác thực), các
nhà cung cấp đồng bộ [bên thứ ba](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) có thể bị chặn ngầm. Phần
khó hiểu là xác thực cục bộ (ví dụ: Touch ID, [Face ID](https://www.corbado.com/faq/is-face-id-passkey), quét
[sinh trắc học](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan) Windows) vẫn hoạt động
nhưng trang đăng nhập Entra sau đó lại hiển thị lỗi.

### 5.4 Conditional Access buộc sử dụng một số loại passkey nhất định

Ngay cả khi passkey được bật, Conditional Access vẫn có thể buộc người dùng sử dụng một
tập con các phương thức (ví dụ: "Chỉ Authenticator" hoặc một cấu hình độ mạnh không cho
phép passkey profile dự định). Trên thực tế, điều này tạo ra "sự phụ thuộc vào
Authenticator" ngay cả khi kế hoạch là sử dụng passkey đồng bộ.

### 5.5 Người dùng khách B2B so với tài khoản thành viên

Nếu các đối tác bên ngoài là **người dùng khách B2B trong một resource tenant**, có những
hạn chế đã biết xung quanh việc ở đâu/làm thế nào họ có thể đăng ký các phương thức xác
thực. Đây thường là câu trả lời tiềm ẩn cho câu hỏi "tại sao nó không hoạt động" khi mục
đích là "đối tác sử dụng passkey trong tenant của chúng tôi."

## 6. Các thách thức vận hành & giải pháp

### 6.1 Nghịch lý bootstrapping

Vấn đề phổ biến nhất ("Đăng ký là phần khó nhất") là vấn đề bootstrapping: **Làm cách nào
bạn phát hành chứng danh bảo đảm cao một cách an toàn cho một người dùng hiện chưa có
chứng danh (hoặc chỉ có chứng danh bảo đảm thấp)?**

#### 6.1.1 Temporary Access Pass (TAP)

[Temporary Access Pass (TAP)](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass)
là một phương pháp tiếp cận kiến trúc để onboarding không mật khẩu.

- **Nó là gì:** Một mật mã có thời hạn (ví dụ: 1 giờ), entropy cao mà Entra ID coi như một
  phương thức "xác thực mạnh mẽ" (strong authentication). Nó bỏ qua nhu cầu về mật khẩu
  hoặc MFA hiện có.
- **Quy trình (Workflow):**
    1. **Xác minh Danh tính:** Danh tính của nhân viên mới được xác minh (ví dụ: qua quy
       trình HR hoặc xác minh của Người quản lý).
    2. **Phát hành:** Một quản trị viên (hoặc Logic App tự động) tạo một TAP cho người
       dùng.
    3. **Đăng nhập "Ma thuật":** Người dùng truy cập `aka.ms/mysecurityinfo`. Họ nhập tên
       người dùng và TAP.
    4. **Đăng ký:** Bởi vì TAP thỏa mãn yêu cầu "Xác thực Mạnh mẽ", người dùng được phép
       truy cập blade Security Info. Họ nhấp vào "Add Method" và đăng ký passkey của mình.
    5. **Trạng thái Ổn định:** TAP hết hạn. Bây giờ người dùng đã có chứng danh chống
       phishing. Họ không bao giờ phải gõ một mật khẩu nào cả.

#### 6.1.2 Tự động hóa qua Graph API

Đối với các tổ chức lớn, việc phát hành TAP thủ công không thể mở rộng. Phương pháp hay
nhất là
[tự động hóa qua Microsoft Graph API](https://janbakker.tech/how-to-create-a-temporary-access-pass-using-logic-apps/).

- **Tình huống:** Một nhân viên mới được xử lý trong hệ thống HR (Workday/SuccessFactors).
- **Trình kích hoạt:** Sự kiện cấp phép (provisioning) kích hoạt một Azure Logic App.
- **Hành động:** Logic App gọi Graph API POST
  `/users/{id}/authentication/temporaryAccessPassMethods`.
- **Giao hàng:** TAP được gửi một cách an toàn đến người quản lý tuyển dụng của người dùng
  hoặc email cá nhân (được mã hóa) để truy cập trong ngày đầu tiên.

#### 6.1.3 Microsoft Entra Verified ID cho onboarding bảo đảm cao

Đối với onboarding từ xa hoặc các tình huống yêu cầu sự bảo đảm danh tính cao,
[Entra Verified ID](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication)
của Microsoft cùng với **Face Check** cung cấp một lộ trình đăng ký ưu tiên không mật
khẩu:

1. **Xác thực danh tính:** Người dùng mới xác minh danh tính qua đối tác IDV (quét giấy tờ
   tùy thân của chính phủ).
2. **Khớp sinh trắc học:**
   [Face Check](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck) so
   sánh một bức ảnh selfie trực tiếp với ảnh trên giấy tờ tùy thân sử dụng Azure
   [AI](https://www.corbado.com/vi/blog/vai-tro-cua-ai-trong-phat-hien-moi-de-doa-mang) Vision. Chỉ một điểm tin
   cậy về mức độ trùng khớp được chia sẻ (không có dữ liệu
   [sinh trắc học](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan) thô).
3. **Phát hành chứng danh đã xác minh:** Người dùng nhận được chứng danh Verified ID.
4. **Phát hành TAP:** Sau khi xác minh thành công, hệ thống phát hành một
   [Temporary Access Pass](https://www.corbado.com/blog/enterprise-passkey-deployment-challenges).
5. **Khởi tạo passkey:** Người dùng đăng ký passkey đầu tiên của họ bằng cách sử dụng TAP.

Luồng Face Check hướng dẫn người dùng qua ba bước: Verify (chia sẻ chứng danh), Confirm
(thực hiện quét khuôn mặt) và Review (xem kết quả khớp):

![Luồng Microsoft Entra Verified ID Face Check hiển thị các bước Verify, Confirm và Review](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/face_check_b5a23174b0.png)

Luồng này cho phép **tài khoản thực sự không mật khẩu từ ngày đầu tiên**. Không có mật
khẩu nào từng được tạo ra.

### 6.2 Vấn đề thay điện thoại (thách thức mở rộng ẩn)

Đây thường là nguồn gọi trợ giúp helpdesk lớn nhất trong các đợt triển khai passkey. Các
tổ chức có nhóm dân số BYOD lớn (ví dụ: hơn 10.000 thiết bị) có thể thấy một số lượng lớn
các cuộc gọi hỗ trợ chỉ từ việc người dùng có điện thoại mới và không biết quy trình để
đăng ký lại các phương thức xác thực.

Khi bạn đưa passkey vào, điều này càng trở nên quan trọng hơn vì:

- Người dùng cài đặt các ứng dụng (như Outlook) trên điện thoại mới của họ
- Các ứng dụng này nhắc xác thực
- Lời nhắc MFA xuất hiện trên **điện thoại cũ** (mà có thể họ đã đem đổi lấy máy mới hoặc
  xóa dữ liệu)
- Người dùng bị khóa và gọi cho helpdesk

#### 6.2.1 Ma trận tình huống thay thế điện thoại

| Tình huống              | Người dùng có điện thoại cũ | Người dùng có laptop tin cậy | Giải pháp                                                                                                               |
| ----------------------- | --------------------------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Trường hợp tốt nhất** | Có                          | Có                           | Hướng dẫn người dùng thêm passkey mới trong khi điện thoại cũ vẫn hoạt động. Chuyển sang "happy path" (luồng lý tưởng). |
| **Trường hợp phổ biến** | Không                       | Có                           | **Laptop làm bootstrap:** Sử dụng phiên xác thực WHfB để đăng ký passkey trên điện thoại mới (Self-Service Kiosk).      |
| **Trường hợp tệ nhất**  | Không                       | Không                        | Sự can thiệp của Helpdesk hoặc SSAR với xác minh danh tính là không thể tránh khỏi.                                     |

Mục tiêu là chuyển càng nhiều trường hợp càng tốt sang hai hàng đầu tiên, giảm thiểu sự
can thiệp của helpdesk.

#### 6.2.2 Mẹo với đăng ký Intune

Một insight thông minh: Yêu cầu passkey cho việc đăng ký Intune buộc người dùng phải hoàn
tất thiết lập Microsoft Authenticator trên điện thoại mới của họ **ngay lập tức** - trước
khi họ có thể truy cập các ứng dụng của công ty.

- **Hiện tại:** Đăng ký Intune yêu cầu nâng cấp MFA (MFA step-up). Điều này có nghĩa là
  nếu bạn muốn đăng nhập trên một chiếc điện thoại mới, bạn phải cài đặt Outlook trên đó.
  Tuy nhiên, lời nhắc MFA sẽ chuyển đến chiếc điện thoại cũ.
- **Với yêu cầu passkey:** Người dùng phải thiết lập passkey Microsoft Authenticator trên
  điện thoại mới trước để hoàn tất việc đăng ký. Điều này diễn ra một cách nhanh chóng
  (vào ngày đổi điện thoại) thay vì vài tháng sau khi chiếc điện thoại cũ đã không còn.

Điều này không giải quyết việc khôi phục, nhưng nó dời mốc thời gian. Người dùng đăng ký
thiết bị mới của họ trong khi họ vẫn còn quyền truy cập vào thiết bị cũ.

### 6.3 Khóa bảo mật phần cứng đi kèm với các vấn đề hậu cần

Khóa phần cứng (YubiKey, v.v.) đôi khi được định vị là giải pháp vạn năng. Về lý thuyết
thì đúng, tuy nhiên thực tế lại cho thấy nhiều thách thức hơn:

- **Ác mộng hậu cần:** Các tổ chức trước đây đã triển khai token vật lý (như RSA SecurID)
  thường dành nhiều năm cố gắng loại bỏ chúng. Việc thay thế một chương trình token vật lý
  này bằng một chương trình token vật lý khác không có gì hấp dẫn.
- **Vận chuyển trực tiếp (Drop-shipping):** Yubico có thể vận chuyển khóa trực tiếp đến
  người dùng và họ không cần thay pin vài năm một lần (không giống như SecurID). Nhưng nếu
  [ai](https://www.corbado.com/vi/blog/vai-tro-cua-ai-trong-phat-hien-moi-de-doa-mang) đó quên khóa của mình, họ
  không thể đăng nhập (đối với các desktop dùng chung).
- **Gánh nặng IT cục bộ:** Những người giám sát tại chỗ không nên trở thành hỗ trợ IT bất
  đắc dĩ cho các khóa bị bỏ quên.
- **Chi phí:** Khóa phần cứng tạo thêm chi phí trên mỗi người dùng tăng theo quy mô số
  lượng nhân viên.

**Khi nào thì khóa phần cứng hợp lý:**

- **Quản trị viên Tier 0:** Domain admin, các tài khoản "break-glass"
- **Máy trạm dùng chung (Shared workstations):** Môi trường kiosk, phân xưởng nhà máy, máy
  tính bảng thực địa
- **Nhà thầu không dùng BYOD:** Những người dùng bên ngoài không sử dụng thiết bị cá nhân

### 6.4 Thách thức với thiết bị không được quản lý (Unmanaged device)

Nhiều người dùng phàn nàn rằng họ không thể thấy các tùy chọn sử dụng passkey trên một
thiết bị cá nhân. Đây là một điểm ma sát kinh điển của "thiết bị không được quản lý".

#### 6.4.1 Phân tích lỗi "Passkey chưa được đăng ký"

Người dùng có thể không thể thêm passkey trên một thiết bị cá nhân, trong khi nó vẫn hoạt
động trên thiết bị của công ty. Điều này có thể là do **Các chính sách Tuân thủ
(Compliance Policies) của Intune** tương tác với quy trình đăng ký.

- **Cơ chế:** Windows Hello for Business (WHfB) là một chứng danh nền tảng. Nó được gắn
  với [TPM](https://www.corbado.com/vi/blog/device-bound-session-credentials-dbsc) của thiết bị cụ thể (passkey
  gắn liền thiết bị).
- **Ràng buộc:** Để đăng ký WHfB, thiết bị thường phải được **tham gia (joined)** (Entra
  Joined hoặc Hybrid Joined) vào tenant. Một thiết bị cá nhân chỉ đơn thuần được "Đăng ký
  (Registered)" (Workplace Joined) có thể áp dụng các giới hạn chính sách thông qua
  Intune, chặn việc cung cấp các container WHfB nếu thiết bị không được quản lý hoàn toàn
  hoặc không tuân thủ. Xem
  [Yêu cầu đăng nhập khóa bảo mật FIDO2](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-windows).
- **Tùy chọn "Passkey":** Trên một thiết bị cá nhân, người dùng nên thử đăng ký **Khóa Bảo
  mật FIDO2** (khóa lưu động - roaming) hoặc **Passkey Chéo Thiết bị** (trên điện thoại
  của họ), _chứ không phải_ Windows Hello for Business (trừ khi việc đăng ký BYOD được hỗ
  trợ hoàn toàn).
- **Vấn đề hiển thị trong Entra ID:** Nếu "Windows Hello" không xuất hiện như một tùy
  chọn, thiết bị chưa hoàn tất đăng ký MDM tiên quyết.

#### 6.4.2 Các lỗi Xác thực Chéo Thiết bị (CDA)

Trên các thiết bị không được quản lý, người dùng thường thử luồng **Xác thực Chéo Thiết bị
(Cross-Device Authentication - CDA)** (quét
[mã QR](https://www.corbado.com/vi/blog/phuong-phap-dang-nhap-xac-thuc-ma-qr) trên PC bằng điện thoại của họ).

- **Sự phụ thuộc Bluetooth:** [CDA](https://www.corbado.com/vi/glossary/cda) yêu cầu bật **Bluetooth** trên cả PC
  và điện thoại. Chúng không cần phải ghép nối, nhưng phải thực hiện một bắt tay Bluetooth
  Low [Energy](https://www.corbado.com/passkeys-for-energy) (BLE) để chứng minh tính gần gũi (proximity). Xem lại
  [passkey gắn liền thiết bị trong Microsoft Authenticator](https://janbakker.tech/things-you-should-know-before-rolling-out-device-bound-passkeys-in-microsoft-authenticator-app/)
  để biết thêm chi tiết.
- **Trở ngại từ Chính sách Công ty:** Nếu Bluetooth bị vô hiệu hóa trên laptop của công ty
  thông qua BIOS hoặc GPO vì lý do "bảo mật", bạn đã phá vỡ cơ chế chính cho passkey lưu
  động.
- **Chặn Websocket:** Luồng [CDA](https://www.corbado.com/vi/glossary/cda) sử dụng kết nối websocket đến
  `cable.ua5v.com` hoặc `cable.auth.com`. Tường lửa công ty tích cực hoặc cấu hình Zscaler
  thường chặn các domain này, khiến quá trình quét
  [mã QR](https://www.corbado.com/vi/blog/phuong-phap-dang-nhap-xac-thuc-ma-qr) bị treo hoặc thất bại một cách im
  lặng. Xem
  [tài liệu về passkey trong Microsoft Authenticator](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-authenticator-passkey).

### 6.5 B2B và External Identities

Một điểm đau (pain point) khác đối với các doanh nghiệp là giải quyết các tư vấn viên bên
ngoài (khách B2B).

- **Vấn đề:** Một chuyên gia tư vấn cố gắng truy cập một trang web SharePoint. Tenant thực
  thi một chính sách Conditional Access yêu cầu "Phishing-Resistant MFA."
- **Thất bại:** Chuyên gia tư vấn cố gắng đăng ký một khóa FIDO2 trong resource tenant.
  **Việc này thất bại.** Entra ID
  [không hỗ trợ người dùng khách đăng ký khóa FIDO2](https://learn.microsoft.com/en-us/answers/questions/1192906/cannot-register-fido2-key-for-guest-users-on-resou)
  trong resource tenant.
- **Cách sửa: Cài đặt Truy cập Chéo Tenant (Cross-Tenant Access Settings)**
    - **Logic:** Thay vì buộc khách đăng ký một chứng danh trong tenant của bạn, bạn nên
      **tin cậy (trust)** chứng danh họ sử dụng trong tenant của _họ_.
    - **Cấu hình:** Đi tới _External Identities > Cross-tenant access settings_. Chọn tổ
      chức đối tác. Trong mục **Inbound Trust**, đánh dấu chọn **"Trust multifactor
      authentication from Microsoft Entra tenants"**.
    - **Kết quả:** Khi chuyên gia tư vấn đăng nhập bằng YubiKey trong home tenant của họ,
      tenant của bạn nhận được một xác nhận thông báo "MFA Satisfied + Phishing
      Resistant". Quyền truy cập được cấp mà người dùng không cần đăng ký bất kỳ điều gì.
      Việc này chuyển việc quản lý vòng đời chứng danh cho đối tác, làm giảm trách nhiệm
      pháp lý của bạn và gánh nặng cho helpdesk.

## 7. Các chiến lược khôi phục

Thông thường các quyết định phục hồi vẫn đi sau việc triển khai thực tế. Có nhiều tùy chọn
khôi phục tồn tại tùy thuộc vào nhu cầu của tổ chức bạn.

### 7.1 Khôi Phục Tài Khoản Tự Phục Vụ (SSAR) với Verified ID

Luồng
[Self-Service Account Recovery (SSAR)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-account-recovery-overview)
mới của Microsoft Entra ID (trong Preview) cho phép khôi phục với mức độ bảo đảm cao mà
không cần sự can thiệp của helpdesk.

![Luồng Khôi phục Tài khoản sử dụng Microsoft Entra Verified ID cho thấy quy trình 4 bước](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/account_recovery_microsoft_entry_recovery_8c9f369047.png)

1. **Trình kích hoạt:** Người dùng không thể đăng nhập. Chọn "Recover my account" (Khôi
   phục tài khoản của tôi).
2. **Xác minh Danh tính:** Người dùng được chuyển hướng đến một nhà cung cấp Xác minh Danh
   tính (Identity Verification - IDV) [bên thứ ba](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) (ví dụ:
   Onfido, IDemia).
3. **Kiểm tra Giấy tờ:** Người dùng quét Giấy phép lái xe vật lý, CMND/CCCD hoặc hộ chiếu
   của họ bằng camera điện thoại.
4. **Kiểm tra Người thật (Liveness Check):** Người dùng thực hiện chụp selfie
   [Face Check](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck). Việc
   này được so khớp với tài liệu ID (và có khả năng là ảnh lưu trong Entra ID). Việc so
   khớp sử dụng Azure [AI](https://www.corbado.com/vi/blog/vai-tro-cua-ai-trong-phat-hien-moi-de-doa-mang) Vision
   Face APIs và chỉ một điểm số tin cậy được chia sẻ. Không có dữ liệu
   [sinh trắc học](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan) thô nào đi đến ứng
   dụng.
5. **Khôi phục:** Sau khi thành công, hệ thống sẽ tự động phát hành một **Temporary Access
   Pass (TAP)** cho người dùng.
6. **Đăng ký Lại:** Người dùng sử dụng TAP để đăng ký ngay lập tức một passkey mới.

**Khuyến nghị:** Lộ trình khôi phục tự động, được hỗ trợ bởi sinh trắc học này vượt trội
so với "Gọi Helpdesk", vốn dễ bị tấn công kỹ thuật xã hội (tấn công giả giọng Deepfake).

### 7.2 Khôi phục có Người Quản Lý Hỗ Trợ bằng My Staff

Nếu bạn muốn giảm tải cho Service Desk nhưng không thể kích hoạt chức năng tự phục vụ hoàn
toàn, Microsoft Entra bao gồm một tính năng quản trị được ủy quyền nguyên bản gọi là **My
Staff**.

- **Cách hoạt động:** Ủy quyền các quyền hạn chế cho "Team Managers" (thông qua
  Administrative Units trong Entra).
- **Quy trình:** Nếu một người dùng mất quyền truy cập, họ có thể liên hệ với một quản trị
  viên cục bộ được ủy quyền, người có thể sử dụng cổng **My Staff** cho các tác vụ khôi
  phục được hỗ trợ như đặt lại mật khẩu hoặc cập nhật số điện thoại.
- **Tại sao nó hữu ích:** Nó chuyển công việc
  [khôi phục tài khoản](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) thông thường
  khỏi trung tâm helpdesk và tăng tốc độ hỗ trợ.

### 7.3 Kiosk Khôi Phục Tự Phục Vụ (mạng nội bộ - intranet)

Vì người dùng thường vẫn có một laptop tin cậy, được bảo mật bằng WHfB, bạn có thể xây
dựng một trang web nội bộ "break glass" (cấp cứu) đơn giản.

- **Xây dựng:** Một ứng dụng web nội bộ đơn giản yêu cầu đăng nhập WHfB (xác thực mạnh
  mẽ).
- **Hành động:** Sau khi xác thực, người dùng nhấp vào "Tôi có một điện thoại mới". Ứng
  dụng sử dụng Microsoft Graph API (dịch vụ nền) để tạo một
  [Temporary Access Pass](https://www.corbado.com/blog/enterprise-passkey-deployment-challenges) (TAP) ngắn hạn
  và hiển thị nó trên màn hình.
- **Kết quả:** Người dùng gõ mã TAP đó vào chiếc điện thoại mới của họ để khởi tạo ứng
  dụng Microsoft Authenticator. Không liên quan gì đến helpdesk.

Đây là **đòn bẩy chính** để giảm thiểu việc đặt lại "xóa các phương thức xác thực" mà
không làm suy yếu chính sách. Nếu bạn có một cơ chế dùng laptop làm bootstrap mạnh mẽ,
gánh nặng truyền thông của bạn sẽ giảm đi đáng kể vì người dùng có thể khôi phục mà không
cần biết một trình tự hoàn hảo.

## 8. Khuyến nghị cho Triển Khai Passkey Doanh Nghiệp

Cấu trúc đợt rollout của bạn theo **Các giai đoạn Trưởng thành (Maturity Stages)**. Thừa
nhận những rào cản ma sát ("Công nghệ đã sẵn sàng, vận hành thì khó khăn") và áp dụng
những biện pháp giảm nhẹ này.

### 8.1 Hành động Ngay Lập Tức (Giai đoạn "Fix-It")

1. **Kiểm toán Bluetooth & Tường lửa:** Đảm bảo máy tính xách tay của công ty cho phép
   Bluetooth (cho các kiểm tra proximity) và cho phép các domain relay của FIDO/WebAuthn
   (`\*.cable.auth.com`) để sửa lỗi chéo thiết bị.
2. **Kích hoạt Cross-Tenant Trust:** Ngừng cố gắng đăng ký passkey cho khách. Định cấu
   hình Inbound Trust cho MFA đối với các đối tác chính để giải quyết các vấn đề truy cập
   B2B ngay lập tức.
3. **Triển khai TAP cho Onboarding:** Yêu cầu sử dụng
   [Temporary Access Pass](https://www.corbado.com/blog/enterprise-passkey-deployment-challenges) cho tất cả việc
   onboarding người dùng mới để giải quyết tác nhân chặn đăng ký "con gà và quả trứng".

### 8.2 Các Quyết định Chiến lược (Giai đoạn "Architecture")

1. **Áp dụng Mô hình "Đảm bảo Lai" (Hybrid Assurance):**
    - **Tier 0 (Quản trị viên):** Bắt buộc **Chứng thực (Attestation)** và **Hạn chế Khóa
      (Key Restrictions)**. Chỉ cho phép YubiKeys/Phần cứng (AAL3).
    - **Tier 1 (Lực lượng lao động):** Vô hiệu hóa việc bắt buộc Chứng thực thông qua
      **Passkey Profiles**. Cho phép passkey đồng bộ để giảm ma sát và chi phí (AAL2).
2. **Kế hoạch cho macOS:** Triển khai Platform [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso)
   cùng với MDM của bạn như một hướng đi song song với Windows WHfB.

### 8.3 Chuẩn bị cho Tương Lai (Giai đoạn "Optimization")

1. **Lên kế hoạch cho SSAR:** Bắt đầu thử nghiệm
   [Khôi Phục Tài Khoản](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) Tự Phục Vụ
   với Verified ID để loại bỏ helpdesk như một vector tấn công kỹ thuật xã hội.
2. **Xác thực Ưu Tiên Của Hệ Thống:** Kích hoạt chính sách này để tự động "nâng cấp" người
   dùng lên passkey ngay sau khi họ đăng ký, thúc đẩy sự chấp nhận mà không cần một mệnh
   lệnh cứng nhắc.
3. **Triển khai Các Tùy chọn Khôi phục:** Triển khai TAP do Người quản lý hỗ trợ qua My
   Staff và/hoặc một Kiosk Khôi Phục Tự Phục Vụ.
4. **Yêu cầu Passkey cho Intune:** Xem xét yêu cầu passkey cho việc đăng ký Intune để buộc
   việc đăng ký sớm trên các thiết bị mới.

### 8.4 Ma trận Khắc phục sự cố

| **Thông báo lỗi / Triệu chứng**                            | **Nguyên nhân gốc rễ**                                                                                                                                                            | **Chiến lược khắc phục**                                                                                                 |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **"Passkey not registered"** (Desktop Windows)             | Chính sách bắt buộc "Chứng thực" (Attestation), nhưng người dùng đang sử dụng một phương thức không được chứng thực (ví dụ: Google Password Manager, iCloud Keychain, 1Password). | Sử dụng **Passkey Profiles** để vô hiệu hóa "Enforce Attestation" cho người dùng chuẩn.                                  |
| **"Passkey not registered"** (Mobile App)                  | AAGUID cụ thể của Microsoft Authenticator (Android/iOS) bị thiếu trong danh sách cho phép (whitelist) của "Key Restrictions".                                                     | Thêm các AAGUID: Android: `de1e552d-db1d-4423-a619-566b625cdc84` iOS: `90a3ccdf-635c-4729-a248-9b709135078f`.            |
| **Vòng lặp Đăng ký / Các Lựa chọn bị Làm mờ (Greyed Out)** | Người dùng không có MFA hiện tại và CA yêu cầu Phishing-Resistant MFA để truy cập "Register Security Info".                                                                       | **Lỗi Bootstrapping.** Phát hành một **Temporary Access Pass (TAP)** để bỏ qua kiểm tra MFA cho phiên đăng nhập ban đầu. |
| **Quét Mã QR Thất bại / Bị xoay vòng (Spins)**             | Bluetooth bị tắt trên một thiết bị, hoặc tường lửa đang chặn `cable.auth.com` WebSocket.                                                                                          | Bật Bluetooth (kiểm tra proximity). Đưa vào danh sách trắng (whitelist) các domain FIDO relay.                           |
| **Đăng ký Người dùng Khách Thất bại**                      | Entra ID chặn đăng ký FIDO2 của khách trong resource tenant.                                                                                                                      | **Không được sửa.** Hãy kích hoạt **Cross-Tenant Access Trust** để chấp nhận claim MFA của home tenant thay thế.         |

## 9. Theo dõi triển khai với Phishing-Resistant Passwordless Workbook

Microsoft đã phát hành một
[Phishing-Resistant Passwordless Workbook](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication)
(Bảng phân tích không mật khẩu chống phishing) mà các tổ chức có nhật ký (logs) trong
Azure Monitor có thể sử dụng để theo dõi tiến độ triển khai. Truy cập nó qua trung tâm
quản trị Entra ở phần **Monitoring > Workbooks**:

![Microsoft Entra workbooks hiển thị tùy chọn Triển khai Không mật khẩu Chống Phishing](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/phishing_resistant_passwordless_workbook_6b06c63518.png)

Workbook này có hai phần chính:

### 9.1 Giai đoạn Độ Sẵn Sàng Đăng Ký (Enrollment Readiness)

Sử dụng tab này để phân tích nhật ký đăng nhập và xác định người dùng nào đã sẵn sàng cho
việc đăng ký so với những người dùng có thể bị chặn. Bạn có thể lọc theo nền tảng Hệ điều
hành (Windows, macOS, [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios),
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) và loại chứng danh (Authenticator App
Passkey, FIDO2 [Security Key](https://www.corbado.com/glossary/security-key), Certificate-Based Authentication):

![Giai đoạn Sẵn sàng Đăng ký hiển thị phân tích sự sẵn sàng của thiết bị với Cặp Người dùng/Thiết bị Đã Sẵn sàng và Chưa Sẵn sàng](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/enrollment_phase_165ed80a39.png)

Workbook sẽ hiển thị:

- **Cặp Người dùng/Thiết bị Đã Sẵn sàng Đăng ký**: người dùng có thể đăng ký loại chứng
  danh đã chọn
- **Cặp Người dùng/Thiết bị Chưa Sẵn sàng**: người dùng có thể gặp sự cố đăng ký (ví dụ:
  phiên bản HĐH lỗi thời)

Bạn có thể xuất danh sách những người dùng cần hành động khắc phục (ví dụ: nâng cấp hệ
điều hành, thay thế thiết bị hoặc các tùy chọn chứng danh thay thế).

### 9.2 Giai đoạn Độ Sẵn Sàng Thực Thi (Enforcement Readiness)

Khi người dùng đã sẵn sàng cho việc xác thực chỉ-dùng-chống-phishing, hãy sử dụng tab
Enforcement Readiness. Đầu tiên, hãy tạo một chính sách Conditional Access dạng
**Report-Only (Chỉ báo cáo)** yêu cầu MFA chống phishing. Điều này sẽ điền vào các nhật ký
đăng nhập những dữ liệu về việc truy cập _lẽ ra có bị chặn hay không_ nếu thực thi được
kích hoạt.

![Giai đoạn Độ sẵn sàng Thực thi hiển thị sự cố thỏa mãn chính sách với Phân tích Dữ liệu Chuyên sâu (Further Data Analysis)](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/detail_analysis_workbook_1c0931ee47.png)

Bảng điều khiển hiển thị:

- **Tổng số người dùng (Total users)** trong phạm vi
- **Thành công khi chỉ báo cáo (Report Only Success)** - người dùng sẽ vượt qua việc thực
  thi
- **Chính sách Không được thỏa mãn (Policy Not Satisfied)** - người dùng sẽ bị chặn (hãy
  điều tra những người này!)
- Báo cáo chia theo **Trạng thái thiết bị (Device State)**, **Nền tảng Thiết bị (Device
  Platform)** và **Ứng dụng Máy khách (Client App)**

Sử dụng tab **Further Data Analysis (Phân tích dữ liệu chuyên sâu)** để điều tra lý do tại
sao một số người dùng nhất định sẽ bị chặn. Dữ liệu này giúp bạn nhắm mục tiêu người dùng
để khắc phục trước khi kích hoạt việc thực thi.

### 9.3 Triển khai theo đợt (wave-based) với sự theo dõi của help desk

Microsoft khuyên bạn nên thực hiện việc triển khai theo từng đợt (waves) với khoảng ngày
linh hoạt. Theo dõi lượng ticket (phiếu hỗ trợ) của helpdesk như một tín hiệu:

- **Lượng ticket tăng lên:** Làm chậm lại các hoạt động triển khai, truyền thông và thực
  thi
- **Lượng ticket giảm xuống:** Đẩy mạnh các hoạt động trở lại

Tạo các nhóm bảo mật Microsoft Entra ID cho mỗi đợt và thêm các nhóm vào các chính sách
của bạn một cách dần dần. Điều này ngăn việc các nhóm hỗ trợ bị quá tải.

## 10. Danh sách kiểm tra thử nghiệm Passkey Đồng Bộ (Synced Passkey)

Nếu mục tiêu là **passkey đồng bộ mà không có sự phụ thuộc vào Microsoft Authenticator**,
hãy làm theo hướng dẫn thử nghiệm (pilot) này:

1. **Kích hoạt passkey đồng bộ (preview)** Theo dõi tài liệu
   [Synced passkeys (preview)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys).

2. **Sử dụng Passkey Profiles (preview) và nhắm mục tiêu vào nhóm thử nghiệm** Tạo/gán một
   profile cho phép passkey đồng bộ như được mô tả trong
   [Passkey Profiles](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles).

3. **Không bắt buộc chứng thực (ít nhất là cho nhóm thử nghiệm)** Bắt buộc chứng thực sẽ
   loại trừ passkey đồng bộ theo tài liệu
   [khái niệm Passkeys (FIDO2)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2).

4. **Tránh các danh sách cho phép AAGUID quá nghiêm ngặt trong giai đoạn đầu** Bắt đầu một
   cách nới lỏng (permissive) để xác nhận luồng, sau đó siết chặt các hạn chế khi bạn biết
   nhà cung cấp nào bạn muốn cho phép. Xem
   [Bật passkeys (FIDO2)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2).

5. **Xác nhận Conditional Access không ép buộc Microsoft Authenticator** Đảm bảo CA/độ
   mạnh xác thực (auth strengths) vẫn cho phép passkey profile mà bạn dự định (nếu không,
   nó trông giống như sự phụ thuộc vào Microsoft Authenticator).

6. **Xác thực mô hình danh tính (member so với guest)** Nếu người dùng là khách, hãy xác
   nhận khả năng được hỗ trợ như mong đợi trong mô hình tenant của bạn trước khi dành thời
   gian tinh chỉnh các profile.

## 11. Kết luận

Triển khai passkey trong doanh nghiệp khá phức tạp về mặt vận hành, nhưng lộ trình phát
triển đã được vạch ra rõ ràng. Dưới đây là những câu trả lời cốt lõi, tương ứng với các
câu hỏi vận hành chính đã nêu ở trên:

1. **Passkey gắn liền thiết bị vs passkey đồng bộ:** Chứng danh gắn liền thiết bị (ví dụ:
   Microsoft Authenticator, Windows Hello, YubiKey, smartcard) bị ràng buộc chặt chẽ với
   một thiết bị duy nhất và thỏa mãn [AAL3](https://www.corbado.com/blog/nist-passkeys). Passkey đồng bộ (ví dụ:
   [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), Google Password Manager) hoạt động chéo
   trên nhiều thiết bị và đáp ứng [AAL2](https://www.corbado.com/blog/nist-passkeys). Hầu hết các tổ chức đều cần
   cả hai: trình xác thực phần cứng cho quản trị viên (AAL3) và passkey đồng bộ cho lực
   lượng lao động phổ thông (AAL2).

2. **Bootstrapping nhân viên mới:** Sử dụng Temporary Access Pass (TAP) để giải quyết vấn
   đề con gà và quả trứng ở bước onboarding. Đối với các đợt triển khai quy mô lớn, hãy tự
   động hóa việc này qua Graph API. Đối với các trường hợp sử dụng cần sự bảo đảm cao, bổ
   sung cho quy trình onboarding bằng Entra Verified ID và Face Check.

3. **Khôi phục khi đổi điện thoại:** Cung cấp nhiều phương pháp khôi phục: Kiosk Khôi Phục
   Tự Phục Vụ (sử dụng laptop làm thiết bị bootstrap), TAP do Người Quản Lý Hỗ Trợ qua My
   Staff, và SSAR (Khôi Phục Tài Khoản Tự Phục Vụ) với Verified ID đối với các trường hợp
   đặc thù (edge cases).

4. **Lỗi cấu hình:** Các bước sai lầm phổ biến nhất bao gồm bắt buộc chứng thực
   (attestation) trên toàn cầu, không bật các tính năng preview cho passkey đồng bộ, danh
   sách cho phép (allow-list) AAGUID quá khắt khe, và các chính sách Conditional Access
   (CA) tạo ra sự phụ thuộc vòng tròn (circular dependencies).

5. **Khách B2B:** Tránh việc đăng ký passkey trực tiếp cho khách B2B trong tenant của bạn.
   Thay vào đó, hãy kích hoạt Truy cập Chéo Tenant (Cross-Tenant Access Trust) để xác thực
   chứng danh từ home tenant của người khách.

6. **Khóa phần cứng vs passkey trên thiết bị di động:**
   [Khóa bảo mật phần cứng](https://www.corbado.com/vi/blog/khoa-bao-mat-phan-cung-fido2-tot-nhat-2025) được yêu
   cầu đối với một số vai trò bảo mật cao (quản trị viên, máy trạm dùng chung) nhưng lại
   mang tới những rào cản hậu cần ở quy mô lớn. Passkey di động nhìn chung thiết thực hơn
   đối với lực lượng lao động.

7. **macOS song song với Windows:** Sử dụng Platform SSO với JAMF/MDM để bật hỗ trợ
   passkey trên macOS song song với việc triển khai Windows. Hãy lên kế hoạch cho các
   luồng quy trình làm việc dành riêng cho từng nền tảng.

8. **Biện pháp chủ động:** Sử dụng Intune để xác định các thiết bị không hoạt động và nhắc
   nhở người dùng khắc phục trước khi việc bị khóa diễn ra. Cân nhắc biến việc đăng ký
   passkey trở thành điều kiện tiên quyết cho đăng ký Intune để thúc đẩy sự đón nhận sớm.
   Xây dựng một quy trình khôi phục tự phục vụ sử dụng laptop như các thiết bị bootstrap.

Công nghệ đã sẵn sàng. Thách thức chính là việc thực thi trong vận hành. Kế hoạch phục hồi
phải là thành phần cốt lõi ngay từ ngày đầu, không phải là thứ để nghĩ đến sau. Khi cơ sở
hạ tầng đã vững chắc, hãy tập trung vào việc tối ưu hóa tỷ lệ chấp nhận đăng nhập bằng
passkey để đảm bảo passkey trở thành phương thức xác thực chính trong toàn bộ lực lượng
lao động của bạn.

## Câu Hỏi Thường Gặp (FAQ)

### Tại sao việc bật MFA chống phishing trong Conditional Access lại khóa tất cả người dùng của tôi?

Tạo chính sách Conditional Access yêu cầu MFA chống phishing cho tất cả các ứng dụng đám
mây (cloud apps) ngay lập tức chặn bất kỳ người dùng nào chưa đăng ký passkey, bao gồm cả
việc chặn truy cập vào chính trang đăng ký Security Info. Sự phụ thuộc vòng tròn này, được
gọi là nghịch lý 'Đăng ký Thông tin Bảo mật', có nghĩa là bạn phải cấp một Temporary
Access Pass (Mật mã truy cập tạm thời) cho những người dùng bị ảnh hưởng trước khi kích
hoạt việc thực thi để họ có thể hoàn tất đăng ký ban đầu.

### Làm cách nào để xử lý người dùng khách B2B khi tenant của tôi yêu cầu MFA chống phishing?

Entra ID không hỗ trợ người dùng khách đăng ký khóa FIDO2 trong một resource tenant, do đó
nỗ lực thực thi đăng ký passkey cho khách sẽ thất bại. Cách khắc phục đúng là cấu hình Cài
đặt Truy cập Chéo Tenant (Cross-Tenant Access Settings) trong External Identities để tin
tưởng (trust) các yêu cầu bồi thường (claim) MFA từ home tenant của người dùng khách,
nghĩa là một chiếc YubiKey được sử dụng trong tổ chức riêng của họ sẽ thỏa mãn yêu cầu MFA
chống phishing của bạn mà không cần bất kỳ sự đăng ký nào trong tenant của bạn.

### Điều gì khiến xác thực mã QR chéo thiết bị thất bại trong im lặng khi đăng nhập bằng passkey?

Xác thực Chéo Thiết bị (Cross-Device Authentication) yêu cầu bật Bluetooth trên cả PC và
điện thoại để hoàn tất bắt tay tiệm cận BLE (BLE proximity handshake), vì vậy bất kỳ chính
sách nào của công ty vô hiệu hóa Bluetooth sẽ phá vỡ hoàn toàn luồng quy trình này. Luồng
này cũng sử dụng kết nối WebSocket tới cable.auth.com, điều mà các tường lửa hoặc cấu hình
Zscaler thường xuyên chặn, khiến việc quét
[mã QR](https://www.corbado.com/vi/blog/phuong-phap-dang-nhap-xac-thuc-ma-qr) bị treo hoặc thất bại mà không có
thông báo lỗi rõ ràng.

### Làm cách nào để giám sát nhân viên nào đã sẵn sàng cho việc thực thi MFA chống phishing trước khi tôi bật nó?

Bảng phân tích Phishing-Resistant Passwordless Workbook của Microsoft, có thể truy cập qua
trung tâm quản trị Entra ở phần Monitoring &gt; Workbooks, cung cấp giao diện Độ Sẵn Sàng
Đăng Ký (Enrollment Readiness) hiển thị các cặp người dùng/thiết bị có thể đăng ký theo
nền tảng và loại chứng danh. Để biết mức độ sẵn sàng thực thi (enforcement readiness), hãy
tạo chính sách Conditional Access dạng chỉ báo cáo (report-only) yêu cầu MFA chống
phishing để các nhật ký đăng nhập hé lộ những người dùng nào sẽ bị chặn trước khi bạn kích
hoạt việc thực thi trực tiếp.

### Chiến lược khôi phục tốt nhất cho những nhân viên có điện thoại mới và mất quyền truy cập vào passkey của họ là gì?

Phương pháp được khuyến nghị là phân lớp: một Kiosk Khôi Phục Tự Phục Vụ (Self-Service
Recovery Kiosk) sử dụng laptop được bảo mật bằng WHfB tạo ra Temporary Access Pass thông
qua Graph API và giải quyết hầu hết các trường hợp mà không cần đến sự tham gia của
helpdesk. Đối với những người dùng không có laptop, TAP do Người quản lý hỗ trợ
(Manager-Assisted TAP) thông qua cổng My Staff ủy quyền việc khôi phục cho các quản lý
trực tiếp, và Khôi Phục Tài Khoản Tự Phục Vụ (Self-Service Account Recovery) với sinh trắc
học Face Check của Entra Verified ID xử lý các trường hợp đặc biệt yêu cầu xác minh lại
toàn bộ danh tính.

## Đọc thêm

Để tìm hiểu sâu hơn về các đợt triển khai FIDO2/passkey cho doanh nghiệp, hãy theo dõi các
chuyên gia như **[Merill Fernando](https://au.linkedin.com/in/merill)** và
**[Jan Bakker](https://www.linkedin.com/in/jan-bakker/)**, những người thường xuyên xuất
bản các hướng dẫn thực tế về việc xác thực Microsoft Entra.
