Cross-Domain Solution Requirements for NSS

Cross-domain solutions (CDS) represent one of the most tightly regulated technical controls within the National Security Systems (NSS) ecosystem, governing how data moves between classification domains of differing sensitivity. The requirements governing CDS deployment, approval, and operation are distributed across multiple federal bodies — principally the Committee on National Security Systems (CNSS), the National Security Agency (NSA), and the Defense Information Systems Agency (DISA) — and carry significant implications for system integrators, program managers, and accreditation personnel working in classified environments. This page describes the regulatory structure, technical mechanics, approval pathways, and classification boundaries that define CDS compliance for NSS. Professionals navigating security systems listings will find this reference useful for scoping procurement and accreditation requirements.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

Definition and scope

A cross-domain solution is a form of controlled interface — hardware, software, or a combination — that provides the ability to access or transfer information between two or more differing security domains. Within the NSS context, "security domain" typically corresponds to a classification level (e.g., Unclassified, Secret, Top Secret) or a compartment defined by intelligence community access controls.

The authoritative federal definition is maintained by the CNSS Glossary (CNSSI 4009), which defines a cross-domain solution as "a form of controlled interface that provides the ability to manually and/or automatically access and/or transfer information between different security domains." This definition establishes the outer boundary of the regulatory scope: any interface permitting data flow across a domain boundary in an NSS environment falls under CDS requirements regardless of the underlying technology stack.

The scope of CDS requirements extends to all National Security Systems as defined under 44 U.S.C. § 3552(b)(6), which covers systems that process classified national security information, involve intelligence activities, involve cryptologic activities related to national security, involve command and control of military forces, or are critical to the direct fulfillment of military or intelligence missions.

The NSA's Cross Domain Enterprise Service (CDES) program manages the evaluated and approved products list, known formally as the NSA/CSS Evaluated Products List (EPL) for CDS. Only solutions appearing on that list — or those granted a specific authorization through the NSA CDS approval process — are permitted within NSS environments.

Core mechanics or structure

A CDS operates by enforcing a security policy at the interface boundary between two domains. The core functional layers common to approved solutions include:

Data Guard Layer: Inspects content crossing the boundary against a defined security policy. Guards can operate on file content, metadata, network protocols, or structured data formats. The guard examines each transfer request, applies rules, and either permits, blocks, or quarantines the transfer.

Audit and Logging Subsystem: All transfer attempts — permitted and denied — must be logged with sufficient detail to support forensic reconstruction. NIST SP 800-53 Rev. 5, Control AU-2 establishes the baseline audit event requirements that CDS logging must satisfy within federal systems.

Unidirectional vs. Bidirectional Flow Control: Certain CDS architectures enforce unidirectional data flow (data diodes), allowing information to pass in only one direction — typically from a lower-classification to a higher-classification domain, or the reverse for approved releases. Bidirectional solutions require additional policy enforcement modules and generally require more extensive evaluation.

Human Review Nodes: High-risk transfer categories — particularly those involving intelligence compartments or special access programs — may require a human review step before release is permitted. This is codified in the CNSS Policy 11 framework and reinforced by NSA's CDS approval conditions.

The physical and logical separation requirements derive from the CNSS Instruction No. 1253, which provides security categorization and control selection for NSS, mapping directly to the control families in NIST SP 800-53.

Causal relationships or drivers

The requirement for CDS in NSS environments stems from 3 converging operational pressures:

Mission interoperability demand: Intelligence sharing across classification levels — between federal agencies, coalition partners, and tactical military units — creates unavoidable requirements to move data across domain boundaries. The post-9/11 information-sharing mandates codified in the Intelligence Reform and Terrorism Prevention Act of 2004 (Public Law 108-458) directly increased the operational demand for CDS deployments.

Threat surface expansion: As adversary capabilities for cross-domain exfiltration have grown — particularly through covert channel exploitation and advanced persistent threat techniques — the requirement for rigorously evaluated CDS products has intensified. NSA's formal evaluation process exists specifically because commercial-grade firewalls and routers cannot provide assurance sufficient for NSS environments.

Regulatory consolidation: The Committee on National Security Systems issued CNSS Policy No. 12 to establish governance over CDS across the NSS community, mandating that organizations seek formal NSA CDS approval prior to deployment and prohibiting the use of unevaluated solutions regardless of agency-level risk acceptance authority.

These drivers interact: increasing interoperability requirements push organizations toward deploying CDS faster, while the evaluation timeline — which can extend to 18 months or longer for complex bidirectional solutions — creates acquisition pressure that regulators must manage through interim authorization mechanisms.

Classification boundaries

CDS requirements apply differently depending on the specific domain pairing involved:

Unclassified to Classified (Up-transfer): The most common scenario in tactical and intelligence environments. Requires full CDS approval; data diode architectures are frequently used to enforce one-way flow toward the classified domain.

Classified to Unclassified (Down-transfer / Release): The highest-risk scenario. Requires robust content inspection, human review in most cases, and specific NSA approval conditions. The risk of inadvertent classified data release drives the most stringent requirements in this category.

Cross-Compartment (Same classification level, different compartments): Often overlooked as a CDS trigger. Movement between, for example, two TS/SCI compartments with non-overlapping access lists requires domain separation controls equivalent to cross-classification transfers. CNSS Policy No. 12 explicitly covers cross-compartment scenarios.

Coalition / Multi-National: Data exchanges between US NSS environments and allied nation systems introduce foreign disclosure requirements under DoD Directive 5230.11 in addition to CDS technical requirements, creating a dual regulatory overlay.

Professionals consulting the security systems directory purpose and scope will find additional context on how these boundary categories map to vendor qualification requirements.

Tradeoffs and tensions

Evaluation rigor vs. acquisition speed: NSA's formal CDS evaluation process provides high assurance but imposes timelines incompatible with rapid capability deployment. Program offices frequently request Interim Authorizations to Operate (IATO) that permit use of unevaluated or partially evaluated solutions — a practice that regulators have progressively tightened.

Functionality vs. security policy enforcement: Operational users frequently require richer data types — video, structured databases, complex file formats — to cross domain boundaries. Each additional supported data type expands the attack surface of the guard and requires incremental evaluation. The pressure to support operational formats competes directly with the security objective of minimizing the guard's complexity.

Centralized CDS services vs. program-owned solutions: DISA offers enterprise CDS services under its Defense Information Systems Network (DISN) portfolio, which can reduce per-program evaluation burden. However, centralized services introduce latency, throughput constraints, and dependency on DISA availability that some mission-critical programs cannot accept.

Cost burden: The total cost of acquiring, evaluating, fielding, and maintaining an NSA-approved CDS can exceed $1 million for complex bidirectional solutions (Defense Acquisition University program cost analyses, publicly available), presenting a disproportionate burden on smaller programs that nonetheless must meet the same regulatory floor.

Common misconceptions

Misconception: A FedRAMP-authorized cloud product can serve as a CDS for NSS.
Correction: FedRAMP authorization applies to federal civilian systems under FISMA. NSS operate under a separate statutory and regulatory framework. No FedRAMP authorization substitutes for NSA CDS approval in NSS environments. This is explicit in CNSSI 1253.

Misconception: A firewall or VLAN separation satisfies domain separation requirements.
Correction: Network segmentation controls — including next-generation firewalls — do not provide the content inspection, policy enforcement, and audit assurance required by CNSS Policy No. 12. CDS is a distinct technical category with distinct evaluation requirements.

Misconception: CDS requirements only apply to Top Secret systems.
Correction: CDS requirements apply wherever data moves between security domains of differing classification or compartmentation, including Unclassified to Secret transfers and cross-compartment transfers at the same classification level.

Misconception: Once NSA approves a CDS product, it can be deployed without further authorization.
Correction: NSA approval (appearance on the EPL) is a necessary but not sufficient condition. Individual deployments require a formal Authorization to Operate (ATO) from the responsible Authorizing Official under the Risk Management Framework (RMF) process defined in NIST SP 800-37 Rev. 2.

Checklist or steps (non-advisory)

The following sequence reflects the standard CDS procurement and authorization pathway for NSS programs, as structured by CNSS and NSA guidance:

1. Domain boundary identification — Document all points where data will traverse between security domains, including classification level pairings and data type categories.
2. NSA EPL review — Consult the current NSA/CSS Evaluated Products List to identify approved CDS solutions covering the required domain pairings and data types.
3. Operational requirements documentation — Produce a formal CDS Operational Requirements Document (ORD) specifying throughput, latency, data format support, and human review workflow requirements.
4. NSA CDS approval request — If no EPL-listed product meets requirements, submit a formal CDS approval request to NSA's CDS Program Office with technical specifications.
5. Security control selection — Map CDS deployment to applicable controls in CNSSI 1253 / NIST SP 800-53, identifying CDS-specific overlays.
6. Integration and configuration review — Conduct configuration review against NSA-issued Security Technical Implementation Guides (STIGs) maintained by DISA.
7. Security Assessment — Complete a formal Security Assessment per RMF Step 4 (NIST SP 800-37), including penetration testing for high-risk domain pairings.
8. Authorization to Operate (ATO) submission — Submit the Security Authorization Package to the Authorizing Official for ATO decision.
9. Continuous monitoring enrollment — Enroll the deployed CDS in the program's continuous monitoring plan per NIST SP 800-137 requirements.

Additional guidance on navigating the service landscape for CDS-qualified vendors is accessible through the how to use this security systems resource section.

Reference table or matrix

References

• Committee on National Security Systems (CNSS) — Issuances and Instructions
• CNSS Policy No. 12 — National Information Assurance Policy on CDS
• CNSSI 4009 — National Information Assurance Glossary
• CNSSI 1253 — Security Categorization and Control Selection for NSS
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems
• NIST SP 800-37 Rev. 2 — Risk Management Framework
• NIST SP 800-137 — Information Security Continuous Monitoring
• NSA/CSS Cybersecurity — Resources and Publications
• Defense Information Systems Agency (DISA) — Network Services
• Intelligence Reform and Terrorism Prevention Act of 2004 — Public Law 108-458
• 44 U.S.C. § 3552 — Definitions (NSS statutory scope)
• Intelligence Community Directive 503 (ICD 503) — IC IS Security Risk Management