如何設定 SCEP 以實現自動化企業級 WiFi 憑證註冊
本指南說明如何設定 SCEP（簡單憑證註冊協定）以實現自動化企業級 WiFi 憑證註冊，涵蓋從 PKI 和 NDES 到 MDM 設定檔部署以及 RADIUS 驗證的完整架構。本指南專為飯店、零售連鎖店、體育場館、會議中心和公共部門組織的 IT 經理、網路架構師和 CTO 所設計，旨在協助他們淘汰預先共用金鑰，並實作具擴充性、基於身分識別的 802.1X EAP-TLS 驗證。Purple 獨立於硬體的雲端重疊平台可直接與此架構整合，提供與憑證驗證員工網路並行的訪客和 BYOD WiFi 層。
收聽此指南
查看播客逐字稿
執行摘要
對於企業級場所（無論是擁有 200 間客房的飯店、有 50 個據點的零售連鎖店，還是大型會議中心）而言，依賴預共用金鑰（PSK）作為員工 WiFi 會帶來安全隱患與營運瓶頸。單一密碼外洩就會使整個網路暴露在風險中。透過 IEEE 802.1X 和 EAP-TLS（可延伸驗證通訊協定 - 傳輸層安全性協定）進行憑證驗證可完全消除該風險。在存取點授予網路存取權限之前，每台裝置都必須透過密碼學證明其身分。
挑戰在於分發。手動將唯一的用戶端憑證部署到數千台 Windows、iOS 和 Android 裝置是不可行的。由 IETF 於 2020 年正式確立為 RFC 8894 的 SCEP（簡單憑證登錄通訊協定）解決了這個問題。它透過您的 MDM 平台自動執行在託管裝置上請求、核發和安裝數位憑證的流程，無需任何使用者互動。
本指南涵蓋了完整的架構：SCEP 的作用、它如何與 Microsoft Intune、Jamf 及其他 MDM 平台整合、大多數團隊常出錯的確切部署順序，以及導致斷線的營運陷阱。我們還涵蓋了來自旅宿業和零售業的兩個實際部署案例，並說明 Purple 的 Guest WiFi 平台如何與您的憑證驗證員工網路並行運作。
收聽配套播客簡報：
技術深度解析：SCEP、PKI 與 802.1X
SCEP 的實際作用
SCEP 並非用來取代您的公開金鑰基礎建設（PKI）。它是建構在其之上的自動化登錄層。您的 PKI（通常是包含離線根 CA 和線上核發 CA 的雙層架構）仍然是信任根源。SCEP 自動化了裝置向該 CA 請求憑證的步驟，消除了手動產生 CSR 和安裝憑證的需求。
在 WiFi 驗證的背景下，目標通訊協定是 EAP-TLS。這是 802.1X 驗證方法，要求用戶端裝置和 RADIUS 伺服器都必須出示有效的 X.509 憑證。在沒有密碼學證明的情況下，雙方都不會信任彼此。這種雙向驗證模型消除了憑證遭竊的風險，並能防範邪惡雙生（evil twin）攻擊（即攻擊者架設惡意存取點以竊取使用者名稱和密碼）。
如需 EAP-TLS 握手過程的詳細分解，請參閱我們的指南： WiFi 憑證驗證：安全網路存取 。
逐步解析 SCEP 註冊流程
完整的註冊鏈運作方式如下。您的 MDM 平台（Microsoft Intune、Jamf 或其他 MDM）會將 SCEP 承載資料（payload）推送到受管理裝置。該承載資料包含兩樣東西：指向您的 NDES（網路裝置註冊服務）伺服器或雲端 SCEP 閘道的 SCEP URL，以及挑戰密碼（challenge password）或共享金鑰。
裝置會在本地端自行產生其公鑰與私鑰對。這是 SCEP 的關鍵安全特性：私鑰是在裝置上產生的，儲存在安全隔離區（secure enclave）或 TPM 晶片中，且絕不會透過網路傳輸。接著，裝置會建立憑證簽署要求（CSR）並將其傳送至 SCEP 閘道。閘道會驗證挑戰密碼，將 CSR 轉發給您的憑證授權單位（CA），CA 隨即對其進行簽署並將公鑰憑證傳回給裝置。
從那時起，當裝置連線到您的 WiFi SSID 時，它會向 RADIUS 伺服器出示該憑證。RADIUS 伺服器會根據您的 CA 信任鏈驗證該憑證，檢查憑證撤銷清單（CRL）以確認憑證未被撤銷，如果一切無誤，則向存取點（access point）傳送 Access-Accept 訊息。裝置隨即連上網路。整個過程對使用者而言是完全無感的。
SCEP 對比 PKCS：WiFi 該使用哪一個
像 Intune 這樣的 MDM 平台支援兩種憑證傳遞機制：SCEP 和 PKCS（公鑰加密標準）。這兩者的架構差異非常顯著。
使用 SCEP 時，私鑰是在裝置上產生的，且絕不會離開裝置。而使用 PKCS 時，憑證授權單位（CA）會在集中端同時產生公鑰和私鑰，然後憑證連接器透過網路將該金鑰對推送到裝置上。這意味著私鑰會被傳輸，從而引入了理論上的攻擊面。
PKCS 適用於需要金鑰託管（key escrow）的案例，例如 S/MIME 電子郵件加密。對於 WiFi 驗證，SCEP 才是正確的選擇。私鑰會保留在裝置上。
| 屬性 | SCEP | PKCS |
|---|---|---|
| 私鑰產生方式 | 裝置上（TPM/Secure Enclave） | 集中式（CA） |
| 私鑰傳輸 | 絕不 | 透過網路 |
| 是否需要 NDES 伺服器 | 是（或雲端閘道） | 否 |
| 推薦用於 WiFi | 是 | 否 |
| 推薦用於 S/MIME | 否 | 是 |
硬體相容性
SCEP 和 EAP-TLS 是與廠商無關的標準。它們適用於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 的無線基地台。不論您是使用 Windows NPS、FreeRADIUS 還是雲端 RADIUS 服務，您的 RADIUS 設定都是您定義憑證驗證原則和動態 VLAN 分配的地方。
動態 VLAN 分配是您根據裝置身分進行網路區隔的方式。員工裝置會分配到 VLAN 10 並擁有內部系統的存取權限。承包商裝置會分配到 VLAN 20 且僅能存取網際網路。銷售點（POS）終端機則分配到 VLAN 30 且僅能存取付款處理系統。這一切都由憑證屬性和 RADIUS 原則驅動，無需對每台裝置進行手動干預。
如需深入瞭解 WiFi Analytics 如何與基於身分的網路區隔整合，請參閱我們的分析平台概覽。
實作指南：部署順序
成功為企業級 WiFi 設定 SCEP 需要嚴格遵守特定的部署順序。MDM 平台會強制執行設定檔的相依性：在裝置上存在該憑證之前，參照 SCEP 憑證的 WiFi 設定檔將無法套用。違反此順序是部署失敗最常見的原因。
其順序為：信任的根憑證第一、SCEP 設定檔第二、WiFi 設定檔第三。此順序不容妥協。
步驟 1：部署信任的根憑證設定檔
在任何裝置可以要求用戶端憑證或信任您的 RADIUS 伺服器之前，它必須先信任發行憑證的憑證授權單位（CA）。將您的根 CA 憑證（以及任何中繼 CA 憑證）匯出為 .cer 檔案。在您的 MDM 管理中心中，建立一個「信任的憑證」設定檔，上傳 .cer 檔案，然後將其部署到您的目標裝置群組。
如果您使用的是雙層 PKI 架構（建議做法），您需要根據您的 MDM 平台，將根 CA 和發行 CA 憑證部署為個別的「信任的憑證」設定檔，或是單一設定檔中的憑證鏈。
步驟 2：設定 SCEP 憑證設定檔
建立信任關係後，設定 SCEP 設定檔以指示裝置如何取得其用戶端憑證。
建立一個新的組態設定檔，並選擇 SCEP 憑證設定檔類型。設定主體名稱格式。對於使用者驅動的驗證，標準格式為 CN={{UserPrincipalName}}。對於裝置驗證（共用裝置、IoT、POS 終端機），請使用 CN={{AAD_Device_ID}}。將金鑰用途設定為「數位簽章」與「金鑰加密」。將延伸金鑰用途設定為「用戶端驗證」（OID: 1.3.6.1.5.5.7.3.2）。將此設定檔連結至步驟 1 中建立的「信任的根憑證」設定檔。提供您 NDES 伺服器的外部 URL。
針對 Microsoft Intune，NDES 伺服器必須透過 Azure AD Application Proxy 發佈，以便遠端裝置在抵達現場前進行註冊。切勿將 NDES 直接暴露於網際網路。
步驟 3：部署 802.1X WiFi 設定檔
最後一個步驟是推送將憑證與網路 SSID 綁定的 WiFi 設定。建立一個 Wi-Fi 設定檔。輸入與您的存取點（Access Point）廣播完全相同的網路名稱 (SSID)。選擇 WPA2-Enterprise 或 WPA3-Enterprise 作為安全性類型。將 EAP 類型設定為 EAP-TLS。在驗證設定中，選擇在步驟 2 中建立的 SCEP 憑證設定檔作為用戶端驗證憑證。指定用於伺服器驗證的信任的根憑證（Trusted Root Certificate）——這可確保裝置僅連線到您合法的 RADIUS 伺服器，而非惡意存取點。
識別提供者整合
SCEP 憑證屬性——特別是主體替代名稱 (SAN)——可以攜帶來自 Microsoft Entra ID、Okta 或 Google Workspace 的使用者主要名稱。這會將憑證與特定身分綁定。當您在 Entra ID 中停用帳戶且 MDM 取消註冊該裝置時，憑證會被撤銷，WiFi 存取權限也會自動中斷。這種自動撤銷是預先共用金鑰（Pre-shared key）無法比擬的安全優勢。
如需更多關於 EAP Method WiFi: A Guide to Secure Network Access 的資訊（包括 PEAP-MSCHAPv2 遷移路徑），請參閱我們的專屬指南。
最佳實踐與產業標準
NDES 伺服器部署位置
NDES 伺服器必須可從網際網路存取，以便裝置在抵達現場前進行註冊。請透過 Azure AD Application Proxy 發佈 NDES URL。這提供了安全的遠端存取，而無需開啟輸入防火牆連接埠，並允許您將條件式存取原則套用到註冊流程。切勿將 NDES 直接暴露於網際網路。
對於管理超過 500 台裝置的網路，請考慮使用雲端 SCEP 閘道，而非內部部署的 NDES。雲端閘道消除了 NDES 的單一故障點，可進行水平擴充，且通常直接與雲端 RADIUS 服務整合。
CRL 可用性
您的 RADIUS 伺服器在每次裝置驗證時都會檢查憑證撤銷清單（CRL）。如果您的 CRL 發佈點 (CDP) 因伺服器故障或 URL 變更而無法使用，網路上的所有裝置將同時驗證失敗。請設定您的 NPS 或 RADIUS 伺服器以執行嚴格的 CRL 檢查，並使您的 CRL 端點保持高度可用。在正式上線前測試撤銷功能。
PCI DSS 4.0 規範 8.6 要求在持卡人資料環境的網路層進行多因素驗證。在 Retail 和 Hospitality 環境中，搭配 SCEP 佈署憑證的 EAP-TLS 符合無線網路的此項要求。
WPA3 相容性
EAP-TLS 完全相容於 WPA3-Enterprise。採用 192 位元安全性套件 (Suite B) 的 WPA3-Enterprise 強制要求使用 EAP-TLS，這也是 Wi-Fi Alliance 針對政府、金融和醫療保健網路所推薦的組合。如果您是在具有嚴格合規要求的 醫療保健 或 交通運輸 環境中進行部署，採用 EAP-TLS 的 WPA3-Enterprise 就是正確的目標架構。
BYOD 與訪客 WiFi
SCEP 需要 MDM 註冊才能推播憑證承載資料。它不涵蓋未受管理的 BYOD 裝置或訪客。針對這些使用案例，您需要一個具備 Captive Portal 和身分驗證的獨立 SSID。Purple 的平台能乾淨俐落地處理該層級，與您透過憑證驗證的員工網路並行運作。我們的 Guest WiFi 平台支援自願選擇加入、第一方數據擷取，並與 Microsoft Entra ID、Okta 和 Google Workspace 整合以進行身分驗證。
疑難排解與風險緩釋
WiFi 設定檔套用失敗
症狀： 裝置已接收到信任的根憑證和 SCEP 憑證，但 WiFi 設定檔在 MDM 中顯示為「錯誤」或「不適用」。
根本原因： 群組目標不比對。如果 SCEP 設定檔針對「使用者」群組，而 WiFi 設定檔針對「裝置」群組，MDM 將無法解析此相依性。
修正方法： 稽核您的指派。確保信任的根憑證、SCEP 和 WiFi 設定檔全部針對完全相同的目錄群組。
NDES 403 Forbidden 錯誤
症狀： 裝置無法擷取 SCEP 憑證。NDES IIS 記錄顯示 HTTP 403 錯誤。
根本原因： MDM Certificate Connector 服務帳戶缺乏對憑證範本的「讀取」和「註冊」權限，或者防火牆 URL 篩選封鎖了 SCEP 查詢字串參數。
修正方法： 驗證連接器帳戶在 CA 範本上具有「讀取」和「註冊」權限。檢查防火牆記錄，確保未封鎖包含 ?operation=GetCACaps 的 URL。
CRL 到期後的大規模驗證失敗
症狀： 網路上的所有裝置同時驗證失敗。
根本原因： CRL 已到期或 CDP URL 無法連線。RADIUS 伺服器無法確認憑證是否有效，因而判定失效並關閉連線。
修正方法： 設定 CRL 監控與警示。發佈有效期明顯長於發佈間隔的 CRL。在正式上線前，測試從 RADIUS 伺服器到 CDP 的連線能力。
憑證到期導致無聲失敗
症狀： 個別裝置斷斷續續地連線失敗，且無明顯規律。
根本原因： 用戶端憑證已到期，且 MDM 未成功更新憑證。
修正方法： 將憑證更新設定為在憑證生命週期的 80% 時觸發。監控 MDM 註冊狀態報告，以找出有憑證錯誤的裝置。設定適合您裝置汰換週期的憑證有效期 — 對於受管理端點，通常為一到兩年。
投資報酬率（ROI）與業務影響
過渡到基於 SCEP 的 802.1X 憑證驗證，可在安全性、營運和合規性方面帶來可衡量的回報。
減少技術支援工單： 基於密碼的 WiFi 會產生大量的支援工單，例如密碼過期、鎖定和輸入錯誤。基於憑證的驗證對使用者而言是無感的。企業在移轉後，通常會看到與 WiFi 相關的技術支援工單量減少 70-80%。
安全態勢： EAP-TLS 杜絕了憑證竊取和中間人（Man-in-the-Middle）攻擊。這直接支援了零售和餐旅網路的 PCI DSS 4.0 合規性，以及 GDPR 第 32 條關於適當技術安全措施的要求。
自動撤銷： 當員工離職時，在 Microsoft Entra ID 中停用其帳戶會觸發自動憑證撤銷和 MDM 取消註冊。無需網路團隊進行任何手動干預，即可切斷 WiFi 存取權限。
網路分段： 透過 RADIUS 憑證屬性進行動態 VLAN 分配，為您提供加密強制的網路分段。裝置會根據憑證屬性進入正確的網路分段，而不是根據 SSID 選擇或 MAC 地址過濾（這兩者都極易被繞過）。
Purple 在全球 80,000 多個實體場域運作，可用性達 99.999%，且我們的平台已通過 ISO 27001、GDPR、CCPA 和 Cyber Essentials 認證。我們與硬體無關的雲端重疊網路（cloud overlay）可與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 整合，因此您的憑證驗證員工網路和我們的訪客 WiFi 層可在相同的基礎架構上運作。
如需進一步瞭解 行為分析：WiFi 網路洞察 如何輔助您的安全網路部署，請參閱我們的分析指南。
參考資料
[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council
關鍵定義
SCEP (Simple Certificate Enrollment Protocol)
一項在 RFC 8894 中規範的協定，允許託管裝置透過 HTTP，使用共用挑戰密碼進行初始驗證，自動向憑證授權單位（CA）請求並接收 X.509 數位憑證。私鑰在裝置上產生，且絕不進行傳輸。
Microsoft Intune 和 Jamf 等 MDM 平台所使用的標準機制，用於大規模向託管端點部署 WiFi 驗證憑證。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
最安全的 802.1X 驗證方法，要求用戶端裝置和 RADIUS 伺服器雙方皆須出示有效的 X.509 憑證。雙向驗證意味著在沒有密碼學證明的情況下，雙方互不信任。
企業級 WiFi 的目標驗證協定。PCI DSS 4.0、WPA3-Enterprise 192 位元 (Suite B) 以及 HIPAA 針對處理敏感資料的無線網路，皆強制要求或強烈建議使用此協定。
NDES (Network Device Enrollment Service)
一項 Microsoft Windows Server 角色，在支援 SCEP 的裝置與憑證授權單位（CA）之間充當登冊授權單位（RA）。它負責驗證挑戰密碼，並代表缺乏網域認證的裝置將 CSR 轉發給 CA。
透過 Microsoft Intune 進行 SCEP 部署所需的基礎架構。應透過 Azure AD Application Proxy 發佈，而非直接暴露於網際網路。
PKI (Public Key Infrastructure)
用於發行、管理和撤銷數位憑證的憑證授權單位、原則和程序之階層架構。雙層 PKI 由一個離線根 CA（主信任錨點）和一個線上發行 CA（處理日常憑證發行）組成。
部署 EAP-TLS 和 SCEP 不可妥協的前置條件。根 CA 應保持實體隔離（air-gapped）；其私鑰是您整個憑證信任鏈的基石。
CSR (Certificate Signing Request)
由裝置產生、包含其公鑰和識別資訊的訊息，發送至憑證授權單位以請求已簽署的數位憑證。在 SCEP 中，CSR 在裝置上產生，並在傳輸前封裝於 PKCS 包裹中。
在 SCEP 登冊流程中由裝置自動產生。用於簽署 CSR 的私鑰絕不會離開裝置。
CRL (Certificate Revocation List)
由憑證授權單位發佈的清單，其中包含在到期日前已被撤銷的憑證序號。RADIUS 伺服器在每次驗證嘗試時都會檢查 CRL，以確保被撤銷的憑證無法存取網路。
CRL 發佈點（CDP）的可用性至關重要。如果 RADIUS 伺服器無法連線至 CRL，它將採取安全關閉模式並拒絕所有驗證，從而導致全網中斷。
RADIUS (Remote Authentication Dial-In User Service)
一種網路協定，為網路存取提供集中化的驗證、授權和計費（AAA）。在 802.1X WiFi 中，RADIUS 伺服器負責驗證用戶端憑證、檢查 CRL，並向存取點（AP）傳回 Access-Accept 或 Access-Reject 訊息。
802.1X 請求端-驗證端-伺服器（supplicant-authenticator-server）模型中的驗證伺服器。常見的實作包括 Windows NPS、FreeRADIUS 和雲端 RADIUS 服務。
Dynamic VLAN assignment
一項 RADIUS 功能，可根據憑證屬性或目錄群組成員資格，將已驗證的裝置分配到特定的 VLAN，而非依賴 SSID 選擇或 MAC 地址篩選。透過裝置識別實施網路分段。
使單一 SSID 能夠為具有不同網路存取權限的多種裝置類型提供服務。員工裝置分配到 VLAN 10（內部存取）；承包商裝置分配到 VLAN 20（僅限網際網路）；POS 終端機分配到 VLAN 30（僅限付款系統）。
MDM (Mobile Device Management)
IT 團隊用於登冊、設定、保護和管理智慧型手機、平板電腦和筆記型電腦的軟體。Microsoft Intune 和 Jamf 等 MDM 平台使用 SCEP 設定檔，在無需使用者互動的情況下，將憑證登冊指示推送到託管裝置。
基於 SCEP 的憑證部署之前置條件。裝置必須先在 MDM 登冊，然後才能接收 SCEP 和 WiFi 設定檔。未託管的 BYOD 裝置需要採用獨立的引導上網（onboarding）方法。
範例
一家擁有 200 間客房的 Premier Inn 飯店需要為其銷售點（POS）平板電腦和房務智慧型手機確保員工 WiFi 的安全。他們目前使用已洩露給承包商的預共用金鑰。他們透過 Microsoft Intune 管理裝置，且裝置包含 iOS 和 Android 系統。該飯店使用 HPE Aruba 存取點（AP）。
- 部署內部 Microsoft AD CS 雙層 PKI。在專用 Windows Server 上設定 NDES，並透過 Azure AD Application Proxy 發佈。
- 在 Intune 中，建立一個包含根 CA 和發行 CA 憑證的「信任的根憑證」設定檔。部署至「飯店員工裝置」Azure AD 群組。
- 在 Intune 中建立一個指向 NDES 外部 URL 的 SCEP 憑證設定檔。由於這些是共用裝置，將主體名稱格式設定為 CN={{AAD_Device_ID}}。將金鑰用途設定為數位簽章與金鑰加密，延伸金鑰用途設定為用戶端驗證。部署至「飯店員工裝置」。
- 為員工 SSID 建立一個 Wi-Fi 設定檔，設定 WPA2-Enterprise 和 EAP-TLS。選擇 SCEP 設定檔進行用戶端驗證，並選擇根 CA 進行伺服器驗證。部署至「飯店員工裝置」。
- 設定 HPE Aruba RADIUS 設定以指向 Windows NPS。在 NPS 上，設定一項需要 EAP-TLS 並為員工裝置分配 VLAN 10 的網路原則。
- 當裝置成功接收設定檔並連線後，輪替舊 SSID 上的 PSK 並安排其停用時程。
一家擁有 50 個據點的零售連鎖店希望在所有站點為企業筆記型電腦部署 802.1X。他們使用 Cisco Meraki 存取點（AP）和 Microsoft Intune。他們不想在每個據點或其資料中心部署和維護地端 NDES 伺服器或 AD CS 基礎架構。
- 實作雲端 PKI 和 SCEP 閘道服務，透過 SCEP 協定與 Intune 整合。雲端 CA 發行憑證；雲端 SCEP 閘道處理 CSR 驗證。
- 在 Cisco Meraki 控制面板的「無線 > 存取控制」下，針對企業 SSID 設定由 PKI 廠商提供的雲端 RADIUS 服務。將安全性設定為 WPA2-Enterprise，並將 RADIUS 指向雲端服務。
- 在 Intune 中，建立一個包含雲端 CA 根憑證的「信任的根憑證」設定檔。部署至「企業筆記型電腦」裝置群組。
- 建立一個指向雲端 SCEP 閘道 URL 的 SCEP 憑證設定檔。將主體名稱設定為 CN={{UserPrincipalName}} 以進行基於用戶的驗證。部署至「企業筆記型電腦」。
- 為企業 SSID 建立一個帶有 EAP-TLS 的 Wi-Fi 設定檔，並參照 SCEP 設定檔和雲端 CA 根憑證。部署至「企業筆記型電腦」。
- 當筆記型電腦註冊到 Intune 時，它們會自動透過雲端 SCEP 閘道向雲端 CA 要求憑證。這 50 個據點中的任何一個都不需要地端基礎架構。
練習題
Q1. 您的組織正在從 PEAP-MSCHAPv2 遷移至 EAP-TLS。您已成功將「信任的根憑證」和 SCEP 設定檔部署到 Intune 中的「企業使用者」Azure AD 群組。接著您將 WiFi 設定檔部署到「所有企業裝置」。使用者回報無法連線，且 WiFi 設定檔顯示為「不適用」。
提示：請檢查設定檔的相依性與群組目標規則。Intune 會根據指派的群組來解析設定檔的相依性。
查看標準答案
此問題出在群組目標不匹配。WiFi 設定檔相依於 SCEP 設定檔，而該 SCEP 設定檔的目標是使用者群組（「企業使用者」）。然而，WiFi 設定檔的目標卻是裝置群組（「所有企業裝置」）。Intune 無法跨群組類型解析相依性。解決方法是將這三個設定檔（信任的根憑證、SCEP 和 WiFi）的指派全部變更為相同的目標群組。請根據您的驗證模型（基於使用者或基於裝置）決定要使用使用者群組還是裝置群組，並在所有三個設定檔中一致地套用該設定。
Q2. 安全性稽核顯示，當員工離職且其 Microsoft Entra ID 帳戶被停用時，其公司智慧型手機在離職後最長一週內仍可連線到員工 WiFi 網路。
提示：請思考 RADIUS 伺服器在帳戶停用後，如何判定憑證是否仍然有效。傳達撤銷狀態的機制是什麼？
查看標準答案
這是因為 RADIUS 伺服器未執行嚴格的憑證撤銷清單（CRL）檢查，或者 CRL 的發佈頻率過低。當員工離職時，MDM 應取消註冊裝置，且憑證授權單位（CA）應撤銷該憑證。然而，如果 RADIUS 伺服器未在每次驗證嘗試時檢查 CRL，或者 CRL 僅每週發佈一次，則已撤銷的憑證將繼續被接受。解決方法包含三個步驟：設定 RADIUS 伺服器在每次驗證時強制執行嚴格的 CRL 檢查；設定 CA 以更短的間隔（每天或更頻繁）發佈 CRL；並確保 MDM 設定為在裝置取消註冊時觸發憑證撤銷。
Q3. 您需要為無法執行 MDM 代理程式且無法顯示 Captive Portal 的無螢幕 IoT 裝置（智慧溫控器、數位看板播放器）提供安全的 WiFi 存取。您能對這些裝置使用 SCEP 嗎？如果不行，推薦的替代方案是什麼？
提示：請考慮 SCEP 註冊的前置條件，以及對於無法進行 MDM 註冊或無法與瀏覽器互動的裝置，存在哪些替代方案。
查看標準答案
這些裝置無法使用 SCEP。SCEP 需要 MDM 代理程式來接收註冊 URL 和挑戰密碼、產生金鑰組並安裝產生的憑證。無法執行 MDM 代理程式的無螢幕 IoT 裝置無法參與 SCEP 註冊流程。推薦的替代方案為：（1）MAC 驗證旁路（MAB）結合嚴格的 VLAN 隔離 - RADIUS 伺服器根據裝置的 MAC 地址允許其連線，並將其置於無法存取企業系統的隔離 IoT VLAN 中；（2）如果裝置支援，EST（安全傳輸註冊，RFC 7030）可以為支援 HTTPS 但不支援 MDM 的裝置佈署憑證；（3）對於具有管理介面的裝置，某些廠商支援直接透過裝置韌體進行 SCEP 註冊，而不需要 MDM 代理程式。在所有情況下，無論使用何種驗證方法，IoT 裝置都應隔離在專用的 VLAN 上。
繼續閱讀本系列
企業 SCEP 指南：部署簡單憑證登錄協定以實現自動化校園 WiFi 安全
本技術參考指南為使用 SCEP 的企業 WiFi 憑證部署提供了權威的架構藍圖和逐步實施策略。內容涵蓋 SCEP 與 PKCS 之間的核心差異、成功部署所需的確切順序，以及 IT 主管的實際風險緩釋策略。
如何實施 SCEP 以實現自動化 WiFi 憑證登錄
本指南說明如何在企業場域中實施 SCEP（簡單憑證登錄協定）以實現自動化 WiFi 憑證登錄。內容涵蓋完整的架構藍圖——從 PKI 設計和 MDM 整合到強制性的三步驟部署流程——並向 IT 主管和網路架構師展示如何消除共享認證、自動化憑證生命週期管理，以及大規模滿足 PCI DSS 和 GDPR 的要求。
深入瞭解 Cisco SUDI：網路存取控制中的硬體型裝置識別
本指南詳細介紹 Cisco SUDI 的技術架構，說明以硬體為錨點的識別如何確保網路存取控制的安全。它為 IT 主管提供了具體可行的實作步驟，以便在企業場域中部署 802.1X EAP-TLS 驗證並自動執行零接觸部署 (Zero Touch Provisioning)。