Thiết lập Phân quyền & Kiểm soát truy cập trong Phần mềm Kế toán: Checklist Bảo mật cho Admin/Kế toán trưởng

Bạn có thể thiết lập phân quyền và kiểm soát truy cập trong phần mềm kế toán để bảo mật dữ liệu tốt hơn ngay hôm nay, nếu bạn đi theo checklist đúng: xác định vai trò, chốt phạm vi dữ liệu, khóa các quyền rủi ro cao và bật cơ chế truy vết.

Tiếp theo, để phân quyền không bị “rối”, bạn cần chuyển nhu cầu vận hành thành ma trận vai trò–quyền hạn (ai được làm gì, ở phân hệ nào, với mức quyền nào), thay vì cấp quyền theo cảm tính hoặc theo “người cũ để lại”.

Ngoài ra, phân quyền chỉ thật sự có giá trị khi đi kèm kiểm soát truy cập: mật khẩu mạnh, 2FA, giới hạn đăng nhập sai, quản lý phiên đăng nhập và audit log đủ chi tiết để truy vết thao tác.

Để bắt đầu, bài viết này sẽ đi theo đúng thứ tự: bắt buộc hay không → khái niệm cốt lõi → checklist vai trò → ma trận quyền → giới hạn theo dữ liệu → chính sách bảo mật → quy trình rà soát định kỳ, rồi mới mở rộng tiêu chí chọn phần mềm “bảo mật mạnh”.

Phân quyền & kiểm soát truy cập trong phần mềm kế toán có bắt buộc để bảo mật không?

Có, phân quyền và kiểm soát truy cập trong phần mềm kế toán là “điều kiện gần như bắt buộc” để bảo mật dữ liệu khi có từ 2 người dùng trở lên, vì nó giảm rò rỉ thông tin, giảm sai sót thao tác, và tăng khả năng truy vết khi có sự cố.

Cụ thể, câu hỏi “có bắt buộc không?” sẽ rõ ràng hơn nếu bạn nhìn qua 3 lý do cốt lõi sau:

1) Giảm rủi ro rò rỉ dữ liệu tài chính nhạy cảm
Dữ liệu kế toán không chỉ là số liệu doanh thu/chi phí, mà còn gồm: công nợ khách hàng, hợp đồng, bảng lương, tài khoản ngân hàng, hóa đơn… Nếu ai cũng “xem được hết” thì rủi ro lộ dữ liệu tăng theo số người dùng.
Khi bạn phân quyền theo vai trò (Role) và theo hành động (xem/thêm/sửa/xóa/in/xuất), bạn biến “bảo mật” thành luật hệ thống chứ không phụ thuộc vào ý thức cá nhân.

2) Giảm sai sót và gian lận nhờ giới hạn thao tác rủi ro cao
Trong vận hành thực tế, lỗi thường đến từ “quyền sửa/xóa” hoặc “ghi sổ/khóa sổ” bị cấp quá rộng.
Phân quyền đúng giúp bạn khóa các thao tác có thể làm biến dạng dữ liệu: sửa chứng từ đã ghi sổ, xóa chứng từ có liên quan chuỗi, sửa số dư đầu kỳ…

3) Tăng khả năng truy vết và quy trách nhiệm khi có vấn đề
Không có audit log (nhật ký) thì bạn chỉ đoán “ai làm”. Có audit log thì bạn biết “ai – làm gì – lúc nào – trên dữ liệu nào – từ đâu”.
Đây là nền tảng để xử lý sự cố nhanh, giảm downtime và giảm tranh cãi nội bộ.

Theo nghiên cứu của Brigham Young University từ Computer Science Department, năm 2019, nhóm nghiên cứu đã khảo sát 4.275 người dùng về 2FA và nhấn mạnh 2FA giúp phòng thủ trước rủi ro “mật khẩu bị lộ” trong xác thực tài khoản.

Phân quyền người dùng trong phần mềm kế toán là gì và khác gì với kiểm soát truy cập?

Phân quyền người dùng trong phần mềm kế toán là cơ chế quản trị quyền theo vai trò (Role) để quyết định người dùng được làm gì trong hệ thống; còn kiểm soát truy cập là cơ chế xác thực và ràng buộc đăng nhập để quyết định người dùng có vào được hệ thống và vào bằng cách nào.

Để hiểu rõ hơn, bạn cần tách bạch hai lớp “quyền” hay bị trộn lẫn:

Phân quyền (Authorization – “được phép làm gì”)
Trọng tâm: vai trò, quyền theo chức năng, quyền theo phân hệ, quyền theo dữ liệu.
Ví dụ: Kế toán công nợ được tạo phiếu thu, xem báo cáo công nợ; không được xóa chứng từ đã ghi sổ.

Kiểm soát truy cập (Authentication + Session Control – “vào bằng cách nào”)
Trọng tâm: mật khẩu, 2FA, đăng nhập 1 thiết bị hay nhiều thiết bị, thời gian hết hạn phiên, giới hạn nhập sai, IP/thiết bị tin cậy.
Ví dụ: Admin bắt buộc bật 2FA; nếu nhập sai quá số lần cho phép thì tài khoản bị khóa tạm thời.

So sánh nhanh (móc xích đúng vấn đề): Phân quyền giúp bạn trả lời “ai được làm gì”, còn kiểm soát truy cập giúp bạn trả lời “ai được vào hệ thống như thế nào”. Khi thiếu 1 trong 2, bảo mật sẽ bị thủng ở đúng chỗ mà hacker hoặc sai sót nội bộ khai thác.

Google công bố nghiên cứu về “account hygiene” cho thấy việc thêm bước xác thực/phục hồi giúp chặn phần lớn tấn công tự động và phishing hàng loạt trong giai đoạn nghiên cứu.

Checklist thiết lập phân quyền theo vai trò trong phòng kế toán gồm những nhóm nào?

Có 6 nhóm vai trò phân quyền chính trong phòng kế toán: Admin hệ thống, Kế toán trưởng, Kế toán tổng hợp, Kế toán phần hành, Thủ quỹ/Ngân hàng, và Người xem báo cáo, phân loại theo tiêu chí “trách nhiệm nghiệp vụ + mức rủi ro thao tác”.

Dưới đây, để bám đúng checklist “thiết lập phân quyền”, bạn nên chốt vai trò theo thứ tự từ rủi ro cao đến thấp, rồi mới map quyền.

Vai trò Admin hệ thống nên “Có/Không” quyền gì để an toàn?

Có quyền quản trị người dùng và cấu hình, nhưng không nên có toàn bộ quyền nghiệp vụ kế toán, vì (1) giảm lạm quyền nội bộ, (2) giảm rủi ro tài khoản Admin bị chiếm, (3) tách bạch trách nhiệm khi kiểm tra log.

Cụ thể, Admin hệ thống nên có:
Có: tạo/sửa/khóa user, gán role, cấu hình hệ thống, cấu hình bảo mật, xem audit log, cấu hình tích hợp.
Không (hoặc hạn chế nghiêm ngặt): ghi sổ, xóa chứng từ, sửa chứng từ đã ghi sổ, thay đổi số dư đầu kỳ, thao tác khóa/mở kỳ mà không có phê duyệt.

Để minh họa, nếu bạn đang dùng phần mềm kế toán online, Admin thường là người quản trị tài khoản công ty; tài khoản này nếu “vừa quản trị vừa ghi sổ” sẽ trở thành “một điểm lỗi duy nhất” (single point of failure).

Kế toán trưởng cần quyền nào để vừa duyệt vừa kiểm soát rủi ro?

Kế toán trưởng nên có quyền theo hướng “xem toàn cục + duyệt/khóa”, thay vì “sửa/xóa sâu”, vì mục tiêu chính là kiểm soát chất lượng dữ liệu và chịu trách nhiệm báo cáo.

Gợi ý nhóm quyền tối ưu:
Xem tất cả phân hệ và báo cáo tổng hợp.
Duyệt chứng từ/luồng phê duyệt (nếu phần mềm có workflow).
Khóa kỳ/khóa sổ, mở khóa theo quy trình có lý do.
Xem audit log và báo cáo thay đổi dữ liệu (nếu có).

Kế toán viên theo phần hành (công nợ/kho/thuế) nên được giới hạn đến mức nào?

Kế toán phần hành là nhóm người dùng thao tác chứng từ theo mảng nghiệp vụ; họ nên được cấp quyền “đủ làm việc” trong phạm vi phân hệ, đồng thời bị giới hạn các quyền rủi ro cao để tránh sai lệch dữ liệu dây chuyền.

Cụ thể hơn theo từng nhóm:
Công nợ: tạo/sửa chứng từ trước ghi sổ, xem báo cáo công nợ liên quan; hạn chế xóa; hạn chế sửa sau ghi sổ.
Kho: tạo phiếu nhập/xuất, xem tồn kho theo kho được phân; hạn chế chỉnh sửa định mức nếu có giá thành.
Thuế/hóa đơn: quyền lập tờ khai/bảng kê theo trách nhiệm; nếu dùng phần mềm kế toán online tích hợp hóa đơn điện tử, cần giới hạn rõ: ai được phát hành, ai được điều chỉnh, ai được thay thế/hủy.

Nhiều tài liệu về RBAC nhấn mạnh nguyên tắc phân quyền theo vai trò giúp đơn giản hóa quản trị quyền và giảm sai phạm do cấp quyền trực tiếp theo từng cá nhân.

Thiết lập ma trận quyền theo chức năng “xem/thêm/sửa/xóa/in/xuất” như thế nào?

Thiết lập ma trận quyền theo 5 bước sẽ giúp bạn kiểm soát quyền “xem/thêm/sửa/xóa/in/xuất” nhất quán và giảm cấp quyền thừa: (1) chốt vai trò, (2) liệt kê phân hệ, (3) định nghĩa mức quyền, (4) gán quyền theo rủi ro, (5) test bằng tình huống thật.

Dưới đây là cách làm chi tiết theo đúng “móc xích” từ checklist vai trò sang quyền chức năng.

Bước 1: Chốt danh sách vai trò (Role list)
Admin, Kế toán trưởng, Kế toán tổng hợp, Công nợ, Kho, Thuế, Thủ quỹ, Viewer.

Bước 2: Liệt kê phân hệ/chức năng (Module map)
Danh mục, Chứng từ mua/bán, Thu/chi, Ngân hàng, Kho, Tài sản, Thuế, Báo cáo, Hệ thống.

Bước 3: Chuẩn hóa mức quyền (Permission set)
Xem (Read), Thêm (Create), Sửa (Update), Xóa (Delete), In (Print), Xuất (Export).
Nếu phần mềm có, bổ sung: Duyệt (Approve), Ghi sổ (Post), Khóa kỳ (Lock).

Bước 4: Gán quyền theo rủi ro
Ưu tiên “Read” rộng, “Delete/Update-after-post” cực hẹp.
Quyền “Export báo cáo” cần cân nhắc vì có thể xuất dữ liệu nhạy cảm.

Bước 5: Test bằng kịch bản vận hành
Test 5 kịch bản phổ biến: lập phiếu thu, sửa phiếu thu đã ghi sổ, xuất báo cáo công nợ, điều chỉnh hóa đơn, khóa kỳ.

Để bạn áp dụng nhanh, bảng dưới đây là mẫu ma trận quyền (bảng thể hiện: vai trò vs mức quyền trên một phân hệ điển hình).

Vai trò	Xem	Thêm	Sửa (trước ghi sổ)	Sửa (sau ghi sổ)	Xóa	In/Xuất
Admin hệ thống	Có	Không	Không	Không	Không	Có (giới hạn)
Kế toán trưởng	Có	Có (giới hạn)	Có (giới hạn)	Không/Quy trình	Không/Quy trình	Có
Kế toán phần hành	Có	Có	Có	Không	Hạn chế	Có (theo phạm vi)
Viewer	Có (báo cáo)	Không	Không	Không	Không	Hạn chế

Có nên cấp quyền “Xóa/Sửa sau ghi sổ” không?

Không, bạn không nên cấp quyền “xóa/sửa sau ghi sổ” một cách rộng rãi, vì (1) nó phá tính toàn vẹn dữ liệu, (2) làm khó truy vết đối chiếu, (3) tạo khoảng trống cho gian lận.

Tuy nhiên, để xử lý nghiệp vụ “bắt buộc sửa”, bạn có thể dùng 3 cơ chế thay thế an toàn hơn:
Cơ chế điều chỉnh (adjustment entries) thay vì sửa trực tiếp.
Quy trình mở khóa có phê duyệt: Kế toán trưởng duyệt, hệ thống ghi log lý do.
Giới hạn theo thời gian: chỉ sửa trong ngày/tuần trước khi chốt kỳ.

Nên áp dụng nguyên tắc “least privilege” trong kế toán ra sao?

Least privilege là nguyên tắc cấp quyền tối thiểu đủ làm việc; trong kế toán, nó được triển khai bằng cách cấp quyền theo phần hành, hạn chế quyền rủi ro cao, và rà soát định kỳ để thu hồi quyền không còn dùng.

Ví dụ thực tế:
Kế toán kho cần lập phiếu xuất/nhập nhưng không cần xem “tất cả” tài khoản ngân hàng.
Người xem báo cáo cần đọc báo cáo, nhưng không cần “xuất toàn bộ danh mục khách hàng” nếu không phục vụ công việc.

Phân quyền theo dữ liệu (chi nhánh/kho/tài khoản ngân hàng) có cần thiết không?

Có, phân quyền theo dữ liệu là cần thiết khi doanh nghiệp có đa chi nhánh/đa kho/đa tài khoản, vì phân quyền theo vai trò chỉ trả lời “ai làm gì”, còn phân quyền theo dữ liệu trả lời “làm trên phạm vi nào” để tránh truy cập vượt phạm vi.

Bên cạnh phân quyền theo vai trò, bạn nên nhóm phạm vi dữ liệu theo 3 loại chính:
1) Theo tổ chức: chi nhánh, phòng ban, cửa hàng.
2) Theo tài sản/dòng tiền: kho hàng, tài khoản ngân hàng, quỹ tiền mặt.
3) Theo đối tượng: khách hàng/nhà cung cấp theo khu vực, dự án, hợp đồng.

Phân quyền theo chi nhánh khác gì phân quyền theo vai trò?

Phân quyền theo vai trò quyết định “được làm gì”, còn phân quyền theo chi nhánh quyết định “được làm ở đâu/được thấy dữ liệu của ai”.

Trong khi đó, nhiều doanh nghiệp nhỏ hay nhầm rằng “kế toán kho” chỉ cần vai trò là đủ; nhưng nếu có 2 kho ở 2 chi nhánh, bạn vẫn cần khóa phạm vi để kế toán kho A không xem/không sửa dữ liệu kho B.

Những dữ liệu nào nên áp “giới hạn phạm vi” trước tiên?

Có 5 nhóm dữ liệu nên giới hạn trước tiên vì rủi ro lộ thông tin cao và ảnh hưởng dây chuyền lớn:
1) Tài khoản ngân hàng & giao dịch ngân hàng
2) Phiếu thu/chi & sổ quỹ
3) Công nợ khách hàng/nhà cung cấp
4) Phiếu kho & tồn kho theo kho
5) Hóa đơn & chứng từ thuế

Nếu bạn đang triển khai phần mềm kế toán online cho doanh nghiệp nhỏ, nhóm dữ liệu (1) và (2) thường là nơi “lộ dữ liệu” gây tổn thương nhất vì liên quan trực tiếp dòng tiền.

Chính sách bảo mật tài khoản cho phần mềm kế toán nên gồm những gì?

Có 7 thành phần chính trong chính sách bảo mật tài khoản cho phần mềm kế toán: mật khẩu mạnh, 2FA, giới hạn đăng nhập sai, quản lý phiên, quản lý thiết bị, phân quyền export, và audit log truy vết.

Ngoài ra, bạn nên viết chính sách theo dạng “luật có thể kiểm tra được”, ví dụ: “mật khẩu tối thiểu 12 ký tự”, “khóa 15 phút khi sai 5 lần”, “phiên đăng nhập hết hạn sau 30 phút không hoạt động”, thay vì các câu chung chung.

Danh sách chi tiết:
1) Mật khẩu mạnh: độ dài tối thiểu, không dùng lại mật khẩu cũ.
2) 2FA cho tài khoản nhạy cảm: Admin/Kế toán trưởng/Người duyệt.
3) Giới hạn đăng nhập sai: lockout, captcha, cảnh báo.
4) Quản lý phiên (session): timeout, đăng xuất từ xa, hạn chế đăng nhập đa thiết bị.
5) Quản lý thiết bị/IP (nếu có): thiết bị tin cậy, IP allowlist.
6) Kiểm soát xuất dữ liệu: export báo cáo/danh mục có điều kiện.
7) Audit log: bắt buộc ghi nhận thao tác quan trọng.

Có nên bật 2FA cho kế toán trưởng và admin không?

Có, bạn nên bật 2FA cho kế toán trưởng và admin vì (1) giảm rủi ro tài khoản bị chiếm khi lộ mật khẩu, (2) tăng an toàn khi đăng nhập từ xa, (3) tạo chuẩn bảo mật tối thiểu cho vai trò “quyền lực nhất”.

Ngược lại, nếu bạn không bật 2FA, chỉ cần một lần dính phishing là attacker có thể vào hệ thống như “người thật”, và lúc đó phân quyền cũng không cứu được vì attacker đang cầm đúng tài khoản có quyền cao.

Nhật ký truy cập/audit log cần ghi những trường nào để truy vết?

Audit log là nhật ký ghi lại hành động người dùng trong hệ thống; để truy vết hiệu quả, audit log nên có tối thiểu 8 trường: user, vai trò, hành động, đối tượng dữ liệu, thời gian, IP, thiết bị/phiên, và kết quả thao tác.

Cụ thể hơn, một audit log “đủ dùng” trong kế toán nên ghi:
Ai: userId, tên user, vai trò tại thời điểm thao tác
Làm gì: tạo/sửa/xóa/duyệt/ghi sổ/khóa kỳ/đăng nhập/đăng xuất
Trên cái gì: mã chứng từ, loại chứng từ, bản ghi danh mục
Khi nào: timestamp chuẩn
Từ đâu: IP, thiết bị, trình duyệt
Kết quả: thành công/thất bại, lý do thất bại
Trước & sau (nếu có): giá trị thay đổi (có thể ẩn dữ liệu nhạy cảm)

Quy trình kiểm tra định kỳ phân quyền để không “thừa quyền” nên làm thế nào?

Rà soát phân quyền theo chu kỳ 6 bước sẽ giúp bạn loại “thừa quyền” bền vững: (1) xuất danh sách quyền, (2) đối chiếu job description, (3) phát hiện quyền rủi ro, (4) thu hồi/cấp lại, (5) kiểm thử, (6) chốt biên bản và lịch rà soát tiếp theo.

Tiếp theo, để quy trình này chạy được trong thực tế, bạn cần biến nó thành “routine” theo tháng/quý chứ không làm kiểu chữa cháy.

Gợi ý triển khai:
Tần suất: doanh nghiệp nhỏ nên rà soát hàng quý, thay đổi nhân sự thì làm ngay.
Nguyên tắc: mọi quyền “Delete/Sửa sau ghi sổ/Export dữ liệu nhạy cảm” phải được rà soát riêng.
Bằng chứng: lưu lại ảnh chụp cấu hình/biên bản thay đổi/nhật ký hệ thống.

Khi nhân sự nghỉ việc, cần khóa tài khoản theo thứ tự nào?

Có 5 bước khóa tài khoản chuẩn khi nhân sự nghỉ việc: (1) khóa đăng nhập ngay, (2) thu hồi vai trò/quyền, (3) thu hồi thiết bị/phiên/2FA, (4) rà soát giao dịch gần nhất, (5) bàn giao và cập nhật chủ sở hữu dữ liệu.

Cụ thể:
1) Khóa đăng nhập ngay lập tức (không chờ bàn giao xong) để chặn truy cập ngoài ý muốn.
2) Thu hồi role/permission: tránh tình huống “tài khoản bị mở lại” mà vẫn còn quyền cũ.
3) Thu hồi phiên đăng nhập và 2FA: đăng xuất từ xa, đổi phương thức xác thực nếu cần.
4) Rà soát thao tác cuối: xem audit log 7–30 ngày gần nhất với vai trò nhạy cảm.
5) Bàn giao dữ liệu & quyền sở hữu: email nhận hóa đơn, tài khoản tích hợp, tài liệu xuất báo cáo.

Chọn phần mềm kế toán “bảo mật mạnh” dựa trên tiêu chí nào để tránh rủi ro?

Phần mềm A thắng về audit log & phân quyền chi tiết, phần mềm B tốt về 2FA & kiểm soát đăng nhập, còn phần mềm C tối ưu cho doanh nghiệp nhỏ nhờ đơn giản – dễ vận hành, vì “bảo mật mạnh” không chỉ là tính năng, mà là mức độ phù hợp giữa kiểm soát và khả năng dùng được.

Dưới đây là các tiêu chí bạn nên dùng để đánh giá, đặc biệt khi chọn phần mềm kế toán online:

1) RBAC rõ ràng: có vai trò, có phân quyền theo chức năng, có phân cấp.
2) Audit log đủ sâu: xem log, lọc theo user/hành động/chứng từ, xuất log khi cần điều tra.
3) 2FA và quản lý phiên: hỗ trợ 2FA cho tài khoản nhạy cảm; có kiểm soát đăng nhập bất thường.
4) Giới hạn theo dữ liệu: chi nhánh/kho/tài khoản ngân hàng (nếu mô hình cần).
5) Workflow phê duyệt & khóa kỳ: có cơ chế duyệt/khóa để giảm sửa sai.
6) Khả năng triển khai “vừa đủ”: nếu bạn là phần mềm kế toán online cho doanh nghiệp nhỏ, ưu tiên thiết kế đơn giản + checklist chuẩn, tránh cấu hình quá phức tạp khiến nhân sự tự tìm cách “lách”.

Nếu bạn cần một nơi tổng hợp checklist bảo mật và mẫu ma trận quyền để đội ngũ dễ copy áp dụng, bạn có thể lưu lại checklist nội bộ dạng tài liệu và quản lý phiên bản—hoặc tham khảo cách trình bày “template hóa” nội dung hướng dẫn trên DownTool.top để chuẩn hóa tài liệu vận hành (chỉ dùng như gợi ý về cách đóng gói tài liệu, không thay thế quy định nội bộ).

Audit log có “đủ dùng” hay chỉ “trang trí”: phân biệt bằng dấu hiệu nào?

Audit log “đủ dùng” thắng ở khả năng điều tra, còn audit log “trang trí” chỉ để nhìn, vì (1) log đủ dùng có thể lọc/tra theo chứng từ, (2) có định danh bản ghi, (3) lưu được lịch sử thay đổi quan trọng.

Dấu hiệu audit log đủ dùng:
Lọc theo user, vai trò, hành động, thời gian, phân hệ.
Click vào log thấy chi tiết: chứng từ nào, sửa trường nào, trước/sau ra sao (tùy mức hỗ trợ).
Có cơ chế chống sửa/xóa log hoặc hạn chế cực mạnh đối với log.

Phân quyền “càng chi tiết càng tốt” có đúng không?

Không, phân quyền càng chi tiết không luôn tốt, vì (1) tăng độ phức tạp cấu hình, (2) tăng lỗi vận hành do cấp thiếu quyền, (3) khiến đội ngũ tìm cách dùng chung tài khoản để “đỡ rối”—và đó là phản bảo mật.

Ngược lại, mục tiêu đúng là đủ chi tiết ở quyền rủi ro cao (xóa/sửa sau ghi sổ/export), còn các quyền “xem/in” có thể đơn giản hơn để vận hành mượt.

RBAC khác gì ABAC và khi nào nên dùng?

RBAC mạnh ở quản trị đơn giản theo vai trò, ABAC mạnh ở kiểm soát linh hoạt theo thuộc tính, vì RBAC gán quyền theo “chức danh”, còn ABAC gán quyền theo “điều kiện” (chi nhánh, dự án, mức tiền, trạng thái chứng từ…).

Khi nào nên cân nhắc ABAC (hoặc dạng “phân quyền theo điều kiện”):
Công ty đa chi nhánh, dữ liệu tách mạnh theo khu vực.
Quy trình duyệt theo ngưỡng (ví dụ: chứng từ > X cần cấp cao hơn).
Nhiều loại đối tượng dữ liệu và cần tự động hóa phạm vi truy cập.

Có nên cho kế toán làm việc từ xa trên Wi-Fi công cộng không?

Không, bạn không nên để kế toán làm việc từ xa trên Wi-Fi công cộng nếu thiếu lớp bảo vệ, vì (1) dễ bị nghe lén/giả mạo mạng, (2) tăng nguy cơ lộ phiên đăng nhập, (3) khó kiểm soát thiết bị.

Nếu bắt buộc làm remote, tối thiểu phải có:
2FA bắt buộc cho tài khoản nhạy cảm.
VPN hoặc mạng tin cậy.
Quản lý thiết bị (khóa màn hình, cập nhật, không lưu mật khẩu bừa bãi).
Session timeout ngắn và cảnh báo đăng nhập bất thường.

Theo nghiên cứu của Carnegie Mellon University (nghiên cứu triển khai 2FA tại môi trường đại học), năm 2018, nghiên cứu được thực hiện trên bối cảnh tổ chức có quy mô hàng chục nghìn người dùng và tập trung phân tích hành vi, rào cản, và tác động của việc bắt buộc 2FA đối với an toàn truy cập.