Encrypted Document Search: Full-Text Indexing Support

WHITE PAPER

Encrypted Document Search

Full-text indexing for encrypted SQL Server FileStream and FileTable documents 

EXECUTIVE SUMMARY

Search your encrypted documents — without a second system.

Encryptionizer closes a persistent security gap at the intersection of three technologies: SQL Server FileTables, Full-Text Indexing, and Transparent File-level Encryption.

Microsoft’s own encryption models leave this security hole in document stores. The Always Encrypted feature disables full-text search by design. Microsoft SQL Transparent Data Encryption (TDE) has historically had gaps around FileStream containers: TDE does not support encryption of FileStream or FileTable stores. Additionally Microsoft TDE requires SQL Server Standard or Enterprise editions, and SQL Express does not support Microsoft TDE at all. Most third-party file encryption tools do not support full-text indexing of FileTable storage.

Encryptionizer sits between the SQL Server engine and the file system layers. Files are stored AES-256 encrypted on disk, and stay encrypted on disk at all times even when accessed or modified. When SQL Server’s full-text indexer runs, iFilters receive the content they need to extract searchable terms transparently. CONTAINS and FREETEXT queries are unchanged and fully supported. With Encryptionizer, no external search services or application modifications are required to support full-text indexing on encrypted FileTable storage.

THE PROBLEM

Encryption and document search can cancel each other out.

SQL Server FileTables, introduced with SQL Server 2012, is a powerful feature that stores files (PDFs, Word documents, images) as part of the SQL Server FileStream structure while exposing them as viewable files and folders in the Windows File system. Combined with full-text indexing, you can run fast semantic queries across thousands of documents using standard SQL statements.

Issues arise when encryption compliance enters the picture:

• Always Encrypted protects columns cryptographically but disables full-text indexing on any column it covers. Encrypt your documents, lose search.
• Native TDE encrypts the database file, but FileStream containers have historically been excluded. Further, SQL Express, which many smaller healthcare and SMB deployments rely on, has no native TDE at all.
• External search services (Azure Cognitive Search, Elasticsearch, Solr) require pushing document content out of SQL Server to a separate index. This introduces a second system to secure, audit, and keep in sync, and often breaking regulated-data residency requirements.
• Most third-party file encryption tools corrupt text extraction when they encrypt FileStream storage: the indexer sees ciphertext, the terms it tries to extract are not found, and the full-text index returns no useful results.

The result: organizations that must both encrypt and search documents are forced into workarounds:  disabling search on sensitive content, standing up parallel search infrastructure, or accepting compliance exposure. None of these are good options.

THE SOLUTION

Encryptionizer keeps files encrypted and keeps search working.

Encryptionizer is a transparent file-level encryption layer that installs between SQL Server and the Windows file system. For FileTable storage, the behavior is straightforward from the outside and deliberate on the inside.

What you see

• Files are AES-256 encrypted on disk. A hex dump of any FileStream container confirms ciphertext.
• Backups of the FileStream directory are encrypted automatically. No operator action required.
• SQL Server’s full-text index populates normally. CONTAINS and FREETEXT queries return correct results.
• Applications see no change: the same queries and actions that ran last week run this week.

What happens under the hood

• Write path: file content is encrypted in memory before data is written to disk. The application sees a normal file write; the disk stores ciphertext.
• Read path (for SQL Server itself): authenticated processes receive access to unencrypted data in-memory transparently,  including the full-text indexer populating the catalog.
• Read path (for unauthorized processes): Ciphertext files are not recognized. Plaintext is never returned. Database-file theft, container copy, or direct disk access yields ciphertext only.
• Key management: AES-256 with FIPS 140-2 validated cryptographic modules. Keys can be stored locally, on removable media, in the Encryptionizer Key Manager, or integrated with Azure Key Vault as an add-on.

HOW IT WORKS

The four-step flow.

01 · Document stored in FileTable folder.

Your secured application inserts a PDF, .docx, or scanned image into a FileTable folder defined as a Windows file share path. SQL uploads and inserts the document as a FileStream file in the database.

02 · Document File is written encrypted.

Encryptionizer intercepts the write of the document file in its entirety. AES-256 ciphertext is written to disk. The FileStream container, any backups of it, and any copies on removable media all inherit encryption.

03 · Indexer reads transparently.

When the SQL Server full-text crawl runs, it calls the appropriate iFilter for each file type (PDF iFilter, Office iFilter, text iFilter, or any third-party iFilter you’ve installed). The iFilter extracts terms; those terms populate the full-text catalog, which is itself stored inside the encrypted database file.

04 · Queries return results.

Your application can run CONTAINS(file_stream, ‘informed consent NEAR rhinoplasty’),  or any T-SQL full-text query, and receive matching rows. No code change. No second index. No external search service.

Example query (runs unchanged against encrypted FileTables)

SELECT name, file_stream.GetFileNamespacePath() AS pathFROM   dbo.PatientDocuments WHERE  CONTAINS(file_stream, ‘”informed consent” NEAR rhinoplasty’)  AND  creation_time > DATEADD(day, -90, GETDATE());

Under the hood: files are AES-256 encrypted on disk. The query returns plaintext hits. No application change. No second search index. No schema rewrite.

USE CASES

Where this matters most.

Legal & e-discovery platforms

Attorneys need to search across thousands of encrypted case documents  contracts, depositions, exhibits, email archives) during active litigation, compliance review, or legal hold. The encrypted-document-search capability lets the document store stay encrypted at rest while supporting phrase and proximity queries across the full corpus.

Healthcare DMS and EHR add-ons

Scanned intake forms, signed consents, imaging reports, and referral letters contain PHI that must be encrypted under HIPAA. Clinicians, billers, and compliance officers need to search those documents. On-prem SQL Server + Encryptionizer is often the only combination that satisfies both requirements without moving PHI to a cloud search service.

Government and regulated contractors

CUI, ITAR, and CMMC-regulated document stores cannot be pushed to commercial cloud search services. Encryptionizer keeps documents in controlled, encrypted, on-prem SQL Server environments while preserving full-text search for the users who need it.

ISVs and OEMs embedding SQL Server

Document-management, claims-processing, and case-management platforms that embed SQL Server and ship to regulated customers can license Encryptionizer on an OEM / distribution-volume basis, making encrypted-document-search a built-in capability rather than a customer-side procurement project.

SIDE BY SIDE

How it compares.

Every alternative approach trades something: encryption, search functionality, simplicity, or data residency. This capability doesn’t ask you to choose.

Comparison reflects publicly documented behavior as of June 2026. Individual deployments vary; actual behavior in your environment can be validated during the free evaluation.

PERFORMANCE

Typical overhead is in the low single-digit percent range.

Encryptionizer’s AES-256 transparent encryption on modern multi-core servers is efficient. During full-text index population, the most read-heavy workload in this scenario, the typical overhead observed is in the low single-digit percent range. Query-time overhead is not impacted because the full-text catalog itself is already populated; queries read from the catalog, not the underlying documents.

• Indexing throughput: dependent on iFilter performance, document size, and disk I/O. Encryption is rarely the bottleneck.
• Query latency: CONTAINS / FREETEXT queries utilize the full-text catalog; file decryption is not in the processing path.
• Storage overhead: AES-256 adds no meaningful size overhead to encrypted files.

You can run your own performance benchmarks with the fully–functional free evaluation.

DEPLOYMENT

What’s required.

• SQL Server version: 2012 or later. Express, Standard, Developer, and Enterprise editions all supported up to SQL 2025.
• Windows Server: 2008 R2 or later (up to Windows Server 2025). Encryptionizer operates at the Windows file-system layer.
• iFilters: These are independent of Encryptionizer. Choose the appropriate iFilters for your documents. e.g., PDF iFilter (Adobe or Foxit), Office iFilters, and any third-party iFilters for domain-specific formats (DICOM, CAD, etc.).

Typical deployment timeline

• Evaluation: same-day download and license key within 2 hours of request.
• Install: 5 minutes on a test instance.
• Configuration/Initial encryption: Dependent on FileStream content size and machine capabilities. (5-15 GB/min).
• Full-text index rebuild (first time): depends on FileStream content size, typically hours for large document stores, minutes for smaller ones.
• Go-live: customers typically move from evaluation to production within 1-4 weeks, gated by their own change-control process.

NEXT STEP

See it work on your documents.

Request a free, fully functional evaluation. With deployment instructions, you’ll see how your documents can be encrypted-at-rest while working with CONTAINS queries, typically within a business day.

Start a free evaluation: https://www.netlibsecurity.com/free-evaluation/
Phone: 1-877-367-1177