Verified delivery on any device

Proof of delivery. Nothing to install.

Send sensitive information to anyone. It opens in the browser they already have, with cryptographic evidence it arrived unaltered.

See SEAL in cybersecurity

Healthcare professionals need to send confidential information to patients, who open it on any device in the browser they already have. SEAL (Secure Edge Application Layer) makes this possible: every MIME part encrypted separately, the message split into fragments so that no single system holds it whole, and evidence for the recipient that it arrived unaltered. No assumptions about recipient infrastructure. In production across Swiss healthcare with Health Info Net (HIN).

800,000+

verified deliveries per month, across all of Swiss healthcare

What SEAL delivers

Tamper-evident from send to open

SEAL (Secure Edge Application Layer) encrypts every MIME part individually with AES-GCM-256, splits the message into fragments and distributes them across the IPFS network. No single system ever holds the complete message, and recipients can be certain that what reaches them is what was sent.

Shared mailboxes, individual tokens

Recipients can be sure a message arrived unaltered and can reply securely. Where recipient authentication is enabled, several authenticator apps can be enrolled for one recipient address, so several staff in a practice, department or shared mailbox can each use their own. Where a recipient authenticates with an authenticator app, the receipt names the enrolled token that opened the message. SMS codes remain available as a fallback.

Nothing to install by default, on any device

Recipients receive a link by email. The Web Verification App reassembles and decrypts the message in the browser they already have. By default there is no software to install, no account and no certificate to manage; recipients who use authenticator codes need an authenticator app.

Deployable standalone or as part of Verimesh infrastructure

SEAL operates independently within existing messaging infrastructure, wherever tamper-evident delivery is needed. Organisations ready to join the full authenticated exchange ecosystem can upgrade to Verimesh.

How it works

When a sender uses their existing mail client, SEAL encrypts each MIME part individually with AES-GCM-256, splits the encrypted message into fragments and distributes them across the IPFS network. No single system ever holds the complete message, so there is no central store to breach. The recipient receives a link by email, and the Web Verification App reassembles and decrypts the message in their browser. Evidence and recipient effort usually pull against each other: a portal can give you an audit trail, but every recipient needs an account, and S/MIME or PGP give you cryptography, but the far end needs a certificate and a mail client that understands it. With SEAL, the recipient opens the message in a browser, and the sender still gets evidence.

For technical readers, the diagrams below show the full message flow and data structure. Expand either section to view.

SEAL message flow

SEAL delivery operates in three phases: per-part encryption with AES-GCM-256 as the message leaves the sending organisation, fragmentation and distribution across the IPFS network in transit, and reassembly with decryption in the recipient browser on arrival. The Web Verification App provides the recipient experience with no software installation required.

Email data structure

A SEAL message is stored as encrypted fragments rather than as a single file. Each MIME part is encrypted separately, so body text and attachments are independent objects, and the fragments are content-addressed across the IPFS network. Assembly and decryption happen only at the edge, in the recipient browser, so no intermediate system can read the message or alter it undetected.

What recipients see

When someone receives a SEAL message, they open it in their browser and can confirm it arrived unaltered.

Delivery verified

Integrity check passed: message unaltered in transit

From: Dr. Maria Huber
Organisation: Kantonsspital Zürich
Sent: 13 March 2026, 09:14
Subject: Patient referral: confirmed

Delivery receipt recorded for this recipient
No modifications detected since encryption

Verified by Verimesh

SEAL and Verimesh

SEAL is the entry product. It solves the delivery problem: every delivery verified, every message tamper-evident, and by default nothing for recipients to install. Verimesh is the infrastructure destination: identity management, certificates, credentials, policy engine, sovereign data exchange, transport, and semantic interoperability. Start with SEAL. When your organisation is ready to join, or to lead, the authenticated exchange ecosystem, upgrade to Verimesh.

SEAL can be deployed independently wherever tamper-evident delivery is needed: it does not require the full Verimesh infrastructure.

Explore Verimesh

SEAL is the message-layer foundation. Verimesh is the authorisation layer that enforces consent withdrawal across institutions. Together with SEAL, they form the consent enforcement substrate.

Read the consent architecture thesis

See all use cases →

Fully open source

AGPLv3 or later

SEAL is Open Source under the GNU Affero General Public License v3 or later (AGPLv3+). If you run SEAL, or use a service built on it, the licence entitles you to the complete corresponding source, and we provide it on request at contact@vereign.com.

SEAL: frequently asked questions

What is SEAL?

SEAL (Secure Edge Application Layer) is Vereign's encrypted swarm delivery system for secure external communication. Every MIME part is encrypted separately with AES-GCM-256, split into fragments and distributed across the IPFS network, so no single system ever holds the complete message. Recipients open it in any browser, with no account and no certificate. Where recipient authentication is enabled, they also enter an SMS code (mTAN) or a code from an authenticator app. In Swiss healthcare, SEAL handles 800,000+ verified deliveries per month through Health Info Net (HIN).

Does SEAL prove who sent a message?

SEAL proves that the message you received is the message that was sent. Where a recipient authenticates with an authenticator app, the receipt names the enrolled token that opened the message. Verifying a sender's identity cryptographically is what Verimesh Mail adds, through Decentralised Key Management and its certificate authority. If your requirement is sender identity rather than delivery evidence, Verimesh Mail is the product to look at.

How does SEAL differ from S/MIME or PGP?

S/MIME and PGP encrypt and sign a message against a certificate or a key ring, which means the far end needs a certificate and a mail client that understands it. SEAL takes a different route: instead of encrypting a message as a whole, it encrypts each MIME part separately, splits the message into fragments and distributes them across the IPFS network, so no single system holds the complete message. Recipients need no certificate and no software: they open the message in their browser.

Do recipients need to install anything to open a SEAL message?

Not by default. The encrypted fragments are delivered over existing transport paths, and recipients open the link they receive by email in a browser, where the Web Verification App reassembles and decrypts the message. By default there is no software to install and no certificate to manage. Where recipient authentication is enabled, recipients enter an SMS code (mTAN) or a code from an authenticator app they install or already have.

Who runs SEAL in production today?

Health Info Net (HIN) operates SEAL across Swiss healthcare, handling 800,000+ verified deliveries every month.

Can SEAL be deployed without Verimesh?

Yes. SEAL is the standalone entry product: it operates independently wherever tamper-evident delivery is needed. When your organisation is ready to join the full authenticated exchange ecosystem, you can upgrade to Verimesh, which adds the broader identity, credentialing, policy, and data-exchange infrastructure around it.

Is SEAL open source?

Yes. SEAL is licensed under the GNU Affero General Public License v3 or later (AGPLv3+). A public read-only mirror is not published yet. Under the licence, anyone running SEAL or using a service built on it is entitled to the complete corresponding source, and we provide it on request at contact@vereign.com.

Can several people open messages sent to one address?

Yes, where recipient authentication is enabled. Several authenticator apps can be enrolled for one recipient address, so several staff in a practice, department or shared mailbox can each use their own. Where a recipient authenticates with an authenticator app, the receipt names the enrolled token that opened the message. SMS codes remain available as a fallback. This is in production at Health Info Net (HIN).