Building for a post-quantum world: Start your transition today with Rocket.Chat

Rocket.Chat is building for a post-quantum world. Here is where we stand.

The post-quantum transition is a deployment problem. And for the organizations Rocket.Chat serves, the window to act is open because the threat is already operational.

Adversaries are collecting encrypted traffic now with the explicit intent to decrypt it later. Every month that communications infrastructure runs on classical cryptography is another month of harvested data in someone's archive.

The reason we can move on this is because Rocket.Chat is self-hosted. You own the stack. 

Our self-hosted architecture gives you direct control over their encryption layer. That control is what makes it possible to deploy post-quantum protection today, using NIST-finalized algorithms, without modifying the core application and without waiting on a vendor. 

Here’s where we stand:

We ship what exists today: Post-quantum protection at the TLS layer, using NIST-approved ML-KEM in a hybrid configuration with classical X25519, is deployable on any self-hosted Rocket.Chat instance right now. The standards are finalized, the implementation is tested, and our desktop app negotiates the hybrid key exchange automatically when the server offers it.

We are aligning to the standards governments are mandating: CNSA 2.0 in the US. NIS2 and DORA in the EU. ACP 240 across Five Eyes and NATO coalition networks. These are the frameworks our customers' security teams are held to, and our architecture is designed to meet them.

We are building deeper: Transport-layer protection is the right first step. Our roadmap extends post-quantum cryptography beyond the TLS boundary into end-to-end encryption, key management, and ACP 240-aligned data handling at the application layer.

The threat is already here and why your communications platform is a prime target

Picture this: an adversary intercepts your encrypted communications today. They cannot read them yet. So they store them and they wait.

This is the confirmed operating strategy of multiple nation-state actors, and it has a name: Store Now, Decrypt Later (SNDL).

The reason it works comes down to how encryption functions. 

Every time two people communicate over an encrypted channel, the encryption relies on a key exchange: a mathematical handshake that establishes a shared secret between two parties. The algorithms used today, RSA and ECC (Elliptic-Curve Cryptography), are secure against current computers. They are not secure against a cryptographically relevant quantum computer (CRQC).

The critical detail: a CRQC does not need to exist at the moment of interception. It only needs to exist at the moment of decryption.

This means a classified briefing, an operational plan, or a sensitive procurement decision transmitted today over a non-quantum-resistant channel could be fully readable within the decade. The breach has not happened yet. The data collection already has.

For most consumer messaging apps, this is an abstract concern. 

For Rocket.Chat's customers, operating across NIPRNet, SIPRNet, JWICS, federal agencies, and critical infrastructure, it is not. A conversation about an active operation or a classified briefing has a confidentiality horizon that easily outlives current cryptographic assumptions.

What governments are requiring, and when

Regulators have moved from guidance to mandate, with concrete deadlines on both sides of the Atlantic.

United States

ML-KEM and ML-DSA were standardized by NIST in 2024. ML-KEM is now the algorithm US federal procurement is converging on, and it's what Rocket.Chat deployments can implement at the TLS layer today.

On January 23, 2026, CISA published product categories for technologies that use post-quantum cryptography standards, naming collaboration software, including chat and messaging, as a category where PQC-capable products are now widely available. Per CISA's own guidance, once a category reaches that status, organizations should plan acquisitions to procure only PQC-capable products within it.

European Union

The proposed COM(2026) 13 amendment is significant. Until now, PQC readiness under NIS2 required connecting interpretive dots. If adopted, the gap closes entirely and PQC migration becomes a named, mandatory obligation at the national level.

Allied and coalition networks

ACP 240, developed under the Combined Communications-Electronics Board (CCEB) within the Five Eyes (FVEY) alliance, is now adopted by the US Joint Chiefs of Staff and NATO partners. 

At its core is the Zero Trust Data Format (ZTDF): a model where security travels with the data itself, enforced at the object level, regardless of which network the data crosses. Security is not assumed from the perimeter. It is embedded in the data.

The implication for communications infrastructure is direct. A messaging platform that does not support quantum-resistant channels is already a planning liability in coalition environments where ACP 240 is the operational standard.

Why cloud platforms cannot fix this for you

If your organization runs communications on a cloud platform, here is the reality: the encryption layer is not yours.

TLS termination, the point where every encrypted session is negotiated, sits behind a managed load balancer operated by the vendor. 

• You cannot upgrade it. 
• You cannot audit it. 
• You cannot align it to your cryptographic roadmap. 
• Whatever post-quantum posture you need, you will get it when the vendor decides to ship it, on their timeline.

For organizations subject to CNSA 2.0, NIS2, or ACP 240 requirements, that is an unacceptable dependency. Compliance is tied to your cryptographic posture, not your vendor's future release notes.

Rocket.Chat's architecture is different by design.

Self-hosted, on-premise, and air-gapped deployments give your organization direct control over the TLS termination point. That control is what makes a post-quantum upgrade possible without waiting on anyone and without modifying the Rocket.Chat core codebase. The cryptographic upgrade happens at the NGINX layer. Rocket.Chat itself does not need to know.

How post-quantum protection works on Rocket.Chat today

The implementation sits at the NGINX reverse proxy layer, which already runs in most Rocket.Chat production deployments:

Client → [Post-Quantum TLS 1.3] → NGINX Reverse Proxy →
    [Internal HTTP/WS] → Rocket.Chat

Three components make this work:

liboqs (Open Quantum Safe) An open-source library implementing NIST-approved post-quantum algorithms, including ML-KEM. Fully auditable. No proprietary components between your organization and your key exchange.

oqs-provider A plugin for OpenSSL 3 that exposes liboqs algorithms to anything linking against OpenSSL, including NGINX.

Hybrid key exchange: x25519_kyber768 This combines classical X25519 elliptic-curve key exchange with ML-KEM-768. Hybrid is the responsible posture during a cryptographic transition:

• If a flaw is found in the post-quantum algorithm: classical security holds
• If a CRQC arrives: the post-quantum component holds
• Either way, the session is protected

The NGINX configuration to activate this:

server {
    listen 443 ssl http2;
    server_name chat.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/chat.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/chat.yourdomain.com/privkey.pem;

    ssl_protocols    TLSv1.3;
    ssl_ecdh_curve   x25519_kyber768;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Rocket.Chat's application-level environment configuration needs no changes:

environment:
  - PORT=3000
  - ROOT_URL=https://chat.yourdomain.com
  - MONGO_URL=mongodb://mongodb:27017/rocketchat
  - MONGO_OPLOG_URL=mongodb://mongodb:27017/local

Every message, file, voice call, and WebSocket session now travels over a post-quantum-protected channel, without touching a single line of application code.

Two checks confirm the deployment is working as intended.

From the server (using an OQS-linked OpenSSL build):

openssl s_client -connect chat.yourdomain.com:443 -groups
    x25519_kyber768

Look for Server Temp Key: X25519:Kyber768 in the output.

From the client: Chromium-based browsers, including the Rocket.Chat Desktop App, negotiate the hybrid group automatically when the server offers it. In Chrome, chrome://flags/#enable-tls13-kyber confirms the capability is active.

What makes it possible today: the architecture advantage

Rocket.Chat customers can act on post-quantum security ahead of most of the industry because of three architectural principles the platform has been built around from the start:

Open source. The cryptographic stack is inspectable end to end. liboqs, oqs-provider, the NGINX configuration: all of it is auditable. There are no black boxes between your organization and your key exchange. For defense and intelligence environments where supply chain trust is non-negotiable, this is not optional.

Self-hosted and sovereign. You own the TLS termination point. The upgrade is yours to make on your schedule, scoped to your environment, without vendor permission or dependency. This is the architectural property that makes everything else possible.

Standards-aligned. ML-KEM is the NIST-finalized algorithm referenced in CNSA 2.0, the EU's coordinated PQC roadmap, and national guidance from BSI and ANSSI. The same algorithm that federal procurement conversations are converging on is what Rocket.Chat deployments can implement today.

The window to act

The US expects new national security acquisitions to meet post-quantum requirements from 2027. The EU expects transitions to begin by end of 2026. ACP 240 is already the operational standard for coalition data sharing across FVEY and NATO networks.

For agencies and operators already running Rocket.Chat in classified, air-gapped, or hardened environments, this is the natural next step in the same trajectory: extending the security perimeter to cover not just today's adversaries, but the ones building capability for a decade from now. The infrastructure to act is in place. The standards are finalized. The threat is active.

Two ways to move forward

Get the implementation guide. A full step-by-step covering the liboqs and oqs-provider build, OpenSSL 3 configuration, NGINX compilation, and verification is available for security teams on request.

Map your transition. If your organization is planning a post-quantum transition and wants to understand how Rocket.Chat aligns to your cryptographic roadmap, whether that is CNSA 2.0, NIS2, DORA, or ACP 240, get in touch. We will connect you with the right engineers to scope it for your environment.

What comes next on our roadmap

Transport-layer protection is the right first step, and it is deployable today. 

Our roadmap is focused on extending post-quantum cryptography deeper into the platform:

• Application-layer end-to-end encryption using quantum-resistant key exchange, not just at the TLS boundary but within encrypted channels themselves
• Quantum-resistant key management for stored message encryption
• ACP 240-aligned deployments including ZTDF-compatible data handling for organizations operating across coalition environments

We are stating clearly that these are active engineering priorities. Organizations building multi-year cryptographic transition plans need to know which vendors are genuinely building in this direction; we are.