(更新2023/10/1) 目前，IEC 62443有3種主流的認證機制。其中，IECEE及ISCI這兩種機制最為大宗，且這兩個機制各有其認證的驗證機構，負責執行相對應的標準驗證；本文將針對這兩種認證機制在認證範圍及架構上的差異，進行說明。
差異一：認證範圍
針對IEC 62443系列標準，IECEE與ISCI的認證範圍初步差異如上圖(紅色部分為ISCI涵蓋的範圍，黃色為IECEE涵蓋的範圍)，定義說明如下：
- ISCI涵蓋：part 3-3, part 4-1, part 4-2
從ISCI的涵蓋範圍，可以發現其認證對象較針對系統或組件的供應商(Product Supplier)，當系統或組件開發商拿到ISA Secure認證後，方可將其系統或組件登錄ISA網站，提供給業界做為採購參考。 - IECEE 涵蓋：part 2-4, part 3-3, part 4-1, part 4-2
相對地，IECEE的的標準涵蓋範圍較廣，針對系統整合商(System Integrator)及維運服務商(Maintain Service Provider)這兩種服務提供商(Service Provider)、系統或組件供應商(Product Supplier)都有可提供相對應的認證，供應商通過認證後，也可登錄在IECEE網站。
差異二：認證架構
ISCI跟IECEE的最主要的差異是在認證架構，請參考上圖，ISCI專注在「已開發的系統」、「已開發的組件」及「已執行的流程」；IECEE則在「開發」、「佈署、維運」這些階段都能提供認證。
ISCI: 三種認證機制，主要認證系統或組件的開發。
ISCI共定義了三種認證機制，其中兩個是針對產品認證，一個是針對流程認證。
- 產品認證：分別是「組件安全保證認證」(CSA)及「系統安全保證認證」(SSA)。這兩種認證均需要搭配安全開發流程(或稱安全開發生命週期)，供應商應透過安全開發流程，開發系統或組件，並符合IEC 62443所定義的安全等級要求(系統需參照part 3-3, 組件需參照part 4-2)。
- 流程認證：即「開發生命週期保證認證」(SDLA)，認證供應商的開發流程的合規性，其認證結果並沒有區分成熟等級；通過認證，表示供應商具有安全開發流程(文件)，且已按照安全開發流程執行專案，並產出符合安全開發流程的證據(已執行)，這相當於IEC 62443標準中所定義的成熟度等級4。
IECEE: 多種認證組合，跨越開發、佈署與維運階段。
IECEE目前針對IEC 62443系列標準中的四部標準(-2-4, -3-3, -4-1及-4-2)，提供8種認證機制，分佈在「開發」、「佈署與維運」兩個階段。
- 開發階段：分別針對流程、組件、系統，存在四種認證機制。流程認證部分，針對產品供應商的安全開發流程提供認證，包含「已定義但未執行」(即part 4-1 Scenario 1, 成熟度2)，「已定義且已執行」(即 part 4-1 Scenario 2, 成熟度3或4)；組件認證部分，產品供應商應依據安全開發流程，開發組件，該認證可彈性認證組件的安全等級(即part 4-2 Scenario 1)；系統認證部分，產品供應商可依據安全開發流程，開發系統，該認證可彈性認證系統的安全等級(即part 3-3 Scenario 1)。
額外說明 - 可彈性認證 關於IECEE可彈性認證的部分，筆者將會在下面的內容詳細說明。
額外說明 - 開發階段的組件與系統認證的差異 在IECEE規範文件(IECEE OD 2061)中，針對組件的認證，有規範必須搭配安全開發流程一起認證；至於系統認證，則無此規範。ISCI針對系統及組件，都有規範必須搭配安全開發流程。筆者將這兩者的關係，簡化如下： - ISCI-CSA = part 4-1 + part 4-2 - ISCI-SSA = part 4-1+ part 3-3 - IECEE-4-2 Scenario 1 = part 4-1 + part 4-2 - IECEE-3-3 Scenario 2 = part 3-3 (with/without part 4-1)
- 佈署與維運階段: 分別針對流程與系統，存在三種認證機制。流程認證部分，針對服務提供商的安全計畫提供認證，包含「已定義但未執行」(即part 2-4 Scenario 1, 成熟度2)，「已定義且已執行」(即 part 2-4 Scenario 2, 成熟度3或4)；系統認證部分，服務提供商可依據安全計畫，佈署和維運一套系統解決方案，該認證可彈性認證這一套系統解決方案的安全等級(即part 3-3 Scenario 2)。
額外說明 - 未被提及的IECEE認證 在佈署與維運階段，IECEE規範文件中，亦有針對part 2-4提供一產品認證。這邊的產品認證，指的是認證有助於實現系統解決方案的產品/組件。(請參考IEC 62443 的3種認證機制文中的介紹)
差異三：證書體現
ISCI跟IECEE都會在其網站公告通過認證的供應商，其目的都是為了提供給供應鏈的採購流程參考。然而，這兩個認證所揭露的公開訊息是有差異的。
ISCI認證公開資料
本範例是ISA Secure CSA認證。在ISA網站的公開資料中，可以發現本認證符合IEC 62443-4-1, IEC 62443-4-2兩份標準(A)，且本組件是一個嵌入式設備，符合安全等級1(B)， 在2020年12月15日取得(C)。在這份公開資料中，較難看到的部分是，這個組件通過了哪些安全要求？還是，通過的是全部的安全要求？詳細資訊，需要進一步取得報告才能了解。
IECEE認證公開資料
本範例是IECEE產品能力認證(即Part 4-2 Scenario 1)。在IECEE網站的公開資料中，可以發現本認證符合IEC 62443-4-2標準(A)，讀者可從Requirements Assessed這個欄位(A)中發現，並非所有規格要求都有通過，從通過的數量可以推測出該組件為軟體應用程式，且達成的安全等級為Level 1；該認證為產品認證(B)，且於2021年2月5日取得認證(C)。
在這份公開資料中，較難直接確認的是，產品通過的安全等級(需要透過推測才能知道)及產品的分類(需要透過推測才能知道)。另外，針對部分未通過的規格要求，亦沒有更進一步的資料，這些是需要再進一步看測試報告才能得知的訊息。
額外說明-並非所有的規格要求都通過認證 在IECEE認證的公開資訊案例中，讀者應能發現這個組件的「IAC系列要求」僅通過22項要求中的10項(這10項要求為安全等級1定義應通過的10個要求)，而「RDF系列要求」則通過0項。 如果有規格要求，無法被「待驗證組件」實現時，應註記能夠協助實現規格要求的「對應措施」；這些「對應措施」通常存在「待驗證組件」的外部，為了實現安全規格要求，當組件要與其他組件/系統整合時，應有文件能夠詳述說明「對應措施」該如何實行，以利達成其安全等級。
差異四：彈性認證機制
IEC 62443 part 3-3和part 4-2定義了四種安全等級及其相對應的規格要求。如下圖所示為IEC 62443-3-3定義安全等級所對應的規格要求，這四種不同安全等級(SL1, SL2, SL3及SL4) ，在下表中各自有標示「✓」，為其應符合的規格要求。
所謂的「彈性認證」，則是打破這四種固有的安全等級機制，這也是ISCI與IECEE認證之間最大的差異。ISCI基本上是完全遵照IEC 62443的定義，進行系統或組件的認證，亦即如果系統或組件設定其安全等級，則必須通過相對應定義的規格要求。
相對地，IECEE則可以認證標準定義的任何規格要求，舉個例子來說：
案例1: 組件A 實作IEC 62443-4-2的5個「安全等級1」的規格要求。
案例2: 組件B 實作IEC 62443-4-2的10個「安全等級1」的規格要求，及10個「安全等級2」的規格要求。
上述這兩種組件，均可以在IECEE通過認證。但是，明顯的，組件B擁有更優質的產品。當資產擁有者在採購流程時，可以透過檢視產品認證報告來區分不同產品的特性。
差異五：設定檔
在IECEE亦特別加入了設定檔(Profile)的概念。所謂的設定檔(或稱「輪廓」或「特性」)，是由IECEE定義的預設功能列表，舉例來說，現行IEC 62443-3-3 或 -4-2 標準中，四個安全等級都會有相對應的規格要求，這便可被視為四個設定檔，只是這四個設定檔是依循安全等級來定義。
由於不同產業的特性不同，各產業亦能定義其專屬的設定檔，這些設定檔可以是包含所有安全等級1的規格要求，加上10個安全等級2的規格要求，再加上3個安全等級3的規格要求。最終，每個產業都會有其獨特的設定檔，而各產業的系統/組件供應商，則可以根據產業的特性，透過設定檔，進行系統/組件的認證。
額外說明 - 設定檔的說明指引 IEC 62443-1-5 標準已於2023年9月15日，正式發行。 有興趣的讀者，請參考：IEC網站中的IEC 62443-1-5頁面
