Cross Domain Solutions vs Air Gaps: What Federal Architects Actually Need to Know

The conversation about separating sensitive networks from less-trusted ones has been happening in federal IT for decades. Early on, the answer was straightforward: disconnect them entirely. If data cannot physically travel between two networks, the risk of unauthorized transfer drops to near zero. That logic still holds in certain environments. But as mission requirements evolved, the calculus changed. Operators needed real-time data feeds across classification boundaries. Analysts needed to move products from high-side systems to releasable environments. Command structures needed connectivity between enclaves that were never designed to talk to each other.

That pressure produced cross domain solutions — purpose-built technologies designed to transfer data between networks of different classification or trust levels in a controlled, auditable, policy-enforced manner. But the rise of CDS technology did not make air gaps obsolete. Both approaches remain active in federal and defense environments, and the decision between them is not always clean. In some cases the right answer is both, layered in ways that reflect the specific mission, risk tolerance, and operational tempo of the organization.

What makes this comparison genuinely difficult is that neither approach is inherently superior. Air gaps offer a level of isolation that no software-defined policy can fully replicate. CDS technology offers operational flexibility that a physical disconnect cannot provide. The real question is not which approach is better in the abstract. The question is which approach — or which combination — fits the threat model, the mission workflow, and the sustainment reality of the organization doing the planning.

Experienced federal architects already know that both options come with compliance overhead, operational constraints, and sustainment costs that tend to grow after initial deployment. The purpose of this article is to examine both approaches honestly — not to sell a preference, but to help practitioners make decisions grounded in operational reality rather than vendor talking points or policy defaults.

Before diving into the architecture details, one framing point matters: this is fundamentally a risk reduction discussion. The question is not how to eliminate risk — that is not achievable — but how to reduce risk to an acceptable level while preserving the operational capability the mission actually requires.

Understanding Air Gap Architecture in Federal Environments

An air gap is exactly what the name implies: a physical separation between two networks with no electronic connection between them. No shared cables. No bridged switches. No software-defined link. Data cannot travel between the networks unless a person physically carries it — via removable media, a print-to-paper workflow, or a manual transfer process with its own chain of custody and audit trail.

In federal environments, air gaps have historically been applied to the most sensitive enclaves: compartmented programs, special access programs, nuclear command and control systems, certain intelligence community platforms, and operational technology networks that control critical infrastructure. The logic is sound. An attacker who cannot reach a network electronically faces a dramatically harder problem. Nation-state adversaries can and do find creative approaches — compromised removable media, supply chain implants, insider threats — but the baseline attack surface is substantially reduced.

The operational cost is significant. Every workflow that requires data to move between an air-gapped network and any other system becomes a manual process. That means personnel time, physical media handling procedures, sanitization workflows, and the kind of meticulous documentation that federal security officers require. In a low-volume environment where data transfer happens occasionally and the sensitivity of the information justifies the overhead, those costs are acceptable. In an environment where analysts need to move data frequently to support time-sensitive decisions, the friction becomes a mission liability.

There is also the matter of what happens over time. Air gaps require disciplined operational security to remain effective. A single misconfigured Bluetooth adapter, an unauthorized device brought into the enclave, or a removable media process that drifts from policy can introduce a pathway that undermines the architectural intent. Air gaps are not self-maintaining. They require consistent enforcement of physical security controls, media handling procedures, and personnel training that must be sustained across the full lifecycle of the environment — not just at initial accreditation.

Where Air Gaps Remain the Right Answer

Air gaps remain the right choice in environments where the sensitivity of the data is high enough that no amount of policy enforcement or technical filtering can adequately substitute for physical disconnection, where data transfer requirements are low enough that manual processes are operationally viable, and where the threat model specifically includes sophisticated adversaries targeting the network electronically. They are also the right answer in environments where accreditation authorities simply will not approve an electronic connection regardless of the technical controls in place — a reality that program managers navigating certain classification authorities understand well.

The decision is rarely purely technical. In many cases, air gaps persist not because they are the optimal operational architecture but because they are the inherited baseline, the accreditation authority’s default position, or the only approach a legacy system was designed to support. Modernization programs frequently encounter air-gapped enclaves that someone eventually needs to connect to a broader enterprise — and that is often where the CDS conversation begins.

How Cross Domain Solutions Actually Work

A cross domain solution is a controlled interface that enforces a security policy governing what data can move between two networks of different classification or trust levels, in which direction, and under what conditions. Unlike a firewall, which primarily manages access control based on network parameters, a CDS operates on the content and structure of the data itself. A well-implemented CDS inspects what is being transferred, validates it against a defined policy, and either passes it, blocks it, or holds it for human review depending on what the policy dictates.

The range of CDS implementations is broad. Some solutions handle file transfer between a high-side and low-side network, scrubbing metadata and enforcing format restrictions. Others support streaming data feeds for sensor fusion or situational awareness applications. Some enable interactive access between enclaves under tightly controlled conditions. The specific capability profile of any CDS implementation is defined by its accreditation, its approved data types, and the security policy loaded on the device — and those boundaries matter enormously when program managers are scoping requirements.

Federal cross domain solutions operate under a structured accreditation process managed by the relevant security authority. For defense and intelligence community environments, that generally means involvement from NSA’s National Cross Domain Strategy and Management Office, which maintains the Raise the Bar initiative and the associated baseline security requirements. Meeting those requirements is not a checkbox activity. It involves formal testing, architectural review, policy validation, and an approval process that can take significantly longer than most program timelines assume.

The Policy Configuration Reality

One of the most underestimated aspects of CDS implementation is the policy configuration burden. A CDS is not a plug-and-play device. The security policy that governs what the device will and will not pass must be carefully written, tested, and approved. That policy is specific to the use case, the data types, the networks involved, and the mission workflow the device is intended to support. When mission requirements change — and they always do — the policy may need to be updated, retested, and reapproved. In practice, this means that CDS policy management becomes an ongoing operational function, not a one-time deployment task.

Staffing this function is a real constraint. The personnel who understand CDS policy architecture well enough to write, validate, and maintain it are not abundant in most federal IT organizations. Programs that deploy CDS technology without planning for the sustained operational management of that technology frequently find themselves in a position where the device is in place but the policy has drifted, the accreditation is lapsing, or the approved use cases no longer match what the mission actually needs. That gap between initial deployment and sustained operations is where risk accumulates quietly.

Side-by-Side Comparison: CDS vs Air Gaps

The table below is not meant to declare a winner. It is meant to surface the real operational dimensions that should inform an architecture decision. Every row in this comparison represents a genuine tradeoff that a federal architect will need to evaluate against the specific requirements of the environment.

Operational Realities After Deployment

The deployment decision is only the beginning. Both air gaps and cross domain solutions have operational tails that extend years or decades beyond initial fielding, and the organizations that fail to plan for that sustainment burden tend to end up in difficult positions during assessments, reaccreditation cycles, and mission-critical operational periods.

For air-gapped environments, the long-term challenge is discipline drift. The physical controls that make an air gap effective — enforced media handling procedures, physical access restrictions, documented transfer workflows, personnel training — are all dependent on human behavior sustained consistently over time. In a mature, well-resourced security organization, that is achievable. In an understaffed program office where the same two people are responsible for operations, security, and sustainment simultaneously, those procedures are the first thing that gets compressed under operational pressure. The gap between what the accreditation package says happens and what actually happens is often wider than anyone will acknowledge during a formal review.

For CDS environments, the long-term challenge is policy currency. The policy loaded on a cross domain solution reflects the mission requirements and data types that were understood at the time of accreditation. Mission requirements evolve. New data types get introduced. Workflows change. When the policy does not keep pace with operations, one of two things typically happens: operators find workarounds that circumvent the CDS entirely, or the CDS becomes a bottleneck that the mission works around rather than through. Neither outcome is acceptable from a security or operational standpoint.

There is also the matter of CDS firmware and software currency. Cross domain solutions are not static appliances. They require patching, firmware updates, and configuration management over their operational lifecycle. Some CDS platforms have long patch cycles driven by the formal testing requirements associated with their accreditation. That means a known vulnerability may exist in a fielded system for longer than a standard enterprise IT organization would tolerate, because the remediation path runs through a formal approval process rather than a standard change control workflow. Program managers need to understand that timeline and account for it in their risk posture.

When Layered Architectures Make Sense

The premise that CDS and air gaps are mutually exclusive is a simplification that rarely holds in complex federal environments. Many mature defense and intelligence community architectures use both in deliberate combination, with the specific placement of each reflecting the sensitivity of the enclave, the operational tempo of the mission, and the risk tolerance of the accreditation authority.

A common pattern involves a tiered architecture where the most sensitive compartmented programs remain fully air-gapped, a CDS handles transfers between a classified enterprise network and a collateral network, and a separate transfer mechanism handles movement to an unclassified or releasable environment. Each boundary has a different control mechanism calibrated to the sensitivity of the data crossing it and the operational frequency of that transfer. This kind of architecture is not elegant in a textbook sense — it is operationally complex, requires multiple accreditation packages, and demands careful documentation of data flows — but it reflects how real-world federal environments actually stratify risk.

Layered architectures also create opportunities to enforce defense in depth in ways that a single-mechanism approach cannot. If a CDS policy is compromised or bypassed, an air-gapped boundary downstream provides a residual control. If a manual media handling procedure fails, automated CDS audit logging may capture the anomaly. The controls complement each other when the architecture is designed thoughtfully.

The risk in layered architectures is complexity itself. More boundaries mean more accreditation packages, more policies to maintain, more stakeholders with equities over how data flows, and more potential for one boundary’s controls to be inconsistent with another’s. Enterprise architects building these environments need to think carefully about who owns each boundary, how changes get coordinated across the full stack, and what the operational impact of a boundary failure looks like at the mission level. Those are not questions that get answered once and filed away — they need to be revisited on a defined cycle tied to the broader RMF continuous monitoring posture.

Common Mistakes

Most of the serious problems that emerge in cross domain and air-gap environments are predictable. They are not the result of exotic attack techniques or unforeseen threat vectors. They are the result of well-understood operational gaps that programs chose not to address early enough — usually because of budget pressure, timeline compression, or an optimistic assumption that the accreditation package reflected operational reality more closely than it actually did.

Treating air gaps as maintenance-free. Physical separation does not mean operational neglect is acceptable. Programs that air-gap a system and then fail to maintain physical security controls, enforce media handling procedures, and conduct periodic assessments of the enclave’s actual operational posture are not running a secure environment. They are running an environment that looked secure at the time of accreditation and has been degrading ever since. Air gaps require ongoing attention — just a different kind than CDS environments.

Underestimating CDS accreditation timelines. Programs consistently discover that the time required to get a cross domain solution through formal approval is longer than the program schedule assumed. When a CDS is on the critical path for a system fielding, and the accreditation timeline slips by six months, that slip cascades across the entire delivery schedule. Requirements for CDS integration need to be identified early, the accreditation process needs to be started early, and the program schedule needs to include realistic buffer for a process that is not under the program’s control.

Failing to plan for policy change management. The mission workflow that justified a CDS deployment will not stay static. New data types, new users, new operational requirements, and new threat intelligence all create pressure to update the CDS policy. Programs that do not establish a formal policy change management process — including who initiates changes, who validates them, and who runs them through the appropriate approval cycle — end up with a growing gap between what the policy allows and what the mission needs.

Ignoring the operator experience. Both air gaps and CDS implementations have real effects on the people who work with them daily. When the friction of a security control is high enough, operators find workarounds. Those workarounds are typically less secure than the original control and often go undocumented. An architecture that operators consistently work around is not providing the protection it was designed to provide. The operational experience of the user community is a legitimate design input, not a secondary concern.

Selecting architecture based on acquisition convenience rather than mission need. This is perhaps the most common and consequential mistake. In practice, the architecture that gets fielded is often the architecture that was easiest to procure, easiest to justify in an existing acquisition vehicle, or most familiar to the team doing the planning. That can produce environments where a CDS was deployed because someone had an existing contract vehicle and a program office needed to move quickly — not because the mission required automated data transfer across a classification boundary. Or conversely, where an air gap persists because nobody has the bandwidth to navigate a CDS accreditation even though the mission would benefit significantly from controlled connectivity. Neither outcome is defensible from a mission architecture standpoint.

Recommended Federal Approach

The recommended approach begins before any technology decision is made. It begins with a rigorous, documented understanding of the mission workflow — specifically, what data needs to move, between which networks, how frequently, at what latency tolerance, and under what audit requirements. That analysis should drive the architecture, not the other way around.

If the workflow analysis shows that data transfer between classification levels is infrequent, low volume, and involves data types where physical transfer is operationally viable, an air gap with formalized media handling procedures may be entirely appropriate. If the workflow analysis shows that analysts need to move products regularly, that situational awareness feeds require near-real-time data sharing across boundaries, or that coalition or joint operations create data sharing requirements with external partners, a properly accredited cross domain solution is the better tool.

Regardless of which approach is selected, the program needs to plan explicitly for sustainment from the outset. That means designating ownership of the security controls, establishing a maintenance and review cycle, staffing the function appropriately, and building the accreditation maintenance schedule into the program’s long-term resource plan. The most well-designed security architecture will degrade over time without the operational foundation to maintain it.

For organizations considering a CDS deployment, early engagement with the relevant approval authority is not optional — it is a program management imperative. The accreditation process involves stakeholders, timelines, and requirements that exist outside the program office’s direct control. Understanding those requirements early, documenting them in the program’s acquisition planning, and engaging subject matter expertise with direct experience navigating the process can substantially reduce the risk of timeline slippage and accreditation surprises later.

Finally, architecture reviews for both air-gap and CDS environments should be conducted on a defined cycle — not just at initial accreditation and not only when an assessment is imminent. Mission requirements change. Threat intelligence evolves. Personnel turn over and institutional knowledge walks out the door with them. A periodic, documented review of whether the current architecture still matches the mission it was designed to support is one of the highest-value activities a federal security team can conduct, and it is one of the most consistently deferred.

For organizations evaluating their options, the solutions available across the federal security landscape vary considerably in their accreditation posture, their approved data types, and their operational burden. Working with experienced practitioners who understand the full lifecycle — from requirements definition through accreditation and into sustained operations — reduces the risk of fielding an architecture that cannot be maintained at the operational tempo the mission demands. Connecting with a team that has navigated these decisions in real federal environments is a reasonable early step, and talking to an expert before requirements are locked is considerably more productive than doing so after the acquisition vehicle has already been selected.