Cross-domain solutions for defense: moving data safely between classification levels

A Cross-Domain Solution (CDS) is a hardware and software system that enables controlled transfer of data between networks operating at different security classification levels – for example, from a SECRET operational network to an UNCLASSIFIED coalition portal, or from an UNCLASSIFIED sensor feed to a SECRET command-and-control system. Without a CDS, these two networks must remain completely isolated: no data can flow between them at all. With a CDS, carefully defined transfers can occur under strict policy enforcement, allowing classified intelligence to inform unclassified tactical decisions and unclassified data to feed classified analytics without exposing the higher-classification network to compromise.

CDS technology sits at the intersection of policy, engineering, and national security law. Selecting, deploying, and integrating a CDS correctly is one of the most consequential architectural decisions in a classified defense software program. A poorly specified or improperly integrated CDS is either too restrictive – blocking operationally necessary data flows and degrading mission effectiveness – or too permissive, creating a controlled path through which sensitive information can leak to lower-classification networks. This article covers the architecture, accreditation, and integration patterns that security architects and defense CIOs need to navigate the decision.

Why cross-domain transfers are operationally necessary

The operational imperative for cross-domain data transfer arises from the fundamental tension in defense information management: the most valuable intelligence is often highly classified, but the personnel and systems that must act on it frequently operate at lower classification levels or within coalition environments where data sharing across national classification boundaries is required.

Intelligence-to-operations downgrade is the classic CDS use case. A SECRET intelligence product – a threat assessment, a targeting package, a force disposition report – must be sanitized and released to an UNCLASSIFIED or coalition network so that tactical commanders and partner nation forces can act on it. Without a CDS, this process requires manual human review and manual re-entry of the downgraded information, which is slow, error-prone, and does not scale to the volume of modern information operations.

Sensor data aggregation across classification levels drives the reverse flow. Unclassified open-source intelligence (OSINT), commercially available satellite imagery, and partner nation sensor feeds must be ingested into SECRET or higher classification analytics environments for fusion with classified data. A CDS provides the controlled ingestion path: unclassified data enters the higher-classification environment through the guard, where it can be combined with classified data that never leaves the high-side network.

Coalition operations create cross-domain requirements across national classification boundaries. NATO's REL (Releasable) markings and the Mission Secret classification level define what information can be shared with specific partner nations, but the technical mechanism for enforcing those sharing rules at the network layer requires a CDS that understands and enforces the data-sharing policies of the coalition.

CDS architecture patterns

CDS products implement one of several architectural patterns, each appropriate to different data flow requirements and assurance levels.

Data diodes are the simplest and highest-assurance CDS architecture. A data diode is a hardware device that physically enforces one-way data flow using optical isolation: a transmitter on the high side sends data via a fiber optic link to a receiver on the low side, with no return path physically possible. Because there is no return channel, the high-side network cannot receive any information from the low-side network – not even TCP acknowledgment packets. Data diodes are used where the assurance of absolute one-way flow is more important than protocol efficiency. They require protocol adaptation (typically UDP-based data pumps) to work around the lack of TCP acknowledgment, and they do not perform content inspection – they pass all data in the specified direction. Common use cases include one-way log export from classified systems to SIEM platforms, one-way sensor data feeds into classified networks, and one-way release of pre-approved bulk data.

High-to-low guards are bidirectional devices that enforce content-based security policy for data flowing from a higher-classification network to a lower-classification one. The guard receives a transfer request from the high side, inspects the content against the defined security policy, and – if the content passes all inspection checks – forwards the approved content to the low side. The guard logs both approved transfers and blocked transfers for audit. High-to-low guards are used for controlled declassification: releasing intelligence products, reports, or database records from a classified network to an unclassified or coalition network. The inspection engine examines content for classification markings, sensitive keywords, embedded metadata, and malicious content before approving transfer.

Bilateral guards support controlled data exchange in both directions across a classification boundary. Data flowing high-to-low is inspected for classification policy compliance and malicious content. Data flowing low-to-high is inspected for malware, format compliance, and unauthorized content types. Bilateral guards are used where operational workflows require both directions: command messages flowing from unclassified command-and-control systems into classified sensor or weapon networks, with status reports flowing back. Bilateral guards have a larger attack surface than data diodes and require more rigorous accreditation, but they support the full range of operational workflows.

Filter-based guards with content inspection implement structured analysis of each transfer request against a formal security policy. The content inspection pipeline typically includes: file type validation (whitelisting approved formats), schema validation for structured data (XML, JSON checked against approved schemas), malware scanning (AV and sandboxing for files), metadata stripping (removing file metadata that may contain classification markers or author information), and – for high-assurance high-to-low transfers – semantic content inspection that analyzes text for classification markings and sensitive keywords.

Accreditation frameworks: UCDMO, NSA, and NATO

CDS products used on US national security systems must appear on the Unified Cross Domain Management Office (UCDMO) Baseline – the authoritative list of NSA-evaluated and approved CDS products. The UCDMO Baseline is maintained by the NSA's National Cross Domain Strategy and Management Office (NCDSMO) and is available to cleared program offices through classified channels. A product reaches the baseline through NSA's evaluation process, which assesses the security architecture, the implementation, and the operational procedures against the requirements of the applicable Protection Profile.

The evaluation process for a new CDS product typically takes 18–36 months. For program offices, the practical implication is clear: design your cross-domain architecture around products that are already on the UCDMO Baseline. Attempting to introduce a new, unevaluated product into your program will delay your accreditation timeline by years.

Even when using a baselined product, deploying it in a specific environment requires a site accreditation. The site accreditation package documents the specific configuration of the CDS, the content inspection policy in force for each approved data flow, the integration with the surrounding system, and the operational procedures for managing and monitoring the CDS. The accrediting authority reviews this package and grants an Authority to Operate (ATO) for that specific deployment. Site accreditations typically take 3–9 months depending on the complexity of the integration and the workload of the accrediting authority.

NATO accreditation is managed through the NATO Communications and Information Agency (NCI Agency) and national Communications Security Authorities. NATO CDS products are evaluated against NATO-specific Protection Profiles and listed in NATO's equivalent of the UCDMO Baseline. Products approved for US national security systems are not automatically approved for NATO use – a separate evaluation and listing is required, although vendors typically pursue both in parallel.

EU classified information systems are governed by the EU Classified Information (EUCI) security rules, with accreditation managed by the Council Security Committee and national Security Accreditation Authorities. CDS products used in EU-classified environments must be approved under the EU framework, again through a separate evaluation process.

CDS product categories and vendor landscape

The commercial CDS market is served by a small number of vendors who have invested in the years-long NSA evaluation process. Rather than endorsing specific products, it is more useful for architects to understand the product categories and the capabilities to evaluate.

Network-level guards operate at the IP/TCP layer and are integrated into the network infrastructure between the two classification-level networks. They provide protocol filtering, IP filtering, and basic content inspection. They are appropriate for bulk data transfers where the content inspection requirements are relatively simple (file type and malware scanning) and latency is less critical.

Application-level guards operate at the application protocol layer – email, file transfer, web services – and integrate with specific application protocols. Email guards inspect email messages and attachments according to the security policy; file transfer guards inspect individual files against approved schemas and file type rules; web service guards act as API proxies that inspect request and response payloads. Application-level guards provide richer content inspection capabilities than network-level guards but require integration with the specific applications on each side of the boundary.

Streaming guards handle real-time data streams – video, telemetry, sensor data – and are optimized for low-latency, high-throughput transfer with format validation and content filtering appropriate to the stream type. Video guards, for example, may strip embedded metadata from video streams, enforce codec restrictions, and scan for steganographic content.

Vendors active in the accredited CDS market include companies focused on data diode hardware (typically for the highest-assurance one-way requirements) and companies offering broader guard product families covering email, file transfer, and web services transfers. Any vendor claiming CDS capability for national security system use should be able to point to their UCDMO Baseline listing or active evaluation status – if they cannot, the product is not suitable for classified deployments regardless of its technical capabilities.

Integration patterns for defense software

Defense software architects must design their applications to interoperate with an existing or planned CDS. The CDS is typically procured and managed separately from the application software – your application does not control the CDS; it submits data to it and receives approved data from it. The integration pattern must be chosen to match the CDS product's supported interfaces and the data flow requirements.

API proxy pattern: The high-side application sends data to a CDS-managed API endpoint (typically REST or SOAP). The CDS inspects the payload and, if approved, forwards it to the corresponding low-side endpoint. The application receives a synchronous response indicating approval or rejection. This pattern is appropriate for low-volume, latency-tolerant transfers where the application needs immediate feedback on whether a transfer was approved.

Message queue pattern: The high-side application publishes messages to a message queue (JMS, AMQP, or a proprietary CDS queue). The CDS consumes messages from the queue, inspects each one, and republishes approved messages to a low-side queue where the receiving application consumes them. Rejected messages are logged and an alert is generated. This pattern is appropriate for higher-volume, asynchronous transfers where decoupling the producing and consuming applications is desirable. The application must handle the case where a message is rejected and not delivered to the far side.

Email gateway pattern: The high-side application generates email messages with structured attachments (PDF reports, XML data files) and sends them through the CDS email relay. The CDS acts as an MTA that inspects the message and attachments before forwarding to the low-side mail server. This pattern is the most common for human-initiated data releases – an analyst composes a report, attaches a PDF, and sends it to a distribution list on the low-side network. The CDS strips metadata from the PDF, scans for classification markings, and delivers the sanitized message if it passes inspection.

Regardless of the integration pattern, application code must handle CDS rejection gracefully. Transfers can be rejected for policy reasons (content contains a classification marking that should not be released), technical reasons (malformed XML, unexpected file type), or transient reasons (CDS temporarily unavailable). The application should define explicit behavior for each case: operator notification, quarantine queue, retry logic, and audit logging of every transfer attempt and outcome.

How to scope a CDS requirement for a new defense system

Scoping a CDS requirement early in a program avoids the costly late-stage architectural rework that results from treating cross-domain transfer as an afterthought. The scoping process should produce a formal Cross-Domain Transfer Requirements document that becomes part of the system's security requirements baseline.

Step 1 – Identify all cross-domain data flows. Map every data flow in the system that crosses a classification boundary. For each flow, document: source and destination classification levels, data type and format, transfer direction, volume and latency requirements, and the operational need the flow supports. This inventory is the foundation for all subsequent decisions.

Step 2 – Determine the applicable accreditation framework. Identify whether the program will use US UCDMO, NATO, EU-ACC, or a national framework. This determines which product lists are authoritative and which accrediting authority must approve the site accreditation package. Engage the accrediting authority early – their input on acceptable architectures can save months of rework.

Step 3 – Select the CDS architecture. Match the architecture (data diode, high-to-low guard, bilateral guard) to the data flow characteristics. Prefer simpler architectures where operationally feasible – a data diode that meets the requirement is preferable to a bilateral guard that introduces unnecessary complexity and attack surface.

Step 4 – Define the content inspection policy. For each approved data flow, specify the exact inspection rules: permitted file types, maximum file size, schema definitions for structured data, malware scanning requirements, and handling rules for failed inspection. The policy document is a formal deliverable that must be approved as part of the accreditation package.

Step 5 – Design the integration interface. Choose the integration pattern and design the application interfaces to the CDS. Ensure the application handles rejection gracefully and logs all transfer attempts.

Step 6 – Build and test against a representative CDS instance. Obtain a test unit from the vendor and build automated integration tests covering: approved data passing through, rejected data being blocked, malformed data handling, and CDS failure modes.

Step 7 – Prepare the site accreditation package. Compile the accreditation documentation and submit to the accrediting authority well ahead of the planned operational date. Plan for 3–9 months of review time.

For programs where a CDS requirement is identified late – after the application architecture is already defined – the integration work is more complex but the same principles apply. Engage the CDS vendor's integration team early: they have experience adapting their product to different application architectures and can identify the lowest-friction integration path for your specific situation. For guidance on how CDS integration fits within a broader secure cloud architecture, see our article on zero-trust architecture for military networks and how air-gapped deployment patterns complement CDS-controlled transfer paths. For the secrets and key management that must accompany any CDS deployment, see secrets management in defense CI/CD pipelines.