Chứng chỉ firmware trên thiết bị sắp hết hạn: Tháng 6/2026 có ý nghĩa gì với đội ngũ IT?

Mọi thiết bị Windows được doanh nghiệp triển khai trước năm 2025 đều chứa một tập hợp chứng chỉ trong firmware Unified Extensible Firmware Interface (UEFI). Các chứng chỉ này đã tồn tại từ năm 2011, âm thầm xác thực chữ ký khởi động để đảm bảo không có thành phần không đáng tin cậy nào được chạy trước khi hệ điều hành tải. Phần lớn đội ngũ IT chưa từng phải quan tâm đến chúng. Nhưng điều đó sắp thay đổi.

Để hiểu chính xác điều gì đang thay đổi, trước tiên hãy cùng xem cách Secure Boot sử dụng hệ thống phân cấp các khóa được lưu trữ trong firmware UEFI:

• Ở cấp cao nhất là Platform Key (PK), có nhiệm vụ cấp quyền cho Key Enrollment Key (KEK).

• Tiếp theo, KEK ký các bản cập nhật cho hai cơ sở dữ liệu quan trọng: Allowed Signature Database (DB), chứa danh sách các chữ ký khởi động đáng tin cậy, và Forbidden Signature Database (DBX), dùng để chặn các chữ ký đã được xác định là không an toàn.

• Khi thiết bị khởi động, firmware sẽ đối chiếu chữ ký của bootloader với DB. Nếu chữ ký khớp và không nằm trong DBX, hệ thống sẽ tiếp tục quá trình khởi động.

Sau tháng 6, các thiết bị bị ảnh hưởng sẽ không còn nhận được các bản cập nhật bảo mật cho Secure Boot. Đến sau tháng 10, các thiết bị này sẽ ngừng nhận hoàn toàn các bản vá bảo mật cho Windows bootloader, bao gồm cả các biện pháp giảm thiểu những cuộc tấn công dạng bootkit như BlackLotus (CVE-2023-24932).

Đáng chú ý, quá trình chuyển đổi vào tháng 10 chỉ có thể diễn ra sau khi quá trình chuyển đổi tháng 6 hoàn tất. Vì vậy, nếu bỏ lỡ thời hạn đầu tiên, doanh nghiệp có thể phải đối mặt với những ảnh hưởng lớn hơn khi đến thời hạn tiếp theo.

Với các đội ngũ endpoint đang quản lý số lượng lớn thiết bị chạy Windows 10, Windows 11 hoặc Windows Server từ phiên bản 2012 đến 2025, đây là một công việc dễ bị bỏ qua nhưng hoàn toàn có thể mất đến ba tháng nếu không được chuẩn bị từ sớm.

Phạm vi ảnh hưởng cũng không chỉ giới hạn ở thiết bị vật lý: các máy ảo Hyper-V Generation 2 và VMware VM có bật Secure Boot cũng nằm trong diện cần xử lý, và đây chính là phần mà nhiều đội ngũ IT thường đánh giá thấp.

Vấn đề không nằm ở chứng chỉ, mà ở quá trình chuyển đổi  

Nếu đây chỉ là một bản vá thông thường, đội ngũ IT có thể triển khai bản cập nhật, chạy báo cáo xác minh rồi hoàn tất. Nhưng lần này thì khác. Quá trình chuyển đổi từ các chứng chỉ năm 2011 sang phiên bản UEFI CA 2023 mới là một workflow gồm nhiều bước theo trình tự, với các điều kiện tiên quyết bắt buộc do chính firmware thực thi.

Trước khi có thể thực hiện chuyển đổi, thiết bị phải sử dụng firmware UEFI và đã bật Secure Boot. Các máy sử dụng Legacy BIOS không thể tham gia quá trình này. Firmware từ OEM cũng phải được cập nhật lên phiên bản mới nhất. Đây là điều kiện dễ khiến các đội ngũ IT gặp khó khăn, bởi firmware của nhà sản xuất đã lỗi thời có thể khiến quá trình chuyển đổi thất bại giữa chừng và trông giống như lỗi Windows, cho đến khi truy ngược nguyên nhân về firmware.

Chỉ sau khi đáp ứng tất cả các điều kiện này, việc đặt khóa registry AvailableUpdates thành 0x5944 và khởi chạy scheduled task Secure-Boot-Update mới thực sự bắt đầu quá trình chuyển đổi. Tiếp theo, thiết bị thường cần khởi động lại hai lần, trong đó scheduled task phải chạy lại sau lần khởi động đầu tiên.

Cuối cùng, đội ngũ IT cần tiếp tục giám sát để xác nhận UEFICA2023Status thực sự chuyển sang trạng thái Updated, thay vì chỉ kiểm tra xem script đã chạy thành công hay chưa.

Thực hiện tất cả các bước này trên một thiết bị riêng lẻ không quá phức tạp. Khó khăn thực sự nằm ở việc triển khai trên toàn bộ hệ thống endpoint, nơi mỗi thiết bị có thể đang ở một trạng thái khác nhau: một số vẫn sử dụng Legacy BIOS, một số chưa bật Secure Boot, một số đang chờ cập nhật firmware từ OEM, một số đã sẵn sàng để chuyển đổi và một số khác đã hoàn tất. Những trạng thái này cũng liên tục thay đổi khi thiết bị được sửa chữa, cài đặt lại image hoặc mới được đưa vào hệ thống.

Microsoft hỗ trợ ba phương thức để kích hoạt quá trình chuyển đổi: sử dụng registry key thông qua PowerShell, Group Policy và WinCS API. Tuy nhiên, mỗi phương thức đều có những hạn chế đáng kể.

• PowerShell không cung cấp cách tích hợp sẵn để xác nhận quá trình chuyển đổi đã thực sự hoàn tất.

• Group Policy chỉ áp dụng cho các thiết bị đã tham gia domain, vì vậy các thiết bị của nhân viên làm việc từ xa không kết nối VPN hoặc các máy thuộc workgroup có thể bị bỏ sót.

• WinCS chỉ hỗ trợ Windows 11 23H2 trở lên và cũng chỉ dành cho các thiết bị đã tham gia domain, khiến những thiết bị còn lại không được bao phủ.

Việc xử lý tất cả những yếu tố này theo cách thủ công trên một hệ thống endpoint quy mô doanh nghiệp (từ kiểm tra trạng thái firmware trên từng thiết bị, điều phối quá trình khởi động lại, phân tích event log để phát hiện lỗi đến xác nhận quá trình chuyển đổi đã hoàn tất) là một khối lượng công việc rất khó mở rộng theo quy mô. Khi số lượng thiết bị tăng lên, bài toán về cơ bản vẫn không thay đổi, chỉ trở nên lớn và phức tạp hơn.

DEX add-on của Endpoint Central hỗ trợ như thế nào?  

Nếu doanh nghiệp đang sử dụng Endpoint Central, DEX add-on cung cấp một workflow được thiết kế riêng cho quá trình chuyển đổi này, giúp xử lý những bước mà việc triển khai registry hay Group Policy chưa thể bao phủ đầy đủ.

SecureBoot Upgrade workflow  

Thành phần đảm nhiệm phần lớn quá trình này là SecureBoot Upgrade workflow. Trước khi kích hoạt chuyển đổi trên bất kỳ thiết bị nào, workflow sẽ kiểm tra mức độ sẵn sàng dựa trên loại firmware, trạng thái Secure Boot, thông tin OEM và capability flag.

• Những thiết bị chưa sẵn sàng sẽ không được kích hoạt chuyển đổi mà được đưa vào một hàng đợi riêng, kèm theo nguyên nhân cụ thể. Nhờ đó, đội ngũ IT có thể nhanh chóng xác định thiết bị nào cần cập nhật firmware từ OEM và thiết bị nào hoàn toàn không thể thực hiện chuyển đổi.

• Với những thiết bị đáp ứng các điều kiện, workflow sẽ tự động kích hoạt quá trình chuyển đổi, điều phối các lần khởi động lại kèm thông báo cho người dùng để tránh làm gián đoạn công việc, chạy lại scheduled task sau lần khởi động đầu tiên để thực hiện giai đoạn chuyển đổi thứ hai, đồng thời liên tục theo dõi UEFICA2023Status và UEFICA2023Error trên từng thiết bị.

Một thiết bị chỉ được xác nhận hoàn tất khi hệ thống kiểm chứng quá trình chuyển đổi đã thực sự thành công, thay vì mặc định thành công chỉ vì không phát sinh lỗi.

Firmware Readiness sensor  

Hỗ trợ cho workflow này là Firmware Readiness sensor, liên tục thu thập và cập nhật trạng thái firmware trên toàn bộ hệ thống endpoint.

Thay vì chỉ xuất dữ liệu một lần rồi nhanh chóng trở nên lỗi thời khi trạng thái thiết bị thay đổi, sensor cung cấp một góc nhìn theo thời gian thực về mọi endpoint được quản lý và tự động cập nhật khi thiết bị chuyển sang trạng thái mới. Quá trình thực thi được đảm nhiệm bởi SecureBoot Update script, có nhiệm vụ thiết lập registry key và khởi chạy scheduled task, nhưng chỉ trên những thiết bị đã được sensor xác nhận đủ điều kiện.

Kết quả là đội ngũ IT có được điều mà phương pháp triển khai thủ công khó có thể cung cấp: một bức tranh chính xác và luôn được cập nhật về trạng thái chuyển đổi của toàn bộ hệ thống endpoint. Bao nhiêu thiết bị đã hoàn tất? Bao nhiêu đang trong quá trình chuyển đổi? Bao nhiêu bị chặn do firmware chưa đáp ứng yêu cầu? Bao nhiêu gặp lỗi và cần xử lý?

Đây chính là những thông tin mà đội ngũ IT có thể sử dụng để báo cáo với ban lãnh đạo khi được hỏi liệu doanh nghiệp đã sẵn sàng cho thời hạn tháng 6 hay chưa.

Nếu đang sử dụng Endpoint Central, bạn có thể kích hoạt DEX add-on và chạy Firmware Readiness Sensor trên toàn bộ hệ thống endpoint để có cái nhìn chính xác về mức độ sẵn sàng hiện tại. Sau đó, SecureBoot Upgrade Workflow sẽ đảm nhiệm quá trình chuyển đổi.

Để tìm hiểu cách triển khai trong môi trường thực tế trước khi đưa ra quyết định, hãy liên hệ với các chuyên gia sản phẩm của chúng tôi để được tư vấn. Dù bạn lựa chọn phương án nào, đây vẫn là công việc nên được bắt đầu ngay từ bây giờ.

Tài liệu gốc: Your fleet's firmware certificate is expiring: What June 2026 means for IT teams