NCDSMO、Raise the Bar（RTB）與 DoD 跨域治理常被放在同一句話裡，但三者不是同義詞。它們分別涉及國家安全系統的治理職責、跨域方案的安全策略與要求，以及 DoD 對特定任務、系統、實作與營運用途所採用的風險決策程序。忽略發行者、版本、日期、系統背景或授權範圍，很容易把「文件提到某項技術」誤寫成「這項技術已取得資格」。
本文以 2026 年 7 月 19 日可公開查核的四份官方一手文件為範圍。2026 年 6 月發布的 NSPM-12 已撤銷 NSD-42 與 NSM-8，並要求 CNSS 與 NSA Director 以 National Manager 身分整合相關政策。較早的 NSA 年度報告、DoDI 8540.01 Change 1 與 DISN Connection Process Guide（DCPG）仍提供可查證的制度與程序紀錄，但在新的官方決定公布前，不能把不同年代的文件合併成一套不變、適用所有環境的資格標籤。
核心結論
第一，NSPM-12 把跨域方案的要求與測試職責交給 National Manager，並透過 CNSS 執行；NSA 2022 年度紀錄則把 NCDSMO 放在跨域能力與任務需求的計畫背景中。Raise the Bar 是跨域方案生命週期中的安全策略與要求；DoDI 8540.01 是 DoD 的跨域政策；DCPG Appendix G 則說明 DISN 環境中的授權程序。它們的發行者、適用對象、決策權限與產出文件都不同。
第二，設計要求、安全評估、基準列名、CDSA、系統 ATO 與 DISN Approval to Connect（ATC）不是同一種狀態。某個元件、架構做法或出版物符合其中一項，不能取代另一層所需的證據、風險決策或正式文件。
第三，2026 年 6 月後正處於政策整合期。NSPM-12 Section 6(b) 要求 CNSS 判斷哪些與 NSM-8 有關的 National Manager 政策應保留並納入 CNSS Directives。在這項工作完成並由正式來源公布前，不能只靠舊網頁或單一計畫文件，就認定某個 RTB 版本對所有 NSS、DoD 系統或部署都以相同方式適用。查閱 NSPM-12 的 transition provisions
文件與制度地圖｜先看發行者、版本與適用範圍
| 出版物或制度紀錄 | 正式發行者、版本與日期 | 目的與適用範圍 | 不能由此推定 |
|---|---|---|---|
| NSPM-12 | White House；2026-06-12 | 建立 NSS cybersecurity governance、CNSS 與 NSA Director 作為 National Manager 的職責；涵蓋擁有或操作 NSS 的政府機關 | 某項 RTB release 已自動成為所有環境的完整 implementation rule，或某一 system 已通過 assessment |
| NSA Cybersecurity 2022 Year in Review | NSA Cybersecurity Directorate；2022-12-15；page 20 | 記錄 2022 年 NCDSMO 與 RTB 的官方 program context，包含 design、development、assessment 與 implementation | RTB baseline 全文、目前 release identifier、測試結果或產品 status |
| DoDI 8540.01 | DoD CIO；2015-05-08，Incorporating Change 1 於 2017-08-28 | 對 DoD Components 與涵蓋 DoD IS 的 CDS 建立 policy、責任與 RMF-aligned process | 其他機關、TS/SCI process 或非 DoD architecture 一律套用相同程序 |
| DISN CPG v6.1 | DISA；Version 6.1，cover dated August 2023；官方 download record 2023-08-11 | 為 DISN／DoD-authorized cloud connection 提供程序；Appendix G 說明 DoD CDS authorization process | DCPG 自己建立 DoD policy，或 ATC、CDSA、ATO 與 ballot 是同一文件 |
這張表只整理各文件自己說明的角色，不是本文另創的跨域要求階層，也沒有把 2017、2022、2023 與 2026 年的文件拼成一份新的綜合標準。
來源事實｜治理、策略、政策與程序各自說了什麼
NSPM-12｜2026 年 NSS 治理與政策過渡
NSPM-12 由 White House 於 2026 年 6 月 12 日發布。Sections 1–3 建立 NSS cybersecurity governance，re-establish CNSS，並指定 NSA Director 為 National Manager for NSS。Section 2(a) 明確撤銷 1990 年 NSD-42 與 2022 年 NSM-8；因此，以 NSD-42 或 NSM-8 為直接現行依據的較早說明，必須接受這個新版本邊界，不能原樣描述為 2026 年 6 月後未變動的 authority chain。查閱 NSPM-12 Sections 1–3
Section 5(d) 要求 National Manager through the CNSS establish requirements for cross-domain solutions and alternative technical solutions for separation of security domains for NSS。相鄰職責包括：擔任 NSS owners／operators 的 principal advisor、維持 cross-domain community outreach、建立改進的 security solutions／standards／technologies，以及以 comprehensive testing 支持 approved cross-domain solution products。這是對 National Manager／CNSS 的職責分配，不是對任何未指名 component 或 deployment 作出的個別結果。
Section 6(b) 另設 transition work：CNSS 要判斷哪些與 NSM-8 有關的 National Manager policies 應維持，適當時納入 CNSS Directives，並 review existing CNSS policies、directives 與 instructions。本文因此把 2026-06-12 視為現行 overarching governance 的版本點，也把後續 harmonization 視為尚需追蹤的正式制度工作，而不自行宣告哪些舊 requirements 已全部延續、修改或撤銷。
NCDSMO 與 Raise the Bar｜官方年度紀錄支持的有限事實
NSA Cybersecurity 2022 Year in Review 的 page 20「Raising the Bar on Cross-Domain Solutions」把 cross-domain solutions 描述為透過 controlled interfaces 跨越 international、government、agency 與 classification boundaries 分享資訊，並記錄 U.S. Government 依賴 NSA 的 NCDSMO 處理 cross-domain solution capabilities 與 mission needs。查閱 NSA 2022 Year in Review page 20
同一頁將 Raise the Bar 稱為 NSA 為保護 classified information 的 cross-domain solutions 所設定的 strategy，焦點是 design、development、assessment 與 implementation stages；頁面也記錄 2022 年 remote management／monitoring work 與 lab-based security assessment 的 program activity。這份年度報告證明的是 2022 年的 program context 與工作方向，不是 RTB design requirements 全文，也沒有提供可拿來判定任意 architecture 的 universal checklist。
RTB 因此不能只被翻成一個 certification label。從公開年度紀錄可查證的是 lifecycle scope 與 security-improvement strategy；具體 requirement release、applicable increment、assessment procedure、system category 與 evidence expectation，仍須回到負責機關在適用環境提供的正式文件。本文不從產品文宣、職缺、program-specific administrative records 或二手文章補造未在 selected authoritative publications 內公開的 requirement detail。
DoDI 8540.01 Change 1｜DoD 政策與授權範圍
DoDI 8540.01 的 original issue date 是 2015-05-08，本文使用 2017-08-28 的 Incorporating Change 1。Section 1 說明其目的：對不同 security domains 的 IS interconnection 建立 policy、責任與 procedures，並把 CDS risk management／authorization 與 DoD RMF 對齊。Section 2 的 scope 是 DoD Components，以及向、從、在 DoD IS 內或 DoD IS 之間提供 cross-domain capability 的 CDS，包含 mission partner IS；TS/SCI 連線仍受 DNI policy 與 guidance 限制。查閱 DoDI 8540.01 Sections 1–2
Section 3 把 mission need、security requirements 與 risk decision 分開。Information flow 要基於 essential mission requirement、security requirement implementation 與 associated risk assessment；每條 flow 的 operational need 要和 affected ISs／DoD risk 平衡。文件偏好在 enterprise service 能滿足 mission requirement 時使用 existing ECDSP service，替代方案則要依其 procedures 分析。
同一節還區分兩種 formal decision。含 CDS 的 DoD IS 或作為 separate IS 的 CDS 要由 AO authorize to operate；跨越 interconnected security domains 使用 CDS 的 DoD-level risk decision，則由 designated DoD risk executive 以 CDS authorization（CDSA）作成。Enclosure 4 進一步把 CDS 放入 IS authorization boundary 或 separate authorization boundary，並依 RMF 展開 categorization、control selection、implementation、assessment、authorization 與 monitoring。文件使用當時的 UCDSMO 名稱；本文保留原文名稱，不把 2017 角色名稱靜默改成 2026 governance。
Enclosure 4 的 RMF Step 4 要對 implemented controls 進行 independent evaluation，判斷 controls 是否 correctly implemented、operating as intended 且 producing the desired outcome。評估對象是實際 CDS、components、security controls 與 operating environment；文件名稱、architecture concept 或 component feature 都不能自己成為這個 assessment result。查閱 DoDI 8540.01 Enclosure 4 的 assessment boundary
DISN CPG v6.1｜Appendix G 的程序與 RTB 引用
DISN CPG v6.1 的 cover dated August 2023，官方 download record dated 2023-08-11。Executive Summary 說明 DCPG 描述取得 DISN services 的 connection process、依 current DoD policies 運作，而且「does not establish DoD policy」。其 general scope 是尋求連線到 DISN 或 DoD-authorized cloud services 的 DoD Component 與 Mission Partner enclave owners；Appendix G 才是 DoD CDS authorization process 的 tailored guidance。查閱 DCPG Executive Summary 與 scope
Appendix G, Section G.1 把公開 process scope 限定在 Top Secret and below 的 CDS connections，包含 standalone、isolated 與 test networks；連到 TS/SCI and above 的 devices 適用 DNI 決定的其他 approval processes。Section G.3 將 DoD CDS authorization process 分成四期：categorization／criticality determination、engineering／control selection／implementation、security control assessment／authorization，以及 operational monitoring；Figures 17–19 顯示 RMF、CDS process 與 P2P exemption 的關係。
Section G.3 要求 organization 先和 CDSE 記錄 information transfer 與 mission requirements，再依 category、enterprise-service availability、risk analysis 與 required artifacts 推進。Phase 3 會使用 SBSA results、actual test results 與 risk rating；Phase 4 則延續 operational monitoring。這些步驟把 requirement review、engineering、assessment、risk decision 與 sustainment 分列為相鄰但不同的工作。
Table 4 將「Cross Domain Solution (CDS) Design and Implementation Requirements: 2018 Raise the Bar (RTB) Baseline Release」列入 P2P supporting documentation，並給出 identifier NCDSMO-R-00008-001_03。DCPG 說明相關 development／deployment timeline guidance 用來套用該 baseline，若 tactical／P2P criteria 或 schedule shortfall 存在，流程可能要求 POA&M。這項 reference 能證明 DCPG v6.1 的程序使用該 2018 baseline record；它不能證明該 identifier 是 2026 年對每一類 NSS、每個 program 或每次 assessment 唯一且完整的 current requirement set。查閱 DCPG Table 4 與 RTB identifier
DCPG Section G.4 與 G.9.4 還保留重要的文件邊界：CDSA 是 authorizing operational use of a CDS 的 official document；ATC 對應 hosting enclave／DISN connection，且 ATC 明示不 authorize cross-domain solutions；DSAWG 或 ISRMC ballot 本身也不是 community authorization to utilize a CDS。這些定義直接反對把「連線已核准」、「board 已投票」與「CDS 已獲 operational authorization」合併成一個狀態。查閱 DCPG Sections G.4 and G.9.4
來源建議｜要求、評估與決策各自需要什麼證據
下表依各來源原本的制度位置，整理評估者應追蹤的證據。它不是本文自行建立的 RTB 檢查表。
| 決策階段 | 來源提出的要求／指引 | 評估證據的範圍 | 不能互相替換的概念 |
|---|---|---|---|
| NSS governance | NSPM-12 Sections 3、5(d)、6(b)：CNSS directives、National Manager cross-domain requirements／testing、policy harmonization | 適用的 CNSS／National Manager issuance、owner／operator scope、effective date、transition decision | 舊 authority citation、program summary、個別 product status |
| Mission requirement | DoDI 8540.01 Section 3；DCPG G.3.1：先記錄 essential mission／information-transfer requirement 並衡量 risk | Domains、information owner、data type、direction、mission consequence、risk owner | Technology selection、baseline listing、CDSA |
| Architecture 與 control selection | DoDI Enclosures 3–4；DCPG Phase 2：依 system category、operating environment 與 security plan 選擇和實作 controls | Authorization boundary、topology、all interfaces、filters／components、configuration、inherited controls | 文件中提到某種 capability、architecture approval |
| RTB requirement context | NSA 2022 YIR page 20；DCPG Table 4：lifecycle strategy 與 named 2018 baseline／timeline reference | 負責機關提供的 applicable release、increment、category、requirement mapping、test plan | 「RTB」三字、vendor claim、通用 certification claim |
| Security assessment | DoDI RMF Step 4；DCPG Phase 3：independent evaluation、SBSA／actual test results、risk rating | Test scope、version、site／lab boundary、methods、findings、POA&M、residual risk | Listing、deployment configuration、AO／risk-executive decision |
| Operational decision | DoDI Section 3；DCPG G.4：system ATO 與 CDSA 各有決策者及 boundary | Signed decision document、ticket／system identity、conditions、expiry、approved configuration | ATC、ballot、assessment completion、另一 deployment 的 authorization |
| Sustainment | DoDI RMF monitoring；DCPG Phase 4：monitoring 與 change governance | Configuration changes、new channels／filters、due diligence、monitoring results、expiry／renewal | 一次 assessment 永久涵蓋 lifecycle |
這些來源共同指出，治理不是選定一個跨域元件就完成，而是一條從任務需求、系統範圍、控制實作、評估證據、風險決策到持續監控的生命週期。每個階段可以引用前一階段的證據，卻不能把前一階段的名稱當成後一階段的結果。
適用條件與限制｜先確認系統、架構與評估範圍
第一個條件是 治理範圍與生效日期。NSPM-12 適用 NSS 治理，並在 2026-06-12 啟動政策整合；DoDI 8540.01 適用 DoD Components 與相關 DoD IS／CDS；DCPG Appendix G 則是針對 DoD／DISN 程序的指引。組織要先確認自己的所有者、營運者、安全域、網路與決策權限，不能把美國政府、DoD、IC、FCEB、任務夥伴與一般非政府環境視為同一範圍。
第二個條件是 CDS type 與 information-flow purpose。DCPG 區分 enterprise、point-to-point、access、transfer、multi-level、tactical 與 minimal-community-impact 等 context；DoDI 也以不同 security domains 的 information access／transfer requirement 為起點。某文件提及 transfer、access、filtering、one-way architecture 或 controlled interface，不等於要求所有環境採用同一 architecture，也不能把某一 type 的 assessment evidence套到另一 type。
第三個條件是 完整 authorization boundary。必須記錄 hosting IS、CDS、components、administrative path、source／destination domains、data classes、所有 ingress／egress、identity、management、monitoring 與 interconnection。只檢查一個 cross-domain component 或單一 boundary，不能代表 hosting system、其他 path、operator procedure 或 connected domains 已納入 assessment。
第四個條件是 version 與 configuration identity。Requirement release、increment、product／component version、filter、policy、deployment topology 與 test procedure 都要可追蹤。先前 lab result、另一 site 的 ticket、baseline entry 或相似 architecture，不能在沒有 reciprocity／reuse decision 與差異分析時，自動涵蓋目前 implementation。
第五個條件是 評估與授權分開。安全評估產生證據與發現；AO 決定資訊系統是否可在其範圍內運作；指定的 DoD 風險主管以 CDSA 作出 DoD 層級的 CDS 使用決策；DISN ATC 則處理連線。即使文件與程序互相引用，評估、列名、核准、授權與連線狀態，仍各有決策者、範圍、條件與期限。
第六個條件是 公開資料限制。本文使用的 NSA 2022 Year in Review 只公開 strategy／program context，DCPG v6.1 則公開引用 2018 RTB baseline identifier；兩者都不是 2026 年完整 RTB requirements library。若實際 program 需要判定 applicable RTB release，必須向負責 CDSE、National Manager／CNSS 或正式 repository 取得 current controlled document 與 transition decision，不能由本文補寫 requirement content。
編輯推論｜治理不能被壓縮成一張資格標籤
四份來源共同支持一項結論：跨域治理要把資訊分享任務與不同安全域之間的風險放在同一條決策鏈上，並讓要求、工程、評估、授權與監控各自保留證據。這需要完整的可追溯性，不能把所有治理步驟壓縮成一張認證標籤。
文件或制度提到某種跨域架構、能力、程序或控制，不表示所有環境都要採用同一架構。NSPM-12 分配治理職責；NSA 年度報告記錄策略背景；DoDI 建立 DoD 政策；DCPG 說明特定連線與授權程序。閱讀時都要保留其發行者、版本、日期、章節、系統背景與適用範圍。
文件討論某項治理或控制，不代表特定產品、現場或部署已正確實作、列名、核准、驗證、授權或通過評估。每一種狀態都需要對應的設定、測試範圍、決策權限、簽署文件、條件與有效期限；不同發行者、計畫、要求、評估、列名、核准與授權不能互換。
單一跨域元件或邊界，不能取代完整的風險評估、資產盤點、身份／存取控制、資料流治理、監控、事件應變、安全、供應鏈與生命週期管理。邊界外的遠端存取、可攜式媒體、維護路徑、內部人員活動、實體存取、其他入口或既有來源端失陷，也不會因此消失。
產品的合規性、驗證或認證狀態、政府背書、軍規資格、架構核准或部署授權，都無法只靠引用 NSA、NCDSMO、Raise the Bar、White House 或 DoD 文件判定。即使某項要求、評估或正式決策確實適用，結論也只落在文件明定的系統、設定、範圍、目的、條件與期限。
這些文件也不能證明任何控制可以防止所有攻擊、發現所有活動、保護整個環境、保證資料完整性、消除其他入口、修復來源端失陷，或保證任何現場的安全結果。跨域控制只處理其政策與評估範圍內的資訊流風險；來源信任、資料正確性、傳輸確認、營運、安全與應變仍需要獨立證據。
評估清單
- 記錄每份使用文件的正式 title、issuer、original issue、current change／version、effective date、section／figure／table、publication identifier 與 accessed date。
- 先確認適用的是 NSPM-12／CNSS／National Manager、DoD、IC、FCEB、mission-partner 或其他 governance scope，並追蹤 2026 harmonization 的正式結果。
- 為每項 cross-domain need 記錄 source／destination security domains、information owner、data class、direction、mission purpose 與 failure consequence。
- 確認 CDS type、enterprise／point-to-point context、hosting IS、authorization boundary、network connection 與所有管理／monitoring paths。
- 取得負責機關指定的 applicable RTB release／increment 與 requirement mapping，不用公開 program summary 或產品文宣代替 controlled requirements。
- 分開保存 architecture／control design、implementation evidence、lab／site assessment、findings、POA&M、baseline／listing record、AO decision、CDSA 與 ATC。
- 比對 test configuration 與 deployed configuration，記錄 components、versions、filters、policies、channels、topology、site differences 與 reuse／reciprocity decision。
- 將 continuous monitoring、configuration change、new data flow、new channel、renewal、expiry 與 incident handling 納入 lifecycle governance。
- 保留 asset inventory、identity／access control、data-flow governance、logging、incident response、safety、supply chain、physical security 與 other-ingress assessment 的獨立責任。
- 對公開結論執行 governance-claim review，刪除未由正式 artifact 支持的 listing、approval、validation、authorization、certification、endorsement、military-grade 與 universal security outcome。
閱讀限制
本文是產品中立的技術與制度研究，用來區分截至 2026-07-19 可公開查核的治理、策略、政策與程序紀錄。它不是法律意見、現行受控要求的替代品、產品評估、實驗室評估、基準列名判定、CDSA、ATO、ATC 或部署決策。實際適用性必須由具權限的組織，依現行 CNSS／National Manager、DoD／IC 政策、任務需求、系統範圍、設定、證據與風險決策判斷，並持續追蹤 NSPM-12 過渡工作的後續正式出版物。