NearSeal

2026-08-06

Should you encrypt documents before emailing them to your lawyer?

A family-law client emails a financial disclosure to their attorney — bank statements, a custody schedule, maybe a forensic accountant's report — through whatever inbox happens to be open. In a lot of households going through a divorce or a contested custody case, that inbox is one a soon-to-be-ex-spouse still knows the password to, or one that syncs to a shared computer someone else in the house can still log into. The document is often the entire case in miniature, and how it gets sent is usually decided by habit, not by the legal-ethics rules that apply directly to exactly this situation. Those rules exist, they're specific, and one of them names this scenario by name.

What the ethics rules actually require

In 2012, the American Bar Association amended Model Rule 1.6 to add a new duty: "A lawyer shall make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client." What counts as "reasonable" isn't a fixed checklist — Comment 18 to that rule lists five nonexclusive factors a lawyer has to weigh for each communication: the sensitivity of the information, the likelihood of disclosure if additional safeguards aren't used, the cost of those safeguards, the difficulty of implementing them, and how much they get in the way of actually representing the client. The ABA's Standing Committee on Ethics and Professional Responsibility applied that framework directly to encryption in Formal Opinion 477 (May 11, 2017): "A fact-based analysis means that particularly strong protective measures, like encryption, are warranted in some circumstances." Its concrete guidance goes further still: "if client information is of sufficient sensitivity, a lawyer should encrypt the transmission and determine how to do so to sufficiently protect it, and consider the use of password protection for any attachments."

The scenario the rules name by name

Formal Opinion 477 doesn't leave "sufficient sensitivity" as an abstraction. In a footnote, it cites a Texas Professional Ethics Committee opinion (Op. 648, 2015) listing specific situations that call for encryption or another security precaution — and the very first one on that list is the family-law scenario above: "sending an email to a client when it is possible that a third person (such as a spouse in a divorce case) knows the password to the email account, or to an individual client at that client's work email account, especially if the email relates to a client's employment dispute with his employer." The same list adds sending from a public or borrowed computer, and sending to an account the client shares with others. None of these are exotic threat models — they're the ordinary, unremarkable way personal accounts actually get shared inside households and workplaces, which is exactly why a state ethics committee felt the need to write them down.

Encrypting the attachment only works if the passphrase takes a different route

An encrypted attachment sitting in the same email thread as its own passphrase protects nothing — anyone who can read the message can read both. That isn't a limitation specific to any one tool; it's true of any passphrase-based encryption, and it's exactly the gap Texas Opinion 648's own scenario describes: a spouse who already has the account password gets the encrypted file, and if the passphrase is typed anywhere into that same account, gets the passphrase too. The practical fix is unglamorous: send the encrypted file one way (email, a shared-drive link, whatever's already routine) and the passphrase a different way — a phone call, a text to a number the other party actually controls, or in person — so that compromising one channel doesn't hand over both halves at once.

Two channels, not one Channel A — email / drive link Encrypted file attachment Unreadable without the passphrase Channel B — call / text / in person The passphrase itself Never typed into the same email thread Only opens with both halves
Encryption only holds up if the file and the passphrase travel through two different channels — someone who reads one shouldn't automatically get the other.

Why "we emailed a password-protected attachment" isn't automatically enough

Encryption is one input into a Comment 18 analysis, not a rule that satisfies it automatically by existing. That distinction shows up in the numbers: an analysis of ABA Cybersecurity TechReport survey data by the cybersecurity firm DeepStrike puts the share of law firms that have experienced a security breach at some point at around 29%, rising to roughly 39% in the past year alone according to a separate Arctic Wolf survey cited in the same analysis, and higher still — about 42% — at firms with 100 or more employees. Those breaches aren't all, or even mostly, a document intercepted mid-email; phishing and account compromise are the more common paths in. But that's exactly the point Comment 18's "likelihood of disclosure" factor is getting at: the account a sensitive attachment travels through is itself a target, encrypted attachment or not — which is why the same Texas opinion also flags sending from a device "potentially accessible to third persons" as its own separate risk, independent of what's inside the message.

Where NearSeal fits, and what it deliberately doesn't do

NearSeal fits the one specific sentence in Formal Opinion 477 about attachments: encrypt the file, then consider password protection for it. Drop a document in and it's encrypted entirely in the browser — nothing is uploaded — with a passphrase-derived key, using AES-256-GCM (PBKDF2-SHA256 at 220 iterations) in NearSeal's own default format, or the opt-in age-encryption.org standard if the file should also open years from now with the official age or rage CLI, not just this site. Either way, opening it back up needs nothing installed and no account — the same free web page that encrypted it decrypts it, which matters for Formal Opinion 477's own point about clients who may lack "technological sophistication" for anything heavier. What NearSeal deliberately does not do is choose, send, or manage the passphrase itself — there's no link-sharing, no notification, no built-in channel for the second half of the secret, because that's a different job with a different threat model, and Comment 18 asks lawyers to weigh how much a safeguard gets in the way of representing a client before adopting it. None of this is legal advice, and it isn't a substitute for a lawyer's own case-by-case Comment 18 judgment — it's the file-encryption half of a two-part practice the ethics opinion already describes, with the passphrase-delivery half left to whichever channel — a call, a text, an in-person handoff — the other party actually controls.

Sponsored
← NearSeal

This page shows ads only if you consent.