Board packs and executive comms
A pre-meeting board pack unlocks only after each named director completes a BioTone session. Forwarding the link to a non-allowlisted recipient does not unlock the file; the audit log shows who actually opened it.
← All use cases
Integration pattern · Illustrative scenarios and policy values. Confirm supported signals, processing location, and application enforcement for your deployment.
Why a link click is not access
A forwarded link or stolen session can expose sensitive documents. Add a fresh recipient check at the point of access, alongside your document permissions.
Bind verification to the requested document. Your backend validates the recipient and approval before enabling access, and records the decision.
Document classes that benefit
Anywhere the cost of a quiet leak is high enough that a fresh human attestation per open is worth the friction.
M&A and diligence read rooms
Outside counsel, bankers, and named diligence team members are added to the allowlist. The data room releases the underlying ciphertext only after a fresh attestation per session, with full audit trail.
Sensitive customer or HR files
A union case file, a regulatory submission draft, or a customer's complete record opens only after the operator on duty completes a BioTone session — replacing 'they had VPN' as the only proof of access.
CUI and export-controlled artifacts
Controlled artifacts can be wrapped with a per-document allowlist and, in deployments that use it, key disaggregation — so no single party (including BioTone) holds the unlock key on its own.
Unlock flow
The operator assigns approved recipients; each recipient verifies through the configured BioTone flow before access.
Operator uploads to the console
The artifact is encrypted at rest. The operator attaches a per-document allowlist of subject ids — these map to your IdP user records, not free-form email addresses.
Recipient requests access from a shareable link
The link itself is not the credential — it points the recipient at a BioTone broker session. The session payload includes the document id and the requesting subject.
Recipient completes a live attestation
Multi-signal capture runs on the recipient's enrolled handset. The broker checks both that the assertion is valid and that the subject id is on the document's allowlist.
Key release and audit
On a successful in-policy session the unlock key is released to the recipient's session and the open event is logged: who, when, document id, signals passed, expiry. Re-opens require a fresh attestation per your policy.
Controls to validate with your security team
Access verification does not prevent an authorized recipient from copying or photographing content. Plan separate document controls where those risks matter.
- Require recipient verification before the backend releases a document key; possession of the link alone must not grant access.
- Reject non-allowlisted recipients and record denied attempts in the audit log.
- Per-document allowlists make 'who saw it?' an answerable question, not a guess from VPN logs.
- Designed to compose with key-disaggregation deployments where unlock requires multiple parties.
For deployments with distributed key custody, define which participants must cooperate before document access is enabled. Validate the encryption, decryption, and recovery design separately from the signing flow.
Console allowlist + auth-broker pattern
Bring a representative document class (board pack, diligence file, customer record) and an allowlist of recipients. We will wire the upload, the broker session, and the audit log end-to-end.