What Is a Cross Domain Solution (CDS)?

Some networks should never touch each other directly. A classified defense network can't share a connection with the public internet. A power station's control network shouldn't accept traffic from the corporate email server. Yet the people who work on those networks still need data to move between them.

A cross domain solution (CDS) is the controlled gateway that makes this possible. It sits between networks that operate at different security levels, blocks everything by default, and only lets through data that passes a strict security policy. The US Committee on National Security Systems (CNSS) describes a CDS as a controlled interface for accessing or transferring information between different security domains. It can be a single device or a chain of hardware and software components.

Put simply, a CDS decides what's allowed to cross a security boundary, checks that it's safe, and stops everything else. Because a CDS is one of the most sensitive points in your architecture, you also need to see what's happening on each side of it. That's where network TAPs and network packet brokers come in, as long as you deploy them in a way that doesn't open a new path across the boundary.

What a Cross Domain Solution Does

A CDS lets specific, approved information move between separate security domains while stopping everything else, including malware, attacks, and data leaks. To understand how, you first need to know what a security domain is.

What counts as a security domain

The Australian Signals Directorate (ASD) defines a security domain as a system, or group of systems, running under one consistent security policy. That policy covers classification, who information can be released to, and any special handling rules.

So an organization's OFFICIAL and SECRET networks are separate domains. So are the SECRET networks of two different agencies. The UK's National Cyber Security Centre (NCSC) now uses the broader term "zones of trust", which can include internal systems, cloud platforms, and the internet.

The high side and the low side

Cross domain engineers describe each boundary in simple terms:

High side: The more sensitive or trusted domain, such as a classified network or an operational technology (OT) control network
Low side: The less trusted domain, such as the internet, a corporate IT network, or a partner's network
The boundary: The point where the CDS sits and enforces your policy on every piece of data that tries to cross

Most designs focus on protecting the high side from the low side. But threats can travel the other way too, for example when an insider tries to export sensitive data.

Deny by default

The defining feature of a CDS is that it blocks all information flow between domains unless the data matches your security policy. ASD also stresses that the security-enforcing parts of a CDS must be impossible to bypass. If an attacker can route around the checks, the checks don't matter.

Why Organizations Need Cross Domain Solutions

The most secure network is completely disconnected, or "air-gapped." But full isolation is rarely practical. Analysts on classified networks need open-source intelligence. Plant engineers need to send production data to the business. Moving that data by hand with USB drives creates its own risks.

Why a firewall isn't enough

Firewalls make most decisions based on addresses, ports, protocols, and session state, and they usually allow two-way conversations once a session is approved. They're also complex, general-purpose devices, which gives attackers more code to target.

A CDS goes further. It breaks network protocols, inspects and rebuilds content, enforces the direction of data flow, and uses independently evaluated components. The NCSC notes that good standard architecture is enough for most commercial networks. A cross domain approach is for systems that may face targeted attacks and hold sensitive or critical data.

The risks a CDS is designed to stop

According to ASD, weak controls between security domains can let attackers:

Steal or tamper with data: Copy, steal, or interfere with sensitive information
Open covert channels: Create hidden paths that smuggle data into or out of a protected system
Undermine trusted records: Compromise the integrity of data such as audit logs
Skip security controls: Bypass the functions that enforce your policy
Move laterally: Pivot from a less-protected network into a more sensitive one

The Three Main Types of Cross Domain Solution

US government definitions, which much of the industry follows, split cross domain solutions into three categories.

Access solutions

An access CDS lets you work with data in different security domains without moving that data between them. A common example is a single workstation that shows several classified networks side by side, while keeping each network's data separate.

Transfer solutions

A transfer CDS moves data from one domain to another. Transfers can be one-way or two-way, with separate checks in each direction. ASD gives the example of bringing public data from an OFFICIAL network into a SECRET analysis system.

Multilevel solutions

A multilevel CDS stores data at different classifications in one system and uses trusted labels to control who sees what, based on each user's domain and credentials.

Which type fits your use case

Access: Your users need to work across several networks from one desk, but the data shouldn't move
Transfer: Files, messages, or data feeds need to cross from one network to another
Multilevel: You want one shared repository that serves users with different clearances

How a Cross Domain Solution Works

It's tempting to picture a CDS as one box on a cable. Modern designs work more like a pipeline. The NCSC's 2026 cross domain guidance describes a series of control points, each adding confidence in the data before it moves on.

A typical import flow, step by step

Every CDS is built for a specific use case, so details vary. A typical low-to-high flow looks like this:

Receive: Data arrives from the low side and is treated as untrusted at every layer
Break the protocol: The CDS ends the incoming session and extracts the data, so attacks on network stacks can't reach the high side
Validate the format: The data is checked against a tightly defined format, such as a specific XML schema
Clean the content: Malware scanning, macro removal, and file rebuilding strip out anything that could carry an attack
Enforce one-way flow: Hardware such as a data diode makes sure nothing travels back
Deliver and log: The data reaches its destination, and the CDS records what crossed and under which rule

How export flows differ

Import flows protect the high side from harmful data. Export flows protect against leaks. The NCSC splits export control into separate jobs:

Release authorization: Deciding whether data can leave, using keyword scanning, data loss prevention (DLP), or a second person's review
Release control: Technically enforcing that only authorized data leaves
Independent checks: Isolating each check so one failed component can't cause an unexpected release

The NCSC is candid that checking freeform text, including AI-generated content, can't be done with absolute certainty. Layered, independent checks help close that gap.

Key Components Inside a Cross Domain Solution

ASD notes that a CDS is more often built from several separate technologies than delivered as one appliance. These are the building blocks you'll see most often.

Data diodes

A data diode is hardware that lets data travel in one direction only. One common design uses a fiber optic link with a transmitter at one end only, so no signal can travel back. Because physics enforces the restriction, a software exploit can't reverse it.

Guards and content filters

A guard is a trusted gateway that mediates transfers between systems with different security policies. Typical guard checks include:

File type validation: Confirming a file really is what it claims to be
Malware scanning: Detecting known threats with one or more engines
Content disarm and reconstruction: Rebuilding files from known-good elements and discarding macros and scripts
Schema validation: Rejecting structured data, such as XML or JSON, that doesn't match the approved format

Protocol breaks and audit logs

A protocol break ends one network connection and starts a new one on the other side, often using a simpler protocol. This stops attackers from exploiting network stack weaknesses or hiding data in protocol fields. Every transfer and rejection should also be logged, and those logs need protecting, since tampering with audit records helps attackers cover their tracks.

Cross Domain Solutions vs Data Diodes vs Firewalls

These three technologies often get mentioned together. Here's how they compare:

Firewall: Controls two-way traffic with rules based on addresses, ports, and protocols. It's right for most internal segmentation, but not for high-assurance separation.
Data diode: Physically enforces one-way flow, but can't tell a clean file from a malicious one.
Cross domain solution: Combines controlled data paths with protocol breaks, content inspection, and policy enforcement, and is independently evaluated.

A data diode is often part of a CDS, but direction control alone isn't enough. If malicious content can flow one way into your most sensitive network, the diode has simply delivered the attack more reliably.

Where Cross Domain Solutions Are Used

Cross domain technology started in defense and intelligence, but the same thinking now applies wherever sensitive systems exchange data with less trusted ones:

Defense and intelligence: Moving data between classified and unclassified networks, and sharing information with allies
Government agencies: Bringing open-source data into classified analysis systems
Critical infrastructure and OT: Sending telemetry from control networks to business systems without allowing inbound connections
Central security monitoring: Aggregating logs from differently classified environments into one audit system
High-threat commercial environments: Organizations facing targeted attacks on critical data, which the NCSC's latest guidance explicitly covers

Standards and Certification for Cross Domain Solutions

National security agencies set the rules for how cross domain solutions are built and assessed. Which framework applies depends on where you operate.

United States: NCDSMO and Raise the Bar

The National Cross Domain Strategy and Management Office (NCDSMO), based within the National Security Agency (NSA), oversees cross domain solutions for US national security systems. Its Raise the Bar (RTB) requirements set the standard for CDS design and implementation. Products that pass NCDSMO's Lab Based Security Assessment (LBSA) join its Baseline List, which government sites use to select approved solutions.

United Kingdom: NCSC cross domain guidance

In April 2026, the NCSC published new guidance called Cross domain approach and architecture. It replaces the NCSC's earlier 13 security principles, although those still underpin its assurance scheme for cross domain products. The new guidance sets out six design principles:

Understand and minimize data transfer: Only move what the business needs, using simple protocols
Gain trust across the entire stack: Treat all data as untrusted at its origin, from the physical layer up
Only export understood and expected data: Tightly control outbound flows to prevent leaks
Limit the impact of compromised components: Design so an attacker gains as little as possible from any one component
Make key security controls simple: Give each critical component a single function
Design for observability and manageability: Build in monitoring so you can trace every data flow end to end

Common Challenges With Cross Domain Solutions

A CDS solves a hard problem, so deployment comes with hurdles. Knowing them early helps you set realistic timelines and budgets.

Technical challenges

Complex data formats: The more complex a format, the harder it is to validate safely
Performance limits: Deep inspection and file rebuilding take time, which can affect high-volume transfers
Use case specificity: ASD warns that a solution approved for one organization will probably need changes before it suits another

Operational challenges

Accreditation time: Formal assessments, such as NCDSMO's lab testing, can take months
User workarounds: If the CDS is too slow or restrictive, people look for unofficial ways to move data
Limited visibility: If you can't observe traffic on each side of the boundary, you can't prove the CDS is working

How to Plan a Cross Domain Solution Deployment

Every CDS project is different, but planning tends to follow the same path:

Define the business need: Write down which data needs to cross, in which direction, how often, and in what format
Map your domains and threats: Identify each domain, its classification, and the threats from each side
Choose the right type: Decide between access, transfer, and multilevel capability
Engage your accreditors early: ASD advises involving security teams and cross domain advisers early and often
Prefer evaluated components: Use products assessed under your national scheme
Plan monitoring from day one: Decide how you'll observe both sides of the boundary without creating a new path across it
Review regularly: Revisit rules and threats after go-live as data types change

How Network Visibility Supports Cross Domain Security

The NCSC's sixth principle calls for observability from the start. You need to see traffic on each side of the boundary to detect attacks and confirm the CDS is doing its job. But your monitoring setup can create risk if you're not careful.

Monitoring without creating a new path

A poorly designed monitoring network can quietly become an unofficial bridge between domains. Watch out for:

Shared tools: One monitoring tool connected to both the low side and the high side
Addressable devices: Monitoring hardware with IP addresses that attackers can discover
Two-way connections: Monitoring links that can send traffic back into the network they watch
Shared management networks: One management network that reaches devices in several domains

Passive, one-way access to traffic

A network test access point (TAP) copies traffic from a link and sends it to your monitoring tools. Our passive fiber TAPs use a one-way design that stops data flowing back from the monitoring network into the production network. They need no power and are invisible on the network. For copper links, our Ethernet TAPs capture full-duplex traffic without adding a point of failure.

A TAP gives you visibility within a domain. It doesn't move data between domains, so it isn't a cross domain solution.

Keep each domain's monitoring separate

The safest approach is a dedicated visibility fabric for each domain. Packet brokers such as the SmartNA-PortPlus aggregate, filter, and load balance traffic from many TAPs, so each domain's tools see exactly what they need. Good practice includes:

One fabric per domain: Keep high-side and low-side monitoring on physically separate hardware
Mask sensitive payloads: Use payload masking and header stripping on the SmartNA-XL to limit what tools can see
Avoid configuration errors: Our Drag-n-Vu interface warns you before you create a filter or path that isn't allowed
Use out-of-band management: Manage visibility hardware on a separate network that never spans domains

Why bypass doesn't belong on a domain boundary

Bypass TAPs keep traffic flowing around an inline security tool if it fails. That's ideal for an intrusion prevention system inside one domain. But a CDS must fail closed. Never place a bypass mechanism around a cross domain solution, because a failure would let unchecked traffic straight across the boundary.

Frequently Asked Questions

Is a data diode a cross domain solution?

A data diode is usually one component of a CDS. It enforces one-way flow but doesn't inspect content, so most designs pair it with protocol breaks, guards, and content filtering.

Is a network TAP a cross domain solution?

No. A TAP copies traffic within one network so you can monitor it. A passive TAP's one-way design makes it a safe way to monitor sensitive domains, but it doesn't transfer or filter data between them.

Do commercial organizations need a cross domain solution?

Most don't. The NCSC says standard good practice is usually enough for commercial networks. Consider a cross domain approach if your systems face targeted attacks and handle sensitive or critical data, as in critical infrastructure and defense supply chains.

How Network Critical Can Help

Cross domain solutions protect the boundaries between your most sensitive networks and everything else. To work well, they need clear policies, evaluated components, and safe visibility on both sides of the boundary.

We don't build cross domain solutions. We build the visibility hardware that helps you monitor each domain without weakening it. Our hybrid TAP and packet broker solutions deliver full traffic visibility with zero packet loss in compact 1–2RU hardware. For high-speed core networks, the SmartNA-PortPlus HyperCore scales up to 400Gbps.

For an extra layer of low-level protection, INVIKTUS applies zero-trust, policy-based controls at full line rate, with no IP or MAC address for attackers to find. Whether you're planning monitoring for a new cross domain architecture or closing blind spots in an existing one, our team can help you get it right.