ENISA調查顯示，約28%企業的SBOM未採用主流標準格式，雖已「做了」SBOM，仍可能因格式不符而面臨CRA合規風險。重點不只是有沒有SBOM，而是是否可被機器讀取、轉換與驗證。
ENISA 於 2026 年發布的《SBOM Adoption State of Play - 2026》指出，CRA 推動了歐洲組織對 SBOM 的採用，而 SBOM 需使用常見且機器可讀的格式。[1][2]
相關報導也強調，企業若只宣稱「有做 SBOM」，不代表一定符合 CRA；關鍵在於 SBOM 是否為常見、機器可讀的格式，以及是否能納入技術文件與漏洞處理流程。[2][4]
SBOM 的本質是軟體元件清單，但其價值在於可被自動化處理。ENISA 的資料指出，CRA 下的 SBOM 必須是常見且機器可讀的格式，並至少涵蓋產品的 top-level dependencies。[2][5][7]
這也解釋了為何「有 SBOM」仍可能不合規。若 SBOM 不是機器可讀格式，或無法納入技術文件與漏洞處理流程，就難以支援 CRA 所要求的管理與稽核用途。[2][13]
從內容角度看，CRA 明確要求 SBOM 至少涵蓋產品的 top-level dependencies，並在產品生命週期內保持更新；同時，SBOM 必須包含在技術文件中，並可在主管機關要求時提供。[2][5][13]
ENISA 的研究也指出，SBOM 需要納入製造商建立的漏洞處理流程，以支援漏洞識別與記錄。[2]
這項要求影響的是整個供應鏈，而不只是單一產品團隊。ENISA 的調查說明，該研究聚焦於各產業、不同規模的組織如何因應 CRA 而採用 SBOM。[3][4]
對製造商而言，若 SBOM 不符合 CRA 的常見機器可讀格式要求，或未能納入技術文件，將增加法規符合與稽核上的負擔。[2][13]
從產業面觀察，SBOM adoption 正在提升，但 CRA 已使「格式標準化」與「可機器處理」成為關鍵門檻。[1][2]
第一，優先將 SBOM 產出為常見且機器可讀的格式，並避免使用僅供人閱讀的文件形式。[2][13]
第二，將 SBOM 納入 CI/CD 與版本控管流程，讓每次 build 都能自動產生、比對與保存，並與產品技術文件同步維護。[2][5]
第三，確保 SBOM 至少涵蓋 top-level dependencies，並在產品生命週期內持續更新。[2][5][10]
第四，將 SBOM 納入漏洞處理流程，讓其可用於識別與記錄產品中的漏洞與元件。[2]
第五，針對供應商與內部團隊同步制定格式要求，明確寫入採購條款與交付規格，避免「有交付 SBOM」但格式不符合 CRA 要求的情況再次發生。[2][13]