If your organization operates Cross Domain Solutions connected to U.S. National Security Systems, Raise the Bar isn't a suggestion. Since the White House issued NSM-8 in January 2022, it's a mandate — and every agency is required to report on its progress toward compliance.
But what does RTB actually require at the technical level? And where does content filtering fit in? Here's a plain-language breakdown — and how GateScanner maps to it.
What NCDSMO and RTB Are
The National Cross Domain Strategy and Management Office (NCDSMO) sits within the NSA and serves as the principal authority over all Cross Domain Solutions used across U.S. government and defense networks. Its mandate is to ensure that every system transferring data between networks of different security classifications does so without introducing risk in either direction.
Raise the Bar, first published in 2018, is NCDSMO's framework for how that's achieved. It goes significantly beyond NIST RMF controls — designed specifically to ensure CDS systems hold up even under persistent, targeted attack. Passing it requires a Lab-Based Security Assessment (LBSA) that scrutinizes every aspect of the solution's architecture, a process that typically runs six to nine months.
Only CDSs that meet NSA and NCDSMO Raise the Bar requirements can be considered for national security use — including by U.S. intelligence agencies and the DoD.
The Four Foundational Principles: RAIN
At the core of RTB are four non-negotiable architectural principles that every compliant CDS must satisfy. Together they form the RAIN framework:
No single point of failure in the security enforcement path. If one filtering component fails, another takes over. Security cannot degrade silently.
Every file, every transfer, every time. No bypass, no exception, no administrative shortcut that allows unfiltered data to cross a domain boundary.
Security functions must be implemented independently. A flaw in one layer cannot cascade and compromise another.
The filtering path must be architecturally enforced — not policy-enforced. Even a privileged user cannot route around it.
RAIN establishes that RTB compliance isn't just about having the right tools. It's about how they're integrated — independently, redundantly, and without exception.
The Content Filtering Requirement
Beyond RAIN, RTB places specific and demanding requirements on content inspection and sanitization. Every file crossing a domain boundary must be filtered — and that filtering must satisfy the "Rule of Three": three independent verification mechanisms applied to every traffic flow carrying file content.
This is where most CDS vendors face their hardest challenge. Detection-based filtering — antivirus, sandboxing, signature matching — struggles here for two structural reasons. First, it depends on recognizing known threats, meaning zero-days and novel variants pass through uninspected. Second, implementing truly independent verification across three separate enforcement layers without creating bottlenecks or architectural compromise is genuinely difficult.
A file rebuilt from scratch contains no unknown content — because the reconstruction process itself eliminates anything the format specification doesn't permit. It doesn't matter what the threat looks like. It can't survive the rebuild.
How GateScanner Maps to RTB
GateScanner is purpose-built for exactly the environment RTB describes — high-security, no-bypass, zero-trust file flows across domain boundaries. Here's how it maps directly to each RAIN requirement:
| RTB Requirement | GateScanner Implementation |
|---|---|
| Redundant | Active-Active CDR grid with multiple simultaneous processing nodes. No single engine failure creates a security gap. Zero-downtime horizontal scaling keeps enforcement live at all times. |
| Always Invoked | Every file is processed without exception. No whitelist path, no format bypass, no administrative override that passes a file through unprocessed. The architecture enforces this — not policy. |
| Independent Implementations | Up to ten independent CDR engines can be chained, each applying its own processing logic. Multi-AV scanning, static code analysis, and CDR transformation operate as separate independent layers — a compromise in one does not affect the others. |
| Non-Bypassable | GateScanner Multi-source coupled with the GateScanner Injector optical data diode enforces physical-layer unidirectionality. There is no software path around it. The hardware makes bypass structurally impossible. |
On the Rule of Three content filtering requirement specifically, GateScanner's CDR engine deconstructs every file to its elemental components, applies independent verification at each layer — format validation, multi-AV, static code analysis, structural reconstruction — and delivers a clean output. This satisfies the independent, redundant verification RTB demands across file-bearing traffic flows.
The LBSA Reality
Any CDS vendor selling into U.S. government networks must pass Lab-Based Security Assessment testing — six to nine months of scrutiny against RTB requirements before a solution can appear on the NCDSMO Baseline list.
Choosing content filtering components that are already proven within RTB-compliant environments reduces that timeline risk significantly. GateScanner's CDR technology has been deployed within high-security government and defense environments operating to these standards — giving CDS integrators a content inspection layer with a demonstrated track record in exactly this assessment context.
For organizations building or upgrading CDS infrastructure, architectural alignment with RTB isn't a differentiator. Under NSM-8, it's the requirement.
Bottom Line
RTB raises the bar precisely because the threat to cross-domain transfers is real, persistent, and specifically targeted. Detection-first approaches struggle structurally with the independence and certainty RTB demands. CDR — and GateScanner's implementation of it — is architecturally aligned with what RTB actually requires: deterministic, format-level enforcement that doesn't depend on knowing what the threat looks like.
The filtering mechanism that makes a file dangerous doesn't survive the rebuild. That's not a detection problem. It's a structural guarantee.
See how GateScanner CDR supports RTB-compliant CDS architecture.
Book a Demo