Encrypted OCR: In Transit, at Rest, and the Gaps
By Schema LawPublished Updated
Encrypted OCR means your document is scrambled while it travels to the converter and while it sits in storage, so someone who intercepts or steals the data cannot read it. It does not mean the provider cannot read the file. The service has to decrypt a page before it can recognize the text on it.
Encrypted document conversion stops two specific threats. Neither answers the question lawyers usually have in mind, which is who at the other end can open the file.
What does encryption in transit protect?
Encryption in transit protects a document while it moves between your browser and the converter's server. Anyone on the network path, such as a shared office network, hotel Wi-Fi or an internet provider, sees scrambled data. The protection starts when the connection opens and ends when the file arrives.
The protocol that does this on the web is Transport Layer Security, or TLS. It is what the padlock and the https in your address bar refer to. The current version is defined in RFC 8446, the TLS 1.3 specification, which says the protocol lets a client and server communicate "in a way that is designed to prevent eavesdropping, tampering, and message forgery." The same document sets out three properties of the channel: the server is always authenticated, data sent over it "is only visible to the endpoints", and the data cannot be modified by attackers without detection.
The word to notice is endpoints. The converter's server is one of the two endpoints, so the document arrives there readable. TLS says nothing about what the server does next.
Older protocol versions are weaker. NIST Special Publication 800-52 Revision 2, the guideline for TLS on United States government systems, requires TLS 1.2 to be supported, required support for TLS 1.3 by January 1, 2024, and bars servers from using SSL 2.0 and SSL 3.0. A private vendor is not bound by that guideline, but it is a fair benchmark when you read a vendor's answer.
One limit is stated in the specification itself: TLS "does not hide the length of the data it transmits". An observer cannot read your upload but can tell that something of roughly that size went to that site.
What does encryption at rest protect?
Encryption at rest protects a stored copy of a document from someone who gets hold of the storage without the key. Think of a stolen laptop, a drive pulled from a server, or a backup tape that goes missing. The files on it are unreadable without the key that unlocks them.
The algorithm most often named for this job is the Advanced Encryption Standard. FIPS 197, the NIST standard that defines AES, describes it as a symmetric block cipher that uses keys of 128, 192 or 256 bits. "Symmetric" means the same key locks and unlocks the data, so the strength of the arrangement rests on who holds that key and how it is guarded.
For OCR, encryption at rest matters in three places: your uploaded original, the text and tables produced from it, and any backups of either. A vendor's claim should cover all three. Ask, because "at rest" on a marketing page sometimes describes the main storage and leaves backups unmentioned.
It matters on your own side too. An exported Word file in the downloads folder of an unencrypted laptop is a stored copy, and the vendor's encryption does nothing for it.
Information security after the download is the laptop, the downloads folder, and who else can sign in. Encryption at rest on a vendor disk does not cover that local Word file. Client confidentiality follows the export onto the machine you are using. Lock the device, move the file into the matter folder, and clear the downloads folder the same day.
What encryption does not cover
Encryption does not cover the time a document is being read, the people and systems that hold the key, or anything the provider chooses to do with the content. An OCR service must decrypt a page to recognize it. From then on, your protection is the provider's rules and conduct, and the mathematics has done its part.
NIST makes the underlying point about laptops. Its guide to storage encryption for end user devices, Special Publication 800-111, says that when a device with full disk encryption is booted, the encryption "provides no protection" and the operating system becomes responsible for the unencrypted information. The guide is written about end user devices, but the logic carries to any running system: encryption at rest guards storage that is switched off, lost or stolen. A system that is running and authorized to read the file can read it.
| Risk | Encrypted in transit | Encrypted at rest | What does address it |
|---|---|---|---|
| Someone on the network reads the upload | Covered | Not relevant | TLS |
| A disk or backup is stolen | Not relevant | Covered, if the key is kept elsewhere | Storage encryption and key handling |
| The provider's staff open your file | Not covered | Not covered | Access rules, contract terms |
| The provider reuses your file to train a model | Not covered | Not covered | A written no-training commitment |
| The file is kept for years | Not covered | Not covered | Retention and deletion terms |
| An attacker logs in with a stolen password | Not covered | Not covered | Account security |
Two follow-up points come up often.
"End-to-end encrypted" needs a second look. When a conversion site uses the phrase, ask what the two ends are. A hosted converter has to read the page to do its job, so the service is one of the ends, and the phrase tells you nothing about who can open the file there.
Deletion is separate. An encrypted file that is never deleted is still kept. The post on whether OCR software stores your documents deals with retention, and the post on OCR that does not train on your data covers reuse.
How to check a vendor's encryption claim
Check an encryption claim by testing the part you can see and asking written questions about the part you cannot. The connection is visible from your own browser in under a minute. Storage is not, so you depend on the vendor's answers and on how specific they are.
What you can test yourself:
- Open the upload page and confirm the address starts with
https. - Click the padlock or site-information icon and view the certificate. Confirm it was issued to the domain you meant to visit.
- Type the address with
httpin place ofhttps. A properly configured site sends you back to the secure version.
What to ask in writing:
- Which TLS versions do your servers accept?
- Are uploads, outputs and backups all encrypted at rest? With which algorithm and key length?
- Who holds the keys, and are they stored apart from the data?
- Which of your staff or systems can read a customer's decrypted document, and when?
- Is the document sent to any other company for processing? Is that leg encrypted too?
- When I delete a document, how long until it is gone from backups?
A good answer names protocols, algorithms and roles. A weak one repeats "bank-grade" or "military-grade", which are not standards and cannot be checked against anything.
The same questions apply to Schema Law. Every plan lists "Encrypted in transit and at rest", and the security commitments on the homepage put it this way: "Files are encrypted from the moment they leave your computer and stay encrypted while stored." That is the company's own statement, and the site does not give protocol versions or key arrangements, so send the six questions before you rely on it for a sensitive matter.
Encryption is one line in a longer review. The post on what makes OCR private covers the questions about access and control that encryption leaves open. None of this is legal advice, and what counts as reasonable care with client files depends on your jurisdiction's rules.