New: Passkey Benchmark 2026 - 8 production KPIs to compare your passkey rolloutcompare your passkey rollout
Quay lại tổng quan

Hướng dẫn: Mua hay tự xây dựng giải pháp Passkey?

Nên mua hay tự xây dựng giải pháp passkey? Khám phá ưu và nhược điểm của passkey tự làm so với các giải pháp từ nhà cung cấp passkey (SaaS & on-prem), những thách thức, chi phí và phương pháp hay nhất.

Vincent Delitz
Vincent Delitz

Đã tạo: 7 tháng 3, 2025

Đã cập nhật: 27 tháng 5, 2026

Hướng dẫn: Mua hay tự xây dựng giải pháp Passkey?

Trang này được dịch tự động. Đọc phiên bản gốc bằng tiếng Anh tại đây.

Tải xuống toàn bộ Hướng dẫn Mua hay Tự xây dựng Passkey#

Tải xuống miễn phí toàn bộ Hướng dẫn Mua hay Tự xây dựng Passkey và nhận quyền truy cập vào tất cả các thông tin chuyên sâu.

  • ✅ Được yêu cầu bởi các nhóm tại Adidas, Woolworths & Mitsubishi
  • ✅ Danh sách đầy đủ các khối xây dựng & mô hình chi phí để quyết định giữa mua và tự xây dựng
  • ✅ Khung quyết định 50 trang thực tế

Mua hay Tự xây dựng một giải pháp Passkey?

Tải xuống toàn bộ Hướng dẫn Mua hay Tự xây dựng

Nhận danh sách kiểm tra đầy đủ cho việc triển khai passkey, so sánh các giải pháp tự làm so với nhà cung cấp (SaaS & on-prem), các thách thức chính, chi phí và các phương pháp hay nhất.

Tải xuống toàn bộ Hướng dẫn Mua hay Tự xây dựng

Tải xuống miễn phí Hướng dẫn Mua hay Tự xây dựng

Thông tin chính
  • Đối với hầu hết các đợt triển khai quy mô lớn cho người tiêu dùng, việc mua một giải pháp từ nhà cung cấp passkey mang lại thời gian triển khai nhanh hơn, TCO (Tổng chi phí sở hữu) thấp hơn và tỷ lệ áp dụng cao hơn so với tự xây dựng nội bộ.
  • Một ngưỡng áp dụng quan trọng từ 50-80% người dùng hoạt động phải đạt được trước khi việc loại bỏ mật khẩu trở nên khả thi, làm cho công cụ áp dụng trở thành một yếu tố quyết định giữa việc xây dựng hay mua.
  • Hơn 27% các lần đăng nhập bằng mật khẩu thất bại, trong khi xác thực bằng passkey đạt tỷ lệ thành công 95-97%, trực tiếp cải thiện tỷ lệ chuyển đổi trong thương mại điện tử và bán lẻ.
  • Passkey mang lại tốc độ tăng từ 3-5 lần so với mật khẩu kết hợp SMS MFA, tương quan với sự hài lòng của người dùng cao hơn và việc sử dụng bền vững.
  • Các thư viện WebAuthn mã nguồn mở cung cấp một điểm khởi đầu nhưng thiếu tính bảo mật cấp doanh nghiệp, UX được tối ưu hóa và các tính năng nâng cao khả năng áp dụng cần thiết cho việc triển khai quy mô lớn.

1. Động lực: Tôi có nên Mua hay Tự xây dựng Giải pháp Xác thực bằng Passkey?#

Ý tưởng tự xây dựng bản triển khai passkey nghe có vẻ hấp dẫn: kiểm soát hoàn toàn, tích hợp tùy chỉnh và không bị phụ thuộc vào nhà cung cấp. Xét cho cùng, FIDO2 dựa trên các tiêu chuẩn mở và việc viết những dòng mã WebAuthn đầu tiên dường như khá dễ dàng. Nó thực sự khó đến mức nào?

Nhưng đây thường là nơi bắt đầu của sự phức tạp, đặc biệt là khi bạn có kế hoạch xây dựng một giải pháp cho kịch bản triển khai quy mô lớn cho hàng triệu người tiêu dùng trong các ngành như:

  • Ngân hàng & Dịch vụ Tài chính (ví dụ: trực tuyến, ngân hàng, thanh toán, fintech)
  • Chính phủ & Dịch vụ Công (ví dụ: cổng thông tin công dân, nền tảng thuế & an sinh xã hội)
  • Bảo hiểm & Chăm sóc sức khỏe (ví dụ: cổng thông tin bệnh nhân, nền tảng bảo hiểm kỹ thuật số)
  • Thương mại điện tử & Bán lẻ (ví dụ: thị trường trực tuyến, chương trình khách hàng thân thiết)
  • Viễn thông & Tiện ích (ví dụ: nhà mạng di động, nhà cung cấp năng lượng)
  • Du lịch & Khách sạn (ví dụ: tài khoản hàng không, chương trình khách hàng thân thiết của khách sạn)

Thách thức thực sự bắt đầu sau lần đăng nhập passkey thành công đầu tiên và thường chỉ lộ diện trong khi bạn đang triển khai giải pháp passkey của mình. Đột nhiên, những thứ như các trường hợp ngoại lệ kỳ lạ, lỗi người dùng gây nhầm lẫn và khả năng người dùng bị khóa do sự không khả dụng của passkey xuất hiện. Những gì tưởng chừng như là một sự tích hợp đơn giản lại biến thành nhiều tháng hoặc thậm chí nhiều năm nỗ lực phát triển, chi phí bảo trì không mong muốn và một dự án passkey có khả năng thất bại.

Tuy nhiên, tự xây dựng giải pháp của riêng bạn cũng có thể là sự lựa chọn phù hợp cho một số tổ chức và yêu cầu cụ thể. Chúng tôi đã nói chuyện với hàng chục tổ chức về kế hoạch triển khai passkey của họ và đồng hành cùng một số tổ chức trong hành trình của họ một cách thực tế. Hướng dẫn này sẽ giúp bạn xác định khi nào cách tiếp cận passkey Tự làm (DIY) có thể hợp lý và khi nào việc chọn một nhà cung cấp passkey lâu năm là quyết định thông minh hơn.

Với Hướng dẫn Mua hay Tự xây dựng Passkey của chúng tôi, chúng tôi muốn trả lời các câu hỏi sau:

  1. Cần những thành phần nào để triển khai passkey và chuyển sang không mật khẩu?
  2. Tôi có nên triển khai passkey nội bộ hay sử dụng nhà cung cấp passkey bên ngoài?
  3. Lợi ích của việc có nhà cung cấp passkey là gì khi đã có các thư viện mã nguồn mở?
  4. Những thách thức lớn nhất trong việc xây dựng một giải pháp passkey là gì?
  5. Những rủi ro của việc triển khai passkey nội bộ là gì?

2. Điều kiện tiên quyết: Tại sao Passkey lại là Tiêu chuẩn Đăng nhập mới#

Mật khẩu đã lỗi thời, không an toàn và gây bực bội. Passkey loại bỏ rủi ro lừa đảo (phishing), cải thiện trải nghiệm người dùng và đơn giản hóa quá trình xác thực - làm cho chúng trở thành tiêu chuẩn mới của đăng nhập an toàn. Cho dù bạn xây dựng nội bộ hay sử dụng giải pháp bên ngoài, việc tích hợp passkey là một bước nâng cấp lớn về bảo mật và khả năng sử dụng.

Google nhận thấy rằng việc bắt đầu với câu chuyện về sự dễ sử dụng hoặc tốc độ sẽ tạo được tiếng vang và mang lại hiệu quả. Mọi người thường cằn nhằn về việc đăng nhập, vì vậy bất cứ điều gì làm cho quá trình này dễ dàng và nhanh chóng hơn đều là một chiến thắng.

Bên cạnh những lợi ích bảo mật này, có tiềm năng rất lớn để tiết kiệm chi phí hoạt động với passkey. Bạn có thể giảm số lượng SMS OTP được gửi cho người dùng, điều này có thể tích tụ rất lớn đối với các cơ sở người dùng quy mô lớn. Hơn nữa, gánh nặng mà việc khôi phục mật khẩu và MFA đặt lên đội ngũ hỗ trợ khách hàng của bạn cũng là một yếu tố chi phí có thể được loại bỏ.

Ngoài ra, passkey cải thiện tỷ lệ đăng nhập thành công và thời gian đăng nhập cho người dùng, cuối cùng dẫn đến tỷ lệ chuyển đổi tốt hơn, đây là động lực chính cho sự tăng trưởng doanh thu ở các ngành như thương mại điện tử, bán lẻ hoặc du lịch.

3. Hành trình Không mật khẩu: Passkey đóng vai trò như thế nào?#

Mục tiêu cuối cùng của nhiều tổ chức khi xem xét việc áp dụng passkey là tiến tới hoàn toàn không sử dụng mật khẩu. Để đạt được mục tiêu này, thường có bốn giai đoạn cần hoàn thành. Tốc độ tiến triển của các giai đoạn này phụ thuộc phần lớn vào khả năng kỹ thuật, mô hình đăng nhập và cơ sở người dùng của tổ chức. Trong một số trường hợp, các yếu tố bên ngoài như áp lực từ công chúng trong việc áp dụng xác thực an toàn hơn hoặc các hạn chế tài chính cũng có thể đóng một vai trò.

Hãy cùng xem xét và mô tả bốn giai đoạn này, vì việc triển khai passkey chỉ là một bước trong việc đảm bảo thành công của một dự án passkey.

3.1 Giai đoạn 1: Tích hợp Passkey#

Bước đầu tiên trong quá trình chuyển đổi sang một hệ thống hoàn toàn không mật khẩu là tích hợp passkey làm một phương thức đăng nhập. Ở giai đoạn này, mật khẩu và các phương thức xác thực khác vẫn được giữ lại làm phương án dự phòng để đảm bảo người dùng vẫn có thể truy cập tài khoản của họ nếu họ chưa áp dụng passkey. Tích hợp thành công đòi hỏi khả năng tương thích liền mạch với các luồng đăng nhập hiện có và chính sách bảo mật. Các tổ chức nên tập trung vào việc làm cho việc tạo passkey trở nên đơn giản, đảm bảo rằng cả người dùng kỹ thuật và không am hiểu kỹ thuật đều có thể áp dụng phương thức xác thực mới mà không gặp rào cản nào.

Igor Gjorgjioski Testimonial

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

3.2 Giai đoạn 2: Tăng cường Áp dụng Passkey#

Khi passkey đã được tích hợp, thách thức tiếp theo là thúc đẩy người dùng áp dụng passkey. Nhiều tổ chức đánh giá thấp tầm quan trọng của giai đoạn này, nhưng nếu không có sự áp dụng rộng rãi của người dùng, một dự án passkey rất có thể sẽ thất bại. Mục tiêu là khuyến khích càng nhiều người dùng càng tốt tạo và sử dụng passkey, lý tưởng nhất là biến chúng thành phương thức đăng nhập mặc định.

Các chiến thuật chính để tăng cường sự áp dụng bao gồm giáo dục người dùng một cách chủ động, các gợi ý (nudge) trên giao diện người dùng để thúc đẩy việc tạo passkey và các chương trình ưu đãi thưởng cho người dùng chuyển đổi. Các tổ chức nên thiết lập một ngưỡng áp dụng quan trọng, chẳng hạn như 50-80% người dùng hoạt động sử dụng passkey, trước khi chuyển sang giai đoạn tiếp theo. Để hiểu sâu hơn về lý do tại sao sự áp dụng lại quan trọng, hãy tham khảo bài viết chuyên sâu của chúng tôi về cách tỷ lệ áp dụng kém có thể gây nguy hiểm cho dự án passkey của bạn.

3.3 Giai đoạn 3: Loại bỏ Mật khẩu#

Khi việc áp dụng passkey đạt đến một khối lượng tới hạn, các tổ chức có thể bắt đầu loại bỏ dần mật khẩu. Tuy nhiên, việc loại bỏ mật khẩu quá sớm hoặc không có kế hoạch cẩn thận có thể dẫn đến các vấn đề về khả năng sử dụng và gia tăng yêu cầu hỗ trợ. Nên áp dụng phương pháp theo từng giai đoạn:

  • Bắt đầu bằng cách loại bỏ mật khẩu khỏi các tài khoản nơi người dùng liên tục xác thực bằng passkey.
  • Cung cấp tùy chọn loại bỏ mật khẩu trong cài đặt tài khoản cho những người dùng sớm.
  • Sử dụng các hiểu biết dựa trên dữ liệu để xác định người dùng nào đã sẵn sàng chuyển sang hoàn toàn không mật khẩu. Ví dụ: những người dùng có nhiều passkey được đăng ký trên các thiết bị khác nhau có thể được ưu tiên loại bỏ mật khẩu.
  • Chủ động truyền đạt lợi ích của việc loại bỏ mật khẩu để xây dựng niềm tin cho người dùng.

Bằng cách hướng dẫn người dùng một cách có chiến lược hướng tới xác thực hoàn toàn không mật khẩu, các tổ chức có thể tối đa hóa bảo mật mà không làm gián đoạn trải nghiệm người dùng.

3.4 Giai đoạn 4: Tự động hóa Khôi phục Tài khoản#

Sau khi mật khẩu bị loại bỏ, các cơ chế khôi phục tài khoản phải trở nên mạnh mẽ và an toàn. Các phương pháp khôi phục truyền thống thường dựa vào các can thiệp thủ công, chẳng hạn như phiếu hỗ trợ (support ticket) hoặc đặt lại qua email, có thể gây ra rủi ro bảo mật và chi phí hoạt động. Các tổ chức phải triển khai các giải pháp khôi phục tài khoản tự phục vụ, hiện đại để duy trì bảo mật đồng thời cải thiện trải nghiệm người dùng.

Các yếu tố chính của việc khôi phục tài khoản tự động bao gồm:

  • Kiểm tra tính sống (Liveness checks): Ngăn chặn việc chiếm đoạt tài khoản trái phép bằng cách đảm bảo người dùng đang có mặt tại thời điểm đó.
  • Xác minh ID: Tận dụng ID do chính phủ cấp và xác minh sinh trắc học để xác nhận danh tính.
  • Passkey dự phòng (Fallback passkeys): Cho phép người dùng khôi phục tài khoản bằng cách sử dụng các passkey dự phòng được lưu trữ trên các thiết bị khác của họ.

Nhiều tổ chức đã tự đầu tư vào các quy trình khôi phục tự động độc lập với quá trình chuyển đổi không mật khẩu của họ để giảm chi phí và nâng cao khả năng sử dụng. Tuy nhiên, trong một hệ sinh thái dựa trên passkey, các cơ chế này càng trở nên quan trọng hơn để duy trì bảo mật và giảm thiểu ma sát.

Dựa trên bốn giai đoạn này, giờ đây chúng tôi sẽ cố gắng giúp bạn đánh giá quyết định mua hay tự xây dựng. Do đó, điều rất quan trọng đối với thành công lâu dài của dự án passkey của bạn là phải ghi nhớ tất cả các giai đoạn và không chỉ tích hợp passkey (đây vẫn có thể là một mục tiêu nhưng sau đó bạn bỏ lỡ toàn bộ tiềm năng của passkey).

4. Cách Xác định Phương pháp Passkey phù hợp#

Việc lựa chọn giữa giải pháp DIY và giải pháp passkey bên ngoài phụ thuộc vào nguồn lực kỹ thuật, ưu tiên bảo mật, quy mô triển khai và chiến lược passkey dài hạn của công ty bạn. Trong phần tiếp theo, chúng tôi sẽ phân tích các khía cạnh chính để giúp bạn đưa ra quyết định tốt nhất.

Bảng sau hiển thị các tiêu chí đánh giá khác nhau mà bạn cần xem xét. Dựa trên nhận định mà bạn nghiêng về hơn, các số điểm khác nhau sẽ được cung cấp.

Cách sử dụng ma trận đánh giá:

Đối với mỗi tiêu chí, hãy chọn xem công ty của bạn cần một giải pháp đơn giản hơn hay phức tạp hơn.

  • Gán 1 điểm cho mỗi câu trả lời mà mức độ phức tạp trong trường hợp của bạn là thấp nhất và phù hợp hơn với mô tả bên trái.
  • Gán 5 điểm cho mỗi danh mục nơi câu trả lời của bạn phù hợp hơn với mô tả mức độ phức tạp cao nhất bên phải.
  • Nếu bạn không chắc chắn, hãy sử dụng 3 điểm như một tùy chọn trung lập.

Tải xuống toàn bộ Hướng dẫn Mua hay Tự xây dựng Passkey#

Tải xuống miễn phí toàn bộ Hướng dẫn Mua hay Tự xây dựng Passkey và nhận quyền truy cập vào tất cả các tiêu chí đánh giá.

Mua hay Tự xây dựng một giải pháp Passkey?

Tải xuống toàn bộ Hướng dẫn Mua hay Tự xây dựng

Nhận danh sách kiểm tra đầy đủ cho việc triển khai passkey, so sánh các giải pháp tự làm so với nhà cung cấp (SaaS & on-prem), các thách thức chính, chi phí và các phương pháp hay nhất.

Tải xuống toàn bộ Hướng dẫn Mua hay Tự xây dựng

Tải xuống miễn phí Hướng dẫn Mua hay Tự xây dựng

5. Cách sử dụng hướng dẫn này một cách hiệu quả#

Khi quyết định nên xây dựng hay mua một giải pháp passkey, điều quan trọng là phải xem xét toàn bộ quy trình, không chỉ một giai đoạn duy nhất của việc triển khai passkey. Ngay cả khi ưu tiên trong thời gian tới của bạn là cung cấp passkey dưới dạng MVP, bạn vẫn nên lường trước những tác động dài hạn, đặc biệt là việc thúc đẩy sự áp dụng. Dưới đây là cách chúng tôi khuyên bạn nên sử dụng hướng dẫn này và diễn giải kết quả của bạn, nhấn mạnh lý do tại sao sự áp dụng lại quan trọng hơn hầu hết mọi yếu tố khác.

5.1 Tập trung vào Sự Áp dụng như là Yếu tố Thành công số 1#

Cho dù giải pháp passkey của bạn tiên tiến đến đâu, nếu người dùng không áp dụng nó bằng cách tạo passkey và sử dụng passkey để đăng nhập, toàn bộ dự án sẽ gặp rủi ro. Theo kinh nghiệm của chúng tôi, các tổ chức thường đánh giá thấp nỗ lực cần thiết để di chuyển người dùng khỏi mật khẩu. Ngay cả khi bạn triển khai passkey một cách liền mạch ở cấp độ kỹ thuật, sự áp dụng thấp sẽ dẫn đến:

  • Sự phụ thuộc liên tục vào mật khẩu, phủ nhận những lợi ích bảo mật của passkey.
  • ROI tối thiểu, vì việc tiết kiệm chi phí (ít lần đặt lại mật khẩu hơn, giảm SMS OTP) phụ thuộc vào việc sử dụng passkey đáng kể để đăng nhập.
  • Trải nghiệm người dùng bị phân mảnh, nếu hầu hết các lần đăng nhập vẫn diễn ra thông qua các phương pháp truyền thống và chỉ một nhóm nhỏ sử dụng passkey.

Sự áp dụng cao, đôi khi là 50% hoặc thậm chí +80% cơ sở người dùng của bạn, thường được yêu cầu trước khi bạn có thể đạt được những bước tiến có ý nghĩa hướng tới việc giảm hoặc loại bỏ hoàn toàn mật khẩu. Các tổ chức như Google và Amazon đặt ra các mục tiêu áp dụng rõ ràng và thực hiện một cách có hệ thống các thử nghiệm A/B, chiến dịch giáo dục người dùng và các gợi ý trên giao diện người dùng (UI nudges) để đảm bảo passkey được đón nhận rộng rãi. Sự nỗ lực tập trung này vào việc áp dụng không phải là tùy chọn; đó là điều biến việc triển khai passkey của bạn từ một tính năng thành một lợi thế cạnh tranh thiết thực.

5.2 Sử dụng Hướng dẫn một cách Toàn diện hoặc Theo Giai đoạn#

Hướng dẫn này được thiết kế để giúp bạn đưa ra những quyết định sáng suốt về việc triển khai passkey ở mọi giai đoạn của hành trình:

  1. Giai đoạn 1 (Tích hợp Passkey): Nếu bạn chỉ đơn giản đang cân nhắc xem có nên áp dụng passkey và cách tích hợp chúng hay không, hãy tập trung vào các tiêu chí Tự xây dựng hay Mua cho việc tích hợp passkey.
  2. Giai đoạn 2 (Tăng cường Sự áp dụng): Nếu bạn muốn passkey không chỉ là một tính năng, hãy lên kế hoạch từ sớm để thúc đẩy sự áp dụng của người dùng - ngay cả đối với một MVP vì nó đòi hỏi sự đầu tư công nghệ bổ sung, thường nhiều hơn đáng kể so với việc triển khai ban đầu.
  3. Giai đoạn 3 (Loại bỏ Mật khẩu): Nếu việc loại bỏ mật khẩu là một mục tiêu chiến lược dài hạn, hãy đảm bảo kiến trúc và luồng người dùng của bạn được thiết kế có lưu tâm đến bước đi cuối cùng đó.
  4. Giai đoạn 4 (Tự động hóa Khôi phục Tài khoản): Ngay cả khi hôm nay bạn chưa sẵn sàng chuyển sang hoàn toàn không mật khẩu, hãy đảm bảo phương pháp tiếp cận passkey của bạn có thể phát triển thành quá trình khôi phục mạnh mẽ, liền mạch để tránh các rào cản trong tương lai.

Trong số này, Giai đoạn 2 (Tăng cường Sự áp dụng) là quan trọng nhất. Bạn có thể đánh giá riêng từng phần, nhưng hãy nhớ rằng thành công dài hạn và ROI của bạn thường phụ thuộc vào mức độ nghiêm túc của bạn đối với việc áp dụng ngay từ đầu.

5.3 Thu hút Các Bên Liên quan Chính và Thống nhất về Các Mục tiêu Áp dụng#

Nếu bạn đang ở giai đoạn đầu của việc quyết định triển khai passkey, hãy bắt đầu với phần đầu tiên của ma trận đánh giá (tích hợp passkey) và điền vào đó với ban quản lý, IT, chủ sở hữu sản phẩm (product owner) và các nhà ra quyết định chính khác. Hãy tự hỏi bản thân:

  1. Tỷ lệ đăng nhập passkey mong muốn của chúng ta là bao nhiêu? 5% có đủ để chứng minh tính khả thi không hay chúng ta cần 50–80% trước khi chúng ta coi passkey là một thành công?
  2. Chúng ta có ngân sách và sự đồng tình của ban điều hành để chạy các thử nghiệm A/B trong nhiều tháng, chạy các chiến dịch tối ưu hóa, tạo tài liệu giáo dục và tinh chỉnh luồng người dùng liên tục để người dùng hiểu và muốn chuyển sang passkey không? Có đủ năng lực kỹ thuật để triển khai tất cả các báo cáo, phân tích và thử nghiệm cần thiết không? Chúng ta có thể phát hành (release) đủ thường xuyên để đạt được những mục tiêu đó không?
  3. Tầm nhìn dài hạn là gì? Chúng ta đang hướng tới việc loại bỏ mật khẩu hay chỉ cung cấp một giải pháp thay thế?

Việc trả lời những câu hỏi này ngay từ đầu đảm bảo dự án passkey của bạn không đi vào ngõ cụt. Các tổ chức không lập kế hoạch cho việc áp dụng thường thấy mình bị mắc kẹt với mật khẩu trong nhiều năm tới, làm suy yếu toàn bộ chiến lược bảo mật và trải nghiệm người dùng.

5.4 Càng rời xa "trung lập", Nhà Cung cấp càng trở nên có ý nghĩa#

Trong toàn bộ ma trận, mỗi tiêu chí đánh giá có thể đưa bạn từ mức độ phức tạp thấp nhất (1) đến mức độ phức tạp cao nhất (5). Càng nhiều câu trả lời của bạn chuyển sang và vượt qua vùng trung lập (3), thì trường hợp sử dụng nhà cung cấp passkey chuyên biệt càng mạnh mẽ:

  • Các yêu cầu có mức độ phức tạp cao - chẳng hạn như các phương pháp dự phòng nâng cao, tuân thủ nghiêm ngặt, phân tích chuyên sâu và UX đa thiết bị - làm nhân lên gánh nặng kỹ thuật và bảo trì của bạn.
  • Nhấn mạnh mạnh mẽ vào sự áp dụng - đạt được sự áp dụng passkey cao một cách nhanh chóng hoặc loại bỏ mật khẩu thường yêu cầu các luồng người dùng được kiểm tra kỹ lưỡng, đo lường từ xa (telemetry) chi tiết và các gợi ý có cấu trúc.

Những yếu tố này có thể làm quá tải các nhóm nội bộ, cả về kỹ thuật lẫn tổ chức. Một giải pháp passkey được quản lý thường có thể cung cấp các phương pháp hay nhất đã được chứng minh, các bản cập nhật nhanh chóng và chuyên môn trong thế giới thực để tăng tốc độ áp dụng nhanh hơn nhiều so với cách tiếp cận DIY.

5.5. Quan điểm của Corbado: Khi nào Nhà cung cấp là Lựa chọn Tốt hơn#

Là một chuyên gia về passkey, chúng tôi tại Corbado có một quan điểm mạnh mẽ. Nếu passkey nằm trên lộ trình của bạn và bạn muốn một bản triển khai hiện đại giúp tích cực thúc đẩy sự áp dụng, Corbado Connect có thể giúp bạn giải quyết sự phức tạp ở quy mô lớn. Dưới đây là lý do tại sao:

Sự áp dụng được tích hợp vào giải pháp: Nền tảng của chúng tôi được thiết kế xoay quanh việc tối đa hóa sự chọn tham gia (opt-in) của người dùng thông qua các gợi ý thông minh, phân tích và thử nghiệm A/B liên tục, điều này cũng thúc đẩy việc tiết kiệm chi phí.

Các Bước Tiếp Theo:

  1. Điền vào từng phần có liên quan của ma trận đánh giá - xem xét cả các mục tiêu trước mắt và dài hạn.
  2. Ưu tiên sự áp dụng trong quá trình ra quyết định của bạn - thống nhất với các bên liên quan về các mục tiêu áp dụng rõ ràng và nguồn lực để đạt được chúng.
  3. So sánh TCO (Tổng chi phí sở hữu) cho nội bộ so với giải pháp từ nhà cung cấp một khi bạn hiểu rõ độ phức tạp và tham vọng áp dụng của mình, và thực hiện quy trình nội bộ của bạn để đánh giá xây dựng hay mua.

  1. Tham khảo ý kiến các chuyên gia về passkey (như Corbado) nếu các mục tiêu chiến lược của bạn hướng tới một nền tảng được quản lý hoàn toàn xử lý hiệu quả cả những thách thức về kỹ thuật lẫn sự áp dụng.

Bằng cách giải quyết passkey một cách toàn diện và biến sự áp dụng thành một trong những mục tiêu chính, bạn sẽ đạt được kết quả tốt nhất. Điều đó có nghĩa là bảo mật mạnh mẽ hơn, đăng nhập đơn giản hơn và một con đường thực sự hướng tới tương lai không mật khẩu. Nếu bạn quan tâm đến việc tìm hiểu thêm về Corbado Connect và cách chúng tôi giúp khách hàng đạt được sự áp dụng passkey cao, chúng tôi luôn sẵn sàng trò chuyện.

6. Làm thế nào để đo lường sự thành công của một lần triển khai passkey?#

Bây giờ chúng tôi đã giúp xác định phương pháp tiếp cận đúng đắn để trả lời câu hỏi "Mua hay Tự xây dựng?", chúng tôi sẽ phân tích cách đánh giá sự thành công của một lần triển khai passkey. Do đó, chúng tôi định nghĩa các KPI đầu vào và đầu ra của một dự án passkey.

6.1 Các KPI đầu vào quan trọng của passkey là gì?#

Các KPI đầu vào giúp theo dõi sự áp dụng ở giai đoạn đầu của passkey và xem liệu các điều kiện cần thiết cho việc sử dụng rộng rãi có đang được thiết lập hay không. Những chỉ số này xuất hiện trước hành vi đăng nhập thực tế nhưng rất quan trọng để kích hoạt sự áp dụng có ý nghĩa và tối ưu hóa quá trình triển khai.

KPIĐịnh nghĩaTại sao nó quan trọngCách Đo lườngMốc chuẩn (Benchmark)
Tỷ lệ Chấp nhận Passkey (Passkey Acceptance Rate)Tỷ lệ người dùng, sau khi đăng nhập thành công (post-sign-in), nhận được một "gợi ý" (một dấu nhắc hoặc đề xuất khuyến khích họ thiết lập passkey) và chọn tạo passkey. KPI này đặc biệt đo lường mức độ phản hồi của người dùng đối với các lời nhắc sau khi đăng nhập này, nêu bật hiệu quả của thông điệp gợi ý trong việc thúc đẩy việc tạo passkey. Cách tiếp cận này được coi là hiện đại nhất vì người dùng thường không chủ động tạo passkey thông qua tài khoản hoặc cài đặt quản lý thông tin xác thực. Thay vào đó, passkey được áp dụng thành công nhất khi người dùng được nhắc trực tiếp sau khi đăng nhập, làm cho các gợi ý trở thành động lực chính của việc tạo passkey. Đảm bảo phân biệt giữa gợi ý đầu tiên và các gợi ý sau đó vì tỷ lệ này sẽ giảm xuống.Sự chấp nhận cao cho thấy sự thuyết phục người dùng và thiết kế gợi ý thành công. Tỷ lệ thấp báo hiệu sự cản trở, thông điệp không rõ ràng hoặc sự ngần ngại của người dùng.Công thức: (Số người dùng hoàn thành việc tạo passkey sau khi được gợi ý) ÷ (Số người dùng tiếp xúc với gợi ý). Phân khúc theo Hệ điều hành/Trình duyệt/Thiết bị.50%-75% ở lần gợi ý đầu tiên, lên đến 85% qua nhiều lần gợi ý trên thiết bị di động. Thấp hơn trên máy tính để bàn. Phụ thuộc nhiều vào cách diễn đạt và cách thực hiện.
Tỷ lệ Tạo Passkey Thành công (Passkey Creation Success Rate)Tỷ lệ người dùng bắt đầu quy trình đăng ký passkey nhưng hoàn thành thành công nó (nghĩa là không từ bỏ).Cho thấy có bao nhiêu người dùng bỏ cuộc giữa chừng trong quá trình tạo do UX khó hiểu, các sự cố kỹ thuật hoặc người dùng suy nghĩ lại.Công thức: (Số lượt đăng ký passkey hoàn thành) ÷ (Số lượt thử đăng ký) Phân tích các điểm thất bại theo Hệ điều hành/Trình duyệt/Thiết bị.Gần mức 100%.
Số lượng Passkey Được tạo (Number of Created Passkeys)Số lượng lũy kế của các passkey mới được tạo trong một khoảng thời gian nhất định (hàng ngày, hàng tuần, hàng tháng).Một thước đo áp dụng thô thường được coi là KPI bán đầu ra. Phản ánh khối lượng sử dụng passkey và khả năng chuyển đổi đăng nhập trong tương lai rời khỏi mật khẩu.Công thức: Tổng số tất cả các passkey mới được đăng ký trên các danh mục Hệ điều hành, Trình duyệt, Thiết bị. Theo dõi xu hướng tăng trưởng theo thời gian. Con số tuyệt đối không mang ý nghĩa mà phụ thuộc vào quy mô của cơ sở người dùng.Một số lượng đáng kể mỗi ngày ngay sau khi triển khai hoàn toàn.

Các KPI đầu vào này đóng vai trò là các chỉ số dẫn dắt cho sự áp dụng passkey trong tương lai và cho phép các tổ chức tinh chỉnh việc giáo dục người dùng, các luồng UX và việc thực hiện kỹ thuật.

6.2 Các KPI / OKR đầu ra quan trọng của passkey là gì?#

Các KPI đầu ra (OKR) đo lường sự thành công thực tế của việc áp dụng passkey bằng cách đánh giá hành vi người dùng, các cải tiến hoạt động và tác động kinh doanh. Các chỉ số này phản ánh hiệu quả trong thế giới thực của việc triển khai passkey. Tỷ lệ Đăng nhập Passkey là một KPI Đầu ra cốt lõi vì nó trực tiếp phản ánh sự áp dụng và việc sử dụng passkey thực tế. Tỷ lệ đăng nhập passkey ngày càng tăng cho thấy sự giới thiệu thành công và sự ưa thích liên tục của người dùng đối với passkey so với các phương thức xác thực cũ.

KPIĐịnh nghĩaTại sao nó quan trọngCách Đo lườngMốc chuẩn (Benchmark)
Tỷ lệ Kích hoạt Người dùng (User Activation Rate)Trong số tất cả những người dùng đã thấy ít nhất một gợi ý (có thể là nhiều lời nhắc theo thời gian), tỷ lệ phần trăm những người cuối cùng đã tạo ít nhất một passkey.Đo lường tổng thể thành công của việc giới thiệu passkey thông qua nhiều lần gợi ý. Người dùng có thể từ chối gợi ý đầu tiên nhưng sẽ chuyển đổi sau đó.Công thức: (Số người dùng duy nhất đã tạo ≥1 passkey) ÷ (Số người dùng duy nhất đã từng được hiển thị ít nhất một gợi ý) Phân khúc theo Hệ điều hành, trình duyệt, thiết bị để xem ai cuối cùng cũng áp dụng passkey. Một khi đợt triển khai phát triển, các passkey bị xóa cũng phải được phản ánh ở đây.Hơn 50% trong 12 tháng. Tỷ lệ đăng nhập passkey hội tụ về Tỷ lệ Kích hoạt Người dùng. Nó sẽ phụ thuộc vào thành phần người dùng của bạn.
Tỷ lệ Đăng nhập Passkey (Passkey Login Rate)Tỷ lệ phần trăm của tất cả các sự kiện đăng nhập được hoàn thành bằng cách sử dụng passkey thay vì phương pháp cũ (mật khẩu, SMS OTP, v.v.).Chứng minh tần suất sử dụng passkey trong thế giới thực. Tỷ lệ đăng nhập thấp liên tục chỉ ra rằng người dùng thích hoặc quay lại sử dụng mật khẩu bất chấp việc ban đầu đã tạo passkey, phản ánh tỷ lệ kích hoạt thấp (vì tỷ lệ đăng nhập cao chỉ có thể xảy ra nếu bản thân sự kích hoạt đã cao), hoặc do việc thực hiện đăng nhập chưa tối ưu không tự động tận dụng các passkey hiện có.Công thức: (Số lần đăng nhập bằng passkey) ÷ (Tổng số lần đăng nhập) Phân khúc theo Hệ điều hành/trình duyệt/thiết bị hoặc nhóm người dùng. Điều này giúp xác định vị trí các nền tảng hoặc nhóm nhân khẩu học gặp vấn đề với mức độ sử dụng passkey thấp.Hơn 20% trong vài tuần, hơn 50% trong 12 tháng. (Phụ thuộc nhiều vào cách bạn triển khai)
Tỷ lệ Đăng nhập Passkey Thành công (Passkey Login Success Rate)Tỷ lệ các lần thử đăng nhập bằng passkey kết thúc thành công mà không cần quay lại phương án dự phòng (fallback).Tiết lộ sự cản trở trong luồng passkey. Tỷ lệ thấp hơn có thể chỉ ra sự nhầm lẫn của người dùng, những ràng buộc về môi trường hoặc sự cố tương thích thiết bị dẫn đến việc phải sử dụng phương án dự phòng. Mức không phải 100% là điều được dự đoán trước, vì người dùng chuyển đổi thiết bị hoặc cố gắng đăng nhập từ các thiết bị không được kết nối. Phụ thuộc nhiều vào mô hình người dùng và thiết bị được sử dụng.Công thức: (Số lần đăng nhập bằng passkey thành công) ÷ (Số lần thử đăng nhập bằng passkey) Theo dõi các lần thử nghiệm một phần, trong đó người dùng từ bỏ passkey giữa chừng và chuyển sang mật khẩu.Hơn 95% trên web di động. Hơn 99% trên Ứng dụng Gốc (Native Apps). Tỷ lệ đăng nhập trên máy tính để bàn phụ thuộc vào số lượng người dùng của bạn có nhiều thiết bị và nơi họ đăng ký đầu tiên.
Thời gian Đăng nhập Passkey so với Đăng nhập Cũ (Passkey Login Time vs. Legacy Login Time)So sánh thời gian trung bình để xác thực qua passkey so với mật khẩu (hoặc các phương pháp cũ khác), từ thời điểm người dùng bắt đầu đăng nhập cho đến khi hoàn thành thành công.Việc đăng nhập bằng passkey nhanh hơn tương quan với sự hài lòng của người dùng cao hơn và việc sử dụng bền vững.Ghi lại dấu thời gian bắt đầu và thành công của từng nỗ lực đăng nhập. Tính toán thời gian đăng nhập passkey trung bình so với thời gian đăng nhập cũ trung bình. Phân khúc theo Hệ điều hành/trình duyệt/thiết bị để có cái nhìn sâu sắc hơn.Tốc độ tăng từ 3 đến 5 lần. Khi so sánh với MFA hiện có (Mật khẩu + SMS).
Tỷ lệ Dự phòng (Fallback Rate)Tần suất người dùng quay lại sử dụng mật khẩu hoặc một phương pháp không phải passkey khác trong một nỗ lực đăng nhập ban đầu được bắt đầu bằng một passkey.Cho thấy sự phụ thuộc liên tục vào các luồng cũ, có thể do độ tin cậy của passkey kém hoặc do người dùng cảm thấy không thoải mái.Công thức: (Số sự kiện dùng phương án dự phòng) ÷ (Số lần thử đăng nhập bằng passkey) Tương quan dữ liệu phương án dự phòng với các cuộc khảo sát người dùng hoặc các phiếu hỗ trợ để xác định nguyên nhân gốc rễ.KPI này về cơ bản là tỷ lệ đăng nhập passkey bị đảo ngược và phụ thuộc vào việc triển khai của bạn.

Điều quan trọng là phải tối ưu hóa chủ yếu cho việc đăng nhập passkey thành công và tỷ lệ đăng nhập passkey để đảm bảo trải nghiệm người dùng không gặp rào cản, đồng thời làm việc để tăng tỷ lệ kích hoạt người dùng - nhưng chỉ khi tỷ lệ đăng nhập thành công đủ cao để tránh gây ra sự bực bội cho người dùng. Ngoài ra, việc theo dõi các KPI này theo các phân khúc khác nhau (chẳng hạn như Hệ điều hành, trình duyệt và thiết bị) và các trường hợp sử dụng cụ thể (ví dụ: đăng nhập trên nhiều thiết bị) có thể cung cấp những thông tin chi tiết hơn về các mô hình áp dụng và các điểm cản trở tiềm năng.

6.3 Làm thế nào để ghi lại các sự kiện cần thiết cho các chỉ số passkey#

Việc đo lường chính xác cả các KPI đầu vào (ví dụ: sự chấp nhận, việc tạo) và KPI đầu ra (ví dụ: tỷ lệ đăng nhập, mức độ sử dụng phương án dự phòng) đòi hỏi phải thu thập dữ liệu từ ba nguồn chính:

  1. Dữ liệu sự kiện front-end
  2. Kho lưu trữ passkey / thông tin xác thực
  3. Nhật ký xác thực cũ & phương án dự phòng

6.3.1 Dữ liệu sự kiện front-end#

Để tính toán các chỉ số như Tỷ lệ Chấp nhận Passkey hoặc Tỷ lệ Tạo Passkey Thành công, bạn phải phát hiện được có bao nhiêu người dùng nhìn thấy một gợi ý sau khi đăng nhập, có bao nhiêu người nhấp vào “Có, tạo một passkey” và liệu họ có thực sự hoàn thành việc tạo passkey hay không. Điều này yêu cầu tính năng theo dõi sự kiện bằng JavaScript (hoặc ứng dụng di động gốc) để ghi nhận:

  • Khi nào và liệu gợi ý có được hiển thị hay không (lần đầu tiên so với các lần tiếp theo)
  • Họ mất bao lâu để hoàn thành gợi ý
  • Liệu họ có hủy bỏ quy trình tạo passkey một hoặc nhiều lần không

Bạn cũng sẽ cần phân tích chuỗi user agent (user agent parsing) hoặc client hints để liên kết tỷ lệ chấp nhận với các phiên bản Hệ điều hành / trình duyệt cụ thể nhằm có thể phát hiện các đường dẫn bị hỏng cụ thể.

6.3.2 Kho lưu trữ passkey / thông tin xác thực#

Sau khi người dùng bắt đầu quá trình đăng ký ở front-end, máy chủ phải xác nhận xem một passkey mới có thực sự được lưu trữ hay không. Bạn sẽ cần quyền truy cập vào cơ sở dữ liệu hoặc API của một nhà cung cấp định danh bên ngoài ghi lại sự kiện tạo của mỗi thông tin xác thực. Kho lưu trữ này giúp bạn đếm xem mỗi người dùng có bao nhiêu passkey và theo dõi kết quả cuối cùng (thành công hoặc thất bại), đảm bảo bạn biết chính xác những nỗ lực nào đã kết thúc bằng việc đăng ký hoàn tất.

6.3.3 Nhật ký xác thực cũ & phương án dự phòng#

Đối với các chỉ số như Tỷ lệ Dự phòng, bạn phải xem xét các quy trình & nhật ký xác thực hiện tại của mình. Bằng cách hợp nhất các nhật ký này với các sự kiện ở front-end, bạn xem liệu một người dùng có bắt đầu đăng nhập bằng passkey, bị lỗi và sau đó chuyển sang đăng nhập dự phòng (ví dụ: SMS hoặc mật khẩu) hay không.

Cuối cùng, việc đo lường các KPI dựa trên thời gian chẳng hạn như Thời gian Đăng nhập Passkey so với Thời gian Đăng nhập Cũ dựa vào dấu thời gian của cả máy khách và máy chủ. Bởi vì nhiều tổ chức chỉ ghi lại các lần đăng nhập thành công, bạn phải thêm các công cụ để theo dõi các luồng passkey thất bại hoặc bị hủy giữa chừng nhằm thực sự đánh giá được ma sát và sự phụ thuộc vào phương án dự phòng. Việc tích hợp ba nguồn dữ liệu này, đồng thời tôn trọng các ràng buộc về quyền riêng tư và quy định, thường phức tạp hơn dự đoán và là một yếu tố khác khiến một số nhóm áp dụng các nền tảng passkey chuyên dụng cung cấp các công cụ theo dõi sự kiện và phân tích được tích hợp sẵn.

6.3.4 Phương pháp Tiếp cận Tích hợp của Corbado: Khai phá Quy trình Xác thực#

Các thành phần của Corbado Connect thu thập một cách ngầm định tất cả các điểm dữ liệu được mô tả (hàng trăm điểm dữ liệu khác nhau) bằng cách tự động tạo ra một quy trình duy nhất cho mọi người dùng bắt đầu quy trình xác thực. Thông qua sự tích hợp liền mạch, Corbado cũng thu thập các chỉ số xác thực từ giải pháp hiện có của bạn. Chế độ xem toàn diện này chỉ ra chính xác các điểm cần cải thiện cho người dùng, cung cấp thông tin chi tiết toàn diện về tất cả các KPI cốt lõi của passkey mà không cần bất kỳ nỗ lực bổ sung nào từ phía bạn.

6.4 Những KPI / OKR đầu ra quan trọng khác sẽ bị ảnh hưởng là gì?#

Ngoài ra, tác động của các KPI đầu ra sau đây cũng sẽ xuất hiện sau khi triển khai passkey thành công và phần lớn thời gian đã được thu thập trong doanh nghiệp:

Các Chỉ số Hoạt động & Giảm thiểu Chi phí

  • Sự sụt giảm trong việc sử dụng SMS OTP – Số lượng SMS OTP được tiết kiệm nhờ xác thực bằng passkey (tiết kiệm chi phí trực tiếp).
  • Giảm số Yêu cầu Đặt lại Mật khẩu – Giảm các tương tác của bộ phận trợ giúp liên quan đến quên mật khẩu.
  • Giảm các Phiếu Hỗ trợ Khách hàng – Khối lượng các vấn đề dịch vụ khách hàng liên quan đến xác thực thấp hơn.
  • Giảm Khối lượng Cuộc gọi Hỗ trợ – Ít cuộc gọi đến liên quan đến các vấn đề truy cập tài khoản hơn.

Các Chỉ số Kinh doanh & Tác động UX

  • Tỷ lệ Giữ chân Người dùng – Tỷ lệ người dùng tiếp tục xác thực sau lần đăng nhập đầu tiên.
  • Tỷ lệ Chuyển đổi – Mức độ thường xuyên người dùng hoàn thành giao dịch sau khi xác thực.
  • Tỷ lệ Bỏ dở trong Phễu Đăng nhập – Liệu passkey có làm giảm số lượng người dùng từ bỏ việc cố gắng đăng nhập hay không.

Bằng cách theo dõi cụ thể các KPI đầu vào và đầu ra của passkey và liên kết chúng với các dữ liệu khác, các tổ chức có thể định lượng tác động của việc triển khai passkey và đưa ra những cải tiến dựa trên dữ liệu để tối đa hóa sự áp dụng, giảm chi phí và tăng cường bảo mật.

7. Các khuyến nghị#

Việc lựa chọn giải pháp passkey phù hợp phụ thuộc vào những thách thức cụ thể, yêu cầu bảo mật và các cân nhắc về chi phí của bạn. Dưới đây là những khuyến nghị chính cho các quyết định mua hay tự xây dựng trên các lĩnh vực khác nhau.

7.1 Khuyến nghị về Passkey trong Ngân hàng & Dịch vụ Tài chính#

Các Lưu ý Chính:

  • Tuân thủ quy định (ví dụ: PSD2, SOC 2, ISO 27001, GDPR) đòi hỏi các biện pháp bảo mật nghiêm ngặt trong xác thực bằng passkey.
  • So sánh chi phí passkey là rất quan trọng, vì các ngân hàng thường đánh giá thấp mức độ phức tạp lâu dài và việc bảo trì các giải pháp nội bộ.
  • Xác thực an toàn là điều cần thiết để giảm bớt sự gian lận chiếm đoạt tài khoản và tấn công lừa đảo (phishing)

Khuyến nghị:
Hầu hết các ngân hàng và tổ chức tài chính nên dựa vào một giải pháp từ nhà cung cấp passkey thay vì tự xây dựng nội bộ, vì việc quản lý cơ sở hạ tầng passkey nội bộ mang lại những sự phức tạp tiềm ẩn vượt quá chuyên môn IT truyền thống. Việc triển khai xác thực bằng passkey ở quy mô lớn đòi hỏi sự tối ưu hóa và cập nhật liên tục, quản lý khả năng tương thích của WebAuthn và sự tích hợp liền mạch với các hệ thống ngân hàng cũ - tất cả những điều mà các nhà cung cấp passkey đã xử lý.

Các ngân hàng như Ubank, Revolut và Finom đang dẫn đầu trong việc áp dụng passkey, nhận ra tiềm năng của công nghệ này trong việc tăng cường bảo mật đồng thời cải thiện trải nghiệm người dùng. Việc phân tích ROI passkey thường nghiêng về hướng mua một giải pháp passkey hơn là đầu tư vào việc bảo trì và cập nhật liên tục, với việc triển khai cho thấy sự sụt giảm đáng kể trong các nỗ lực gian lận và chi phí hỗ trợ liên quan đến xác thực.

Các ví dụ: Armstrong Bank, First Financial Bank, Ubank, Revolut, Finom, Neobank, Cathay Financial Holdings, Stripe, PayPal, Square

7.2 Khuyến nghị về Passkey trong Chăm sóc Sức khỏe#

Các Lưu ý Chính:

  • Tuân thủ HIPAA và GDPR yêu cầu tính bảo mật xác thực nghiêm ngặt trong việc áp dụng passkey.
  • Những thách thức khi triển khai passkey bao gồm việc cân bằng giữa tính bảo mật và sự dễ sử dụng cho bệnh nhân, nhân viên y tế và quản trị viên IT của bệnh viện.
  • Nhiều hệ thống xác thực trong chăm sóc sức khỏe vẫn dựa vào cơ sở hạ tầng cũ, làm cho việc tích hợp passkey trở nên phức tạp hơn.

Khuyến nghị:
Một giải pháp từ nhà cung cấp passkey là cách hiệu quả nhất để đáp ứng các yêu cầu tuân thủ đồng thời đơn giản hóa việc xác thực. Các nhà cung cấp passkey xử lý các bản vá bảo mật, các bản cập nhật tuân thủ và độ tin cậy của việc xác thực, giảm bớt gánh nặng cho các nhóm IT.

Các ví dụ: CVS Health, Caremark, Helsana, NHS, Swica

7.3 Khuyến nghị về Passkey trong Thương mại Điện tử & Bán lẻ#

Các Lưu ý Chính:

  • Tối ưu hóa Tỷ lệ Chuyển đổi (CRO) mang ý nghĩa sống còn với doanh nghiệp - các rào cản trong xác thực ảnh hưởng trực tiếp đến doanh thu.
  • Các kịch bản đa thiết bị phải hoạt động trơn tru (người dùng duyệt trên thiết bị di động nhưng hoàn tất thanh toán trên máy tính để bàn).
  • Lỗi xác thực trực tiếp làm tăng tỷ lệ bỏ giỏ hàng, khiến các luồng đăng nhập được tối ưu hóa UX trở nên rất cần thiết.

Khuyến nghị:
Các nền tảng thương mại điện tử được hưởng lợi nhiều nhất từ một nhà cung cấp triển khai passkey có tỷ lệ áp dụng cao. Các nền tảng lớn như Amazon và Shopify đã triển khai xác thực bằng passkey, chứng minh sự áp dụng ngày càng tăng của công nghệ này trong thương mại điện tử. Dữ liệu thực tế cho thấy hơn 27% các lần đăng nhập bằng mật khẩu ban đầu bị thất bại, trong khi xác thực dựa trên passkey có thể đạt tỷ lệ đăng nhập thành công lên đến 95-97% như đã được thấy ở các lần áp dụng trước đó. Phân tích ROI passkey cho thấy tỷ lệ chuyển đổi cao hơn và tổn thất do gian lận thấp hơn nhanh chóng biện minh cho khoản đầu tư này.

Amazon gần đây cho biết rằng họ đã đặt ra một mục tiêu đầy tham vọng là áp dụng passkey 100% và loại bỏ hoàn toàn mật khẩu.

Google cũng phát hiện ra rằng những người dùng dùng thử có tương tác với passkey có khả năng chuyển đổi thành khách hàng trả phí cao hơn 20% so với những người không sử dụng.

Các ví dụ: KAYAK, Amazon, Mercari, Best Buy, eBay, Home Depot, Shopify, Target

7.4 Khuyến nghị về Passkey trong Du lịch & Khách sạn#

Các Lưu ý Chính:

  • Xác thực trên nhiều thiết bị là rất cần thiết, vì người dùng đặt chuyến đi trên một thiết bị và check-in trên một thiết bị khác.
  • Các nhà cung cấp passkey chuyên biệt phải đảm bảo đăng nhập nhanh chóng và an toàn để việc đặt phòng, check-in và quản lý tài khoản diễn ra thuận tiện.
  • Phòng chống gian lận là ưu tiên hàng đầu, vì các nền tảng du lịch xử lý các giao dịch có giá trị cao.

Khuyến nghị:
Hầu hết các công ty du lịch nên triển khai các giải pháp passkey để nâng cao bảo mật và trải nghiệm người dùng. Các công ty hàng đầu như Kayak và các hãng hàng không lớn đã và đang sử dụng xác thực bằng passkey để cải thiện trải nghiệm người dùng của họ. Các giải pháp dựng sẵn cung cấp khả năng phát hiện gian lận mạnh mẽ hơn, trải nghiệm đăng nhập liền mạch và hỗ trợ đa thiết bị ngay tức thì. Lĩnh vực khách sạn đặc biệt được hưởng lợi từ việc giảm thời gian check-in và cải thiện bảo mật thông qua việc triển khai passkey, đảm bảo việc xác thực suôn sẻ trên tất cả các điểm tiếp xúc (ứng dụng, ki-ốt, web và các nền tảng đối tác).

Các ví dụ: Air New Zealand, Bolt, Grab, Uber, Hyatt

7.5 Khuyến nghị về Passkey trong Bảo hiểm#

Các Lưu ý Chính:

  • Chi phí triển khai passkey phải phù hợp với nhu cầu tuân thủ và những cải thiện về trải nghiệm người dùng.
  • Nhiều khách hàng bảo hiểm không quá am hiểu công nghệ, vì vậy trải nghiệm người dùng trên tất cả các loại thiết bị và trình duyệt là một điều bắt buộc
  • Thường yêu cầu tích hợp passkey với việc xác minh danh tính để quản lý hợp đồng bảo hiểm và xử lý các yêu cầu bồi thường.

Khuyến nghị:
Một giải pháp passkey bên ngoài là phù hợp nhất để triển khai nhanh chóng và tuân thủ các quy định. Các nhà cung cấp bảo hiểm báo cáo sự sụt giảm đáng kể đối với các phiếu hỗ trợ liên quan đến xác thực sau khi triển khai passkey. Một nhà cung cấp triển khai passkey với các luồng xác thực có thể tùy chỉnh và việc xác minh danh tính được tích hợp đảm bảo bảo mật trong khi vẫn giữ cho quá trình đăng nhập của khách hàng trở nên đơn giản. Phân tích ROI passkey cho thấy rằng việc giảm thiểu các lần đặt lại mật khẩu và tổn thất do gian lận bù đắp cho chi phí của nhà cung cấp.

Các ví dụ: Branch

7.6 Khuyến nghị về Passkey trong Chính phủ & Dịch vụ Công#

Các Lưu ý Chính:

  • Các tiêu chuẩn bảo mật cao nhất và các yêu cầu tuân thủ (ví dụ: NIST, Khung Essential Eight yêu cầu MFA chống lừa đảo).
  • Nhu cầu triển khai quy mô lớn trên các tập người dùng đa dạng với các mức độ thành thạo công nghệ khác nhau
  • Yêu cầu tích hợp với các hệ thống xác minh danh tính của chính phủ và cơ sở hạ tầng cũ

Khuyến nghị:
Đối với các cơ quan chính phủ, một giải pháp passkey chuyên biệt đáp ứng các tiêu chuẩn bảo mật nghiêm ngặt trong khi vẫn đảm bảo khả năng tiếp cận là điều thiết yếu. Thành công trong việc triển khai tại VicRoads chứng minh rằng các tổ chức chính phủ được hưởng lợi nhiều nhất từ các giải pháp passkey bên ngoài có thể xử lý các yêu cầu tuân thủ và cập nhật bảo mật một cách tự động. Do đó, hãy chọn một nhà cung cấp triển khai passkey cung cấp bảo mật cấp doanh nghiệp, hỗ trợ xác thực trên nhiều thiết bị và cung cấp các luồng xác thực thích ứng để tạo sự thuận tiện cho mọi công dân.

Ví dụ: VicRoads, myGov, State of Michigan

7.7 Khuyến nghị về Passkey trong Viễn thông & Tiện ích#

Các Lưu ý Chính:

  • Khả năng mở rộng và độ tin cậy là rất quan trọng, vì các nhà cung cấp viễn thông và tiện ích thường quản lý hàng triệu người dùng trên các phân khúc khách hàng khác nhau, đòi hỏi xác thực có tính khả dụng cao và khả năng chịu lỗi.
  • Hỗ trợ đa thiết bị và đa nền tảng là điều cần thiết, vì người dùng truy cập tài khoản qua ứng dụng di động hoặc cổng thông tin điện tử. Xác thực passkey liền mạch phải hoạt động trên tất cả các điểm tiếp xúc của khách hàng.
  • Hỗ trợ cho các hệ thống xác thực cũ thường là cần thiết, vì các nhà cung cấp viễn thông và tiện ích có thể cần tích hợp passkey vào các hệ thống IAM hiện có và nền tảng định danh khách hàng mà không làm gián đoạn các luồng xác thực hiện tại.
  • Ngăn chặn gian lận và bảo mật tài khoản là ưu tiên hàng đầu, đặc biệt là đối với hành vi lừa đảo tráo SIM (SIM swap fraud), đánh cắp danh tính và truy cập tài khoản trái phép. Passkey có thể làm giảm đáng kể các cuộc tấn công lừa đảo và rủi ro nhồi nhét thông tin xác thực (credential stuffing).

Khuyến nghị:
Đối với các nhà cung cấp viễn thông và tiện ích, việc áp dụng một giải pháp passkey bên ngoài là phương pháp được khuyến nghị. Do quy mô, mức độ phức tạp và yêu cầu bảo mật của các ngành này, một nhà cung cấp passkey được quản lý đảm bảo tuân thủ, tính khả dụng cao và tích hợp liền mạch với cơ sở hạ tầng xác thực hiện có. Những người khổng lồ viễn thông và các nhà cung cấp tiện ích ưu tiên kỹ thuật số đang đón nhận passkey như là một phần trong nỗ lực hiện đại hóa bảo mật của họ để giảm gian lận và cải thiện trải nghiệm người dùng. Ngoài ra, việc thuê ngoài triển khai passkey làm giảm Tổng chi phí sở hữu (TCO) so với việc tự xây dựng nội bộ, vì việc bảo trì liên tục, các bản cập nhật bảo mật và việc tuân thủ quy định sẽ do nhà cung cấp đảm nhận.

Ví dụ: Deutsche Telekom, Telstra, SK Telecom

7.8 Khuyến nghị về Passkey trong B2B SaaS#

Các Lưu ý Chính:

  • Xác thực đa khách thuê (multi-tenant) là yếu tố thiết yếu đối với B2B SaaS, đòi hỏi việc tích hợp passkey có khả năng mở rộng trên các hệ thống IAM khác nhau.
  • Các doanh nghiệp kỳ vọng vào SSO (OIDC/SAML), do đó sự tích hợp liền mạch với các Nhà cung cấp Định danh mang ý nghĩa sống còn đối với doanh nghiệp.
  • Chi phí triển khai passkey phải được cân bằng với các khoản đầu tư bảo mật khác, chẳng hạn như xác thực đa yếu tố (MFA) và các mô hình bảo mật Zero-Trust.

Khuyến nghị:
Đối với hầu hết các nhà cung cấp B2B SaaS, việc triển khai passkey từ bên ngoài là lựa chọn tối ưu. Việc triển khai thường nhanh hơn so với tự phát triển nội bộ. Các công ty B2B kỹ thuật số như Notion, Hubspot hoặc Vercel đã áp dụng passkey để tăng cường bảo mật xác thực của họ. Tổng chi phí sở hữu thấp hơn đáng kể so với việc phát triển nội bộ, vì các yêu cầu về bảo trì, cập nhật và tuân thủ đều được đáp ứng bởi nhà cung cấp.

Ví dụ: Canva, DocuSign, Notion

8. Kết luận#

Passkey đã trở thành tiêu chuẩn toàn cầu cho việc xác thực, đơn giản hóa các lần đăng nhập cho người dùng cuối đồng thời tăng cường bảo mật. Khi các công ty đánh giá cách triển khai passkey, họ phải quyết định xem nên xây dựng một giải pháp nội bộ hay tận dụng một nhà cung cấp passkey chuyên biệt. Mặc dù các triển khai tự làm cung cấp toàn quyền kiểm soát, nhưng chúng đòi hỏi chuyên môn kỹ thuật đáng kể, nguồn lực phát triển và bảo trì liên tục. Ngược lại, các nhà cung cấp passkey cung cấp một cách tiếp cận nhanh hơn, có thể mở rộng và hiệu quả về mặt chi phí, đảm bảo tỷ lệ áp dụng cao, trải nghiệm người dùng liền mạch và sự tuân thủ các tiêu chuẩn bảo mật đang phát triển,

Hướng dẫn này đã giải quyết các câu hỏi chính sau::

  • Cần những thành phần nào để triển khai passkey và chuyển sang không mật khẩu?

    Việc triển khai passkey thành công đòi hỏi cơ sở hạ tầng FIDO2/WebAuthn, các luồng UX trơn tru, các cơ chế dự phòng và các tùy chọn khôi phục tài khoản an toàn. Các công ty cũng phải xem xét khả năng tương thích đa nền tảng và tuân thủ bảo mật.

  • Tôi có nên triển khai passkey nội bộ hay sử dụng một nhà cung cấp bên ngoài?

    Mặc dù việc phát triển nội bộ cung cấp quyền kiểm soát, nhưng nó đi kèm với độ phức tạp cao, chi phí bảo trì liên tục và các trách nhiệm về bảo mật. Hầu hết các tổ chức đối mặt với người tiêu dùng quy mô lớn đều được hưởng lợi từ một giải pháp passkey bên ngoài cung cấp khả năng triển khai nhanh chóng, chi phí vận hành thấp hơn và giảm bớt gánh nặng kỹ thuật.

  • Lợi ích của việc có một nhà cung cấp passkey là gì khi có các thư viện mã nguồn mở?

    Các thư viện WebAuthn mã nguồn mở cung cấp một điểm khởi đầu nhưng thiếu tính bảo mật cấp doanh nghiệp, trải nghiệm người dùng được tối ưu hóa cho passkey và các tính năng nâng cao khả năng áp dụng. Một nhà cung cấp passkey đảm bảo triển khai liền mạch, khả năng mở rộng và các chiến lược áp dụng của người dùng được tối ưu hóa mang lại ROI tốt hơn, làm giảm ma sát cho cả người dùng và nhà phát triển.

  • Những thách thức lớn nhất trong việc xây dựng một giải pháp passkey là gì?

    Việc phát triển một hệ thống passkey nội bộ đòi hỏi chuyên môn sâu về WebAuthn, hỗ trợ đa thiết bị và áp dụng passkey. Việc duy trì sự phức tạp liên tục của thiết bị và trình duyệt cũng như đảm bảo tỷ lệ áp dụng cao càng làm tăng thêm độ khó.

  • Những rủi ro của việc triển khai passkey nội bộ là gì?

    Các công ty đối mặt với rủi ro chi phí phát triển cao, thời gian triển khai kéo dài và gánh nặng bảo trì bảo mật liên tục. Những thất bại trong tuân thủ, lỗ hổng bảo mật và sự áp dụng kém của người dùng có thể làm hỏng sự thành công của một lần triển khai passkey. Một giải pháp passkey được nhà cung cấp quản lý sẽ giảm thiểu những rủi ro này bằng cách cung cấp một cơ sở hạ tầng xác thực đã được chứng minh, có thể mở rộng với tính năng bảo mật tích hợp và tuân thủ quy định.

Corbado

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

Những Câu hỏi Thường gặp#

Rủi ro chính của việc tự xây dựng nội bộ một giải pháp passkey cho doanh nghiệp là gì?#

Việc xây dựng nội bộ đòi hỏi chuyên môn sâu về WebAuthn, việc quản lý khả năng tương thích của trình duyệt và thiết bị liên tục, và sự bảo trì bảo mật chuyên dụng. Các công ty gặp rủi ro về thời gian triển khai bị kéo dài, những thất bại trong việc tuân thủ và sự áp dụng kém của người dùng. Đối với các ngành được quản lý chặt chẽ như ngân hàng và chăm sóc sức khỏe, việc tuân thủ các quy định như PSD2, HIPAA và NIST làm tăng thêm sự phức tạp mà các nhà cung cấp passkey đã xử lý liên tục.

Tôi cần bao nhiêu tỷ lệ áp dụng passkey trước khi có thể loại bỏ mật khẩu một cách an toàn?#

Các tổ chức cần từ 50-80% người dùng hoạt động tiến hành xác thực bằng passkey trước khi gỡ bỏ mật khẩu. Việc loại bỏ mật khẩu quá sớm sẽ làm tăng các yêu cầu hỗ trợ và các vấn đề về khả năng sử dụng. Một cách tiếp cận theo từng giai đoạn bắt đầu với các tài khoản nơi người dùng thường xuyên xác thực qua passkey, tận dụng nhiều lần gợi ý (tỷ lệ chấp nhận đạt tới 85% trên thiết bị di động sau nhiều lời nhắc) và mở rộng dựa trên những thông tin chi tiết từ dữ liệu.

Tôi nên theo dõi những KPI nào để đo lường sự thành công của việc triển khai passkey?#

Theo dõi các KPI đầu vào bao gồm tỷ lệ chấp nhận passkey (mốc chuẩn: 50-75% ở lần gợi ý đầu tiên, lên đến 85% trên thiết bị di động qua nhiều lần gợi ý) và tỷ lệ tạo thành công hướng tới gần 100%. Đối với các KPI đầu ra, hãy nhắm mục tiêu tỷ lệ đăng nhập bằng passkey trên 20% trong vòng vài tuần và trên 50% trong 12 tháng. Phân khúc tất cả các chỉ số theo hệ điều hành, trình duyệt và thiết bị để xác định các điểm gây cản trở.

Tại sao các dự án passkey thất bại ngay cả sau khi triển khai kỹ thuật thành công?#

Hầu hết các dự án passkey thất bại do sự áp dụng của người dùng thấp chứ không phải do các vấn đề kỹ thuật. Việc người dùng tiếp tục phụ thuộc vào mật khẩu sẽ phủ nhận các lợi ích bảo mật, triệt tiêu sự tiết kiệm chi phí từ việc giảm thiểu SMS OTP và đặt lại mật khẩu, đồng thời tạo ra một trải nghiệm người dùng bị phân mảnh. Google và Amazon giải quyết vấn đề này thông qua các thử nghiệm A/B liên tục, các gợi ý trên giao diện người dùng và các chiến dịch giáo dục người dùng có cấu trúc nhằm đặc biệt vào việc thúc đẩy sự áp dụng.

Những ngành nào được hưởng lợi nhiều nhất từ việc sử dụng một nhà cung cấp passkey thay vì tự xây dựng nội bộ?#

Các lĩnh vực ngân hàng, chăm sóc sức khỏe, chính phủ, thương mại điện tử, viễn thông và bảo hiểm được hưởng lợi nhiều nhất từ các giải pháp của nhà cung cấp passkey do các yêu cầu về quy định như PSD2, HIPAA và NIST, kết hợp với các tập người dùng quy mô lớn và cơ sở hạ tầng cũ phức tạp. Amazon đã đặt ra mục tiêu áp dụng 100% passkey và loại bỏ hoàn toàn mật khẩu, minh họa cho quy mô cam kết mà các đợt triển khai này yêu cầu.

Xem điều gì thật sự đang diễn ra trong quá trình triển khai passkeys của bạn.

Khám phá Console

Chia sẻ bài viết này


LinkedInTwitterFacebook