Skip to main content
Enigm handles lawful requests within the limits of its legal obligations, data minimization model, and technical architecture. This page is public guidance for enterprise customers, privacy reviewers, security auditors, and technical partners. It is not legal advice and does not publish internal legal procedures, escalation paths, verification workflows, internal tools, or operational playbooks.

​
Overview

Enigm is designed so that legal, administrative, operational, and server-management workflows do not become plaintext access paths. Enigm can only evaluate lawful requests against data that exists, is retained, is legally available, and is technically accessible within the Enigm architecture. Legal communications should be directed to legal@enigm.io. Legal request handling is guided by:
  • Lawful basis and appropriate authority.
  • Jurisdictional review.
  • Data minimization.
  • Purpose limitation.
  • User privacy.
  • Operational security.
  • Technical feasibility.
  • Content confidentiality.
Enigm does not create new data categories to satisfy requests that cannot be fulfilled from retained data.

​
Data Categories

Requests can involve different categories of data:
  • Account lifecycle data.
  • Device lifecycle data.
  • Session state.
  • Enigm Server membership and lifecycle state.
  • Enigm eSIM lifecycle state.
  • Enigm Key lifecycle state.
  • Security events.
  • Operational metadata.
  • Encrypted content objects.
  • Support, legal, or responsible disclosure records.
Availability depends on the applicable retention period, deletion state, legal constraints, and technical accessibility.

​
What Enigm Can Access

Where such data exists and is legally required, Enigm may be able to provide limited account, lifecycle, administrative, security, or operational metadata. Examples include:
  • Account state.
  • Device association state.
  • Session lifecycle state.
  • Enigm Server membership state.
  • Server-scoped encrypted content lifecycle state.
  • Enigm eSIM lifecycle state.
  • Enigm Key lifecycle state.
  • Security event categories.
  • Operational records retained for security, availability, abuse prevention, or compliance.
These categories are subject to data minimization, retention limits, legal review, and technical availability.

​
What Enigm Cannot Access

Enigm cannot provide data that it does not possess, does not retain, or cannot access in plaintext by design. Enigm cannot provide:
  • Plaintext message content when Enigm does not possess plaintext.
  • Plaintext attachments when Enigm does not possess plaintext.
  • Secure call content.
  • User conversation plaintext.
  • Private cryptographic keys.
  • Device-held private key material.
  • Plaintext recovery phrases.
  • Data deleted according to lifecycle policy, unless a valid preservation obligation applied before deletion.
Enigm cannot bypass end-to-end encryption through Enigm Command, Enigm Server administration, monitoring workflows, support workflows, or legal process workflows.

​
Technically Unavailable Data

Some requests are technically unavailable because the data is:
  • Not collected.
  • Not retained.
  • Deleted according to policy.
  • Not accessible in plaintext.
  • Encrypted without server-side plaintext access.
  • Held only on authorized endpoint devices.
  • Outside Enigm-controlled systems.
Data minimization can make some requested data unavailable even when a request is legally valid.

​
Encrypted Content

Encrypted content can include encrypted messages, encrypted attachments, encrypted multimedia, encrypted server-scoped content, and encrypted lifecycle objects. Encrypted content lifecycle control is not plaintext access. Enigm can manage encrypted content lifecycle state where authorized by product policy, legal obligation, or administrative authority. That does not mean Enigm can decrypt the content.

​
Administrative Boundaries

Administrative authority does not imply plaintext access. Enigm Command does not provide plaintext access to messages, attachments, secure calls, user conversations, or private keys. Administrative workflows can affect account state, device state, sessions, product lifecycle, server membership, policy, and encrypted content lifecycle. They must remain separate from end-to-end encryption and device-held protected key material.

​
Enigm Server Data

Enigm Server administrators can:
  • Manage server membership.
  • Invite users.
  • Remove users.
  • Approve or reject join requests.
  • Delete server-scoped encrypted content.
  • Delete encrypted messages and encrypted multimedia within the server environment.
  • Delete encrypted content belonging to a specific user within the server environment.
  • Delete the entire server environment.
Enigm Server administrators cannot read message plaintext, attachment plaintext, user communications, or private keys. Enigm Server administration is a lifecycle and availability capability, not a cryptographic authority.

​
Enigm eSIM Carrier Data

Enigm eSIM is provided through an independent telecommunications infrastructure provider. Enigm is not a mobile network operator, mobile virtual network operator, telecommunications carrier, radio access network operator, or direct issuer of the underlying carrier connectivity. Enigm does not operate the carrier network and does not receive carrier-layer traffic records as part of normal Enigm eSIM operation. Carrier-layer records that are not Enigm-held records include:
  • Mobile network traffic logs.
  • Carrier-side IP allocation records.
  • Radio access records.
  • Packet routing records.
  • Carrier connection records.
  • Carrier roaming records.
  • Carrier network usage records.
Enigm cannot provide carrier network traffic records, carrier IP allocation logs, carrier connection logs, carrier-side telecommunications records, or other data that is held only by an independent telecommunications infrastructure provider. Enigm can only evaluate lawful requests against Enigm-held lifecycle records, such as Enigm eSIM purchase state, entitlement state, Enigm account association, activation state, unlinking state, deletion state, and support records retained under the documented retention model. This boundary does not affect Enigm App content confidentiality. Enigm eSIM carrier connectivity and Enigm App end-to-end encryption are separate layers.

​
User Notification

Enigm does not currently provide a user-notification mechanism for legal requests. This limitation is documented so that users, customers, auditors, and partners do not infer a notification workflow that does not exist. Legal request handling remains governed by legal obligation, data minimization, technical availability, and content-confidentiality boundaries.

​
Transparency Reporting

Enigm publishes aggregated transparency information where legally permitted. Transparency reporting is designed to help users, customers, auditors, and partners understand request categories and outcomes without exposing individual users, sensitive legal details, or operational procedures.

​
Security Limitations

Legal process transparency improves accountability, but it does not eliminate all legal or operational risk. Limitations include:
  • Some requests can be legally restricted from disclosure.
  • Some data can be unavailable due to minimization or deletion.
  • Some metadata is necessary to operate the platform.
  • Legal outcomes can vary by jurisdiction and request type.
  • Public documentation cannot describe internal legal procedures.