> ## Documentation Index > Fetch the complete documentation index at: https://docs.enigm.io/llms.txt > Use this file to discover all available pages before exploring further. # Data Retention > Public data retention and data minimization model for Enigm. Enigm is designed around data minimization and purpose-limited retention. The platform should collect and retain only the information required to operate platform services, maintain security functions, support compliance obligations, and protect users. Enigm uses an identity-minimizing account model for standard registration through Enigm Command. Standard Enigm account creation does not require an email address, phone number, or identity document. Data handled by Enigm is encrypted at rest according to the applicable product, storage, and security domain. Encryption at rest does not replace end-to-end encryption, Device Trust, access control, retention limits, or deletion workflows. Enigm's core platform infrastructure is operated under Enigm's Swiss subsidiary and Swiss legal governance. Enigm Server dedicated customer environments are deployed in the user-selected public region category and remain distinct from the Enigm core platform. For processing activities involving users in the European Union, Enigm is designed to align with GDPR/RGPD principles including data minimization, purpose limitation, storage limitation, integrity, confidentiality, and accountability. ## Overview The Enigm data retention model is aligned with the Enigm Privacy Model. Retention decisions are guided by: * Data minimization. * Purpose limitation. * Security requirements. * Operational requirements. * Legal or contractual obligations. * Risk reduction. Legal inquiries related to retention may be directed to [legal@enigm.io](mailto:legal@enigm.io). ## Data Minimization Enigm is designed around collecting and retaining only the information required to operate platform services and security functions. Data minimization means: * Avoid collecting unnecessary data. * Retain data only for defined purposes. * Limit access to authorized workflows. * Reduce unnecessary identity metadata where possible. * Separate security visibility from message confidentiality. * Encrypt data at rest according to the applicable product and storage domain. ## Jurisdiction And Legal Governance Enigm's core platform infrastructure is operated under Enigm's Swiss subsidiary and Swiss legal governance. This includes Enigm-held customer records, account lifecycle services, platform APIs, public web surfaces, and supporting internal platform services. Server region selection for Enigm Server is a product and deployment control for dedicated customer server environments. Enigm Server dedicated customer environments are deployed in the user-selected public region category, currently United States, Europe, or Asia, and are distinct from the Enigm core platform. Legal governance does not create plaintext access to protected communications. Enigm Command, Enigm Server administration, operational workflows, and legal workflows must remain separate from message plaintext, attachment plaintext, secure call content, user conversations, and private key material. For EU-related processing, Enigm's retention model is designed to support GDPR/RGPD principles through purpose limitation, minimized retention, encryption, deletion workflows, and documented retention categories. ## Standard Registration Data Standard Enigm account registration is designed to avoid unnecessary public identifiers. Standard registration does not require: * Email address. * Phone number. * Identity document. The account model is pseudonymous and identity-minimizing, not an absolute identity-erasure claim. Account activity, device state, payment records, security events, legal obligations, or user behavior can still create exposure outside the normal registration model. ## Retention Matrix The following table summarizes the public retention model for major Enigm data categories. | Data Category | Examples | Retention Model | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account identity state | Username, account status, account creation state, recovery boundary state, account deletion state | Retained for the duration of the service relationship. Removed from normal service operation when the user deletes the account, subject only to legal, security, compliance, accounting, or valid preservation constraints. | | Authentication material | Password verification material, server-side PIN verification state, recovery-related state, excluding plaintext passwords, plaintext PINs, or plaintext recovery phrases | Retained while the account exists. Removed from normal service operation when the user deletes the account, subject only to legal, security, compliance, accounting, or valid preservation constraints. Plaintext passwords, plaintext PINs, and plaintext recovery phrases must not be retained. | | Device state | Trusted device list, enrollment state, revocation state, replacement state, Privacy-Preserving Device Handles, Device Trust status, optional Enigm OS trust signals | Retained until the user removes the device, deletes the account, or the lifecycle state is no longer required. Device deletion removes the associated device state from normal operation. | | Session state | Active sessions, session creation state, last activity state, termination state | Enigm App sessions use a 1-hour validity window and are automatically renewed while eligible. Enigm Command sessions are limited to 6 hours. Session lifecycle records are minimized and retained only as required for security, abuse prevention, or operational review. | | PIN and profile risk state | PIN validation outcomes, reverse PIN event state, repeated incorrect PIN risk state, profile risk status | Retained only as required to enforce account security, show current risk state, support auditability, and clear the risk state after successful PIN validation. Plaintext PIN values must not be retained. | | Profile security level | Low, Medium, High, or Extreme profile security level and the underlying account configuration signals required to display it | Retained while the account exists or until the user changes the relevant security configuration. | | Message content | Encrypted messages, encrypted attachments, encrypted multimedia | User-defined message lifetime up to a maximum of 30 days. Users can manually delete messages immediately. Server-side storage, where required, stores encrypted content only. | | Message metadata | Delivery state, synchronization state, expiration state, conversation membership, lifecycle markers | Partially encrypted and otherwise protected according to the applicable product and storage domain. Follows the message lifecycle where possible, with a maximum of 30 days for normal message-related lifecycle state unless security, abuse, or legal constraints require limited preservation. | | Enigm Server lifecycle data | Server lifecycle state, server ID join requests, membership, region selection, server audit visibility | Retained while the user or customer maintains the Enigm Server service. Deleted when the user or customer deletes the server environment, subject only to legal, security, or compliance constraints. | | Enigm Server content | Server-scoped encrypted messages, encrypted attachments, encrypted multimedia, encrypted user-generated content | Follows the message-content retention model: user-defined lifetime up to a maximum of 30 days, with immediate manual deletion where authorized by policy. | | Enigm Link lifecycle data | Official USB association, product entitlement, update channel, version state, official device validation state, revocation, replacement or retirement state | Retained while the user maintains Enigm Link service or until the lifecycle state is no longer required, subject only to legal, security, support, or operational constraints. | | Enigm Key emergency data | Emergency alert messages, emergency contacts, emergency activation event, event-bound location sharing, emergency event end state | Treated as message and emergency-event data. Retained according to the message lifecycle, up to a maximum of 30 days, and minimized after the user cancels the emergency sending workflow. | | Enigm Key device lifecycle data | Account association, initial linking state, device revocation state, loss state, replacement state | Retained until the user removes or revokes the Enigm Key, deletes the account, or the lifecycle state is no longer required, subject only to legal, security, or operational constraints. | | Enigm eSIM data | Activation state, Enigm account association, connectivity lifecycle state, service status metadata, unlinking, deletion, replacement or retirement state | Retained until the user deletes or retires the Enigm eSIM service, subject only to legal, security, or operational constraints. | | Security data | Authentication events, Device Trust events, runtime protection findings, Active Defense findings, Enigm Intelligence events, incident records, defensive action records | Retained for a maximum of 30 days for normal security operations unless an active investigation, legal obligation, or security requirement requires preservation. | | Operational data | Service health events, error logs, availability logs, abuse prevention records, rate-limit events, security-control events | Anonymized where possible and retained for a maximum of 30 days for normal operations. | | Payment data | Payment status, subscription state, entitlement state, payment method category, purchase country selected by the user, transaction reference, Code Coin redemption state, invoice or accounting records when requested | Retained for the duration of the user service relationship and according to applicable legal, accounting, tax, abuse-prevention, and security obligations. Standard payment enrollment does not require email address, phone number, or identity document collection. | | Training data | Essential or advanced training state, final-exam completion state, product education progress | Retained while required for account education, product guidance, support, enterprise review, or user-requested deletion, subject to legal, security, compliance, or operational constraints. | | Support and legal data | Support requests, legal inquiries, security disclosure reports, responsible disclosure communications, enterprise security inquiries | Retained for 30 days after the case is closed, unless legal, security, compliance, or contractual obligations require preservation. | ## Account Data Account data may include information required to operate account and identity workflows. Conceptual examples include: * Account state. * Device associations. * Security state. * Administrative metadata. Account data supports identity lifecycle, device association, access control, account recovery boundaries, and security review. Account data is retained for the duration of the service relationship and removed from normal service operation when the user deletes the account, subject only to legal, security, compliance, accounting, or valid preservation constraints. ## Security Data Security monitoring may require limited retention of security-relevant events. Security data may support: * Threat detection. * Risk assessment. * Security investigation. * Incident response. * Defensive response. * App runtime integrity review. * Auditability of security-relevant decisions. Retention should be proportional to operational and security requirements. Security data should not be used as a substitute for message content access. Normal security data retention is limited to a maximum of 30 days unless an active investigation, legal obligation, or security requirement requires preservation. ## Metadata And Operational Identifiers Enigm treats metadata as security-sensitive information. Metadata is partially encrypted according to the applicable product, storage, and security domain, and otherwise protected through access control, purpose limitation, retention limits, and separation from protected content. Metadata is not treated as unrestricted plaintext operational data. Some identifiers remain necessary to operate the platform. These include session identifiers, Privacy-Preserving Device Handles, delivery and synchronization state, server membership state, join request state, connectivity lifecycle state, security event correlation state, and short-lived routing or request-handling identifiers. Operational identifiers are used to provide routing, authentication, availability, abuse prevention, security monitoring, lifecycle control, and compliance support. They are minimized, purpose-limited, access-controlled, partially encrypted according to the relevant product or storage domain, and retained according to the documented retention model. Connection metadata, such as limited connection source information, authentication event state, request timing, rate-limit events, and security-control events, is treated as operational or security metadata. It must remain separated from message plaintext, attachment plaintext, secure call content, media, user conversations, and private key material. ## Device Data Device management and trust systems may require device-related state information. Device data may include: * Device association state. * Trust state. * Security posture. * Managed device state where enabled. * Device lifecycle status. Device data supports trusted device workflows, Trust Security Center visibility, managed device operations where enabled, and security review. Device data is retained until the user removes the device, deletes the account, or the lifecycle state is no longer required. ## Enigm Server Data Enigm Server data may include limited state required to operate dedicated private messaging environments. Conceptual examples include: * Server lifecycle state. * Invitation lifecycle state. * Server membership state. * Geographic deployment region selection. * Server-scoped content lifecycle state. * Server audit visibility where appropriate. Enigm Server retention should remain purpose-limited. Server-scoped lifecycle controls should manage encrypted content availability and deletion according to policy without creating administrative access to message plaintext, attachment plaintext, user communications, private key material, or cryptographic authority. Administrative deletion controls operate on encrypted content objects and lifecycle state. Deletion affects content availability and lifecycle; it does not imply content visibility or content decryption. Enigm Server lifecycle data is retained while the user or customer maintains the server environment. Server-scoped encrypted content follows the message-content retention model unless deleted earlier by the user or authorized server lifecycle controls. ## Enigm Link Data Enigm Link data supports the official USB product lifecycle governed through Enigm Command. Conceptual examples include: * Official USB association state. * Product entitlement state. * Update channel and version state. * Official device validation state. * Revocation, replacement, or retirement state. * Support state required to maintain the product lifecycle. Enigm Link lifecycle data is product and device lifecycle data. It does not provide Enigm with access to Enigm Command plaintext data, message plaintext, secure call content, attachments, private key material, recovery phrases, local host files, or protected browser session content. Enigm Link lifecycle data is retained while the user maintains Enigm Link service or until the lifecycle state is no longer required, subject only to legal, security, support, or operational constraints. ## Enigm Key Data Enigm Key emergency data is treated as event-bound emergency communication data. Conceptual examples include: * Initial linking state. * Account association state. * Emergency contact configuration. * Emergency activation event. * Emergency alert messages. * Event-bound location sharing during the emergency workflow. * Emergency event end state. * Enigm Key revocation, loss, or replacement state. Emergency alert messages and event-bound emergency data follow the message lifecycle model, with a maximum retention of 30 days unless the user deletes them earlier or a legal or security constraint requires preservation. Enigm Key device lifecycle data is retained until the user removes or revokes the device, deletes the account, or the lifecycle state is no longer required. Enigm Key is not documented as a continuous tracking system. Emergency location sharing continues only during the active emergency workflow and until the user cancels the emergency sending workflow. Emergency location data should be minimized after the user cancels the emergency sending workflow. ## Enigm eSIM Data Enigm eSIM data supports private mobile data connectivity lifecycle workflows. Conceptual examples include: * Activation state. * Enigm account association. * Connectivity lifecycle state. * Plan or status metadata. * Unlinking state. * Deletion state. * Replacement or retirement state. Enigm eSIM data is retained until the user deletes or retires the Enigm eSIM service, subject only to legal, security, or operational constraints. The Enigm-side eSIM purchase and lifecycle-management workflow does not collect KYC verification, email address, phone number, or identity document. Enigm eSIM lifecycle data should remain limited to connectivity operation, account association, entitlement, support, and security needs. Enigm eSIM relies on an independent telecommunications infrastructure provider for carrier-layer mobile data connectivity. 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. Carrier-layer traffic records, carrier-side IP allocation records, radio access records, packet routing records, carrier connection records, carrier roaming records, and carrier network usage records are not Enigm-held retention categories when they are generated or retained by the independent telecommunications infrastructure provider. Enigm cannot retain, delete, export, or disclose carrier-layer telecommunications records that it does not receive or control. Enigm-held eSIM retention is limited to Enigm eSIM lifecycle, entitlement, Enigm account association, deletion, support, and security records described in this document. ## Operational Data Operational services may require limited retention for reliability, abuse prevention, and security. Operational data may support: * Service reliability. * Abuse prevention. * Fraud prevention. * Security monitoring. * Incident response. * Compliance obligations. Operational data should be scoped to defined service and security purposes. Operational data should be anonymized where possible and retained for a maximum of 30 days for normal operations. ## Payment Data Payment data supports service entitlement, subscription state, accounting, abuse prevention, and security obligations. Conceptual examples include: * Payment status. * Subscription or entitlement state. * Payment method category. * Purchase country selected by the user. * Transaction reference. * Code Coin redemption state. * Invoice or accounting records when requested. Payment data is retained for the duration of the user service relationship and according to applicable legal, accounting, tax, abuse-prevention, and security obligations. Payment data should remain separate from message content, call content, media, attachments, user conversations, private key material, and Device Trust secrets. Standard payment enrollment does not require email address, phone number, or identity document collection. ## Support And Legal Data Support and legal data supports user support, enterprise security review, legal inquiries, and responsible disclosure handling. Conceptual examples include: * Support requests. * Legal inquiries. * Security disclosure reports. * Responsible disclosure communications. * Enterprise security inquiries. Support and legal data is retained for 30 days after the case is closed, unless legal, security, compliance, or contractual obligations require preservation. ## Retention Principles Retention is guided by: * Least retention. * Purpose limitation. * Risk reduction. * Security requirements. * Operational necessity. * Legal and contractual requirements. Retention periods should be defined according to the purpose of the data, the risk profile, and applicable obligations. ## Deletion Principles Data should be deleted when no longer required for operational, security, or legal purposes. Deletion principles include: * Remove data after its defined purpose expires. * Preserve only what is required for security, compliance, or legal obligations. * Avoid retaining unnecessary identity or device metadata. * Apply deletion workflows consistently. Deletion may be constrained by security investigations, legal obligations, abuse prevention, or required operational records. User-to-user deletion can be scoped to the requesting user or applied for all participants where policy allows. In group conversations, administrators can delete protected content according to group policy, and users can delete their own messages when group permissions allow. For deletion and retention purposes, message content includes text messages, voice messages, call records, encrypted files, images, videos, multimedia, attachments, and related protected conversation objects unless a product page defines a narrower category. See [Platform Limitations](/legal/limitations).