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

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 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 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?
5. Làm cách nào để xử lý người dùng khách B2B khi yêu cầu MFA chống phishing?
6. Tôi có nên sử dụng khóa bảo mật phần cứng (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).

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). 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)
• 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

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).

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, Google Password Manager hoặc các nhà cung cấp bên thứ ba). 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). Để kích hoạt và kiểm soát passkey đồng bộ, Entra sử dụng Passkey Profiles (preview).

Mức độ phù hợp với quy định: Gần đây đã được NIST SP 800-63B 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" 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 của luồng khôi phục tài khoản của nhà cung cấp đám mây.

Dưới đây là tổng quan về các nhà cung cấp passkey đồng bộ được Entra hỗ trợ:

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) và một passkey gắn liền thiết bị (YubiKey 5C NFC) hiển thị:

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 dựa trên phần cứng, gắn liền thiết bị (như YubiKey hoặc 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.
• 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 đố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 chống phishing, chúng phải chạy các phiên bản tối thiểu này:

Các hệ điều hành cũ hơn có thể yêu cầu trình xác thực bên ngoài (khóa bảo mật FIDO2) để hỗ trợ xác thực không mật khẩu 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, 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 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 không phải là đường dẫn Conditional Create, và đặc biệt là Edge báo cáo hỗ trợ Conditional Create 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ề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 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ều thiết bị):

Chứng danh cục bộ (Local credentials) (cụ thể cho từng thiết 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 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 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 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. Đ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 (Security Key)
• Khóa phần cứng (Hardware Key)
• YubiKey
• Không mật khẩu (passwordless)
• Windows Security
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft 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 và SSPR cũ không còn được dùng nữa. Tất cả cấu hình FIDO2 phải diễn ra trong blade Authentication Methods Policy 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 (ví dụ: YubiKey 5 NFC, Microsoft Authenticator trên iOS, 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 cao, hãy sử dụng cài đặt "Enforce Key Restrictions" để chỉ Cho phép (Allow) các 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 "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, Bitwarden hoặc Google Password Manager) thường không hỗ trợ chứng thực 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" (No 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):

• Profile A (Quản trị viên): Enforce Attestation = Yes
• Profile B (Nhân viên chung): Enforce Attestation = No

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

Hãy coi 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 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)"

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:

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 cụ thể:

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).

• Độ 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" 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, 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:

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ý.

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ê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. 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" 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:

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 của Mac
• Trải nghiệm 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/AAL3

Lưu ý: macOS Platform 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)
• Cấu hình profile sử dụng 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 (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 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, quét sinh trắc học 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) 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.

• 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 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 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 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 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.
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 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#

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 đó 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 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.
• 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 trên PC bằng điện thoại của họ).

• Sự phụ thuộc Bluetooth: 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 (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 để 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 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 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.

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 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) 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.

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 (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. 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 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 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 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 (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 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 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 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ố#

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

Microsoft đã phát hành một Phishing-Resistant Passwordless Workbook (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:

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, Android) và loại chứng danh (Authenticator App Passkey, FIDO2 Security Key, Certificate-Based Authentication):

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.

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).

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.

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).

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).

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. Passkey đồng bộ (ví dụ: iCloud Keychain, Google Password Manager) hoạt động chéo trên nhiều thiết bị và đáp ứng AAL2. 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 đượ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.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

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 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 > 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 và 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.