Security

Where your files are stored

Case files are stored exclusively in the United States, in SOC 2 Type II–attested data centers — on every plan, not as a paid upgrade.

They do not sit in one provider's vault. Each file is encrypted, then erasure-coded into many fragments distributed across nodes in that vetted pool; each file rebuilds from a subset of them. Every fragment is ciphertext, and the decryption keys are never present on a storage node — so a breached node yields encrypted bytes of one segment, and even an operator holding every fragment of a file would hold encrypted bytes, not a viewable file. There is no single conventional vault holding every customer's evidence behind one lock.

Our application and database infrastructure runs on SOC 2 Type II–attested providers as well.

What we claim, and what we do not

MyCaseViewer does not hold a SOC 2 attestation of its own, and you should be wary of any small vendor that claims one loosely.

What we can tell you is precisely where your files sit and what protects them. The controls a vendor review actually asks about — encryption in transit and at rest, no publicly readable storage, expiring signed links, enforced retention, and a complete access audit trail — are built in rather than optional. The section near the end of this page lists, in plain terms, the things we have not built. We would rather you learn them here than discover them later.

Encryption

In transit. Every connection is HTTPS, over TLS 1.2 or better — TLS 1.0 and 1.1 are refused outright. We send a two-year HSTS policy covering all subdomains, with preload, so a browser that has seen the site once will refuse to connect over plain HTTP.

At rest. Case files are encrypted with AES-256-GCM before they are distributed to storage, and the fragments are meaningless individually. Database and application storage are encrypted at rest by their providers.

Files are temporary, and deletion is enforced

Every case has a retention period, set by your plan and by any per-case timer you choose. When it ends the case is deleted — the files, and any converted display copies, are permanently removed from storage and your quota is released, after a 24-hour grace period. A case you delete yourself is purged after seven days.

This is enforced by a scheduled job, not by a policy someone remembers to follow. It is also the single most effective security control on this page: material that no longer exists cannot be exposed by any future breach, subpoena, or mistake.

The one exception is a case under legal hold, which stops expiring on purpose, and only when you place the hold.

Your client views without downloading

Regulated organizations — banks, insurers, corporate legal departments — routinely forbid staff from downloading attachments, because downloads are how ransomware and malware arrive. MyCaseViewer shows the material instead.

Video, audio, images, and documents play and render inside the viewer. You decide per case, and per file, whether downloading is permitted at all. A recipient who is only meant to look at something never receives a copy of it.

Office documents never leave the recipient's browser

Modern Word and Excel files are parsed and rendered entirely on the recipient's own device. They are fetched through the same metered access route as any other file and displayed locally. They are never handed to a conversion service, ours or anyone else's.

Only legacy formats a browser genuinely cannot display — older .doc and .ppt files, HEIC photos, unusual video containers — pass through a conversion service, pinned to its US East region so processing stays on US soil, and only for as long as the conversion takes.

Getting into a case

The link. Each case link carries a 24-character random identifier drawn from a 64-symbol alphabet — about 144 bits of entropy. Guessing one is not a practical attack. Viewer pages are served with no-index directives and are not reachable from any listing.

Passwords. Every case has one. We generate a strong password when the case is created — four groups of letters and digits, about 79 bits — and you can replace it at any time. When a viewer enters it correctly, the proof they hold is a signed token in a cookie scoped to that one case — not the password, and not usable anywhere else.

Changing the password is how you cut someone off. The token is signed together with the password it was issued for, so the moment you change it every open session stops working: the next page or file they request asks for the new password. The one thing already in their hands is a video or audio stream that has started, which can keep playing until its own signed URL expires (see below). Anyone you still want reading gets the new password from you.

That proof is deliberately short-lived, in two ways at once. It is a session cookie, so closing the browser re-locks the case: the next person at a shared or borrowed machine has to enter the password again. And the token carries a signed four-hour expiry that is absolute, not sliding — four hours from the moment the password was typed, however much the reader is doing in between. Staying active does not extend it, and neither the browser nor the reader can move it.

Per-recipient links. Instead of one shared link you can send each recipient their own link, carrying its own 128-bit random token, and see which of them has opened the case and when. A per-recipient link identifies who opened the case; it does not restrict who can. To cut off someone who already has a link, change the case password.

Every one of those signed values is verified with a constant-time comparison, so the check itself leaks nothing.

Every file request is checked, and every URL expires

Storage is never publicly readable. There is no such thing as a permanent URL to one of your files.

Each time a file is opened, the request passes through our own route, which re-checks the password gate, the download permission, the per-IP rate limit, and the account's bandwidth quota before issuing a signed URL that expires almost immediately: 60 seconds for a download, four hours for a video or audio stream that a viewer may need to seek through. A URL that leaks is a URL that has already stopped working.

Accounts, sub-users, and administrators

Account passwords and sub-user access codes are stored as non-recoverable hashes. Nobody at MyCaseViewer can tell you what your account password is, because nobody here can read it.

Case passwords are the one deliberate exception, because they exist to be handed to your client. The gate checks a hash, but we also keep a copy encrypted with AES-256-GCM so that you can see and copy the password on the case. Our servers can decrypt that copy in order to show it to you. It is not included in any email we send.

Sessions last 30 days and refresh once a day. Clicking an email verification link does not sign you in — it confirms the address, and you still sign in with your password, so possession of a forwarded email is not possession of an account.

Sub-users sign in to a separate portal with your account handle, their name, and an access code you issue and can disable at any time. They can create cases and upload files under your quotas, and nothing else — a sub-user who navigates to the dashboard is bounced to the login page. Every upload is tagged with which sub-user made it.

Two-step verification is available on every account and required on ours: no MyCaseViewer administrator can reach the admin panel with a password alone. You can use an authenticator app or have a six-digit code emailed to you, and you get single-use backup codes for a lost phone. Codes are checked against a per-account lockout as well as a per-address rate limit.

Administrative access is gated at the layout and independently re-checked inside every administrative action, so a single missed check cannot expose the panel.

API keys and webhooks

Corporate and Enterprise accounts can connect MyCaseViewer to other systems. An API key is shown once, when it is created, and only its SHA-256 hash is stored — we cannot show it to you again, and a copy of our database does not contain a usable key. Keys are 256 bits of randomness, are either read-only or read-and-write, and stop working on the very next request after you revoke them. Requests are logged with the key that made them and the IP address they came from.

The API cannot do the irreversible things. It can list cases, create them, upload files and send links — under exactly the rules the dashboard enforces, because it runs the same code. It cannot delete a case or a file, seal or unseal a delivery, or place or release a legal hold. Uploaded bytes still go straight from the sender to storage; they never pass through our servers.

Webhooks carry names, not evidence. An event tells your system that a case was opened or a file downloaded: the case and file names, the recipient name you entered, a time and a country. It never contains a recipient's IP address, file contents, a link to a file, or a case password.

Each webhook request is signed with a secret only you and we hold (HMAC-SHA256 over a timestamp and the body), so your endpoint can reject anything that did not come from us or that is being replayed. The secret is stored encrypted with AES-256-GCM. Because a webhook address is something a customer types in, we treat it as hostile: deliveries go only to public HTTPS addresses, never to private or internal network ranges, redirects are not followed, and the address is checked at the moment of connection rather than only when it is saved.

Revoking an API key also switches off every webhook that key created.

Rate limiting

Abuse budgets are applied per surface, so guessing attacks fail quietly:

The cap on outbound sends exists so the application can never be used as a mail relay.

The audit trail

Every view and every download is recorded: the time, the IP address, an IP-derived country, a description of the browser and device, and which file. When per-recipient links are used, each recipient's opens of the case are recorded against them too. From that record you can produce a Certificate of Delivery showing what was delivered and when it was opened.

The certificate states plainly what each field is and what it is not. An IP-derived country is not proof of where a person was standing, and saying so on the document is what keeps the rest of it credible.

Legal hold events — every placement and release, with a reason and the person responsible — are written to an append-only, hash-chained log. Each entry's digest covers the previous entry's, so removing or altering one breaks every digest after it, and the certificate reports whether the chain verifies. A custody record that could be quietly edited would be worth nothing.

Browser-level hardening

Every response carries a content security policy restricting where scripts, frames, and media may come from, plus X-Frame-Options, X-Content-Type-Options: nosniff, a referrer policy, and a permissions policy that denies camera, microphone, and geolocation outright.

No tracking, anywhere

There are no advertising or analytics trackers on this site or in the viewer. No Google Analytics, no ad pixels, no third-party session recorders. Every cookie we set is one the product needs to function, and they are listed in the Privacy Policy. Your clients are not profiled for opening your case.

What we have not built

A security page that lists only strengths is a sales document. These are the things a thorough reviewer will ask about and not find:

• No IP allowlisting.
• No hardware security keys. Two-step verification supports authenticator apps and emailed codes; WebAuthn and passkeys are not offered yet.
• No independent penetration test has been performed to date.
• No SOC 2 attestation of our own, as stated above. Our storage and infrastructure providers hold theirs.
• No granular role-based permissions. There are account owners, sub-users who may only upload, and administrators. Access to case material is controlled per case and per file rather than by role.

If one of these is a requirement for your firm, tell us — it moves up the list.

Reporting a vulnerability

If you believe you have found a security issue, write to security@mycaseviewer.com, or use the form at mycaseviewer.com/contact?topic=security, with enough detail to reproduce it. We will acknowledge within two business days, keep you updated, and we will not pursue anyone who reports in good faith and does not access other people's data.

Questions we get asked

Is MyCaseViewer SOC 2 certified?

No. We do not hold an attestation of our own, and we will not imply otherwise. Your case files are stored exclusively in SOC 2 Type II–attested data centers on US soil, on every plan, and our application and database infrastructure runs on SOC 2 Type II–attested providers.

Is my data encrypted?

Yes — in transit over HTTPS with a preloaded two-year HSTS policy, and at rest. Case files are encrypted and split into fragments across independent storage operators before they come to rest anywhere.

Where is my data stored?

Entirely in the United States. We do not offer storage outside the US.

Do you support two-factor authentication?

Yes. Turn it on under Security in your dashboard, using an authenticator app or emailed codes. It is mandatory for MyCaseViewer administrators. Hardware keys are not supported yet.

Can I stop my client downloading files?

Yes, per case and per file. Viewing and playback still work; only the download is withheld.

What happens to my files when a case expires?

They are permanently deleted from storage, along with any converted display copies, after a 24-hour grace period, and your storage quota is released. Deletion is run by a scheduled job. Keep your own copies of anything you need to retain.

Who can see my case material at MyCaseViewer?

Our staff do not read the contents of your cases except when you ask us to for support, when strictly necessary to investigate a fault or a security incident, or when compelled by valid legal process. Such access is limited and logged. Our Terms of Service set out exactly how we respond to subpoenas.