> ## 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. # Threat Model > Public threat-model framework for Enigm products and services. The Enigm threat model covers Enigm App, Enigm Command, Enigm Server, Enigm OS, Trust Security Center, OTA Architecture, Remote Attestation, Threat Intelligence Platform, Enyra, Enigm Proxy, VPN Service, public website onion access, Hardware-Backed Signing, and Controlled Device Management. This document provides a public framework for review. It avoids deployment-specific topology, non-public component identifiers, environment-specific network details, and operational details that could reduce system security. ## Assets in scope The threat model considers the following asset categories: * Enigm App account state, session state, runtime protection state, secure messaging state, secure call state, and multi-device state * Privacy-Preserving Device Handles and Controlled Device Management lifecycle records * Enigm OS trust state, Trust Security Center state, network policy, privacy mode, and device-management state * OTA release artifacts, release metadata, signing state, rollout state, client-verification state, and Remote Attestation outcomes * Enigm Command account lifecycle actions, deletion workflows, session controls, device lifecycle actions, product lifecycle actions, approval history, and policy assignments * Enigm Server join request state, membership state, server-scoped lifecycle state, and audit visibility * Enigm eSIM activation state, Enigm account association, lifecycle state, and connectivity policy outcomes * Payment status, product entitlement state, payment method category, Code Coin redemption state, purchase country selected by the user, and invoice records when requested * Enigm Proxy and VPN Service policy outcomes * Public website onion access outcomes * Threat Intelligence Platform signals, Enyra outputs, risk categories, and blocking outcomes * Audit records ## Threat categories ### Account and app compromise An actor attempts to misuse Enigm App account state, session state, secure messaging, secure calls, or multi-device enrollment. Expected controls include secure identity layer enforcement, scoped authorization, key-management controls, multi-device lifecycle controls, and audit records. ### Application runtime tampering An actor attempts to reverse engineer, repackage, debug, instrument, hook, tamper with, or modify Enigm App at runtime. An actor may also attempt to run the app in a rooted, jailbroken, emulator-like, or otherwise high-risk environment to weaken app integrity. Expected controls include app shielding, code protection, runtime integrity verification, anti-tampering controls, anti-debugging controls, hooking or instrumentation detection, root and jailbreak risk detection, fail-closed behavior for sensitive operations, Device Trust impact, and auditability of security-relevant runtime findings. ### Conversation policy misuse An actor attempts to misuse conversation or group policy to send, forward, delete, retain, or expose protected messages, files, images, videos, or other supported multimedia outside authorized policy. Expected controls include conversation policy evaluation, group permission enforcement, Device Trust checks, protected key material, secure viewers, lifecycle auditability, expiration policy, forwarding controls, deletion controls, and separation from administrative plaintext access. Capture-resistance controls are modeled as exposure-reduction controls. They are not modeled as complete protection against compromised endpoints, external recording, intentional user disclosure, or modified operating environments. ### Device lifecycle abuse An actor attempts to enroll, reactivate, suspend, revoke, or retire a device outside authorized Controlled Device Management workflows. Expected controls include Privacy-Preserving Device Handles, Enigm Command authorization, lifecycle audit events, and deny-by-default policy behavior. ### Enigm OS policy bypass An actor attempts to bypass Enigm OS network policy, privacy mode, launcher constraints, setup requirements, Trust Security Center posture checks, or device-management state. Expected controls include device-level policy enforcement, Trust Security Center visibility, fail-closed behavior, and auditable state transitions. ### OTA integrity failure An update package, policy bundle, configuration bundle, release metadata, or device-facing artifact is modified, misclassified, or accepted without valid verification. Expected controls include OTA Architecture release controls, Hardware-Backed Signing for security-sensitive release materials, client verification, Remote Attestation as an OTA Eligibility signal, release traceability, and rejection of failed verification. ### Network-policy misuse An actor attempts to misuse Enigm Proxy, VPN Service, Enigm eSIM connectivity policy, or public website onion access boundaries, routing eligibility, access eligibility, or blocking outcomes. Expected controls include policy evaluation, authorization, audit records, separation from protected content logging, and controlled configuration review. ### Enigm Key misuse An actor attempts to misuse Enigm Key association, emergency activation, device authentication, emergency contacts, event-bound location sharing, revocation, replacement, or lifecycle visibility. Expected controls include Enigm App initial linking, user-controlled emergency contact configuration, device-bound authenticated signing material, encrypted communication, rejection of unauthenticated device traffic, event-bound location sharing, Enigm Command lifecycle scoping, and revocation for lost, stolen, retired, or replaced devices. Enigm Key emergency workflows are modeled as bounded emergency events. They are not modeled as routine location tracking, protected message access, secure call access, attachment access, or private key access. ### Enigm Server abuse An actor attempts to misuse Enigm Server purchase, creation, server ID join requests, membership control, server-scoped content lifecycle controls, region selection, or deletion workflows. Expected controls include Enigm Command authorization, server owner or authorized administrator scoping, join request auditability, server membership review, encrypted content availability controls, and separation from message plaintext, attachment plaintext, user communications, private key material, and cryptographic authority. The server ID is modeled as a join-request locator, not as an access credential. Possession or disclosure of a server ID should not grant membership, Device Trust, protected key access, or encrypted content access without administrator approval and normal Enigm App authorization controls. Administrative deletion controls are modeled as lifecycle and availability controls over encrypted content objects. They are not modeled as content visibility, content decryption, plaintext access, or cryptographic key access. ### Intelligence manipulation A signal, risk category, Enyra output, or evaluated intelligence record is altered, injected, suppressed, or misclassified in a way that affects detection, risk review, or blocking architecture. Expected controls include classified handling, source authorization, normalization, audit records, and review workflows. ### Enigm Command abuse An actor attempts to misuse privileged workflows, delete account or platform data outside authorized scope, close or preserve sessions improperly, remove or retain devices improperly, change policy, alter device-management state, view restricted audit data, or alter rollout state outside approved scope. Expected controls include strong administrative identity, explicit authorization, role separation, approval workflows, and auditability. ### Loss of audit visibility Security-relevant events are unavailable, incomplete, or insufficient to support investigation and compliance review. Expected controls include audit event generation for Enigm App, Enigm OS, Trust Security Center, Enigm Command, OTA Architecture, network policy, Threat Intelligence Platform, Enyra, and Controlled Device Management. ## Trust boundaries Threat modeling should evaluate transitions between: * User and Enigm App * Enigm App and Enigm OS device state * Enigm OS and Trust Security Center posture representation * Device lifecycle and Enigm Command Controlled Device Management * Enigm OS and OTA Architecture * Remote Attestation and OTA Eligibility decisions * Hardware-Backed Signing and artifact distribution * Enigm Proxy, VPN Service, and network-policy enforcement * Public website onion access and Enigm website exposure * Enigm Command, Enigm Server management, join requests, membership, and server-scoped content lifecycle * Threat Intelligence Platform, Enyra, and blocking architecture * Enigm Command and enterprise administrative workflows Each boundary is reviewed according to its documented trust domain. Public documentation describes the security objective, data exposure constraint, and authorization model for each boundary without exposing internal topology or operational procedures. ## Control mapping Threats are evaluated against defense-in-depth controls across identity, app state, app runtime protection, OS state, Privacy-Preserving Device Handles, Controlled Device Management, Trust Security Center posture, network policy, OTA verification, Remote Attestation, Hardware-Backed Signing, Threat Intelligence Platform handling, Enyra outputs, and Enigm Command authorization. ## Residual risk Residual risk depends on deployment configuration, enterprise policy, integration depth, operational maturity, and product scope. Residual risk is reviewed against documented controls, available evidence, deployment constraints, and the separation between Account Trust, Device Trust, OTA Eligibility, Remote Attestation, and Administrative Authorization. ## Review cadence Threat-model reviews are part of Enigm security governance. Review evidence is maintained at a level appropriate for audit and enterprise assurance while avoiding public disclosure of operational procedures, internal topology, or implementation-sensitive controls.