Security objectives
- Establish explicit trust between users, devices, Enigm App sessions, Enigm App runtime integrity, Enigm OS state, and administrative workflows.
- Use Trust Security Center as the user-visible and administrator-reviewable surface for device posture and security state.
- Protect OTA Architecture with Hardware-Backed Signing, release lifecycle controls, client verification, and Remote Attestation as an OTA Eligibility signal.
- Apply Controlled Device Management for enrollment, policy assignment, suspension, revocation, and retirement.
- Route mandatory app-scoped product traffic through Enigm Proxy and optional network privacy decisions through VPN Service where enabled.
- Govern Enigm Server purchase, creation, server ID join requests, membership, region selection, and server-scoped encrypted content lifecycle through Enigm Command.
- Govern Enigm Link purchase, official USB validation, update eligibility, and protected-state lifecycle through Enigm Command.
- Keep public website onion access limited to the public Enigm website and separate from Enigm Command, documentation, status, product traffic, and administrative workflows.
- Process security signals through the Threat Intelligence Platform and Enyra while preserving data minimization and content confidentiality.
- Preserve audit evidence for security-relevant decisions without storing unnecessary protected content.
Enigm security terms
The following terms are used consistently across Enigm documentation:- Defense in Depth: layered controls across Enigm App, Enigm OS, network policy, intelligence, signing, rollout governance, and administration.
- Hardware-Backed Signing: protected signing for security-sensitive artifacts and release materials.
- Privacy-Preserving Device Handles: device correlation identifiers designed to support policy and audit workflows without public exposure of direct device identifiers.
- Controlled Device Management: authorized device enrollment, policy assignment, suspension, revocation, and retirement.
Trust model
Enigm treats trust as contextual and bounded. A valid account session in Enigm App does not automatically imply Device Trust, administrative authorization, network-policy eligibility, or OTA Eligibility. Trust decisions should consider:- Actor identity
- Privacy-Preserving Device Handle
- Enigm OS trust state
- Trust Security Center posture
- Enigm App session state
- Enigm App runtime protection state
- Requested action
- Resource category
- Policy state
- Integrity state
- Remote Attestation outcome for workflows that require OTA Eligibility or device-integrity evidence
Enforcement layers
Enigm App
Enigm App establishes authenticated user context, manages account lifecycle, coordinates secure messaging and secure calls, and participates in multi-device state. The app should treat authorization failures as expected security outcomes and avoid logging protected content. Enigm App integrates Enigm Proxy for product traffic and VPN Service where enabled. These controls support network privacy, traffic separation, and metadata reduction without replacing end-to-end encryption or Device Trust. Standard Enigm account creation is performed through Enigm Command using username and password authentication, recovery phrase generation and handling, 6-digit PIN setup, account identity creation, and explicit trusted-device association without requiring email address, phone number, or identity document. Enigm App sessions use a 1-hour validity window and are automatically renewed while eligible; they do not automatically imply Device Trust, administrative authorization, or protected-content access. Enigm App access is protected by a 6-digit PIN after authentication. PIN validation is performed against the Enigm server-side security layer, not only on the local device. The PIN is also used to authorize critical Enigm Command workflows such as platform data deletion and account deletion. Reverse PIN workflows and repeated incorrect PIN attempts are treated as security events. A configured reverse PIN triggers protected-content deletion according to the data-deletion and retention model and records a profile risk state. This deletes messages, voice messages, call records, multimedia, attachments, and other protected conversation content available to the account; it does not delete the Enigm account itself. Five incorrect PIN attempts close the Enigm App session and record a profile risk state until the user successfully validates with the correct PIN. Enigm App includes application runtime protection controls such as app shielding, code protection, runtime integrity checks, anti-tampering, anti-debugging, instrumentation detection, and root or jailbreak risk detection. These controls contribute to Device Trust and protected workflow eligibility, but they do not replace end-to-end encryption, protected key material, PIN validation, or server-side authorization.Enigm OS
Enigm OS provides device-level policy enforcement, Trust Security Center state, setup controls, launcher policy, network policy, privacy mode, device management, and OTA verification. OS security state should be represented through clear status categories without exposing non-public implementation details.Trust Security Center
Trust Security Center is the posture and security-state surface for Enigm OS. It should summarize Device Trust state, network-policy state, privacy controls, and security warnings in a way that is reviewable by users and administrators.Enigm Command
Enigm Command governs user, organization, enterprise, and administrative workflows such as account lifecycle, account deletion, platform data deletion, active session closure, connected-device visibility, unauthorized device removal, device revocation, Enigm Server administration, Enigm eSIM lifecycle management, Enigm Key lifecycle visibility, Enigm OS managed-device mode, policy assignment, Controlled Device Management, rollout visibility, audit review, and security posture review. Enigm Command actions should require strong identity context, explicit authorization, scoping, and audit records. Enigm Command also provides account creation and training workflows. Training can include essential or advanced Enigm usage education with a final exam.Enigm Link
Enigm Link is a secure portable environment governed through Enigm Command. It uses official USB identity, VPN-required protected state, controlled update eligibility, manifest and payload validation, and platform-specific app behavior for macOS, Windows, Linux, and supported Boot OS targets. Enigm Link protected state should fail closed when official device validation, VPN validation, update-security requirements, or required policy state cannot be established.Enigm Server
Enigm Server provides dedicated private messaging environments for approved Enigm users. Server administration governs purchase, creation, geographic deployment region selection, server ID join request approval, membership, and server-scoped encrypted content lifecycle without becoming a plaintext, attachment, user communication, or private key access surface. Enigm Server administrators can manage the lifecycle and availability of server-scoped encrypted content. Administrative deletion controls operate on encrypted content objects and lifecycle state. Administrative controls do not grant access to message plaintext, attachment plaintext, user communications, private key material, or cryptographic authority.Network controls
Enigm Proxy and VPN Service are treated as policy-governed network privacy and traffic-separation controls connected to Enigm App usage. Their use should be authorized, auditable where security-relevant, and separated from protected content logging. Public website onion access is treated as a privacy-oriented access path for the public Enigm website only. It must remain separate from Enigm Command, Enigm Documentation, Enigm Status, Enigm App product traffic, Enigm Server, internal APIs, operational tooling, and sensitive infrastructure management.Threat intelligence
The Threat Intelligence Platform processes security signals for detection, risk evaluation, and blocking architecture. Enyra is documented as the security AI and correlation capability within that ecosystem. Intelligence outputs should use category-level risk context and avoid unnecessary identity metadata or protected content.OTA and integrity
OTA Architecture uses release lifecycle controls, client verification, Remote Attestation as an OTA Eligibility signal, and Hardware-Backed Signing for security-sensitive artifacts. Artifacts that fail verification should be rejected.Administrative security
Administrative functions are treated as high-risk control-plane operations. Enigm Command actions should identify the actor, action category, target resource category, timestamp, outcome, and change reference when a change reference exists. Privileged actions should be separated from routine runtime activity. Approval and review models should support least privilege, separation of duties, and auditable authorization.Audit expectations
Security-relevant events should be recorded with enough context to support investigation and compliance review. Audit events should minimize metadata and must not include protected content or credential material. Auditable event categories include:- Enigm App authentication and authorization outcomes
- Enigm App runtime integrity and tampering outcomes
- Device enrollment, suspension, revocation, and retirement events
- Trust Security Center state changes
- Enigm Command administrative changes
- Enigm Link official device validation, update eligibility, and protected-state outcomes
- Enigm Proxy and VPN Service policy outcomes
- Public website onion access outcomes
- Enigm Server join request, membership, and server-scoped lifecycle outcomes
- OTA release, rollout, Remote Attestation, and client-verification outcomes
- Hardware-Backed Signing and artifact-verification events
- Threat Intelligence Platform and Enyra detection or blocking outcomes