Security
Trust by design. Verifiable in code.
New Journey is built on RFC 9420 Messaging Layer Security and an open architecture you can audit. We do not ask you to take our word for it — read the protocol, read the code.
End-to-end encryption
OpenMLS, RFC 9420, one group per channel
Messaging Layer Security, in production
Every Channel in New Journey maps to one MLS group. Messages, presence, and CRDT updates ride inside MLS application messages, encrypted client-side before they ever touch our infrastructure. The same family of protocols underpins iMessage, Signal, and Wire — we did not invent the cryptography, we use the standard.
Forward secrecy
Each epoch derives fresh keys. Compromise of today's keys cannot decrypt yesterday's messages — past traffic stays sealed even if a device is later breached.
Post-compromise security
Key rotation on every membership change recovers from device compromise. Removing a member or rekeying re-establishes confidentiality on the next epoch.
Group-scale by design
MLS uses a TreeKEM ratchet so groups of thousands stay efficient. The same protocol family powers Signal, iMessage, Wire, and Webex deployments.
Open implementation
We use OpenMLS, an audited Rust implementation of the IETF standard. The broker only sees ciphertext and routing metadata — never plaintext.
Threat model
What we defend against — and what we don't
An honest security page lists both columns — what we defend against today and what we have not yet covered.
If our servers are seized or breached, the attacker sees ciphertext and routing metadata only. Message content, file bodies, and CRDT state are sealed by MLS keys held on devices.
TLS 1.3 protects every connection on the wire. MLS encrypts the payload end-to-end on top. A passive or active network attacker observes neither plaintext nor message structure.
Local stores are encrypted at rest with a device-derived key bound to the OS keychain or secure enclave. A locked, stolen device does not leak content.
If an attacker controls a signed-in device, they have the user's keys. No application-layer protocol can defend against this. Use OS-level controls, MDM, and endpoint detection.
A device handed over while unlocked exposes session keys. Forward secrecy still protects past epochs after the user removes the device, but live state on that device is reachable.
We enforce a minimum entropy on user passphrases and recommend hardware-backed passkeys. We cannot guarantee a user will not be tricked or coerced. Train your team accordingly.
Compliance
Compliance roadmap
Where we are, and where we have committed to be.
In progress. Type I report targeted Q3 2026, Type II Q1 2027. Auditor selection complete; controls mapped to the AICPA Trust Services Criteria.
Compliant by architecture. Data minimization, EU residency option, and end-to-end encryption mean we hold the minimum necessary. DPA available on request.
BAA available on the Enterprise plan. Architecture supports the technical safeguards required for covered entities and business associates.
Planned post-SOC 2. ISMS scaffolding shares controls with the SOC 2 program; certification follows once Type II is complete.
Data residency
EU, US, or your own infrastructure
Choose a region at signup
Data residency is a workspace-level decision made at signup. The choice pins your workspace to a region and is enforced at the database, object-store, and broker layers. Enterprise customers can step out of our hosted regions entirely and deploy on infrastructure they control.
Hosted EU region
Frankfurt-anchored deployment for customers who need data and processing to remain inside the European Economic Area.
Hosted US region
us-east deployment for North-American customers and teams with regional latency requirements.
Enterprise self-host
Run the entire stack on your own infrastructure with the Pulumi modules in /infra/enterprise. You own the keys, the database, and the audit trail.
Vulnerability disclosure
Tell us first. We'll thank you publicly.
Coordinated disclosure
We run a standard responsible-disclosure program. If you find a security issue in New Journey — in our hosted services, our open-source code, or our infrastructure — please tell us before you tell the world. We will work the fix, credit you, and ship it.
security@newjourney
Send reports to security@newjourney. PGP key on request. We acknowledge within two business days and triage within five.
90-day disclosure window
We commit to fixing or mitigating reported issues within 90 days of confirmation. Researchers may publish after that window — earlier by mutual agreement.
Researcher acknowledgment
With your permission, we credit researchers in release notes and on a public hall of fame. We do not pursue legal action against good-faith research within this policy.
Have specific questions? Talk to security.
Architecture review, threat-model walkthrough, DPA, BAA, audit reports — bring the questions, we'll bring the protocol diagrams.