Cross domain solution (CDS) filtering is the policy and content inspection applied to data moving between networks of different trust levels. It blocks or rewrites unauthorised content, file types, metadata and embedded code. Defenders tune filters to prevent data leakage and malware transfer, and review false positives that disrupt approved sharing.
What CDS filtering does
CDS filtering is the enforcement layer that sits between networks with different trust levels. It examines what is being sent, then allows, blocks, strips, or rewrites content so only approved data crosses the boundary.
The filtering logic matters because CDS is not just a transport control. It can remove risky file types, embedded objects, active content, or metadata that should not move between domains, and it can also reshape approved files so they remain usable without preserving the original threat surface.
Why CDS filtering exists
The core purpose of CDS filtering is to prevent a low-trust source from introducing unwanted content into a higher-trust environment, or to stop sensitive material from flowing out when the destination should not receive it. That makes the control relevant to both data loss prevention and malware containment.
Filtering is often policy-driven rather than purely signature-driven. A file can be blocked because its type is prohibited, because it contains an executable payload, because its metadata leaks origin information, or because embedded code would create an execution path on the receiving side. In practice, organisations usually pair this with NIST Cybersecurity Framework 2.0 style governance so the approved data flows are defined clearly.
How CDS filters inspect and transform content
Effective CDS filtering looks beyond simple extension checks. It may parse file structure, inspect MIME types, examine document objects, detonate or sanitise active content, and validate that the resulting file still matches the expected business purpose.
That inspection can be destructive in a good way: macros, scripts, hidden objects, archive nesting, metadata, or malformed structures may be removed before release. The same logic can also rewrite content into a safer form, for example converting a complex document into a cleaner representation that preserves readability while reducing execution risk. For cloud-hosted boundary controls, the CSA Cloud Controls Matrix is a useful control reference for governance around data handling and boundary protection.
What makes CDS filtering hard in practice
CDS filtering creates a tension between security and usability. If the rules are too strict, approved sharing breaks, business workflows slow down, and users may try to bypass the boundary. If the rules are too loose, malicious content or sensitive information can pass through unchanged.
False positives are especially important here because they can block legitimate files, corrupt formatting, or strip information that downstream users need. Organisations also need to watch for data types that are safe in one context but unsafe in another, such as a document that contains harmless text plus hidden code, or a file that looks benign until it is opened by a vulnerable application.
Risk and Threat Considerations
CDS filtering reduces a high-value attack path: crossing a trust boundary with content that should not be allowed to execute, persist, or disclose information. The main risks are malware transfer, covert data leakage, and operational disruption when legitimate exchange is blocked or altered.
Failure mechanism: If the filter misses embedded code, unsafe file types, or hidden metadata, the receiving side can ingest hostile or sensitive content that the boundary was meant to stop.
Impact: A successful bypass can lead to compromise of the higher-trust network, leakage of protected data, or a loss of confidence in the cross-domain workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | CDS filtering depends on defined trust boundaries and approved information flows. |
| PR.DS-01 — Data-at-rest is protected | CDS filtering protects data from leakage as it moves between domains. | |
| PR.PS-01 — Configuration management | CDS filtering relies on tightly controlled policy and parsing configuration. | |
| Recommendation — Define the cross-domain trust boundary and document which data flows the filter must permit or deny. Apply data handling controls that prevent sensitive content from crossing the boundary unapproved. Harden and review the filtering policy so only intended content transformations are allowed. | ||
| CIS Controls v8 | CIS-3 — Data Protection | CDS filtering is a boundary data-protection control that blocks or rewrites unsafe content. |
| CIS-9 — Email and Web Browser Protections | The control logic mirrors content inspection and sanitisation used to stop hostile file transfer. | |
| Recommendation — Classify and protect data flows so the CDS policy matches the sensitivity and allowed transfer rules. Inspect and sanitise transferred content before it reaches the receiving environment. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | CDS filtering is a boundary enforcement mechanism between networks of different trust levels. |
| SI-3 — Malicious Code Protection | CDS filtering is used to block or transform content that could carry malware. | |
| AU-2 — Audit Events | Cross-domain filtering needs logging to review blocked, rewritten, and allowed transfers. | |
| Recommendation — Enforce boundary controls that filter, mediate, and restrict cross-domain traffic and content. Scan and sanitise transferred files and objects to prevent malicious code from crossing domains. Log CDS decisions so blocked, rewritten, and approved transfers can be reviewed and investigated. | ||
| ISO/IEC 27001:2022 | A.8.12 — Data leakage prevention | CDS filtering directly supports preventing unauthorised disclosure across trust boundaries. |
| A.8.7 — Protection against malware | Content inspection and rewriting help stop malware from crossing domains. | |
| Recommendation — Use transfer controls that prevent sensitive data from leaving approved channels. Inspect transferred content to reduce the chance of malware entering the receiving network. | ||
Practitioner Guidance
Why practitioners should care: CDS filtering only works when policy, content inspection, and business exceptions are aligned. Teams should treat the filter set as a governed control surface, not as a one-time technical configuration.
What to watch for: Review blocked-file patterns, recurring false positives, and any repeated request to exempt a content type. Those signals usually show where the policy is either too blunt for the workflow or too permissive for the threat model.
Practitioner takeaway: Keep the filter rules narrowly tied to the approved data flows, then re-test them whenever the content mix, file formats, or trust boundary changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org