Hard questions, honest answers

TLS — including Cloudflare's post-quantum TLS — encrypts the channel between two network hops. The moment your HTTPS request hits a CDN edge node, a load balancer, or your own origin server, TLS terminates and the payload is plaintext. That plaintext is then written to logs, stored in a database, forwarded to a third-party API, and held in cloud-provider memory.

Nen encrypts the payload — the JSON body — end-to-end between the two application endpoints that actually need the data. TLS termination, CDN inspection, log pipelines, multi-tenant databases, and internal proxies all see ciphertext only. Cloudflare cannot offer this because it is the TLS terminator.

The short version: TLS + Nen, not TLS or Nen.

Nation-state adversaries and well-funded criminal groups are currently recording encrypted traffic in bulk. The bet: a cryptographically-relevant quantum computer will arrive within 10–15 years and retroactively decrypt everything collected today. This is not speculative — NSA and CISA advisories from 2022–2024 explicitly name it as an active collection strategy.

For most data this is irrelevant. For financial records, medical histories, legal communications, and AI prompts containing PII, a 10-year exposure window is catastrophically long. The time to encrypt under ML-KEM is before the data leaves your app — which is now, not when quantum computers ship.

Nen protects the payload in transit between two application endpoints. Every hop in between — CDN, load balancer, log pipeline, database, third-party API, multi-tenant infrastructure — sees only ciphertext.

Nen does not protect against:

• A fully compromised browser or runtime environment
• XSS that executes in the same origin
• Stolen session tokens (rotate frequently; use short TTLs)
• Malicious endpoint logic — the endpoint decrypts by design
• The model provider seeing your AI prompts (inference needs plaintext)

The threat model is published in full at /docs/threat-model.

ML-KEM is FIPS 203, finalized by NIST in August 2024 after an eight-year public competition and multiple independent cryptanalysis rounds. It is as battle-tested as any standard gets before widespread deployment.

Even if a theoretical weakness were found in ML-KEM, Nen's architecture limits the blast radius: the shared secret is used as a ChaCha20-Poly1305 key, and every session has forward secrecy via key rotation. A compromised session key does not compromise past sessions. The symmetric cipher (ChaCha20-Poly1305) is independent of ML-KEM and is not quantum-vulnerable at any practical key size.

We follow NIST advisories. If a parameter-set downgrade is recommended, the session handshake version field allows a clean protocol upgrade without breaking the wire format.

The platform threat is real and worth naming honestly. Our answer is three-part:

1. Platform middleware enforces your trust in the platform. If your payload is encrypted at the Cloudflare Worker or Vercel Edge Function layer, Vercel and Cloudflare hold the keys. Nen keeps keys at your application endpoints — the only two parties that need the data.
2. Next.js-first, but not Vercel-only. Nen runs on any Node.js or Edge runtime: Fly.io, Railway, AWS Lambda, bare VMs. A platform-native solution creates lock-in; Nen does not.
3. The SDK moat compounds over time. Dev experience, compliance artifacts, audit-ready documentation, and the session management layer are not things a CDN middleware ships. The cipher is a commodity; the platform is not.

You can — and for a security-focused team, reading the FIPS 203 spec is a reasonable exercise. The problem is the layer above the cipher: session management, nonce tracking, replay prevention, HMAC-authenticated requests, key rotation, error handling, and a wire format that survives load balancers and CDNs.

Each of those pieces has well-known failure modes. The session store must be shared across instances (InMemory fails in multi-node deployments). The HMAC canonical string must cover the right fields (missing the path means a path-swap attack). Nonces must be tracked per-session, not globally. Key rotation must not disrupt in-flight requests.

Nen ships the cipher plus the protocol — tested, documented, and auditable as a unit. The alternative is building and auditing each piece yourself and getting the integration right under production load.

mTLS encrypts the transport channel between services — which is great. But it still terminates at each service boundary. The JSON body that your API service writes to PostgreSQL, passes to an analytics pipeline, or forwards to an LLM provider is plaintext from the moment it arrives at that service.

Nen is orthogonal to mTLS: use both. mTLS secures the internal channels; Nen ensures the payload itself stays ciphertext across every log line, database row, and third-party call that originates from those services.

No regulation names ML-KEM by algorithm today — and that's not the right frame. The right question is: which regulations impose a forward-looking adequacy standard?

• HIPAArequires "reasonable and appropriate" technical safeguards. An OCR auditor asking about your encryption posture in 2026, after NIST published FIPS 203, has a higher adequacy bar than in 2020.
• NIST SP 800-131A Rev 3 (2024) explicitly disallows RSA and ECDH for new key establishment after 2030 and recommends transitioning to ML-KEM now. FedRAMP systems must comply.
• NSA CNSA 2.0 mandates ML-KEM for National Security Systems by 2030; new systems should use it now.
• EU NIS2 Directive (2024) requires state-of-the-art cryptographic measures for operators of essential services.

More practically: if your security team fills out a vendor questionnaire that asks "Are you PQC-ready?" the answer should be yes and demonstrable. Nen provides the demonstrable part — a signed audit artifact showing which endpoints encrypted payloads with ML-KEM-768 and when.

Nen does not route traffic through any Nen-operated infrastructure — there is no relay, no proxy, no SaaS middleman. The payload goes directly from your client to your server. Session state (the encrypted shared secret and nonce cache) lives in whichever store you choose: InMemorySessionStore, RedisSessionStore, or UpstashSessionStore.

If your Redis is in Frankfurt, your session keys are in Frankfurt. Nen inherits your existing data-residency posture rather than adding a new jurisdiction.

The handshake is the expensive step: one ML-KEM key generation + encapsulation. On a modern CPU, ML-KEM-768 key generation takes ~70µs and encapsulation ~90µs — total handshake crypto under 200µs, dominated by the network round trip to /api/nen/handshake. The handshake happens once per session (not per request).

Per request: ChaCha20-Poly1305 encryption + HMAC-SHA256. ChaCha20 benchmarks at ~3 GB/s on a single core; for a 10 KB JSON payload that is under 5µs. HMAC-SHA256 over the canonical string (method + path + timestamp + nonce, typically under 200 bytes) is under 1µs. Total per-request crypto overhead: under 10µs for payloads up to ~100 KB.

The Wasm binary (~120 KB gzipped) is loaded once at startup, not per request. Session store lookups (Redis/Upstash) add one network call per request — the same trade-off as any authenticated session system.

Session state per request is a single key-value lookup in your store — the same cost as reading a JWT signing key or session cookie from Redis. If you're running 10,000 RPS, you're already doing this.

The nonce cache (for replay prevention) is the only unbounded structure, and it is scoped per session with a 30-second window. The store evicts nonces when the session is rotated or terminated. High-frequency streaming is served by withNenStream, which issues one nonce per stream rather than per chunk.

If your API makes 100 encrypted calls per second per client, the overhead is 100 Redis reads + 100 ChaCha20 encrypt/decrypt cycles. For most applications the session store latency is the dominant cost, and it is shared with your existing auth layer.

client.rotate() calls /api/nen/rotate, which atomically creates a new session entry and marks the old one for immediate expiry on the server. The client then atomically swaps its internal session to the new keys.

Requests that were in flight at the moment of rotation with the old session ID will get an ISO-2002 (session invalid) response from the server. The client SDK retries those automatically with the new session. This is a one-time hiccup of at most one RPC per in-flight request at rotation time.

The SDK is open-source and always will be. What you pay for is the layer that makes it production-grade for a security-conscious organization:

• Cloud dashboard: session telemetry, rotation history, error tracking, and alert thresholds across all your endpoints.
• Audit logs: cryptographic proof that endpoint X encrypted payloads with ML-KEM-768 between date A and date B — the artifact an auditor needs.
• Enterprise controls: KMS/HSM integration, SAML SSO, role-based access, SLA-backed support, signed compliance attestations.

The open-source strategy is deliberate: adoption earns trust; trust earns the enterprise conversation. A CISO who already has the SDK running in production needs a purchase order for the compliance artifact, not a proof-of-concept.

The SDK is MIT-licensed on GitHub. If Nen disappears, you own the code and the protocol spec (published in PROTOCOL.md). You can fork, self-host, and maintain it indefinitely. There is no phone-home, no activation key, no usage metering in the SDK itself.

The paid cloud dashboard is the only component that depends on Nen infrastructure. Enterprise customers receive a data-export SLA and a 12-month wind-down window in their contract — audit logs are exportable at any time in a structured format.

ML-KEM-768 is FIPS 203 — a finalized federal standard, not a research paper. The RustCrypto crates Nen uses (ml-kem, chacha20poly1305) have been in use in production systems since 2022 and are maintained by the same community that maintains ring and rustls.

The question is not "is the crypto ready?" — it is. The question is "what is the cost of waiting?" Every payload transmitted under RSA or ECDH today is a harvest candidate. Regulations are moving faster than most engineering roadmaps. The organizations that wait for a "mature ecosystem" are the ones who will face the first enforcement actions.

Yes — the model provider (OpenAI, Anthropic, etc.) receives plaintext prompts and returns plaintext tokens. That is unavoidable: inference requires plaintext.

What Nen protects is the path from the browser to your backend: the prompt that a user types into your SaaS product, the context your app appends, and the streamed response tokens on the way back. Without Nen, that data is plaintext across your CDN, load balancer, application log, and any internal proxy between your Next.js server and your users.

The trust boundary: browser ↔ your backend is encrypted by Nen. your backend ↔ model provider is TLS only (Nen does not and cannot encrypt that hop). For FinTech, Healthcare, and Legal AI products handling PII or privileged information, the browser-to-backend leg is where the exposure lives today.

Nen encrypts between your browser client and your Next.js backend server — it does not touch the hop from your backend to the AI gateway. Your backend decrypts the prompt, calls the gateway (over TLS), and encrypts the streamed response before sending it back to the browser.

Your AI gateway sees plaintext prompts exactly as it does today. Nen adds E2EE on the user-facing leg; it is orthogonal to whatever infrastructure you have between your backend and the model provider.