How to Select the Right Cross Domain Solution

Selecting a cross domain solution is not a product decision. It is a program decision with security, acquisition, operational, and sustainment dimensions that will follow your organization for years. Most programs that stumble during CDS procurement do so not because they chose the wrong technology, but because they never clearly defined what the technology needed to do inside a real operational environment before they started evaluating vendors.

Cross domain solutions sit at one of the most sensitive intersections in federal IT: the boundary between security domains. Whether you are connecting enclaves with different classification levels, bridging operational technology networks to enterprise IT, or enabling controlled data transfer between coalition partners, the stakes around getting this wrong are not abstract. A misconfigured or undersized CDS creates real risk, and replacing one mid-program is expensive, time-consuming, and politically difficult inside most organizations.

The evaluation process matters as much as the solution itself. Programs that invest time upfront in defining use cases, throughput requirements, data type profiles, and operational ownership boundaries almost always have better outcomes than those that treat CDS procurement as a catalog search. This is especially true in environments where the accreditation path is unclear, where legacy infrastructure shapes what integration is even possible, or where the operational tempo leaves little room for extended testing cycles.

This article walks through the core evaluation criteria that federal programs should work through before committing to a CDS platform. The goal is not to point to a winner. The goal is to give practitioners the framework to make a defensible, mission-aligned selection decision that holds up through accreditation, deployment, and the years of sustainment that follow.

These considerations apply across defense, civilian, and intelligence community contexts, though specific requirements around guard solution types, data transfer directions, and approved product list constraints will vary by program and authorizing authority.

Defining Requirements Before You Evaluate Anything

The most common CDS procurement failure mode is beginning the evaluation process with a product list instead of a requirements document. This sounds obvious, but it happens constantly, particularly when a program is under schedule pressure, when leadership has already seen a vendor demo, or when someone has assumed that the solution used on a previous program will carry over. Requirements that were not explicitly stated almost never survive accreditation review intact.

Before touching any evaluation criteria, the program team needs to answer a core set of operational questions. What domains are being connected? What is the direction of data flow — unidirectional, bidirectional, or both? What data types will traverse the solution, and in what formats? What is the expected frequency and volume of transfers? Who initiates transfers, and what approval or validation workflow, if any, is required before data moves? What happens operationally if the CDS is unavailable for two hours? For twelve hours? These questions define the use case envelope, and the use case envelope defines what kind of solution architecture actually fits.

It is also worth distinguishing between what the mission requires today versus what it will require in eighteen to thirty-six months. CDS deployments have long procurement and accreditation cycles. A solution selected for today’s data types may not be able to handle the file formats, protocols, or transfer volumes that will be in use by the time it reaches full operational capability. This does not mean over-engineering the solution, but it does mean building some headroom into the requirements rather than optimizing tightly around current-state operations.

Programs operating in environments where cross domain solutions must support multiple mission threads or multiple user communities simultaneously face additional complexity. A solution that works well for a single, well-defined transfer workflow may not perform well under diverse load from multiple teams with different data types and security requirements. Requirements gathering should involve actual mission users, not just the IT shop, to surface the operational diversity that tends to be invisible in initial scoping conversations.

Documenting Operational Ownership

Ownership definition is a requirements activity, not a post-deployment administrative task. The program needs to establish before selection who owns the CDS from a system authorization perspective, who manages day-to-day operations and configuration, who handles filter rule updates, who responds to alerts, and who has authority to approve changes. In environments with shared service constructs or multiple AOs, this can become genuinely complex and needs to be resolved on paper before the solution is deployed rather than negotiated under operational pressure afterward.

Throughput, Data Profiles, and Transfer Direction

Throughput is one of the most underestimated variables in CDS evaluation, and it is also one of the hardest to characterize accurately at procurement time. Most programs can describe their average transfer load with reasonable confidence. Far fewer can accurately describe their peak load, and peak load is what determines whether a CDS becomes an operational bottleneck. In high-activity environments — particularly those supporting intelligence workflows, sensor data aggregation, or large file transfers between operational and analysis systems — a solution that performs acceptably under normal conditions can become a queue-building constraint during the events that matter most.

When modeling throughput requirements, programs should account for file size distribution, not just aggregate volume. A solution configured to handle frequent small file transfers efficiently may behave very differently when presented with large imagery files, database exports, or video data. The content inspection and filtering processes that provide the security value in a CDS are not compute-free, and those processes scale differently depending on data type, file structure, and inspection depth. Understanding how a candidate solution handles your specific data profile under realistic peak conditions is a testing question, not a datasheet question.

Transfer direction adds another layer of consideration. Unidirectional solutions — data diodes — are appropriate for use cases where the security model genuinely requires one-way data flow and where operational users accept the workflow constraints that come with it. Bidirectional solutions support more complex workflows but carry a different risk surface and typically require more extensive filter rule development and validation. Some programs attempt to use a bidirectional solution for a use case that would be better served by a unidirectional architecture, often because the workflow feels simpler to manage. The security model should drive the architecture, not the other way around.

Data type coverage is a related and frequently overlooked evaluation dimension. Not all CDS solutions support all file formats, protocols, or content inspection types natively. A solution that handles structured data transfers well may require additional filter development or third-party content inspection components to handle email, video, imagery, or structured databases. The cost and timeline for that additional development should be factored into the total evaluation, not treated as a post-selection engineering problem. Filter rule development and validation is a sustained program activity, and the maturity of the tooling a vendor provides to support that work has a direct impact on long-term operational cost.

Latency and User Experience

Latency introduced by CDS content inspection is a user experience issue that becomes a mission issue in time-sensitive workflows. For most file transfer use cases, moderate latency is acceptable. For workflows where analysts, operators, or commanders are waiting for data to cross a domain boundary before taking action, the inspection delay can be operationally significant. This is not an argument for reducing inspection depth — it is an argument for testing latency under realistic operational load before selecting a solution, and for being honest with mission users about what to expect after deployment.

Accreditation Pathway and Authorizing Authority Alignment

CDS solutions do not self-authorize. They enter an accreditation process that varies significantly in complexity, timeline, and specific requirement depending on the authorizing authority, the classification levels involved, and whether the solution appears on an approved products list. Programs that treat the accreditation pathway as a step that comes after selection are setting themselves up for timeline risk that is very difficult to recover from inside a program schedule.

The first question to answer is whether a candidate solution has been through a relevant prior approval process for your domain and use case. Solutions that have existing approvals for similar connection types or that are on an approved configuration list for your organization’s AO can substantially reduce the accreditation timeline. Solutions that are newer, that are being applied to a novel use case, or that require an approval authority with limited bandwidth should be evaluated against a realistic timeline, not an optimistic one. A technically capable solution that cannot be authorized in time to meet program milestones is not the right solution for that program.

The RMF documentation burden for CDS deployments is substantial. Security controls specific to boundary protection, content filtering, audit logging, and configuration management require detailed implementation statements, and the evidence packages required to support authorization can take significant analyst time to produce. Programs that do not account for this labor in their staffing model find that accreditation becomes the long pole in the tent. This is especially common in programs relying on a small ISSO or systems engineering team that is also supporting other authorization activities simultaneously.

Connection approval requirements add another layer on top of system authorization. Even after a CDS platform is authorized, the specific connections it supports may require separate approval. Understanding the connection approval process for your AO, including what documentation is required, what technical review is conducted, and what the expected timeline is, should be part of the evaluation process rather than discovered after selection. Some AOs have well-defined processes with predictable timelines; others are more variable, and that variability is a program risk.

Integration Complexity and Sustainment Burden

The CDS is rarely the only system that needs to change when a cross-domain capability is implemented. Source systems, destination systems, directory services, logging infrastructure, security information and event management platforms, and change management workflows all have integration touchpoints that need to be designed, tested, and sustained. Programs that evaluate the CDS in isolation and treat integration as an implementation detail tend to discover that the integration work dwarfs the CDS configuration work and that sustainment of those integrations drives more operational cost than anything else.

Logging integration is frequently underestimated. CDS solutions generate significant audit log volume, and those logs need to flow into the program’s SIEM or logging infrastructure in a format that supports meaningful analysis and satisfies audit requirements. If the existing logging infrastructure does not natively support the CDS log format, a parsing and normalization layer is required. If the SIEM is shared with other programs, CDS log volume may require capacity adjustments. None of these are insurmountable problems, but each represents labor and timeline that needs to be in the program plan.

Legacy infrastructure creates integration friction that is often invisible during vendor evaluation. CDS solutions evaluated in clean lab environments perform predictably. CDS solutions deployed into environments with aging network equipment, non-standard protocol configurations, or source systems that do not conform to documented interfaces behave differently, and the engineering effort required to bridge those gaps is real. Technical due diligence that includes a realistic inventory of the infrastructure the CDS will touch — not just the interfaces the vendor expects — produces more accurate integration estimates and fewer surprises during deployment.

Sustainment planning should begin at selection, not after deployment. Key questions include: How does the vendor deliver security updates, and how quickly must they be applied to maintain compliance? What is the patch testing and deployment process for a solution sitting at a sensitive network boundary? Who holds the vendor relationship, and what happens to support if the program loses a key team member? What is the upgrade path when a major software version reaches end of life? These questions do not have bad answers, but programs that have not asked them before deployment routinely find themselves in difficult positions when the first significant update cycle arrives.

CDS Evaluation Criteria Comparison

The table below summarizes the primary evaluation dimensions and how they apply across different program contexts. Use this as a starting structure for your own evaluation framework, adjusted to your specific mission, domain, and accreditation context.

Common Mistakes in CDS Selection

The most persistent mistake in CDS procurement is selecting a solution based on a successful demonstration in a clean environment without testing it against the actual data types, volumes, and infrastructure conditions that will exist in production. Demonstrations are designed to show a solution at its best. Evaluation test events should be designed to stress the solution against the conditions that will actually stress it operationally. These are very different activities, and programs that mistake the first for the second tend to encounter performance and compatibility issues late in the deployment cycle when schedule pressure makes course corrections expensive.

A second common mistake is treating throughput requirements as a secondary consideration. Throughput sizing errors are particularly common because peak load is hard to characterize accurately at procurement time and because the consequences are not immediately visible — a CDS that is modestly undersized may appear to function acceptably under normal conditions and only become a visible bottleneck during high-activity periods that correlate with the events where operational performance matters most. Building realistic peak load testing into the evaluation process and sizing with reasonable headroom is standard practice in other infrastructure domains and should be applied here.

Programs also frequently underestimate filter rule development as a sustained program activity. CDS filter rules are not set-once configurations. Data types change, new transfer workflows are added, security policies are updated, and existing rules require periodic review and validation. Programs that do not budget for ongoing filter development and validation labor, or that have not built the expertise to manage that work organically, find themselves dependent on vendor professional services for changes that should be routine operational activities. Building internal filter management capability — or explicitly funding a contractor to provide it — is a sustainment decision that should be made at selection, not discovered as a gap two years into operations.

Finally, programs sometimes select a CDS architecture that is more complex than the use case requires. Bidirectional solutions are not inherently better than unidirectional solutions. High-capacity platforms are not inherently better than right-sized ones. Complexity in a CDS creates more potential failure modes, more extensive filter rule sets, more accreditation documentation, and more sustainment surface. When the use case genuinely supports a simpler architecture, selecting the simpler solution is not a compromise — it is an engineering judgment that reduces program risk.

Recommended Federal Approach

A disciplined CDS selection process runs in four distinct phases: requirements development, market research and AO engagement, technical evaluation, and sustainment planning. None of these phases should be collapsed into the others. Programs that combine requirements and market research tend to let vendor capability shape their requirements rather than the other way around. Programs that skip formal sustainment planning before selection consistently face operational problems that were foreseeable but not planned for.

Requirements development should be driven by mission users and documented with enough specificity to serve as evaluation criteria. It should capture all relevant data types, transfer directions, volume and peak load estimates, latency tolerances, availability requirements, and operational ownership expectations. This document becomes the scorecard against which candidate solutions are evaluated — and it becomes the defensible record of why the program made the selection it did, which matters during accreditation and during program reviews.

AO engagement should happen in parallel with requirements development, not after. Understanding what the authorizing authority will require, what solution types have existing approval history in the environment, and what the realistic accreditation timeline looks like for a new connection type directly shapes which candidate solutions are viable within the program timeline. A solution that requires twelve months of additional accreditation activity may be technically excellent but programmatically inappropriate for a program with a six-month deployment window.

Technical evaluation should include realistic testing against actual data types and representative load profiles, not just functional demonstrations. It should evaluate integration touchpoints against the real infrastructure the CDS will connect to. It should include a filter rule development exercise to assess the maturity of the tooling and the complexity of the development workflow. And it should produce a written assessment that connects technical findings back to mission requirements — not just a feature comparison.

Sustainment planning before final selection means understanding the patch and update cycle, the support model, the filter development process, the staffing required to manage the solution, and the lifecycle horizon. Programs that approach federal technology solutions with a total cost of ownership perspective — accounting for years of operational management, not just initial deployment — make better selection decisions and have more realistic budget expectations. A solution that costs more to acquire but substantially reduces sustainment burden may represent better total program value than a lower-acquisition-cost alternative that creates ongoing operational drag.

CDS programs that execute well share a common characteristic: the selection was treated as a program decision, not a procurement transaction. The technical team, the ISSO, the mission users, the AO, and the program manager were all involved early, their requirements were documented, and the evaluation was structured to answer the questions that matter operationally — not just the questions that are easy to answer from a datasheet. That investment at the front end of the program consistently produces better outcomes at deployment and across the years of sustainment that follow. Organizations looking for structured support through this evaluation process can find additional resources at Anchor Defense.