Zero-Trust architecture: why traditional email is a security breach and how the Proton standard solves it

Today, 90% of companies operate under a false sense of security provided by the tech giants (Google Workspace, Microsoft 365). These platforms are undeniably robust against low-level external attackers, but they base their model on an architectural principle that is unacceptable for business sovereignty: they protect your data from third parties, but keep the access keys for themselves.

From the standpoint of business intelligence and intellectual property protection, paying for a traditional email service is like hiring a heavily armoured security team that, by contract, has the right to open, read, classify and use the content of all your communications before handing them over to you.

In an increasingly strict regulatory environment (NIS2, GDPR) and faced with the real risk of industrial espionage, your company's confidentiality cannot depend on the ever-changing privacy policies of a foreign corporation. Security should not be a legal promise; it must be a mathematical guarantee.

In this analysis, Oksigenia sets out the critical migration towards a Zero-Trust architecture with end-to-end encryption (E2EE), using the Proton ecosystem as the industry standard.

1. The architectural flaw: the myth of TLS encryption and “retained keys”

To understand the vulnerability of modern companies, you have to look at how information travels. The standard email protocol, SMTP (Simple Mail Transfer Protocol), was designed in the 1980s to transmit plain text. To patch this, the industry adopted TLS (Transport Layer Security) encryption.

When an employee sends an email through Google's or Microsoft's infrastructure, the transmission channel is encrypted. However, this model has an insurmountable structural flaw known as encryption in transit vs. encryption at rest with retained keys:

1. The message travels encrypted across the network from the employee's computer to the provider's data centre.
2. On reaching the server, the provider temporarily decrypts the message. It scans it in plain text to index it in its search engines, apply filters, train artificial intelligence models or extract operational metadata.
3. It then encrypts it again to store it on its hard drives (encryption at rest).

The attack vector: The provider holds the symmetric decryption key. If the corporation receives a court order (even from foreign jurisdictions operating under laws such as the CLOUD Act), if it suffers an internal breach by a malicious employee, or if it simply decides to change its terms of service to mine your data, your company's information is exposed and you have no control over it.

2. The mathematical solution: zero-access encryption (ZAE) and E2EE

To eradicate this vulnerability at the root, at Oksigenia we implement communication architectures based on the OpenPGP standard and advanced cryptography (such as elliptic-curve cryptography, or ECC). The Proton ecosystem, hosted in underground bunkers under Swiss jurisdiction (outside the “Fourteen Eyes” alliance), is the most mature and auditable commercial implementation of this technology.

The technical difference that makes for real sovereignty lies in the decentralised management of the cryptographic keys:

End-to-end encryption (E2EE)

When communication takes place within the secure ecosystem (between two employees of your company, or with a client using the same technology), the message is encrypted locally on the sender's device using the recipient's public key (K_pub).

Mathematically, only the recipient's private key (K_priv), which is generated and kept encrypted on their physical device, can solve the decryption function M = D(K_priv, C). The servers of the Swiss infrastructure act as mere blind carriers; all they see is an unintelligible string of characters (C) passing through their network.

Zero-access encryption (ZAE)

The real technical challenge of email is interoperability. What happens when you receive an email from an insecure external provider (e.g. a client using Gmail)?

The message inevitably reaches the incoming server in plain text. However, with the ZAE architecture, within milliseconds and in RAM, the server encrypts that message with your employee's public key before writing it permanently to disk. Once it has been written, not even the provider's own engineers can read it.

If an attacker managed to physically breach the data centres, they would only extract encrypted data blobs, without the keys needed to read them.

3. The architect's dilemma: why doesn't Oksigenia self-host email?

If at Oksigenia we advocate absolute technological independence by deploying our own VPS servers (Debian, Proxmox, Docker) to host n8n, CRMs and corporate databases… why do we recommend delegating email to a third party such as Proton?

The technical answer is the oligopoly over the SMTP protocol and deliverability.

Email today is broken at the level of global trust. If we set up our own independent mail server (using Postfix and Dovecot, or stacks such as Mailcow), we face an ecosystem in which Google and Microsoft act as absolute judges. A slight change in the reputation of your VPS's IP address, or an unannounced change in Big Tech's anti-spam algorithms, can send critical emails (contracts, invoices, credentials) straight to your clients' spam folder, regardless of whether your server's technical configuration is perfect.

Delegating the email layer to hyper-specialised infrastructure, with an impeccable IP reputation, the resources to battle Google's and Microsoft's false positives, and auditable open-source code that guarantees they cannot read your data, is not a surrender; it is the most efficient and intelligent risk-engineering decision to ensure the business never stops.

# Oksigenia's deployment logic prioritises delivery without sacrificing privacy:
if (Servicio == "Base de Datos" || Servicio == "Automatizaciones") {
    Desplegar(Infraestructura_Propia_VPS);
    Control_Absoluto = TRUE;
} else if (Servicio == "Email_Corporativo") {
    Delegar(Proton_Ecosystem);
    Garantizar(Zero_Access_Encryption);
    Entregabilidad = MAXIMA;
}

4. Beyond email: hardening the attack surface

Dealing only with email is like leaving the office's back door wide open. The sovereign ecosystem must cover the entire attack surface of modern office work:

• Proton Drive (cryptographic storage): Unlike traditional corporate clouds, where the provider scans files to build “usage profiles” or apply hash algorithms, this architecture encrypts the files, the document names and even the folder structure on the client's device (client-side encryption) before they are uploaded. Nobody knows what you store or what it is called.
• Proton VPN (corporate-grade tunnels): An essential tool for remote and travelling employees. It implements modern protocols such as WireGuard and obfuscation technologies (Stealth) so that encrypted traffic looks like ordinary HTTPS traffic, evading Deep Packet Inspection (DPI) on public Wi-Fi networks in hotels, airports or countries with censorship.
• Proton Pass (secrets management): A common failing in IT management is securing the network but letting employees save corporate passwords in browsers with telemetry. An auditable, open-source, locally encrypted password manager is non-negotiable.

5. Technical implementation: the Oksigenia standard at the DNS layer

Migrating to an encrypted email architecture is not simply a matter of “creating user accounts” and changing passwords. It requires a thorough re-engineering of the DNS layer of the company's domain to shield the corporate identity against spoofing (impersonation) and phishing.

At Oksigenia, we carry out this transition by strictly implementing the email authentication triad:

1. SPF (Sender Policy Framework): Configuration of TXT records that act as a public cryptographic authorisation, stating exactly which IP addresses anywhere in the world are allowed to send email on behalf of your domain.
2. DKIM (DomainKeys Identified Mail): Injection of asymmetric digital signatures into the headers of every outgoing email, guaranteeing to receiving servers that the message has not been altered in transit.
3. DMARC (Domain-based Message Authentication, Reporting, and Conformance): The final lock. We implement strict rejection policies that instruct servers worldwide to immediately destroy any email attempting to impersonate your company, and to send forensic reports directly to our administration dashboards.
4. MTA-STS (Strict Transport Security): DMARC protects who sends the message, but MTA-STS protects how it travels. We implement strict policies, combining DNS records and a dedicated web server, that force any server in the world to communicate with your domain exclusively over an encrypted, authenticated TLS channel. If an attacker attempts a Man-in-the-Middle (MitM) attack to degrade the connection to plain text (a downgrade attack), the MTA-STS policy orders the transmission to be aborted immediately. The message is not delivered over compromised networks.
5. TLS-RPT (TLS Reporting): Security without auditing is blind faith. We deploy cryptographic telemetry records that instruct servers worldwide to send us daily forensic reports in JSON format. This lets us monitor in real time whether any node on the internet is trying to downgrade or intercept your company's email traffic.

DNS zone file

# Transport hardening configured by Oksigenia:
_mta-sts.tuempresa.com. IN TXT "v=STSv1; id=2026021801;"
_smtp._tls.tuempresa.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@oksigenia.com;"

---

6. Strategic conclusion

The convenience and supposed “zero cost” of traditional communication platforms carry an incalculable hidden price: the total loss of business secrecy and data sovereignty.

Implementing an architecture based on open-source asymmetric cryptography and zero-access encryption is not a luxury reserved for cybersecurity firms or defence contractors; it is the minimum due diligence that any board of directors, CISO or managing director must demand today to protect their company's intellectual property and their clients' confidentiality.

Encryption does not hide information; encryption protects your business.

Is your company's communications infrastructure ready for a digital sovereignty audit, or are you still trusting that nobody will read your emails? Let's talk.