Detection-based file scanning has to recognise a threat to stop it, while content disarm and reconstruction (CDR) assumes every file may be hostile and rebuilds it without the parts that could carry an attack. CDR products parse an incoming document, image or archive, keep the content that conforms to the file format and business need, discard active and malformed elements such as macros, embedded objects and scripts, and produce a new clean file. The approach suits email attachments, web downloads, file uploads into applications and transfers between networks of different trust. This vendor-neutral guide is for email, application and network security teams scoping a CDR purchase. Our Email Security Buyer's Guide mentions CDR only briefly, and application-side controls are covered in the File Upload Security Guide; this page goes deep on the CDR decision itself.
Key takeaways
- File type coverage decides value. A product that rebuilds Office and PDF well but passes archives, images or CAD files untouched leaves the remaining doors open; test your own file mix.
- Fidelity is what users notice. Broken formatting, lost formulas or removed signatures drive users to workarounds, so measure what the rebuilt file still does, not only what was removed.
- Integration point shapes everything. Email gateway, web proxy, file transfer, storage and application API deployments have different latency, scale and failure behaviour.
- Policy for files that cannot be rebuilt is a security decision. Encrypted, password-protected, signed or malformed files need a defined outcome: block, quarantine, release on request or pass with a warning.
- CDR is a layer, not a replacement. The UK NCSC's safe import pattern pairs transformation with strict verification and says the pattern is not a guarantee of safety, so keep scanning, sandboxing and macro controls.
Define requirements
- Entry points: list every way untrusted files arrive: inbound email, web downloads, customer and partner uploads, file transfer services, removable media kiosks and cross-domain transfers. See the Managed File Transfer (MFT) Security Guide.
- File mix: sample a month of real traffic per entry point and count file types, sizes, nesting depth of archives and the share of encrypted files. This is the test set for the proof of concept.
- Threats addressed: malicious attachments (MITRE ATT&CK T1566.001 Spearphishing Attachment), user execution of malicious files (T1204.002 Malicious File), macro-based persistence (T1137 Office Application Startup), and exploits of parsers in viewers and back-end processors.
- Business needs: which features users rely on: macros in finance workbooks, digital signatures on contracts, form fields, tracked changes, hyperlinks, embedded images, metadata for records management.
- Operating constraints: latency budget per channel, peak volume, maximum file size, data residency, whether files may leave your environment for a cloud service, and air-gapped or classified network requirements.
- Original file handling: whether originals are kept for release, for how long, who can release them and how that is logged.
Size changes the answer. A small organisation often gets enough from CDR built into its email security service plus strict macro blocking. See the Office Macro Blocking Guide. Organisations that accept files from the public at scale, regulated sectors and those moving data between networks of different classification usually need a dedicated CDR engine with an API, several deployment points and on-premises options.
Deployment options
| Integration point | Typical use | What to test |
|---|---|---|
| Email gateway or cloud email service | Attachments in inbound mail | Delivery delay; handling of encrypted attachments; how users request originals |
| Web proxy or secure web gateway | Files downloaded by users | Large file handling; browser experience while rebuilding; interaction with isolation |
| File transfer and storage connectors | Partner transfers, shared drives, cloud storage | Throughput at peak; behaviour on rebuild failure; audit trail |
| REST API or SDK | Customer uploads in web and mobile apps, internal pipelines | Synchronous versus asynchronous calls; authentication; error codes; scaling |
| Cross-domain or kiosk | Moving files between networks of different trust, removable media | Fit with the transformation, protocol break, flow control and verification pattern |
Capability areas
- Format parsing and rebuild: parses against the file specification, discards non-conforming structures and rebuilds a new file, rather than only deleting known bad elements from the original.
- Active content policy: granular control over macros, scripts, embedded objects, external links, form actions, attachments inside PDFs and hidden data, set per channel and user group.
- Nested content: recursive handling of archives, embedded documents and images inside documents, with limits on depth and expanded size to resist archive bombs.
- Conversion options: flatten to a simpler format (for example a document to an image-based PDF) where fidelity matters less than safety. The NCSC pattern notes that transforming into a simple format lets the verification step check "just one simple format".
- Verification: checks that the rebuilt file is well formed before release, and alerts when verification fails, since in a working design a failure indicates something wrong.
- Reporting: per-file record of what was removed or changed, so users and analysts can see whether transformation altered the data, a point the NCSC cross domain principles raise.
- Management and security: SSO and MFA on the console, role-based release rights, audit logs exported to the SIEM, and scoped API credentials.
Evaluation criteria
An illustrative weighting: 30% file type coverage and rebuild depth, 25% fidelity, 20% integration and performance, 15% policy and release workflow, 10% management and commercial terms.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| File type coverage | Published list of supported formats and versions matching your file mix, including archives, images and specialist formats you use | "All common formats" with no list; unsupported types passed silently |
| Rebuild depth | Full reconstruction from parsed content; removal of malformed structures, not only known bad features | Strip-only approach that leaves the original structure in place |
| Fidelity | Formatting, formulas, images and hyperlinks preserved per policy; measured on your samples | Rebuilt files that look different or lose function |
| Unsupported and encrypted files | Configurable outcome per channel: block, quarantine, release on approval, or scan and pass with a label | Pass by default with no record |
| Performance | Published latency and throughput at your file sizes; horizontal scaling; defined behaviour under load | Benchmarks only on small files |
| Integration | Connectors for your email, web and storage platforms plus a documented API | Single channel; API as an afterthought |
| Release workflow | Originals stored securely with retention limits; release by role, logged, optionally scanned first | Users can release any original themselves |
| Data handling | On-premises or regional processing options, no retention of content beyond policy, clear processing terms | Files sent to a shared cloud service without residency options |
| Engine security | Parsing isolated and sandboxed, engine patched on a stated cadence, vulnerability disclosure process | No statement on how the parser itself is protected |
The last row matters because the CDR engine parses the most hostile content you receive. The NCSC pattern places transformation on the less trusted side because "it is inherently risky to parse and process untrusted content", and assumes the transformation engine could be compromised.
Where identity fits
API deployments introduce machine credentials: the application that submits uploads and the service that retrieves rebuilt files each hold a key or token. Scope them per application and environment, store them in a secrets manager and rotate them. Release rights for original files are a privileged role; tie them to named users through SSO and review them. See the API Key Management Guide.
Questions to ask vendors
- Provide your supported format list with versions. What happens to a file type you do not support, by default and by policy?
- Do you rebuild a new file from parsed content, or remove elements from the original? Show the difference on a sample.
- How do you handle password-protected and encrypted files, digitally signed documents and files with macros that the business needs?
- How deep do you recurse into archives and embedded objects, and what limits protect against archive bombs?
- What latency should we expect for a 2 MB document and a 50 MB archive, and how does the service behave under peak load or failure?
- What record does a user or analyst see of what was removed from each file?
- How is the parsing engine isolated, how often is it patched, and how do you handle vulnerabilities in it?
- Where are files processed and stored, for how long, and can we run the engine in our own environment?
- How is pricing calculated: per user, per file, per gigabyte or per deployment, and are API calls priced separately?
Red flags
- No published format list, or unsupported types passed through without a log entry.
- Fidelity demonstrated only on the vendor's own sample files.
- Claims that CDR removes the need for scanning, sandboxing or macro controls.
- Users able to release originals with one click and no record.
- No answer on how the engine itself is protected from malicious files.
- Per-file pricing with no allowance for spikes, encouraging teams to bypass CDR on busy channels.
Proof of concept
- Build the test set: collect a representative, sanitised sample of your real files per channel, including large archives, signed documents, macro-enabled workbooks and specialist formats, plus a set of known malicious test files handled in an isolated lab.
- Measure coverage: run the set through each candidate and record files rebuilt, blocked, passed unmodified and failed, by type.
- Measure fidelity: have business users compare rebuilt files with originals for layout, formulas, links and signatures, and score usability.
- Test integration in monitor mode: deploy on one channel, such as inbound email for a pilot group, with originals delivered and rebuilt copies logged, then compare.
- Load test: replay peak volume and the largest expected files and record latency and failure behaviour.
- Enforce and roll back: switch the pilot to deliver rebuilt files, track help desk requests and original release rates, and confirm one setting returns the channel to pass-through.
Track after go-live: share of files rebuilt versus passed or blocked per channel, original release requests per 1,000 users, median added latency, help desk tickets about damaged files, and malicious files caught by later layers that CDR passed.
Standards and references
- NCSC: Pattern for safely importing data
- NCSC: Cross domain solutions principles
- NIST: SP 800-53 Rev. 5 (SI-3 Malicious Code Protection, SI-10 Information Input Validation, SC-44 Detonation Chambers)
- MITRE ATT&CK: T1566.001 Spearphishing Attachment
- MITRE ATT&CK: T1204.002 Malicious File
- MITRE ATT&CK: T1137 Office Application Startup
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: File Upload Security Guide · Email Security Buyer's Guide · Macro Malware Guide · Remote Browser Isolation Guide · Secure File Transfer Buyers Guide