# App security App security in Sealed focuses on one core principle: the device is the main security boundary. The app creates the user’s identity locally, stores sensitive data locally, and decrypts messages locally. Because of this, Sealed must protect access to the app, stored keys, local conversation data, and emergency situations where the user may need to remove access quickly. ### Access code After the wallet is created inside the app, the user creates a local access code. This code is used to unlock Sealed on that device. It is not a cloud password, not a server-side login, and not a recovery method. Its only role is to protect local access to the application. If the access code is entered incorrectly 5 times, the app resets itself. This protects the device against repeated guessing attempts. After a reset, the user needs the 24-word mnemonic phrase to restore the main Sealed identity. ### Termination code During the same setup flow, the user also creates a termination code. This code is entered on the same PIN screen as the normal access code, but it has the opposite effect: instead of opening the app, it silently wipes local Sealed data from the device. The termination code is designed for high-risk situations where a user may be forced to unlock the app. It does not erase anything from the blockchain, but it removes the local data needed to access conversations from that device. ### Hardware enclave Sealed uses the device’s hardware security layer to protect an AES wrapping key. This key is held inside the hardware enclave and is used to protect sensitive keys stored by the application. The AES wrapping key never leaves the enclave. It is not exported into normal app memory and is not sent to Sealed infrastructure. This gives the app a stronger local protection layer for key material. ### Encrypted private key storage The ed25519 private key is stored encrypted at rest using AES-256-GCM. This means the private key is not saved as plain readable data on the device. AES-256-GCM protects the stored key and helps detect unauthorized modification. The app only unlocks the key through the protected local flow when access to Sealed is allowed. ### Screenshot protection Sealed prevents screenshots inside the application. This helps reduce one common way of leaking sensitive information from a device, such as conversation screens, wallet-related screens, or recovery-related views. This protection cannot stop someone from taking a photo of the screen with another device, and it cannot control what another participant does with messages they receive. Its role is limited to blocking screenshots inside the operating system where the app can enforce it. ### Device risk Sealed reduces trust in central infrastructure, but it cannot remove the risk of a compromised device. If a device is already unlocked, infected, or controlled by an attacker, local data may be exposed despite the app’s protections. For this reason, device hygiene still matters. Users should keep their operating system updated, protect their screen lock, and store their 24-word mnemonic phrase safely. Sealed protects the app environment, but the device itself remains the final security boundary. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sealed.channel/security-and-privacy/app-security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.