How ASTIS Mail + Calendar Protects Content Without Migrating from Gmail or Microsoft 365

An explainer for Legal, CEO, CTO, and CISO.

I'm building ASTIS around one principle:

Infrastructure access should not automatically mean data access.

Your email provider should deliver the message. Your calendar infrastructure should sync the event. Your cloud storage should hold the sealed envelope — a PGP-wrapped packet that infrastructure routes but cannot open.

None of them should automatically own the protected content inside. That applies to ASTIS too — as a SaaS provider, ASTIS infrastructure should not have that access either.

---

TL;DR

• Plaintext content (email body, subject, attachments, calendar event context) never exists on ASTIS infrastructure. Encryption happens in your browser before data leaves the device; decryption happens on the recipient's device. ASTIS edge routes the encrypted envelope and does not see the content.
• Architecturally this is four independent trust boundaries: storage / encryption / access control / audit. A breach of one does not compromise the others. The same principle from W1 — Infrastructure Access Should Not Mean Data Access, applied to Mail and Calendar.
• Cross-provider works: your recipient stays on their existing Outlook or Gmail; encryption finds their key via WKD without requiring migration.

---

Principles ASTIS Mail uses to protect your data

Content, not account

Plaintext content (body, subject, attachments, calendar context) exists only on end-user devices — in your browser (PWA Mail) or in your platform's native app. Not on ASTIS servers. Not in logs. Not in backups. Content encryption happens before data leaves your device. Key material is a separate category with nuances per custody model (see below).

Custody scales with tier

Three custody models, honest about the trade-off between convenience and architectural zero-access.

B2C / Mail Plus (solo professional)

Individual user OpenPGP key only. Generated on your device, encrypted with a password only you know. Stored in browser (IndexedDB in PWA Mail) or in your platform's native app — plus an encrypted backup copy in CryptoVault Service (CVS) in the same password-protected form. Decryption is possible only on the edge device with your password — plaintext of the key never exists on ASTIS servers. There is no org-level key in B2C — no organization, no need for org-recovery flow.

B2B managed CVS (Mail Team / Organization)

Individual user keys follow the same pattern as B2C (on device + encrypted backup in CVS, password-protected). Plus an organization-level OpenPGP key for cross-org operations: encryption to multiple org members, employee-departure recovery, legal hold, compliance access. Managed CVS keeps the org key inside the ASTIS-operated custody boundary. Recovery after loss of runtime state requires admin participation. Architectural details — including runtime custody semantics — are available under NDA architecture review.

Enterprise HYOK (zero-access by construction)

All keys (user-level + org-level) live in a CVS pod sitting in your infrastructure. ASTIS edge has zero access to key material — neither encrypted blobs nor master keys. This is the mode for threat models that require architectural zero-access — for example, scenarios where ASTIS must not be a potential compelled-disclosure target for org keys. HYOK removes ASTIS from the custody boundary entirely.

Choose based on your tier + threat model. Managed CVS protects most regulated workflows with a legitimate org-recovery flow; HYOK is for buyers whose threat model requires the additional architectural assurance.

Infrastructure routes, doesn't read

This is the same role separation that ENISA technical-measures guidance describes as role segregation. At the audit-pack level it maps well to cryptography/encryption controls in NIS2 Art. 21(2)(h) and to access-control / supply-chain evidence in a broader compliance bundle.

Recovery is a governance act

Org recovery (legal hold, employee departure, compliance access) is not a back-door — it's a policy-gated operation that goes through validation and is captured in a tamper-evident audit log. An org admin cannot silent-decrypt employee content; every recovery is initiated through an audit pipeline that a CISO or external auditor can verify. Details on this flow in Section 3.5 below.

What's still work in progress: we say openly what's not shipped yet — IETF Protected Headers conformance, 3rd-party security audit, SOC 2 Type I/II observation. Roadmap-honest disclosure is part of how we operate. See Section 6 for the full status.

---

1. Who this is for

ASTIS Mail is for organizations where communication content is protected by privilege or compliance obligation:

• Law firms — attorney-client privilege in daily workflow (litigation, M&A, corporate counsel, trade & finance, compliance)
• Trading firms, funds, investment companies, family offices — commercially sensitive negotiations, deal flow, client information under regulatory oversight (MiFID II, AIFMD, MAR)
• Regulated businesses (healthcare, financial advisory, insurance, compliance-adjacent) — NIS2 / DORA / GDPR Art. 32 requirements
• B2B SaaS serving a regulated customer — when the biggest customer's CISO has already asked "where does plaintext live in your stack?"
• Journalism and NGOs — source protection requires that a court order to your email provider physically cannot produce plaintext
• MilTech and high-OPSEC operators — adversarial threat models that assume hostile interception of communications

If your business is internal-only SaaS without privilege-protected content, your existing corporate email provider with default settings is likely sufficient. Buying zero-knowledge in that case is overengineering.

---

2. What your current email provider can give — and why it's still not enough

In most cases your corporate email provider can give you:

• TLS in transit
• Encryption at rest in the provider's database
• RBAC, SSO, audit logs
• Anti-spam, retention, backup, calendar, contacts, sharing

We can't guarantee that — the specific tier and configuration depend on your provider and contract. But even if you have all of it at maximum, it doesn't deliver end-to-end content protection, because structurally:

• The provider technically can read the body of any email — its KMS holds the keys
• The provider can produce decrypted data under a court order — for US-resident providers, Cloud Act or other compelled-disclosure statutes¹ make that standard procedure
• Metadata — subject, meeting attendees, file names, recipient lists, CC patterns — is usually not encrypted at all
• A provider administrator with operational access technically can read your content — policy forbids it, architecture does not

This is called "compensating controls": RBAC + KMS + SOC 2 reduce risk. They do not change the data-ownership model. Ownership stays with the provider as long as content is plaintext-accessible inside its perimeter.

For attorney-client privilege, NIS2 essential-entity workloads, journalistic source protection, or medical data under GDPR Art. 32 — this is a fundamental gap. Your biggest enterprise customer's CISO knows this; that's why the security questionnaire asks "where does plaintext live?"

This is not about bad providers. It's about architecture. Infrastructure can carry the envelope. It should not automatically read the content.

---

3. How ASTIS Mail protects differently

Load-bearing claim: plaintext content (email body, subject, attachments, calendar context) never exists on ASTIS infrastructure. Not on edge servers. Not in logs. Not in backups. Not in persistent storage.

Encryption happens in your browser (via WALEW — Wall Encryption WebAssembly, our Rust → WASM engine) before data leaves the device. Decryption happens on the recipient's device. Between those two points is a sealed envelope that ASTIS routes but cannot open.

What ASTIS does NOT see (in any of the three modes — Solo / default org / HYOK):

• Email body
• Subject (plaintext)
• Attachments (content and filenames)
• Calendar context (event title, attendees, location, description)

What ASTIS does see — operational metadata, required for delivery and operations:

• Routing: who is sender, who is recipient, time
• Encrypted session-key capsules (one per recipient, OpenPGP-wrapped)
• Cryptographic commitment over the recipient list (for integrity verification)
• TTL timestamp
• Internal dedup / integrity hashes (not plaintext content — their cryptographic derivatives)
• Email hashes (SHA-256 sender / recipient)

None of this is plaintext content. This is an operational metadata layer required for delivery and integrity guarantees; full disclosure of the metadata layer + cryptographic details is under NDA architecture review.

Not "we promise we don't read the body". Not "our policy forbids reading the body". But: plaintext of the body does not exist on ASTIS infrastructure — there is nothing to read.

📋 Need the full architecture view? Request the ASTIS Mail + Calendar security brief — a deeper walkthrough of trust boundaries, custody model, and audit evidence under NDA. astis.io/contact — subject "Security brief".

This is achieved through separation into four independent trust boundaries:

A breach of one boundary does not compromise the others. This is not policy — it's structure.

(If you read W1 — Infrastructure Access Should Not Mean Data Access — it's the same principle applied to Mail + Calendar.)

---

3.5. Org recovery without silent admin plaintext access

An obvious question with an E2E / ZK model: "if only the user has the key — how does the organization perform legal hold, employee-departure recovery, compliance audits?"

ASTIS implements a policy-gated recovery flow: every org-recovery action (legal hold, employee departure, compliance access) goes through policy validation and is captured in a tamper-evident hash-chained audit log. An org admin cannot silent-decrypt an employee's content — every request is logged with initiator, scope, timestamp, justification; a CISO or external auditor can verify independently.

Important for compliance evidence (applies to B2B Team / Organization / Enterprise tiers — for B2C this section is not applicable, no organization):

• User-level OpenPGP private keys are generated on user devices, encrypted with the user's password, stored on device + encrypted backup in CVS (managed or HYOK, depending on tier).
• The org-level OpenPGP private key is generated, encrypted, and stored in CVS — in managed mode this is ASTIS-managed CVS; in HYOK mode this is a CVS pod in your infrastructure.
• An org admin physically has no API for directly downloading an employee's private key. Everything an org admin can initiate is a policy-gated recovery operation that goes through the audit pipeline (validate access → CVS Convert → audit log → result delivered to compliance officer). This is a structural constraint, not a procedural one.

Default managed mode gives operational convenience + a legitimate org-recovery capability, but runtime exposure to ASTIS perimeter exists (part of the threat-model evaluation). HYOK — all key custody on customer infrastructure, ASTIS edge has zero access — for threat models that require zero-access by construction.

Mechanics of the custody model, key derivation, and threat boundaries are available under architecture review.

Privacy by architecture, accountability by audit. An org admin cannot silent-read; every recovery is policy-gated + audit-tracked.

---

4. How this works with Gmail / Microsoft 365

ASTIS Mail discovers the recipient's public key via WKD (Web Key Directory) — the open OpenPGP key-discovery standard. ASTIS supports enterprise discovery patterns (org-level lookups, multi-domain key resolution) without exposing plaintext or centralizing account control — details under architecture review. WKD lookups go through SHA-256 hash of the email address (the actual address never leaks into the lookup request). If the recipient has a published WKD key, the message is encrypted directly to it; the encrypted envelope travels through the recipient's normal mailbox-provider delivery path into their existing Gmail / M365 mailbox. No client migration required.

If the recipient has no key yet, the sealed payload stays in pending state until they register; when they create an ASTIS account and publish their key via WKD, the accumulated mail becomes readable to them (automatically re-encrypted to their personal key).

CISO threat-model caveat: during the pending state there is a short window in which a server-fallback key can transiently be unwrapped server-side for rewrap. The body of the message is not affected — the body is already encrypted under a session key and does not pass through ASTIS edge in plaintext. Threat-model details are available under architecture review.

Step-by-step details are on astis.io/product/mail (How It Works section).

---

5. Trade-offs — the honest side

ASTIS Mail is not free of operational compromise. What you give up in exchange for zero-knowledge:

• You lose: server-side search across all messages. You search inside your own mailbox via a client-side index. Provider-side ML features (like AI summary reading your privileged correspondence) — also absent. By architecture. Not a design bug — a desired property.
• You lose: easy IT monitoring "show me what user X emailed last week". Without the user's consent — not possible. In a regulated industry that's a feature, not a bug.
• You lose: some convenience of cloud AI assistants on privileged correspondence. If you want AI features, that's done separately via MCP scoped access, not via "give the AI access to read everything".

You gain:

• Structural protection of privileged communication — plaintext body, subject, attachments, and calendar context don't exist on ASTIS infrastructure in any mode
• An audit-ready NIS2 Art. 21(2)(h) cryptography story — evidence pack maps to auditor expectations; 3rd-party security audit planned for 2026
• For HYOK / customer-side custody — no Cloud Act compelled-disclosure exposure for plaintext content (because ASTIS holds no keys)
• Data-minimal sub-processors + a single DPA — Cloudflare (edge / CDN), Stripe (billing), Resend (auth OTP); none receives plaintext content. Hosting / colocation — EU/EEA-domiciled (under NDA per Business+ tier). One DPA + one audit pack instead of a 4-5-vendor stack. Full list: astis.io/legal/subprocessors.
• TTL (time-to-live) on messages — messages can automatically become inaccessible after a defined period. Useful for NDA discussions, deal-flow communications, and retention-compliance limits.

If your processes rely on server-side search or admin-side moderation, this isn't your product.

---

6. Status — shipped, in progress, on roadmap

Shipped: body / subject / attachments E2E encryption (AES-256-GCM + OpenPGP wrapping); WKD key discovery; subject privacy via sealed-envelope format; encrypted Calendar (title / attendees / location); PWA Mail (desktop + mobile); browser extensions (where deployed); hash-chained audit log; HYOK option (Enterprise); TTL; auto-rewrap for late onboarding; policy-gated org-recovery flow.

In progress / roadmap: SOC 2 program (CASA Tier 2 done; Type I first, Type II to follow; timeline driven by auditor engagement); 3rd-party security audit (planned 2026); IETF Protected Headers conformance (subject privacy is already implemented via sealed-envelope format; an IETF-conformant version will add interop with other OpenPGP clients); Thunderbird desktop plugin production release.

If your decision depends on a completed 3rd-party audit or formal certification, come back in 6 months. If you're comfortable with architecture review under NDA + roadmap-honest disclosure, let's go.

---

We've articulated the general structural questions worth asking any encrypted-email vendor before procurement in W1. This blog answers those questions in the specific context of ASTIS Mail.

---

7. Q&A — anticipated questions from CTO / CISO / managing partner

If a champion is preparing this blog for a meeting with CTO/CISO, here are 8 questions most likely to come up. Answers are 30-second talking points.

Q1. "Is this just OpenPGP with a UI? We've tried PGP — nobody adopted it." (Note: PGP™ is a proprietary trademark of Symantec/Broadcom; OpenPGP is the open IETF standard RFC-4880 / RFC-9580 — and that's what ASTIS uses. The distinction is critical for compliance/audit purposes.)

No, not just OpenPGP with a UI. OpenPGP is a primitive. ASTIS Mail is a workflow on top of the primitive: WKD-driven key discovery (not manual fingerprint exchange), AES-256-GCM session keys + OpenPGP wrapping (not OpenPGP body encryption), sealed-envelope architecture (not "OpenPGP message as attachment"), Hybrid CVS / HYOK custody options (not "your .gpg on a USB stick"). UX: native PWA Mail without the keysigning ritual. For deeper detail, we can walk through the sealed-envelope architecture under NDA.

Q2. "How is this different from other secure email providers?" Most secure-email products solve body encryption inside their walled garden. ASTIS is built around four architectural pillars that rarely combine in one product: (1) HYOK / customer-custody model for enterprise where the org key can live entirely in your pod; (2) API layer with the same crypto primitives for your own product, not just for mailbox; (3) NIS2 / DORA-oriented audit pack as a first-class deliverable; (4) WKD-driven cross-provider workflow without requiring recipient migration. At the functional message-encryption level there are similarities with other secure-email categories; the main difference is in platform / custody / audit / cross-provider story.

Q3. "Can you read our emails under a court order?" Body, subject, attachments, calendar context — we cannot. Plaintext content does not exist on ASTIS infrastructure in any mode. What we can produce: routing metadata + encrypted blobs (unreadable without the key). For HYOK — no keys at all, so even encrypted blobs in our infrastructure are limited. Architecture review available under NDA for security-team verification.

Q4. "What happens to our archive if ASTIS goes out of business?" Your messages are wrapped in standards-based OpenPGP wrapping (RFC-4880 / 9580) — a format any compatible client can decode if the private key is available. If your private key is stored locally (PWA Mail IndexedDB / native app), the archive is technically decryptable via standalone OpenPGP tooling plus the sealed-envelope decapsulation library (documented for customers under NDA). If the private key exists only as an encrypted backup in CVS, full standalone archive portability requires a password-authenticated key-extraction flow, which is on the roadmap for Enterprise tier. Source code escrow is available on Enterprise tier as an additional continuity guarantee. Roadmap-honestly: full self-sufficient archive portability is work in progress, not a shipped feature.

Q5. "Does it work with our existing M365 / Outlook without migration?" Yes — WKD-driven cross-provider workflow lets a recipient stay on their M365 / Gmail / Outlook with no changes. Mechanics details — in Section 4 of this blog.

Q6. "Legal hold / discovery / employee departure — how does that work?" A policy-gated recovery flow. An org admin cannot silent-decrypt an employee's content — every recovery action goes through policy validation and is captured in a tamper-evident hash-chained audit log. For HYOK — recovery happens in customer perimeter without ASTIS involvement. Mechanics — under architecture review.

Q7. "Does this pass a NIS2 / DORA / GDPR audit?" Three levels of claim, honestly distinguished:

→ Architecturally maps: ASTIS architecture meets cryptography requirements in NIS2 Art. 21(2)(h) + (d), GDPR Art. 32 (encryption + role separation), DORA RTS Art. 6/7 (cryptographic-control documentation). This is an architectural mapping — we say "our system satisfies these requirements". We provide audit evidence (architecture docs, hash-chained logs, sub-processor list, DPA); the final attestation is made by your auditor.

→ Already passed: CASA Tier 2.

→ On roadmap: SOC 2 program (Type I starting 2026, Type II to follow); 3rd-party security audit (2026); ISO 27001 (post-SOC 2).

We do not promise that your auditor will pass you — we say the architecture is built so an audit pass is achievable without heroics.

Q8. "What if Gmail / Microsoft 365 launches a similar E2E feature tomorrow?" If Gmail or Microsoft 365 add more E2E features, that's good for the market. But ASTIS differentiates not by a single feature but by trust model: Mail operates as an independent cryptographic layer on top of the existing provider, with WKD-driven cross-provider flow, audit evidence, and HYOK / customer-custody option for enterprise. If you're already standardized on M365/Gmail, ASTIS doesn't ask you to migrate — it adds a content-protection boundary over the existing workflow. Detailed competitive analysis — in the sales battlecard under NDA.

---

8. How to get started

30-day trial — no credit card, full features, 1 mailbox. Most managing partners and CTOs spend 15 minutes in trial before a demo conversation. Architecture review / sales-led demo — for Team+, custom HYOK setup, design-partner cohort, or security-team deep-dive under NDA. Tier models and pricing — on astis.io/pricing/mail.

ASTIS Mail is currently in design-partner mode for law firms, funds / investment companies, regulated SMBs, and journalism / NGO; five partners form the first cohort. ASTIS CVS Hybrid — a separate self-hosted product, sales-led.

---

9. How this connects

The same crypto-trust architecture powers the ASTIS API Platform and ASTIS CVS Hybrid — one DPA, one audit pack across all surfaces. This blog focuses on Mail + Calendar; deeper coverage of the platform thesis, custody lifecycle, and audit infrastructure is upcoming in the W-series. Provider-compatible, content-private — the same model in email, in API, in AI workflow.

---

References

• W1 — Infrastructure Access Should Not Mean Data Access — foundational principle
• astis.io/product/mail — product page with all features
• astis.io/pricing/mail — tiers and free trial
• astis.io/security — compliance posture (CASA Tier 2, SOC 2 in progress, ISO 27001 planned, hash-chained audit, sub-processor reference)
• astis.io/contact — sales-led demo or design partner application
• RFC-4880 — OpenPGP Message Format
• RFC-9580 — OpenPGP
• Web Key Directory specification (draft-koch-openpgp-webkey-service)
• Schrems II ruling (Case C-311/18)

---

By Ievgen Bobliev, Founder of ASTIS. 22+ years in enterprise IT — ex-UBS Alternative Investment, ex-IBM, ex-UniCredit Bank, ex-EPAM.

Last updated: 2026-05-11.

Footnotes

1. Besides the US Cloud Act (HR 4943, 2018) — UK Investigatory Powers Act 2016, AU Assistance & Access Act 2018, China National Security Law / Cybersecurity Law, Russia Yarovaya laws. In many jurisdictions where a provider has operational presence, compelled-disclosure mechanisms exist. Your provider's sub-processor list is the main source of exposure. ↩