---
url: 'https://www.corbado.com/vi/blog/huong-dan-mua-hay-tu-xay-dung-passkey'
title: 'Hướng dẫn Mua hay Tự xây dựng giải pháp Passkey'
description: 'Nên tự xây dựng hay mua một giải pháp passkey? Khám phá ưu và nhược điểm của việc tự làm passkey so với các giải pháp từ nhà cung cấp (SaaS & tại chỗ), cùng với những thách thức, chi phí và các phương pháp hay nhất.'
lang: 'vi'
author: 'Vincent Delitz'
date: '2025-07-15T09:19:06.420Z'
lastModified: '2026-04-17T06:05:26.713Z'
keywords: 'tự làm passkey, mua hay tự xây dựng passkey, thuê ngoài passkey, chi phí triển khai passkey, so sánh chi phí passkey, passkey SaaS và tự host, nhà cung cấp passkey và tự phát triển, phân tích ROI của passkey, thách thức triển khai passkey, phương pháp tri'
category: 'Passkeys Strategy'
---

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

### Tải xuống Hướng dẫn Mua hay Tự xây dựng Passkey đầy đủ

Tải xuống miễn phí **Hướng dẫn Mua hay Tự xây dựng Passkey đầy đủ** và tiếp cận tất cả các
thông tin chi tiết.

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

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

Ý tưởng tự xây dựng một hệ thống passkey nghe có vẻ hấp dẫn: toàn quyền kiểm soát, tích
hợp tùy chỉnh và không bị phụ thuộc vào nhà cung cấp. Suy cho cùng,
[FIDO2](https://www.corbado.com/glossary/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 có vẻ khá dễ dàng. Thực sự thì nó có thể khó đến mức nào?

Nhưng đây thường là lúc sự phức tạp bắt đầu, đặc biệt là khi chúng ta 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 người tiêu dùng với hàng triệu người
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](https://www.corbado.com/passkeys-for-banking),
  [thanh toán](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet),
  [fintech](https://www.corbado.com/vi/blog/finom-passkeys))
- **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](https://www.corbado.com/passkeys-for-insurance) kỹ thuật số)
- **Thương mại điện tử & Bán lẻ** (ví dụ: [sàn giao dịch](https://www.corbado.com/passkeys-for-e-commerce),
  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](https://www.corbado.com/passkeys-for-energy))
- **Du lịch & Khách sạn** (ví dụ: tài khoản [hãng hàng không](https://www.corbado.com/passkeys-for-airlines),
  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 bằng passkey thành công đầu tiên và thường
chỉ lộ ra khi chúng ta đã và đang trong quá trình 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 hiếm gặp, lỗi người dùng khó hiểu và nguy cơ người
dùng bị khóa tài khoản do passkey không khả dụng xuất hiện. Việc tích hợp tưởng chừng đơn
giản lại biến thành nỗ lực phát triển kéo dài hàng tháng, thậm chí hàng năm, chi phí bảo
trì không lường trước và có khả năng dẫn đến một dự án passkey thất bại.

Tuy nhiên, tự xây dựng giải pháp cũng có thể là lựa chọn đúng đắn cho một số tổ chức và
yêu cầu cụ thể. Chúng tôi đã trao đổi với hàng chục tổ chức về kế hoạch triển khai passkey
của họ và đã trực tiếp đồng hành cùng một số tổ chức trên hành trình này.
[Hướng dẫn](https://www.corbado.com/vi/blog/ung-dung-crud-react-express-mysql) này sẽ giúp bạn xác định khi nào
phương pháp tự làm (Do-It-Yourself - DIY) passkey có thể hợp lý và khi nào việc chọn một
[nhà cung cấp passkey](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) uy tín 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à tiến tới không mật khẩu?**
2. **Nên tự triển khai passkey hay sử dụng một nhà cung cấp passkey bên ngoài?**
3. **Lợi ích của việc có một nhà cung cấp passkey khi đã có các thư viện mã nguồn mở là
   gì?**
4. **Những thách thức lớn nhất khi xây dựng một giải pháp passkey là gì?**
5. **Những rủi ro khi tự triển khai passkey là gì?**

## 2. Điều kiện tiên quyết: Tại sao Passkey 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 khó chịu. 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 việc xác thực - khiến chúng
trở thành tiêu chuẩn mới cho việc đăng nhập an toàn. Dù bạn tự xây dựng hay sử dụng giải
pháp bên ngoài, việc tích hợp passkey là một nâng cấp lớn về
[bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) và khả năng sử dụng.

Google nhận thấy rằng việc nhấn mạnh vào câu chuyện về sự dễ sử dụng hoặc tốc độ sẽ tạo
được tiếng vang và hiệu quả. Mọi người thường phàn nà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 điểm cộng lớn.

Ngoài những lợi ích [bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) này, còn có tiềm
năng to lớn trong việc tiết kiệm chi phí hoạt động với passkey. Chúng ta có thể giảm số
lượng [SMS OTP](https://www.corbado.com/vi/blog/ngan-hang-singapore-va-passkeys-thay-the-sms-otp) gửi cho người
dùng, một khoản chi phí có thể tăng lên rất nhiều đối với lượng người dùng lớn. Hơn nữa,
gánh nặng từ việc khôi phục mật khẩu và MFA đặt lên đội ngũ hỗ trợ khách hàng cũng là một
yếu tố chi phí có thể được loại bỏ.

Bên cạnh đó, 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 trong các ngành như [thương mại điện tử](https://www.corbado.com/passkeys-for-e-commerce),
[bán lẻ](https://www.corbado.com/passkeys-for-e-commerce) hoặc [du lịch](https://www.corbado.com/passkeys-for-travel).

![introducing passkeys table](https://www.corbado.com/website-assets/introducing_passkeys_table_b5fd537984.jpg)

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

![passwordless-journey-passkeys.png](https://www.corbado.com/website-assets/passwordless_journey_passkeys_af666bc198.png)

Mục tiêu cuối cùng của nhiều tổ chức khi cân nhắc giới thiệu passkey là hoàn toàn không
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 năng lực 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 để giới thiệu phương thức [xác thực an toàn](https://www.corbado.com/vi/glossary/open-id-4-vp)
hơn hoặc các hạn chế về tài chính cũng có thể đóng một vai trò.

Hãy cùng đi qua bốn giai đoạn này và mô tả chúng, vì việc triển khai passkey chỉ là một
bước trong việc đảm bảo sự 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 hệ thống hoàn toàn không mật khẩu là **tích
hợp passkey như 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. Việc 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 và chính sách
[bảo mật](https://www.corbado.com/vi/blog/cach-bat-passkey-tren-android) hiện có. Các tổ chức nên tập trung vào
việc làm cho việc [tạo passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) trở nên đơn giản,
đảm bảo rằng cả người dùng có chuyên môn kỹ thuật và không có chuyên môn kỹ thuật đều có
thể áp dụng phương thức xác thực mới mà không gặp trở ngại.

### 3.2 Giai đoạn 2: Tăng tỷ lệ chấp nhận Passkey

Khi passkey đã được tích hợp, thách thức tiếp theo là **thúc đẩy người dùng chấp nhận
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ự chấp nhận rộng rãi của người dùng, một dự án passkey có khả năng 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 tỷ lệ chấp nhận bao gồm giáo dục người dùng một cách chủ
động, các gợi ý trên giao diện người dùng (UI nudges) nhằm quảng bá việc
[tạo passkey](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) và các chương trình khuyến khích
(incentive) thưởng cho người dùng khi chuyển đổi. Các tổ chức nên đặt ra một ngưỡng chấp
nhận quan trọng, chẳng hạn như 50-80% người dùng đang 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 việc chấp nhận 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ề việc tỷ lệ chấp nhận thấp có thể gây nguy hiểm cho dự án passkey của bạn như thế nào](https://corbado.com/blog/why-passkey-implementations-fail).

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

Khi tỷ lệ chấp nhận 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](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) 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à tăng yêu cầu hỗ trợ.
Một phương pháp tiếp cận theo từng giai đoạn được khuyến nghị:

- Bắt đầu bằng cách [loại bỏ mật khẩu](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan)
  khỏi các tài khoản mà người dùng thường xuyên xác thực bằng passkey.
- Cung cấp tùy chọn [loại bỏ mật khẩu](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan)
  trong cài đặt tài khoản cho những người dùng sớm.
- Sử dụng thông tin chi tiết dựa trên dữ liệu để xác định những người dùng đã sẵn sàng
  chuyển sang hoàn toàn không dù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 những lợi ích của việc loại bỏ mật khẩu để xây dựng lòng tin của
  người dùng.

Bằng cách [hướng dẫn](https://www.corbado.com/vi/blog/ung-dung-crud-react-express-mysql) người dùng một cách
chiến lược hướng tới việc [xác thực không mật khẩu](https://www.corbado.com/vi/glossary/ctap) hoàn toàn, 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

Khi mật khẩu được loại bỏ, các cơ chế
[khôi phục tài khoản](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) phải 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 sự can thiệp thủ công,
chẳng hạn như phiếu hỗ trợ hoặc đặt lại qua email, điều này 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** nhằm duy trì bảo mật trong khi 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](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) tự động bao gồm:

- **Kiểm tra sự 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 có mặt thực tế.
- **Xác minh danh tính (ID verification)**: Tận dụng giấy tờ tùy thân do
  [chính phủ](https://www.corbado.com/passkeys-for-public-sector) cấp và xác minh
  [sinh trắc học](https://www.corbado.com/vi/blog/sinh-trac-hoc-nhan-thuc-nguoi-thanh-toan) để xác nhận danh
  tính.
- **Passkey dự phòng**: Cho phép người dùng
  [khôi phục tài khoản](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) 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 đã đầ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 sự phiền toái.

Dựa trên bốn giai đoạn này, bây giờ 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 khi đó bạn sẽ bỏ lỡ toàn bộ tiềm năng của passkey).

![account recovery](https://www.corbado.com/website-assets/account_recovery_45773684fd.png)

## 4. Cách xác định phương pháp tiếp cận Passkey phù hợp

Việc lựa chọn giữa giải pháp passkey tự làm và giải pháp 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 đây cho thấy các tiêu chí đánh giá khác nhau mà bạn cần xem xét. Dựa trên phát
biểu mà bạn nghiêng về nhiều hơn, 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à độ 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 **hạng mục mà** câu trả lời của bạn phù hợp hơn với mô tả 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** làm tùy chọn trung lập.

### Tải xuống Hướng dẫn Mua hay Tự xây dựng Passkey đầy đủ

Tải xuống miễn phí **Hướng dẫn Mua hay Tự xây dựng Passkey đầy đủ** và tiếp cận tất cả các
tiêu chí đánh giá.

## 5. Cách sử dụng hướng dẫn này 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, chứ 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 ngắn hạn của bạn là cung cấp passkey như một MVP (sản phẩm khả dụng tối
thiểu), bạn nên lường trước những hệ quả lâu dài, đặc biệt là **thúc đẩy việc chấp nhận**.
Dưới đây là cách chúng tôi khuyên bạn nên sử dụng
[hướng dẫn](https://www.corbado.com/vi/blog/ung-dung-crud-react-express-mysql) này và diễn giải kết quả của mình,
với sự nhấn mạnh vào lý do tại sao việc chấp nhận 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 Tỷ lệ chấp nhận là Yếu tố Thành công số 1

Bất kể giải pháp passkey của bạn tiên tiến đến đâu, **nếu người dùng không chấp nhận 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 để 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, tỷ lệ chấp nhận thấp sẽ dẫn đến:

- **Sự phụ thuộc dai dẳng vào mật khẩu**, làm mất đi 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](https://www.corbado.com/vi/blog/ngan-hang-singapore-va-passkeys-thay-the-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 qua
  các phương thức truyền thống và chỉ một nhóm nhỏ sử dụng passkey.

**Tỷ lệ chấp nhận 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ể 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 chấp
nhận rõ ràng và chạy thử nghiệm A/B một cách có hệ thống, các 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 để đảm bảo passkey được đón nhận rộng rãi. Nỗ
lực tập trung vào việc chấp nhận này 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 hữu hình.

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

Hướng dẫn này được thiết kế để giúp bạn đưa ra 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 là đang xem xét có nên áp dụng
   passkey hay không và cách tích hợp chúng, hãy tập trung vào các tiêu chí _Xây dựng so
   với Mua_ cho việc tích hợp passkey.
2. **Giai đoạn 2 (Tăng tỷ lệ chấp nhận):** Nếu bạn muốn passkey không chỉ là một tính
   năng, hãy lên kế hoạch sớm để thúc đẩy người dùng chấp nhận - ngay cả đối với một MVP
   vì nó đòi hỏi đầu tư công nghệ bổ sung thường lớn 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ế với bước
   đi cuối cùng đó trong tâm trí.
4. **Giai đoạn 4 (Tự động hóa Khôi phục Tài khoản):** Ngay cả khi bạn chưa sẵn sàng để
   hoàn toàn không dùng mật khẩu hôm nay, hãy chắc chắn rằng phương pháp tiếp cận passkey
   của bạn có thể phát triển thành việc khôi phục mạnh mẽ, liền mạch để tránh những trở
   ngại trong tương lai.

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

### 5.3 Thu hút các Bên liên quan chính và Thống nhất về Mục tiêu Chấp nhận

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 nó cùng với ban quản lý, IT, chủ
sở hữu sản phẩm và các nhà ra quyết định quan trọng khác. Hãy tự hỏi mình:

1. **Tỷ lệ đăng nhập bằng passkey mong muốn của chúng ta là gì?** 5% có đủ để chứng minh
   tính khả thi hay chúng ta cần 50–80% trước khi coi passkey là một thành công?
2. **Chúng ta có ngân sách và sự ủng hộ của ban điều hành** để chạy 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à liên tục tinh
   chỉnh luồng người dùng để 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 đủ 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 nhắm đến việc loại bỏ mật khẩu hay chỉ cung
   cấp một giải pháp thay thế?

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ên kế hoạch cho việc chấp nhận 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 xa vùng “trung lập”, việc chọn Nhà cung cấp càng hợp lý

Trong suốt ma trận, mỗi tiêu chí đánh giá có thể đưa bạn đến bất cứ đâu từ **độ phức tạp
thấp nhất (1)** đến **độ phức tạp cao nhất (5)**. Càng nhiều câu trả lời của bạn chuyển
đến và vượt ra ngoài vùng trung lập **(3)**, trường hợp sử dụng một
[nhà cung cấp passkey](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) chuyên biệt càng trở nên mạnh mẽ
hơn:

- **Yêu cầu 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 sâu và UX đa thiết bị - nhân lên gánh nặng kỹ thuật và bảo
  trì của bạn.
- **Nhấn mạnh vào việc chấp nhận** - đạt được tỷ lệ chấp nhận passkey cao một cách nhanh
  chóng hoặc loại bỏ mật khẩu thường đòi hỏi các luồng người dùng đã được kiểm tra kỹ
  lưỡng, đo lường 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 đội ngũ nội bộ, cả về mặt kỹ thuật và 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ập nhật nhanh chóng và chuyên môn thực tế để tăng tốc độ chấp nhận nhanh hơn
nhiều so với phương pháp tự làm.

### 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 trong lộ trình của bạn và bạn muốn một **triển khai hiện đại nhất** mà **tích
cực thúc đẩy việc chấp nhận**, Corbado Connect có thể giúp bạn giải quyết các phức tạp ở
quy mô lớn. Đây là lý do tại sao:

![product related outcome](https://www.corbado.com/website-assets/product_related_outcome_23dde860af.jpg)

**Việc chấp nhận được tích hợp sẵn trong 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ự lựa chọn 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 giúp tiết kiệm chi phí.

Các bước tiếp theo:

1. **Điền vào từng phần liên quan của ma trận đánh giá** - xem xét cả mục tiêu trước mắt
   và lâu dài.
2. **Ưu tiên việc chấp nhận 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 chấp nhận rõ ràng và nguồn lực để đạt được chúng.
3. **So sánh TCO cho các giải pháp nội bộ và nhà cung cấp** một khi bạn hiểu được độ phức
   tạp và tham vọng chấp nhận của mình và đi qua quy trình nội bộ để đánh giá xây dựng hay
   mua.

![internal stakeholder goals](https://www.corbado.com/website-assets/internal_stakeholder_goals_6c4e605c9d.jpg)

4. **Tham khảo ý kiến các chuyên gia 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ả thách thức kỹ
   thuật và thách thức về việc chấp nhận.

Bằng cách tiếp cận passkey một cách toàn diện và biến việc chấp nhận 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 hơn,
đăng nhập đơn giản hơn và một con đường thực sự đến một 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 tỷ lệ chấp nhận passkey cao, chúng tôi luôn sẵn sàng trao đổi.

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

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

![why passkey adoption matters](https://www.corbado.com/website-assets/why_passkey_adoption_matters_7f0a3b0413.png)

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

Các chỉ số KPI đầu vào giúp theo dõi **việc chấp nhận passkey ở giai đoạn đầu** và 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 đi trước hành vi đăng nhập thực tế nhưng rất quan trọng để cho phép việc chấp
nhận có ý nghĩa và tối ưu hóa việc triển khai.

| **KPI**                          | **Định nghĩa**                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | **Tại sao nó quan trọng**                                                                                                                                                      | **Cách đo lường**                                                                                                                                                                                                                    | **Tiêu chuẩn**                                                                                                                                      |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tỷ lệ chấp nhận Passkey**      | Tỷ lệ phần trăm 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 lời nhắc hoặc đề xuất khuyến khích họ thiết lập passkey) và chọn tạo một passkey. KPI này đặc biệt đo lường khả năng phản hồi của người dùng đối với những lời nhắc sau khi đăng nhập này, làm nổi bật hiệu quả của thông điệp gợi ý trong việc thúc đẩy việc tạo passkey. Phương pháp 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 cài đặt tài khoản hoặc quản lý thông tin xác thực. Thay vào đó, passkey được chấp nhận 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. Hãy chắc chắn phân biệt giữa gợi ý đầu tiên và các gợi ý tiếp theo vì tỷ lệ sẽ giảm. | Tỷ lệ 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ự phiền toái, thông điệp không rõ ràng hoặc sự do dự 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 gợi ý) ÷ (số người dùng tiếp xúc với gợi ý). Phân đoạn theo HĐH/trình duyệt/thiết bị.                                                                                  | 50%-75% ở gợi ý đầu tiên, lên đến 85% qua nhiều gợi ý trên 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à triển khai. |
| **Tỷ lệ tạo Passkey thành công** | 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** (tức là không bỏ ngang).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | Cho thấy có bao nhiêu người dùng _bỏ cuộc_ giữa chừng do UX khó hiểu, 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ần thử đăng ký) Phân tích các điểm thất bại theo HĐH/trình duyệt/thiết bị.                                                                                                | Gần 100%.                                                                                                                                           |
| **Số lượng Passkey được tạo**    | Tổng số 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 chấp nhận thô thường được coi là một 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 khỏi mật khẩu.      | **Công thức**: Tổng tất cả các passkey mới được đăng ký trên các HĐH, trình duyệt, danh mục thiết bị. Theo dõi xu hướng tăng trưởng theo thời gian. Con số tuyệt đối không có ý nghĩa, nó 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.                                                                                    |

Những **chỉ số KPI đầu vào** này đóng vai trò là chỉ số hàng đầu về việc chấp nhận 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, luồng UX và
triển khai kỹ thuật.

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

Các chỉ số KPI đầu ra (OKR) đo lường sự thành công thực tế của việc chấp nhận passkey bằng
cách đánh giá hành vi của người dùng, các cải tiến hoạt động và tác động kinh doanh. Những
chỉ số này phản ánh hiệu quả thực tế của một đợt triển khai passkey. Tỷ lệ Đăng nhập bằng
Passkey là một KPI đầu ra cốt lõi vì nó trực tiếp phản ánh việc chấp nhận và sử dụng
passkey thực tế. Một tỷ lệ đăng nhập bằng passkey tăng cho thấy việc 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ĩa**                                                                                                                                                                | **Tại sao nó quan trọng**                                                                                                                                                                                                                                                                                                                                                                                                   | **Cách đo lường**                                                                                                                                                                                                                                                                               | **Tiêu chuẩn**                                                                                                                                                                     |
| ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tỷ lệ kích hoạt người dùng**                                               | Trong số tất cả 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 thành công _tổng thể_ của việc giới thiệu passkey qua nhiều gợi ý. Người dùng có thể từ chối gợi ý đầu tiên nhưng 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 đoạn theo HĐH, trình duyệt, thiết bị để xem ai cuối cùng chấp nhận passkey. Khi việc triển khai phát triển, các passkey đã xóa cũng phải được phản ánh ở đây. | Trên 50% trong 12 tháng. Tỷ lệ đăng nhập bằng passkey hội tụ về Tỷ lệ kích hoạt người dùng. Sẽ phụ thuộc vào thành phần người dùng của bạn.                                        |
| **Tỷ lệ đăng nhập bằng Passkey**                                             | 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 passkey thay vì một phương thức cũ (mật khẩu, SMS OTP, v.v.).                                         | Thể hiện tần suất sử dụng passkey trong thực tế. Tỷ lệ đăng nhập thấp liên tục cho thấy người dùng hoặc thích hoặc quay lại mật khẩu mặc dù 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 việc kích hoạt đã cao), hoặc là kết quả của một triển khai đăng nhập không 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 đoạn theo HĐH/trình duyệt/thiết bị hoặc nhóm người dùng. Điều này giúp xác định các nền tảng hoặc nhóm nhân khẩu học có vấn đề với việc sử dụng passkey thấp.                                                     | Trên 20% trong vài tuần, trê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 bằng Passkey thành công**                                  | 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.                                                                        | Tiết lộ sự phiền toái trong luồng passkey. Tỷ lệ thấp hơn có thể cho thấy sự nhầm lẫn của người dùng, các ràng buộc môi trường hoặc các vấn đề tương thích thiết bị dẫn đến việc sử dụng phương án dự phòng. Tỷ lệ không phải 100% là điều được mong đợi, 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à các 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ử không thành công, nơi người dùng bỏ ngang passkey và chuyển sang mật khẩu.                                                                                                 | Trên 95% trên web di động. Trên 99% trên ứng dụng gốc. 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ý lần đầu. |
| **Thời gian đăng nhập bằng Passkey so với Thời gian đăng nhập truyền thống** | 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 thức cũ khác), từ thời điểm người dùng bắt đầu đăng nhập đế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 mỗi lần thử đăng nhập. Tính toán thời gian đăng nhập trung bình bằng passkey so với thời gian đăng nhập trung bình bằng phương thức cũ. Phân đoạn theo HĐH/trình duyệt/thiết bị để có thông tin chi tiết sâu hơn.                               | Tăng tốc độ gấp 3-5 lần. Khi so sánh với MFA hiện có (Mật khẩu+SMS).                                                                                                               |
| **Tỷ lệ dự phòng**                                                           | Tần suất người dùng quay lại mật khẩu hoặc một phương thức không phải passkey khác trong một lần thử đăng nhập ban đầu bắt đầu bằng 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 người dùng chưa thoải mái.                                                                                                                                                                                                                                                                                                       | **Công thức**: (số sự kiện dự phòng) ÷ (số lần thử đăng nhập bằng passkey) Tương quan dữ liệu dự phòng với các cuộc khảo sát người dùng hoặ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 bằng passkey đả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 sự thành công của việc đăng nhập bằng
passkey và tỷ lệ đăng nhập bằng passkey để đảm bảo trải nghiệm người dùng không gặp trở
ngại, đồng thời nỗ lự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ự thất vọng 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 (như HĐH, 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 thông tin chi tiết sâu hơn về các mô hình chấp nhận và các điểm có
  thể gây trở ngại.

### 6.3 Cách ghi lại các sự kiện cần thiết cho chỉ số passkey

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

1. **Dữ liệu sự kiện từ Frontend**
2. **Kho lưu trữ Passkey / thông tin xác thực**
3. **Nhật ký xác thực truyền thống & dự phòng**

#### 6.3.1 Dữ liệu sự kiện từ Frontend

Để 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ó bao nhiêu người dùng thấy một gợi ý sau khi đăng nhập, 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 đòi hỏi việc theo dõi sự kiện bằng JavaScript (hoặc di động
gốc) để ghi lại:

- 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](https://www.corbado.com/vi/blog/thuc-hanh-tot-nhat-tao-passkey) một
  lần hay nhiều lần

Bạn cũng sẽ cần **phân tích user agent** hoặc **client hints** để liên kết tỷ lệ chấp nhận
với các phiên bản HĐH / trình duyệt cụ thể để có thể phát hiện các đường dẫn bị lỗi 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 đăng ký trên frontend, 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ận dạng 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 có bao nhiêu passkey tồn tại cho mỗi người dùng và theo
dõi kết quả cuối cùng (thành công hay thất bại), đảm bảo bạn biết chính xác những lần thử
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 truyền thống & 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 nhật ký & quy trình 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 frontend, bạn
sẽ thấy liệu một người dùng đã bắt đầu đăng nhập bằng passkey, gặp lỗi và chuyển sang đăng
nhập dự phòng (ví dụ: SMS hoặc mật khẩu).

Cuối cùng, việc đo lường các KPI dựa trên thời gian như **Thời gian đăng nhập bằng
Passkey** **so với Thời gian đăng nhập truyền thống** phụ thuộc vào cả dấu thời gian của
máy khách và máy chủ. 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ông cụ đo lường cho các luồng passkey không thành công hoặc một phần để thực sự đánh
giá được sự phiền toái và việc sử dụng dự phòng. Việc tích hợp ba nguồn dữ liệu này, trong
khi 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ự kiến và
là một yếu tố khác khiến một số đội ngũ áp dụng các nền tảng passkey chuyên biệt cung cấp
các phân tích và theo dõi sự kiện 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 ngầm thu thập tất cả các điểm dữ liệu được mô tả (hàng
trăm điểm 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 một quy trình xác thực. Thông qua việc 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 tại của bạn**. Cái nhìn toàn diện này xác định chính
xác các cải tiế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
passkey thiết yếu mà không cần thêm nỗ lực từ phía bạn.

### 6.4 Những chỉ số KPI / OKR đầu ra quan trọng khác nào sẽ bị ảnh hưởng?

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

**Các chỉ số về Hoạt động & Giảm chi phí**

- **Giảm việc sử dụng SMS OTP** – Số lượng
  [SMS OTP](https://www.corbado.com/vi/blog/ngan-hang-singapore-va-passkeys-thay-the-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 yêu cầu đặt lại mật khẩu** – Giảm các tương tác với bộ phận trợ giúp liên quan
  đến việc quên mật khẩu.
- **Giảm số lượng phiếu hỗ trợ khách hàng** – Giảm khối lượng các vấn đề dịch vụ khách
  hàng liên quan đến xác thực.
- **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.

**Các chỉ số về Tác động Kinh doanh & UX**

- **Tỷ lệ giữ chân người dùng** – Tỷ lệ phần trăm 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** – Tần suất người dùng hoàn thành giao dịch sau khi xác thực.
- **Tỷ lệ bỏ ngang trong phễu đăng nhập** – Liệu passkey có làm giảm số lượng người dùng
  bỏ ngang các lần thử đăng nhập.

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 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 của họ và
thực hiện các cải tiến dựa trên dữ liệu để tối đa hóa việc chấp nhận, giảm chi phí và tăng
cường bảo mật.

## 7. Khuyến nghị

Việc 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ân nhắc về chi phí của bạn**. Dưới đây là các khuyến nghị chính cho **quyết
định mua so với tự xây dựng** trên các lĩnh vực khác nhau.

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

**Những cân nhắc chính:**

- Tuân thủ quy định (ví dụ: [PSD2](https://www.corbado.com/blog/psd2-passkeys),
  [SOC 2](https://www.corbado.com/blog/cybersecurity-frameworks), [ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks),
  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](https://www.corbado.com/vi/blog/nha-cung-cap-xac-thuc-passkey-giup-tiet-kiem-100000-usd) là
  rất quan trọng, vì các ngân hàng thường đánh giá thấp sự phức tạp và bảo trì lâu dài của
  các giải pháp nội bộ.
- [Xác thực an toàn](https://www.corbado.com/vi/glossary/open-id-4-vp) là cần thiết để giảm gian lận chiếm đoạt
  tài khoản và 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](https://www.corbado.com/vi/blog/nha-cung-cap-passkey) thay vì tự xây dựng, vì việc quản lý
[cơ sở hạ tầng](https://www.corbado.com/passkeys-for-critical-infrastructure) passkey nội bộ gây ra những phức
tạp ẩn giấu 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ý tương thích WebAuthn và
tích hợp liền mạch với các hệ thống [ngân hàng](https://www.corbado.com/passkeys-for-banking) cũ - tất cả những
điều này các nhà cung cấp passkey đã xử lý.

Các ngân hàng như Ubank, [Revolut](https://www.corbado.com/blog/revolut-passkeys) và
[Finom](https://www.corbado.com/blog/finom-passkeys) đ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. Phân tích [ROI của passkey](https://www.corbado.com/vi/blog/passkey-ap-dung-luan-cu-kinh-doanh) thường ủng
hộ việc 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
các triển khai cho thấy sự giảm đáng kể các nỗ lực gian lận và chi phí hỗ trợ liên quan
đến xác thực.

**Ví dụ:** Armstrong Bank, First Financial Bank, Ubank, [Revolut](https://www.corbado.com/blog/revolut-passkeys),
[Finom](https://www.corbado.com/blog/finom-passkeys), Neobank, Cathay Financial Holdings, Stripe,
[PayPal](https://www.corbado.com/blog/paypal-passkeys), Square

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

**Những cân nhắc chính:**

- [Tuân thủ HIPAA](https://www.corbado.com/vi/blog/tuan-thu-an-ninh-mang) và GDPR đòi hỏi 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 bảo mật và 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](https://www.corbado.com/passkeys-for-healthcare) vẫn dựa vào
  [cơ sở hạ tầng](https://www.corbado.com/passkeys-for-critical-infrastructure) 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ủ trong khi đơ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ập nhật tuân thủ và độ tin cậy của xác thực, giảm bớt gánh nặng cho
các đội ngũ IT.

**Ví dụ:** CVS Health, Caremark, Helsana, NHS, Swica

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

**Những cân nhắc chính:**

- Tối ưu hóa Tỷ lệ chuyển đổi (CRO) là yếu tố sống còn của doanh nghiệp - sự phiền toái
  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 liền mạch (người dùng duyệt trên di động nhưng
  hoàn tất [thanh toán](https://www.corbado.com/vi/blog/xac-thuc-ky-thuat-so-thanh-toan-apple-vs-google-wallet)
  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 cần thiết.

**Khuyến nghị:** Các nền tảng [thương mại điện tử](https://www.corbado.com/passkeys-for-e-commerce) được hưởng
lợi nhiều nhất từ một nhà cung cấp triển khai passkey mang lại tỷ lệ chấp nhận cao. Các
nền tảng lớn như Amazon và [Shopify](https://www.corbado.com/blog/shopify-passkeys) đã triển khai xác thực bằng
passkey, chứng tỏ sự chấp nhận ngày càng tăng của công nghệ này trong
[thương mại điện tử](https://www.corbado.com/passkeys-for-e-commerce). 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 thất bại, trong khi xác thực dựa trên passkey có thể đạt
được tỷ lệ đăng nhập thành công lên đến 95-97% như đã thấy tại
[các lần áp dụng trước đây](https://fidoalliance.org/case-study-intuits-roi-from-passwordless-customer-authentication/).
Phân tích [ROI của passkey](https://www.corbado.com/vi/blog/passkey-ap-dung-luan-cu-kinh-doanh) 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ư.

Amazon gần đây cho biết họ đã đặt mục tiêu tham vọng là 100% chấp nhận passkey 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 thử nghiệm 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 dùng.

**Ví dụ:** [KAYAK](https://www.corbado.com/blog/kayak-passkeys), Amazon, Mercari, Best Buy,
[eBay](https://www.corbado.com/blog/ebay-passkeys), Home Depot, [Shopify](https://www.corbado.com/blog/shopify-passkeys), Target

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

**Những cân nhắc chính:**

- Xác thực trên nhiều thiết bị là cần thiết, vì người dùng đặt chuyến đi trên một thiết bị
  và làm thủ tục trên một thiết bị khác.
- Các nhà cung cấp chuyên về passkey phải đảm bảo đăng nhập nhanh chóng và an toàn để đặt
  chỗ, làm thủ tục và quản lý tài khoản 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](https://www.corbado.com/passkeys-for-travel) 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](https://www.corbado.com/passkeys-for-travel) nên triển khai các
giải pháp passkey để tăng cường bảo mật và trải nghiệm người dùng. Các công ty hàng đầu
như [Kayak](https://www.corbado.com/blog/kayak-passkeys) và các [hãng hàng không](https://www.corbado.com/passkeys-for-airlines) lớn đã
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ị tức thì. Ngành khách sạn đặc biệt được hưởng lợi từ việc giảm thời
gian làm thủ tục và cải thiện bảo mật thông qua việc triển khai passkey, đảm bảo xác thực
suôn sẻ trên tất cả các điểm tiếp xúc (ứng dụng, kiosk, web, và các nền tảng đối tác).

**Ví dụ:** Air New Zealand, Bolt, Grab, [Uber](https://www.corbado.com/blog/uber-passkeys), Hyatt

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

**Những cân nhắc chính:**

- Chi phí triển khai passkey phải phù hợp với nhu cầu tuân thủ và cải thiện trải nghiệm
  người dùng.
- Nhiều khách hàng [bảo hiểm](https://www.corbado.com/passkeys-for-insurance) không rành về 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à điều bắt buộc
- Tích hợp passkey với xác minh danh tính thường được yêu cầu để quản lý hợp đồng và xử lý
  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ủ quy định. Các nhà cung cấp [bảo hiểm](https://www.corbado.com/passkeys-for-insurance) báo cáo giảm
đáng kể số lượng 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à xác minh danh tính
tích hợp đảm bảo bảo mật trong khi vẫn giữ cho việc đăng nhập của khách hàng đơn giản.
Phân tích [ROI của passkey](https://www.corbado.com/vi/blog/passkey-ap-dung-luan-cu-kinh-doanh) gợi ý rằng việc
giảm đặt lại mật khẩu và tổn thất do gian lận sẽ bù đắp chi phí của nhà cung cấp.

**Ví dụ:** Branch

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

**Những cân nhắc chính:**

- Tiêu chuẩn bảo mật và yêu cầu tuân thủ cao nhất (ví dụ: [NIST](https://www.corbado.com/blog/nist-passkeys),
  khung Essential Eight yêu cầu [MFA chống lừa đảo](https://www.corbado.com/vi/blog/passkeys-va-psd2)).
- Nhu cầu triển khai quy mô lớn trên các nhóm dân cư đa dạng với trình độ kỹ thuật khác
  nhau
- Yêu cầu tích hợp với các [hệ thống xác minh](https://www.corbado.com/vi/blog/xac-minh-danh-tinh-ky-thuat-so)
  danh tính của [chính phủ](https://www.corbado.com/passkeys-for-public-sector) hiện có và
  [cơ sở hạ tầng](https://www.corbado.com/passkeys-for-critical-infrastructure) cũ

**Khuyến nghị:** Đối với các cơ quan [chính phủ](https://www.corbado.com/passkeys-for-public-sector), 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 đảm bảo khả
năng tiếp cận là điều cần thiết. Sự thành công trong việc triển khai tại
[VicRoads](https://www.corbado.com/blog/vicroads-passkeys) cho thấy các tổ chức chính phủ hưởng lợi nhiều nhất từ
các giải pháp passkey bên ngoài 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 đa thiết bị và cung cấp các luồng xác thực thích ứng để phù hợp
với tất cả công dân.

**Ví dụ:** [VicRoads](https://www.corbado.com/blog/vicroads-passkeys), myGov, State of Michigan

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

**Những cân nhắc 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](https://www.corbado.com/passkeys-for-telecom) 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 sẵn sàng cao và chịu
  lỗi tốt.
- Hỗ trợ đa thiết bị và đa nền tảng là 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 web. Xác thực bằng 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](https://www.corbado.com/passkeys-for-telecom) và tiện ích có thể cần tích hợp passkey vào các hệ
  thống IAM và nền tảng nhận dạng khách hàng hiện có mà không làm gián đoạn các luồng xác
  thực hiện tại.
- Phòng chống gian lận và
  [bảo mật tài khoản](https://www.corbado.com/vi/blog/cach-chuyen-sang-khong-mat-khau-hoan-toan) là ưu tiên hàng
  đầu, đặc biệt là đối với gian lận hoán đổi SIM, trộm cắp danh tính và truy cập tài khoản
  trái phép. Passkey có thể giảm đáng kể các cuộc tấn công lừa đảo (phishing) và rủi ro
  nhồi 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](https://www.corbado.com/passkeys-for-telecom) 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ị. Với quy mô,
độ phức tạp và yêu cầu bảo mật của những ngành này, một nhà cung cấp passkey được quản lý
sẽ đảm bảo tuân thủ, tính sẵn sà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ó. Các gã khổng lồ viễn thông và các nhà cung cấp tiện ích ưu tiên kỹ thuật số đã và
đang đón nhận passkey như một phần của 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, vì việc bảo trì liên tục, cập nhật bảo
mật và các yêu cầu tuân thủ quy định đều do nhà cung cấp xử lý.

**Ví dụ:** Deutsche Telekom, [Telstra](https://www.corbado.com/blog/telstra-passkeys), SK
[Telecom](https://www.corbado.com/passkeys-for-telecom)

### 7.8 Khuyến nghị cho Passkey trong B2B SaaS

**Những cân nhắc chính:**

- Xác thực đa người thuê (multi-tenant) là cần thiết cho B2B SaaS, đòi hỏi tích hợp
  passkey có thể mở rộng trên các hệ thống IAM khác nhau.
- Các doanh nghiệp mong đợi [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) (OIDC/SAML), do đó
  việc tích hợp liền mạch với các Nhà cung cấp danh tính là yếu tố sống còn của 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, một giải pháp triển khai
passkey 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 phát triển
nội bộ. Các công ty B2B kỹ thuật số như Notion, Hubspot hoặc
[Vercel](https://www.corbado.com/blog/vercel-passkeys) đã đón nhận 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 phát triển nội bộ, vì việc bảo trì, cập nhật
và các yêu cầu tuân thủ đều được nhà cung cấp chi trả.

**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 việc đăng nhập
cho người dùng cuối trong khi 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 liệu 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. Trong khi các triển khai tự làm (DIY) cung cấp toàn quyền
kiểm soát, 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 phương pháp tiếp cận nhanh hơn, có
thể mở rộng và hiệu quả về chi phí, đảm bảo tỷ lệ chấp nhận cao, trải nghiệm người dùng
liền mạch và 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à tiến tới không mật khẩu?**

    Một đợt triển khai passkey thành công đòi hỏi cơ sở hạ tầng
    [FIDO2](https://www.corbado.com/glossary/fido2)/WebAuthn, các luồng UX liền mạch, 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.

- **Nên tự triển khai passkey hay sử dụng một nhà cung cấp bên ngoài?**

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

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

    Các thư viện WebAuthn mã nguồn mở cung cấp một điểm khởi đầu nhưng thiếu 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 tăng
    cường việc chấp nhận. Một nhà cung cấp passkey đảm bảo việc triển khai liền mạch, khả
    năng mở rộng và các chiến lược chấp nhận người dùng được tối ưu hóa mang lại ROI tốt
    hơn, giảm thiểu sự phiền toái cho cả người dùng và nhà phát triển.

- **Những thách thức lớn nhất khi 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à việc chấp nhận passkey. Việc duy trì sự phức tạp liên tục của thiết bị
    và trình duyệt và đảm bảo tỷ lệ chấp nhận cao càng làm tăng thêm sự phức tạp.

- **Những rủi ro khi tự triển khai passkey là gì?**

    Các công ty có nguy cơ chịu 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. Thất bại trong việc tuân thủ, các lỗ hổng bảo mật
    và việc người dùng chấp nhận kém có thể làm hỏng thành công của một đợt triển khai
    passkey. Một giải pháp passkey do 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
    bảo mật và tuân thủ quy định tích hợp sẵn.