Enterprise security & complianceComing soon

Built to be checked.

How LMN8 Enterprise protects your organisation, what your team can verify, and where each certification stands.

Get early access Trust centre

Where each piece stands8 NOV 2026

Post-quantum encryption · shared engine: In place
Admin device approval: Coming soon
Signed policies: Coming soon
Tamper-evident audit + SIEM export: Coming soon
DPDP grievance flow: Coming soon
Certifications: Planned

Architecture in plain words

Three guarantees, one picture.

01DevicesKeys made here. Policies verified here.

02LMN8 serversEncrypted data, public keys, who and when. No content keys.

03Your systemsSIEM, identity provider, directory.

01
Content is encrypted on devices with keys we never hold.
02
Every policy and approval is signed by your organisation and checked by each device.
03
The log is append-only; your SIEM receives what was logged, signed.

Identity and devices

Every device is approved by an admin.

Sign-in by SSO (OIDC), passkey, one-time code or password.
A new device gets the organisation’s keys only after an admin approves it.
Admin and member compare a short code; the approval is signed.
Seats are devices: a laptop and a phone are two seats.

Company-owned and BYOD, side by side
Company-owned and BYOD, side by side	Company-owned	BYOD
Who owns the data	Everything on the device	Only its own data, in its Cloud
Where org data lives	On the device and in the Cloud	In the Cloud only
Download, export	Per policy	Not allowed
Copy-paste and screenshots	Per policy	Not allowed
Browse local drives remotely	Yes	No
Wipe	The whole device	The organisation’s data only
Location	Always on	Off
Personal LMN8 alongside	Not allowed	Allowed

Policies and roles

Signed, versioned, verified.

Every behaviour is a policy with a default, set in an onboarding wizard.
Each published version is signed with the organisation’s key and checked by devices before it is followed.
Roles from templates (Super admin, Admin, Compliance, IT, Manager, Member, Contractor) or fully custom; permissions further limited by device type.
Removing a super admin needs a second super admin.
Approvals routed by request type with configurable approver counts; unhandled requests expire (7 days by default).

Super admin
Admin
Compliance
IT
Manager
Member
Contractor

Data, Drive and sharing

Encrypted before it leaves a device.

Drive is a shared encrypted Cloud with folders per organisation, team and person; versions kept by policy.
External shares need approval (or an approved domain), view-only, watermark, expiry, view limits, revoke.
Visible watermark on every shared file; an invisible, signature-based mark for images, video and PDF is being built.Coming soon
Regions by contract; BYO storage or keys case by case.

Audit and SIEM

A log that shows its own tampering.

Every action logged, scope adjustable; changes to the scope are logged and can’t be hidden.
Append-only, each entry chained to the previous, signed checkpoints.
Export as CEF, Splunk HEC or JSON, signed, with a manifest.
Retention and visibility by policy.

Deletion with proof

Erasure you can hand to an auditor.

Admins can Zero any company device; BYOD only the organisation’s data.
Leaver flows; lost device = Zero triggered by an admin.
Every Zero produces a signed certificate, verifiable at /verify.
The CLI produces the same certificate for grievance erasure and links it to the request.

Verify a certificate

Compliance

DPDP, CERT-In, and what we don’t claim.

DPDP Act 2023 and Rules 2025

Coming soon

A linked grievance mailbox (Google Workspace, Microsoft 365 or IMAP), a public request form at <company>.lmn8.app/grievance, triage, escalation, erasure with certificate, closure with proof. Most obligations start 13 May 2027; deadline tracking and statutory reports are being detailed.

CERT-In directions

In preparation

Reporting qualifying incidents within six hours and keeping the logs the directions ask for, for 180 days, for our own systems.

Certifications

We publish each step as it happens; a report is shared under NDA once it exists.

SOC 2 Type I, then Type II: An independent auditor checks our security controls at a point in time, then over months of operation.; Planned
ISO/IEC 27001: An information security management system, checked by an accredited body and audited every year.; Planned
ISO/IEC 27701: Privacy management on top of ISO 27001, mapped to the DPDP Act and GDPR.; Planned
ISO/IEC 27017 and 27018: Extra controls for cloud services and for protecting personal data in the cloud.; Planned
CSA STAR: A public, Cloud Security Alliance listing of our cloud controls, starting with a self-assessment.; Planned
CERT-In empanelled penetration test: Independent penetration testing of our apps and servers, with a summary on request.; Planned
FIPS 140-3 validation: A formal certificate for LMN8’s encryption module, issued after an accredited lab tests it. LMN8 already uses the NIST-standard algorithms it covers; the lab certification is the next step.; Planned
Cyber Essentials (UK): A UK government-backed baseline for organisations buying in the UK.; Planned

What we don’t claim

Using LMN8 does not make an organisation compliant.
Certifications are planned; none is held today.
CNSA 2.0 is the algorithm standard we follow, not an approval.

Still classical

What is still classical.

We publish the register of what is still classical and when each item goes.

Trust centre

01CNSA 2.0 is the algorithm standard LMN8 follows. Following it is not a certification and doesn’t imply NSA approval; the FIPS 140-3 lab certificate for our module is planned.
02Connections mix a post-quantum key exchange with a classical one, and public web certificates are classical.
03Device certificates on connections are checked in observe mode for now: a connection without one is still accepted.
04Some signatures are still classical (Ed25519) beside ML-DSA-87: the public key log, and app updates where the download page shows both.
05File transfers to storage use the storage provider’s TLS, at best a hybrid with ML-KEM-768. What travels there is already encrypted with ML-KEM-1024 and AES-256-GCM.
06Calls travel inside WebRTC’s DTLS-SRTP, which is classical. The post-quantum layer is SFrame inside it.
07Sign in with your provider (OIDC) relies on that provider’s classical signatures. It only signs you in; it never carries your keys.

Roadmap, honestly

Where each piece stands.

Enterprise cluster and apps: Coming soon
SAML single sign-on: Planned
MDM integration (Intune, Jamf, Google): Deciding
Steganographic watermarking: Planned
Call recording agent: Planned
External key-transparency witnesses: Planned

Bring this to your next review.

LMN8 Enterprise is coming soon. Early access walks your team through every section above.

Get early access Trust centre