Customer-keyed crypto. Independently verifiable receipts. Enforcement that survives the vendor.
DRM controls files vendors hold. NoData governs files it doesn't.
We don't pick one mechanism and pretend it solves everything. Three layers, each ratified by working code in production. Every Capsule, Continuum, and Sovereign customer gets all three · picked per file, per recipient, per moment.
Every open re-checks the chain. The recipient never holds the bytes · they hold a ticket. Revoke, expire, time-lock.
A leak is now expensive. Forensic watermarks survive screenshots. Bitcoin proves what existed when. Auto-classification pre-empts the wrong send.
Burn means bytes · not flags. If a leak surfaces anyway, drag it back to the console and learn whose copy it was.
One architecture. Three obligations. Buyers recognize themselves by the trigger sentence · not by a feature checklist. Pick the obligation; the system is the same.
“We need control · but not another heavy system””רוצים שליטה · בלי עוד מערכת כבדה“
“If something happens · we must prove it””אם משהו יקרה · חייבים להוכיח“
“We are not allowed to fail””אסור לנו להיכשל“
Security protects systems. NoData controls the data itself. Even after it leaves.
We wrap your data in a signed envelope. The wrap travels with the file.
AES at rest, certificates rotated, vaults sealed. The hard drive has been a solved problem for a decade.
SSO, MFA, conditional access, zero-trust networks. Who got into which system, when, is well covered.
DLP, SIEM, behaviour analytics. Anomalies inside the perimeter raise alerts within minutes.
But the leak that matters happens after the file is shared. That is where control is lost.
A new layer above DSPM, EDRM and zero-trust: every file becomes a controlled asset, every interaction becomes a signed event. The chain is what an auditor reads, the kill switch is what an executive uses.
PDFs, contracts, spreadsheets, photos of credit cards and ID cards, voice recordings, training videos, medical scans, source code, configuration JSON, markdown notes. NoData adds the same cryptographic wrap to all of them · you never adopt a new file format, and recipients never break workflow.
The seal is the constant. The file stays itself. Same wrap, every format · including the photo of a credit card taken two seconds ago.
Drop your file. The NDC seal is applied. The file keeps its format · gets the wrap.
Pick the recipient and the rules (who, how many opens, time window, devices). The envelope leaves your hands.
Recipient opens · in their normal viewer · within your rules. Every open emits a cryptographic receipt.
When the rules trip · or you revoke · the file becomes mathematically unrecoverable. The receipt remains.
We never see your content. The chain of receipts survives every step · independently verifiable, decades after issuance.
Issue, claim, open, burn. The operator does it; the recipient lives it; the chain records it. A child could narrate this; a regulator can audit it.
Seal a file into a .lockbox. The operator drops it; the server wraps it. Out comes a sealed envelope and a separate consent link.
The recipient identifies themselves: name, email, device. That stated identity is signed in, and woven into every future view.
Controlled viewing in any browser. Plaintext never lands on disk. The recipient's name is burned diagonally across every preview.
Access is revoked instantly, everywhere. Every cached copy, on every device, becomes mathematically indistinguishable from random data.
Once a file leaves your system, you lose control. With NoData, you don't.
Most data-security categories ship one box per problem. NoData ships one architecture and lets the boxes fall out of it. A single signed event chain is the substrate; everything visible to operators, recipients and auditors is what that chain enables: one click, one consent, no install.
That is why the operator console, the .lockbox container, the in-browser viewer, the claim flow, the AIP overlay, the watermark and the public verifier all share one audit, one contract, one screen.
These are the tools the architecture makes possible. Pick the surface that fits the file: a sealed container, a viewer in the browser, a label inside Microsoft 365, a watermark, an operator console, a public verifier. No SDK, no install, nothing to configure.
A binary file format with a tearable wrap-key. Sender ticks a box; the file becomes a sealed envelope with a kill switch.
A web viewer that decrypts on-device, renders PDF / Excel / Word / PowerPoint, and wipes plaintext when burn arrives.
The first request is the recipient stating who they are. That stated identity is signed into the chain and burned into every preview.
The recipient’s stated name + receipt id woven across every rendered page. Survives screenshot. Maps any leak back to the claim.
For Office files inside enterprises that already use sensitivity labels: NoData orchestrates label apply, label revoke, and burn over Graph.
Issued, claimed, opened, watermarked, revoked, burned · one row per file, one inline kill switch, one signed audit per action.
Drag any evidence pack into a no-auth web page. WebCrypto checks the signature against /api/chain/pubkey. Five-line script in any language.
The differentiator is not a single feature. It is the combination of all trust layers into one outbound data architecture.
Traditional platforms are excellent at workflow + access management. NoData is the layer that adds continuous, cryptographically-verifiable control. Compliance buyers in legal, finance, healthcare, and defense want all ten in one stack · we are the only product that ships it.
| Capability | NoData | DocuSign | ServiceNow | monday | Salesforce |
|---|---|---|---|---|---|
Server cannot access customer content privacy-first architecture | ✓ | — | — | — | — |
Cryptographic proof per workflow step signed chain receipts | ✓ | ◐ | — | — | — |
Live process editing during active flow | ✓ | — | ◐ | ◐ | ◐ |
High-confidence delivery to designated recipient only device-bound · email-bound · time-burned | ✓ | ◐ | — | — | ◐ |
Per-step operator control plane monitor · intervene · revoke · verify | ✓ | ◐ | ✓ | ✓ | ✓ |
Built-in trust communication layer chat · push · magic links · embedded delivery | ✓ | — | ◐ | ◐ | ◐ |
Instant cryptographic revocation ("burn") | ✓ | — | — | — | — |
Independent public verification without vendor trust | ✓ | — | — | — | — |
Recipient-bound forensic watermarking | ✓ | — | — | — | — |
Continuous control after the file leaves the organization | ✓ | — | — | — | — |
Every receipt is signed with an Ed25519 key whose public counterpart is published at /api/chain/pubkey. A regulator, a court-appointed auditor, or a customer’s in-house security team can verify any receipt with a five-line script in any language. We do not hold the keys to your trust.
// verify any NoData receipt with no shared secret.import { verify } from "@noble/ed25519";const r = await fetch("/receipt/123").then(x => x.json());const pubKey = await fetch("/api/chain/pubkey").then(x => x.json());const message = `${r.event_hash}|${r.prev_receipt_id ?? ""}|${r.created_at}`;const ok = await verify(r.signature_hex, message, pubKey.active.pubkey_hex);// -> true. No NoData involvement required.
Encryption keeps secrets. Identity gates rooms. Signatures detect tampering. None of these were designed to follow a file home.
One payload. A defined hierarchy of recipients. Each step opens only for the designated person · they sign, the chain advances, the next person gets a push. No parallel openings, no “who's next?” friction, no email back-and-forth. Every step is a signed receipt anyone can verify.
Continuous Data Control is not DSPM, not EDRM, not zero-trust networking. It is the orchestration layer above all of them · where the file’s entire life is one signed, revocable, recipient-attributed sequence anyone can verify with a 32-byte public key.