Cross-Domain Solutions: A Practitioner Reference
A cross-domain solution (CDS) is a controlled interface providing the ability to manually or automatically access or transfer information between different security domains. Domains differ by classification level, by releasability, or by trust, and a CDS is the accredited mechanism permitting information to cross that separation without collapsing it. In the Department of Defense, a cross-domain capability requirement must be met by a product on the baseline list managed by the National Cross Domain Strategy and Management Office (NCDSMO). Cross-domain solutions are an exception mechanism, accredited individually, not a general-purpose connection method.
What a cross-domain solution is
A cross-domain solution sits between two security domains and mediates every item that crosses. It terminates the connection on both sides, so there is no direct path between the domains, and it applies inspection and policy to the content itself before permitting it onward.
The United Kingdom's National Cyber Security Centre frames a CDS as "a set of architectural techniques and supporting technologies used to build secure end to end connectivity between IT systems that you trust differently," and stresses that a CDS is a set of discrete components rather than a single device. That framing matters operationally: what gets accredited is an architecture, and swapping one component changes the accreditation.
The NCSC guidance also separates the two directions. Import into a higher-trust domain is about minimizing malicious content; export to a lower-trust domain is about correct release. These are different problems requiring independent components, and conflating them produces a CDS weak in one direction.
The three types of cross-domain solution
Cross-domain solutions fall into three types: access, transfer and multilevel. The type determines what crosses the boundary and therefore what has to be inspected.
| Type | What it does | Typical use | Primary risk it addresses |
|---|---|---|---|
| Access CDS | Presents a user with sessions on platforms at different security levels without transferring data between them; keyboard and mouse in, video out | Analyst workstations reaching multiple classified networks | Data spillage through a shared endpoint |
| Transfer CDS | Moves data one way or bidirectionally between systems at different levels, filtering content | Message, file and imagery flows between domains | Malicious content on import, unauthorized release on export |
| Multilevel CDS | Stores labelled data and provides access at multiple levels, often paired with a transfer function for relabelling | Labelled databases and shared repositories | Incorrect labelling and aggregation |
Access solutions are deployed in the greatest numbers because they solve the desk problem without moving bytes across the separation. Transfer solutions carry the greater residual risk: a wrong transfer decision produces a spill or an import of hostile content.
What a guard appliance does
A guard is the filtering component of a transfer CDS. It receives an item from one domain, breaks the protocol, applies a sequence of inspections, and re-emits the item into the other domain only if every inspection passes.
Guards are good at a specific list of things, and the list is worth stating precisely because guards are frequently dismissed by vendors selling something else:
- Protocol break. The sending and receiving domains never share a session. Exploits targeting the transport do not traverse.
- Schema and format validation. For structured message formats, a guard validates the message against a schema and rejects anything that does not conform. This is a genuinely strong control, because a conforming message has a bounded set of fields.
- Content inspection and sanitization. Dirty word search, metadata stripping, file format normalization, and reconstruction of documents to remove active content and steganographic payloads.
- Label checking. Where items carry security labels, the guard verifies the label against the release policy and rejects mismatches.
- Human review workflows. A guard can hold items for release authority review, which is the correct answer for anything the automated filters cannot decide.
- One-way enforcement. Where the requirement is truly unidirectional, hardware-enforced one-way links remove the return path physically rather than by configuration.
Guards do these things under accreditation, with independent testing, which is why they remain the accepted mechanism for classification-level crossings.
Raise the Bar and the NCDSMO accreditation burden
The NCDSMO was stood up on 15 February 2019 under National Security Agency authority. It advises national security system owners, sets cross-domain security requirements, runs the United States Government CDS security testing programme, and maintains the CDS Baseline of assessed products together with a sunset list of products reaching end of life. The baseline is hosted on Intelink-U and requires credentialed access.
Raise the Bar (RTB) is the NCDSMO requirements framework governing CDS design, development, assessment and deployment. RTB is revised periodically to reflect new threats and technologies; a version 4.1 dated 11 July 2022 is cited in public briefings, and it applies to United States Government operated cross-domain solutions and to Foreign Military Sales activity. Full RTB text is not public.
The design principles most often cited from RTB are summarized as RAIN: filtering must be Redundant, Always invoked, built from Independent implementations, and Non-bypassable. Independent implementations means two filters written differently, so a defect in one is unlikely to exist in the other. Process separation at each supported security label and hardware-enforced separation between the sides follow from those principles.
The accreditation path runs in four phases: Definition, in which mission, architecture and environment are fixed; Verification, documenting implemented security features; Validation, including a Site-Based Security Assessment of the integrated system; and Post-Accreditation compliance monitoring and change management. Laboratory testing comes in full, delta and regression forms. Public briefings put new CDS development at two to five years and costs in the millions of dollars, and note that the fastest route to deployment is buying an already-assessed product.
The burden is not only initial. Public guidance is explicit that a CDS is not a black box: it requires patching, sustainment, specialist personnel, and active defensive cyberspace operations for the life of the host system, and component obsolescence forces periodic re-accreditation.
Where guards reach their limits
A guard makes a release decision about content it inspects at a boundary it controls. Three limits follow.
A guard cannot decide what it cannot parse. Encrypted payloads, proprietary binary formats, and rich media are either rejected, sent to human review, or passed on weaker evidence. Volume drives organizations toward the third option.
A guard's decision does not travel with the item. Once released to the lower domain, the object is governed by whatever controls exist there. A correct release decision at time of transfer does not constrain redistribution afterwards.
A guard's authority is the boundary it sits on. Every additional pairing of domains is another accredited instance, another authorizing official, and another sustainment tail. Coalition environments multiply pairings faster than accreditation capacity grows, which is the constraint described in How Coalition Partners Share Classified Data Without Shared Infrastructure.
Where object-level release changes the calculus
Object-level release does not remove guards. It changes what a guard has to prove and how far a release decision reaches.
A guard inspects content largely because it cannot trust the label attached to it. If the label is bound to the object cryptographically and the binding is verifiable, label verification becomes evidence rather than assertion, and for structured data the guard's work shifts toward verifying binding and policy rather than reconstructing meaning from the payload. This narrows the inspection problem without closing it, because sanitization for malicious content is a separate requirement from release correctness.
Object-level policy also extends the decision past the boundary. A released object that still requires a policy decision to open remains governed after the transfer, so revocation and audit continue to apply in the receiving domain. That is a property a guard cannot supply, because the guard's control ends when the item leaves.
The realistic architecture is both. Guards handle classification-level crossings, sanitization and accredited release. Object-level enforcement handles releasability, redistribution and revocation on both sides of the crossing. Prior treatment of that split is in cross-domain solutions, guard appliances and object-level release, and the labelling prerequisite is covered in data classification as the foundation of zero trust.
How Lattix relates to cross-domain solutions
Lattix does not replace an accredited cross-domain solution and does not carry NCDSMO baseline listing. Lattix enforces policy on the object either side of a crossing. The policy decision point (PDP) evaluates attribute-based access control (ABAC) across subject, device, environment and geography, purpose of use, network posture, risk, and data-object attributes, and returns a signed, short-lived decision naming the policy version hash and object identifier. The policy enforcement point (PEP) enforces at decrypt time, defaults are fail-closed, and revocation propagates to deny. The full architecture is described in Data-Centric Security for Defense: A Reference Architecture.
Frequently asked questions
What is a cross-domain solution?
A cross-domain solution is a controlled interface providing the ability to manually or automatically access or transfer information between different security domains. It terminates connections on both sides so no direct path exists, inspects content against a release policy, and operates under formal accreditation. In the Department of Defense, cross-domain requirements must be met by a product on the NCDSMO-managed CDS baseline list.
What are the types of cross-domain solutions?
Three types. Access solutions give a user sessions on platforms at different security levels without transferring data, using keyboard and mouse input and video output. Transfer solutions move data one way or bidirectionally between levels with content filtering. Multilevel solutions store labelled data and provide access at multiple levels, usually paired with a transfer function for relabelling. Access solutions are deployed in the greatest numbers.
What is Raise the Bar?
Raise the Bar is the National Cross Domain Strategy and Management Office requirements framework governing cross-domain solution design, development, assessment and deployment. It is revised periodically; a version 4.1 dated 11 July 2022 is cited in public briefings, applying to United States Government cross-domain solutions and Foreign Military Sales. Its filtering principles are summarized as redundant, always invoked, independently implemented and non-bypassable.
How is a cross-domain solution accredited?
Accreditation runs in four phases: Definition of mission, architecture and environment; Verification of implemented security features; Validation including a Site-Based Security Assessment of the integrated system; and Post-Accreditation compliance monitoring. Laboratory testing comes in full, delta and regression forms. Public briefings put new development at two to five years with costs in the millions, and sustainment continues for the system's life.
How does sharing across different security domains work?
Sharing across different security domains works through an accredited cross-domain solution that breaks the protocol between domains, validates the item against a schema or format, inspects and sanitizes content, checks any security label against release policy, and either releases the item, rejects it, or holds it for human review. Unidirectional requirements can be enforced by hardware-enforced one-way links.
Does object-level encryption replace a cross-domain solution?
No. Cryptographic enforcement on the object does not carry NCDSMO accreditation and does not perform sanitization of malicious content, which is a separate requirement from release correctness. Object-level enforcement changes what a guard must prove, by making a bound label verifiable rather than asserted, and extends governance past the boundary through revocation and audit. Guards and object-level policy are complementary.