Privacy Model

The Enigm privacy model applies across Enigm App, Enigm OS, Enigm Command, Trust Security Center, VPN Network, Proxy Network, Tor Gateway, Threat Intelligence Platform, Enyra, and OTA Architecture. The model is based on data minimization, purpose limitation, scoped access, privacy-preserving device handles, retention control, metadata reduction, and auditable handling of security-relevant data.

​

Objectives

• Limit collection to defined product, security, support, and compliance purposes.
• Separate account identity, privacy-preserving device handles, metadata, protected content, security telemetry, and audit records where applicable.
• Avoid using stable human-readable device identifiers in public documentation or examples.
• Restrict access through the secure identity layer and Enigm Command authorization.
• Avoid exposing protected content or unnecessary identity metadata in logs, examples, or public documentation.
• Retain records only according to documented policy and applicable obligations.
• Support enterprise review without disclosing non-public operational detail.

​

Data categories

​

Account and app data

Enigm App account data supports authentication, authorization, account lifecycle, secure messaging, secure calls, and multi-device management. Protected content should remain separate from operational metadata where applicable.

​

Privacy-preserving device handles

Privacy-preserving device handles support controlled device management, policy assignment, audit correlation, OTA eligibility, and Remote Attestation without requiring public exposure of direct device identifiers. They are intended to reduce dependence on public identifiers while preserving authorized lifecycle and security review.

​

Enigm OS security state

Enigm OS security state includes Trust Security Center posture, network-policy state, privacy-mode state, device-management lifecycle state, and OTA verification state. This state should be limited to authorized product and administrative workflows.

​

Network privacy metadata

VPN Network, Proxy Network, and Tor Gateway may require policy metadata to enforce access, evaluate risk, or support troubleshooting. Protected content should not be stored in routine network-policy logs. Network-policy records should be minimized, purpose-limited, and separated from message, call, media, and attachment content.

​

Threat intelligence data

Threat Intelligence Platform and Enyra process security signals for detection, risk evaluation, and blocking decisions. Intelligence handling should use minimized security context, privacy-preserving identifiers where possible, and access-controlled review boundaries.

​

Audit records

Audit records support compliance review, investigation, controlled device management, Enigm Command accountability, OTA release review, and network-policy review. Audit records should provide useful evidence without storing unnecessary protected content.

​

Handling principles

​

Data minimization

Enigm components should collect the minimum data required for product functionality, security enforcement, compliance, controlled rollout, device lifecycle, and supportable operations.

​

Purpose limitation

Data should be used for defined product, security, legal, administrative, or operational purposes. New uses should be reviewed before implementation.

​

Access limitation

Access should be scoped by identity context, privacy-preserving device handle, resource category, policy state, and operational role. Enigm Command access should be auditable.

​

Retention limitation

Retention should be defined by category and reviewed against product, security, and legal requirements. Retention should follow least-retention and purpose-limitation principles.

​

Disclosure limitation

Public documentation, examples, logs, and error messages should avoid protected content, credential material, unnecessary identity metadata, and sensitive operational detail.

​

Enterprise and partner considerations

Enterprise deployments may require additional privacy controls, retention settings, export workflows, device-management evidence, network-policy evidence, OTA review evidence, or policy constraints. These controls should preserve the same data minimization and content confidentiality principles.

​

Deployment variation

Specific retention periods, export formats, and enterprise policy controls should be reviewed in the relevant contractual, legal, and deployment context.