Add end-to-end encryption as a principle

docs/architecture/security/principles/01-servers-are-not-trusted.mdx

@@ -0,0 +1,48 @@
+# P01 - Servers are zero knowledge
+
+There is no possibility for an attacker or Bitwarden employee to access your unencrypted data by
+compromising Bitwarden's infrastructure. Bitwarden has no ability to decrypt or add to your data.
+Your key, which Bitwarden cannot access, is the only thing that can be used to decrypt your data or
+create new encrypted data.
+
+More precisely, the special status of providing a network sync for client data does not grant the
+server, or any intermediary between the server and client, the ability to reduce the effective
+security of the protections that guard a user's data. If a user chooses a weaker form of protection
+(e.g., a password instead of a passkey), that is an intentional user decision, but the server must
+not be able to manipulate or coerce a client into reducing security beyond what the user knowingly
+configures. Additionally. the server and any necessary infrastructure cannot masquerade chosen clear
+text data as belonging in the set of a users encrypted data. The total sum of a user's encrypted
+data is fully isolated from the server and infrastructure. It cannot be read nor expanded outside of
+the user's client context.
+
+This is what we mean when we sometimes refer to "End-to-end encrypted" or "Zero Knowledge."
+
+## Account key sharing as a feature
+
+This principle does not mean that clear text data is never shared, but rather that any such exposure
+requires informed and explicit consent from the user and is exclusively between accounts, never to
+the server or infrastructure.
+
+## Exceptions
+
+On occasion, product features require breaking this principle in a controlled manner. These
+exceptions are always a last resort, tightly limited scope, and we are always looking for
+improvements to remove them. All exceptions are outlined here.
+
+### Key Connector
+
+Key connector is a self-host only feature that allows an organization user to log in and unlock with
+SSO and no password input. This feature is specifically limited to self-hosted instances due to this
+principle. It is possible for a Bitwarden server to create an authentication token, contact the Key
+Connector server, and retrieve key material that will allow decryption of a user's encrypted data.
+For these reasons we encourage strict isolation of key connector servers to private networks and
+only to be used by advanced self-hosted users.
+
+### Icons service
+
+The Bitwarden icons service provides site favicons to decorate vault items in the Bitwarden clients.
+To enable this functionality, clients need to send clear text domain name information to the
+service. Communicated information is limited to vault item URIs. These URIs are part of a user's
+encrypted content, but we do this to speed up loading of vaults, ensure favicons accurately
+represent the associated URI, and avoid leaking vault contents to local network administrators. This
+feature is easily disabled in client settings.

docs/architecture/security/principles/02-locked-vault-is-secure.mdx

@@ -0,0 +1,21 @@
+# P02 - A locked vault is secure
+
+Clients must ensure that highly sensitive vault data cannot be accessed in plain text once the vault
+has been locked, even if the device becomes compromised after the lock occurs. Protections are not
+guaranteed if the device is compromised before the vault is locked.
+
+## Technical Considerations
+
+Achieving this principle depends on the limitations of the platform and environment. For instance,
+in environments like JavaScript, where memory management is not fully under the control of the
+client, there may be residual plaintext in memory after the vault is locked. While ideal protection
+cannot be guaranteed in such cases, efforts must be made to minimize these risks through techniques
+such as clearing memory buffers and leveraging platform security features when available.
+
+## Key storage mechanisms must provide adequate protection
+
+Mechanisms used for storing encryption keys when the vault is locked, such as PINs or auto-login,
+must provide an appropriate level of security. If encryption keys are stored in less secure
+environments (e.g. in the OS's keyring), the associated risks must be carefully considered and
+mitigated to ensure that unauthorized access to the vault remains limited, even when convenience
+features are used.

docs/architecture/security/principles/03-limited-security-on-semi-compromised.mdx

@@ -0,0 +1,17 @@
+# P03 - Limited security for vaults on semi-compromised devices
+
+:::info Note
+
+This principle applies only to unlocked vaults. Refer to [P01](./locked-vault-is-secure) for details
+on protections for locked vaults.
+
+:::
+
+A semi-compromised device is one where malware exists in User Space but has not breached Kernel or
+OS-level protections. On such devices, clients must leverage available protections to prevent
+malware from accessing plaintext vault data while the vault is unlocked.
+
+- **Technical controls** (e.g., data compartmentalization or HSMs): Clients should maximize the use
+  of Kernel/OS-level protections or other available system mechanisms to safeguard vault data.
+- **Administrative controls** (e.g., biometrics, 2FA, approval flows): Clients should balance
+  security and usability, avoiding excessive complexity in the user flow.

docs/architecture/security/principles/04-no-security-on-fully-compromised.mdx

@@ -0,0 +1,21 @@
+# P04 - No security on fully compromised systems
+
+:::info Note
+
+This principle applies only to unlocked vaults. Refer to [P01](./locked-vault-is-secure) for details
+on protections for locked vaults.
+
+:::
+
+:::info Note
+
+Bitwarden does not currently support Trusted Execution Environments (TEEs). While TEEs could
+potentially provide a secure processing space for vault data on compromised devices, their use is
+limited by the environments in which Bitwarden operates. For this reason, TEEs are not considered
+when defining what constitutes a fully compromised device.
+
+:::
+
+When hardware or OS-level integrity is fully compromised, vault data may become accessible to
+attackers. While Bitwarden continuously strives to provide robust protections, certain threats fall
+beyond the reach of software-based security measures.

docs/architecture/security/principles/05-controlled-access.mdx

@@ -0,0 +1,7 @@
+# P05 - Controlled access to vault data
+
+Clients must ensure that vault data, whether at rest or in use, is accessible only to authorized
+parties and always under the user's explicit control. Even when unlocked, access to vault data must
+be carefully restricted to specific contexts, such as autofill or explicit user actions. Isolation
+mechanisms must be employed, particularly in environments prone to unauthorized access—such as
+browsers—to prevent exposure to third parties without the user's consent.

docs/architecture/security/principles/06-minimized-impact-of-security-breaches.mdx

@@ -0,0 +1,11 @@
+# P06 - Minimized impact of security breaches
+
+Even with robust security measures in place, user error or unforeseen vulnerabilities can lead to
+various security breaches, including the compromise of encryption keys or data leaks. Bitwarden
+should take available actions to help users limit the damage caused by such breaches, both in scope
+and duration. This includes:
+
+- Detecting and invalidating compromised device sessions.
+- Rotating encryption keys to reduce the risk of “harvest now, decrypt later” attacks (forward
+  secrecy).
+- Ensuring that any data added after a breach remains secure, maintaining post-compromise security.