Internal note: Notify of changes

3.1 Zero-knowledge architecture

All vault data is encrypted before leaving the user’s device and can only be decrypted locally. Neither Dashlane nor any third party can access, read, or recover the contents of a vault.

Here is an overview of how this zero-knowledge architecture is applied to critical flows. More details will be provided in subsequent chapters.

Strong encryption

• Each individual’s vault is encrypted with AES-256-CBC + HMAC-SHA256 before being stored on Dashlane’s servers.
• Decryption requires either:
  • A Master Password, known only to the user, or
  • A hidden Machine-Generated Master Password for passwordless users
• The vault encryption key derived from one of these factors is never transmitted to Dashlane or stored on our servers in plaintext. Therefore, Dashlane will never be able to decrypt users’ vaults.

Device authentication

Each device accessing a Dashlane vault must be explicitly verified and bound to the user through a User Device Key. This ensures that even if credentials are stolen, an attacker cannot access vault data without control of an authorized device.

• New account or new device setup: When a user creates a new Dashlane account or enables an additional device for data synchronization, Dashlane verifies the identity of the account holder. This verification is completed by sending a one-time token to the registered email address or mobile number, after which the system auto-generates a unique User Device Key.
• Passwordless login flow: For passwordless users, the process is even more secure: Authorizing a new device requires approval from an already registered device. This eliminates reliance on email, which can be vulnerable to interception or account takeover.

Defense in depth for access

• Decryption on the device: When a user enters their Master Password in the Dashlane app (or uses passwordless authentication), vault data is decrypted only within the memory of that authorized device. Vault data is never decrypted on Dashlane’s servers.
• Users can strengthen security with two-factor authentication (2FA) using TOTP Authenticator applications. Enabling 2FA at each login requires both the Master Password and an authenticator code to decrypt the vault.
• All communications between devices and Dashlane servers are secured using TLS cryptographic protocols.

Account recovery

Dashlane provides recovery mechanisms that preserve zero-knowledge design while enabling continuity:

• Account recovery key (ARK): Available for both Master Password and passwordless accounts, this single-use key allows secure self-service recovery without weakening encryption guarantees.
• Biometric recovery on mobile: Available for Master Password accounts only. Allows a user to reset their Master Password using their face/fingerprint on a mobile device if they forget their password.
• Admin-assisted recovery: Business admins can approve recovery requests via the Admin Console, acting as a trusted verifier of user identity.

3.2 Encryption model: secrets and protections

Dashlane’s encryption relies on distinct, purpose-scoped secrets. This separation of concerns ensures that a compromise of one element does not expose the vault data and authentication mechanisms at the same time.

Table 1: Dashlane Secrets Overview

3.2.1 Deep dive on key secrets

Dashlane’s encryption model relies on multiple secrets, each strictly separated by purpose. This design prevents any single compromise from exposing user vault data or authentication channels. Below are detailed explanations of the most critical secrets.

User Master Password (UserMP)

• Strength validation: Dashlane uses the zxcvbn library to validate UserMP strength. The library analyzes the chosen password against multiple patterns (common passwords, dictionary words, keyboard patterns, complexity rules) and returns a score between 0 and 4:
  • 0: Too guessable
  • 1–2: Weak to moderate strength
  • 3–4: Safely unguessable (estimated 10⁸–10¹⁰ guesses required)
• Enforcement: Dashlane applications enforce a minimum score of 3, ensuring users select sufficiently strong Master Passwords. Feedback is provided to help users improve weak choices.
• Storage and transmission:
  • The User Master Password is never sent to our server in plaintext; therefore, Dashlane will never be able to decrypt users’ vaults.
  • Not stored locally by default; used only transiently to decrypt local files.
  • Optional encrypted local storage if the user enables “Remember my Master Password.”

Machine-Generated Master Password (MachineGeneratedMP)

• Purpose: Alternative to the UserMP, used in passwordless accounts
• Generation: A strong, unique 40-character string (~243 bits of entropy) generated using Dashlane’s Password Generator
• Storage and transmission:
  • Never stored on Dashlane servers, nor are any derivatives
  • Not stored locally by default, except when logging in to the web extension
  • Never transmitted over the internet; only the encrypted vault is sent
• Security advantage: Machine-generated values eliminate human weakness (e.g., predictable passwords) and guarantee a high entropy

Intermediate Key

• Purpose: Used in certain local storage scenarios to strengthen the protection of encrypted files
• Generation and use: Random 32-byte value generated locally on the device
• Protection: Stored encrypted with a derivative of the UserMP
• Design principle: Adds another layer of defense so that one compromised key (e.g., through local device access) is insufficient to unlock vault data

User Device Key (DeviceKey)

• Purpose: Authenticates each device to Dashlane servers; prevents vault access from unauthorized devices, even if credentials are known
• Generation: Generated server-side for each new device linked to an account
• Storage: Stored locally, encrypted within user data.
• Security advantage: Separation of vault encryption (UserMP or MachineGeneratedMP) from device authentication ensures that vault compromise does not imply server compromise, and vice versa

3.2.2 Local access to user data

Access to a user’s encrypted vault requires the User Master Password (UserMP) or, in the case of passwordless accounts, the Machine-Generated Master Password (MachineGeneratedMP).

• Vault key derivation:
  • The UserMP (or MachineGeneratedMP) is used to derive a 256-bit key that encrypts and decrypts vault data using AES-256-CBC + HMAC-SHA256 locally on the user’s device.
  • In passwordless flows, the MachineGeneratedMP is not exposed to the user; it is transported securely between devices during enrollment of a new device, and then functions identically to the UserMP for key derivation.
• Cryptographic libraries:
  • Dashlane uses the Web Crypto API for browser-based clients.
  • On mobile, Dashlane relies on native cryptographic libraries for iOS and Android.
  • For key derivation, Dashlane implements the Argon2 reference library, compiled to WebAssembly (for browsers) or linked directly into the mobile applications.
  • Dashlane also supports PBKDF2 as a backward-compatibility option for older devices. This support will be deprecated in 2026.

Our approach ensures that all cryptographic operations happen locally, using hardened, well-vetted primitives, with no exposure of sensitive material to Dashlane servers.

3.2.3 Local data usage after decrypting

Once a vault has been decrypted—after the user provides their Master Password or validates their MachineGeneratedMP through a PIN code, biometric authentication, or a security key—data is handled under strict constraints to balance usability with security:

• Session-limited decryption: User data is only decrypted into volatile memory and never written back to persistent storage in plaintext.
• Secure automation: Dashlane processes individual credentials in memory to autofill them into websites and apps or to save new credentials, without requiring the user to re-enter their Master Password or MachineGeneratedMP each time.
• Key-stretching defense: Derivation of AES key from the UserMP (or MachineGeneratedMP) employs Argon2d (or PBKDF2 in fallback cases). These algorithms introduce computational latency by design, making brute force attacks significantly more expensive for attackers while remaining acceptable for legitimate users.
• Memory protection: The decrypted data in memory is protected by leveraging pre-existing, platform-level safeguards (as detailed in section 7.4), minimizing exposure even in the event of device compromise.

3.3 Devices and authentication

Dashlane uses a device-based authentication model to ensure that only verified devices can access user vaults, without ever relying on or transmitting a user’s Master Password or Machine-Generated Master Password.

When a user creates an account or adds a new device for data synchronization, Dashlane generates a User Device Key (DeviceKey) composed of 40 random bytes using the OpenSSL RAND_bytes function. The first 8 bytes form the access key, while the remaining 32 bytes form the secret key. This DeviceKey uniquely binds each device to the user’s account.

• Local protection: The DeviceKey is stored locally within encrypted user data, protected by the vault encryption mechanism.
• Server protection: On Dashlane servers, the secret key component is encrypted at rest, ensuring that employees or attackers cannot easily impersonate a legitimate device.
• Independent from vault credentials: Authentication to Dashlane servers use only the DeviceKey, never the User Master Password or Machine-Generated Master Password.
• Frictionless experience: Once the user has unlocked their vault locally, Dashlane uses the DeviceKey for server authentication, enabling synchronization and cloud-based features without requiring further user input.

This design provides secure, password-independent authentication between user devices and Dashlane’s infrastructure, maintaining zero-knowledge architectures while simplifying the user experience.

3.4 Communication security

All communications between the Dashlane application and Dashlane servers are protected by modern transport security protocols. Dashlane enforces HTTPS/TLS across all endpoints, with the dashlane.com domain HSTS-preloaded to prevent protocol downgrades on any subdomain.

• TLS best practices: Cipher suites and protocol configurations are regularly updated to align with current industry standards and security recommendations.
• Beyond transport security: While HTTPS/TLS provides a strong baseline protection, Dashlane’s design ensures that data confidentiality does not depend on the transport layer. Because vault data is end-to-end encrypted, even if the communication channel were compromised, an attacker would gain access only to encrypted ciphertext.

This layered approach to communication security preserves zero-knowledge guarantees while maintaining compatibility with enterprise security frameworks and modern web infrastructure.

3.5 Confidential computing & secure enclaves

Enterprises require solutions that deliver both security and operational transparency when integrating with third-party systems, such as identity providers, and managing sensitive cryptographic operations. Dashlane uses confidential computing to meet these B2B requirements, ensuring that even when customers rely on Dashlane-hosted components, such as our SSO integration, data remains fully protected from both Dashlane and external parties.

Confidential computing establishes a trusted execution environment (TEE/secure enclave) that isolates data and code at runtime. In Dashlane’s implementation, this ensures that encryption keys, SSO tokens, and authentication flows are processed in cloud secure enclaves that even cloud admins cannot access.

3.5.1 Secure enclaves at Dashlane

Dashlane leverages AWS Nitro Enclaves to isolate cryptographic materials and protect sensitive operations from exposure, even if the host infrastructure were compromised.

• Isolated execution: All encryption and decryption operations occur inside secure enclaves, separate from the host operating system and administrative layers.
• Attestable integrity: Each enclave generates a verifiable attestation, ensuring that only trusted code is executed and that no unauthorized changes can occur.
• Confidential processing: Enclave data and memory remain inaccessible to Dashlane personnel or any external process, reinforcing the zero-knowledge architecture.
• Lifecycle assurance: Enclave creation, execution, and destruction are verifiable, providing strong guarantees of code integrity throughout the operational lifecycle.

Our security model leverages AWS Nitro Enclaves as the foundational isolation layer for our confidential computing environment. While Dashlane operates on strict Zero-Knowledge principles, the integrity of our processing relies on the AWS Nitro System. The Nitro Hypervisor creates a logically isolated compute partition, which effectively eliminates administrative access and persistent storage. Our reliance is specifically on AWS’s architectural claim that the Nitro Card and Hypervisor maintain a 'no-operator-access' environment. Crucially, our threat model acknowledges that our security guarantees are tethered to this logical isolation rather than relying on a Trusted Execution Environment (TEE) independent of the cloud provider's firmware, even as we use Cryptographic Attestation to verify our code’s integrity.

This architecture ensures that even if infrastructure is compromised, cryptographic keys and user data remain secure through an isolated workload and attested trust.

To block unauthorized access, the enclave requires authentication via its attestation to access cryptographic material. This validation is managed by a Key Management Service (KMS).

Upon authentication, each enclave instance performs two retrievals:

1. Key Management Service (KMS): Retrieves an Enclave Local Key (ELKey)
2. Internal secret manager: Retrieves an Enclave Unseal Key (EUKey)

These two keys are then combined and used to decrypt the Enclave Encryption Key (EEKey) as described in the following schema:

Figure: How keys are used to decrypt the Enclave Encryption Key

3.5.2 Enclave workflows

The enclave operates through a series of secure workflows that govern initialization, storage, and all other operations related to the features that leverage them.

Cryptographic materials

Enclave initialization

During initial deployment, the enclave requests the Enclave Master Key (EMKey) from the KMS, which grants access only to verified enclaves via attestation. The KMS generates an Enclave Local Key (ELKey) and returns two encrypted versions: one encrypted by EMKey and the other by an ephemeral enclave public key. The enclave stores only the encrypted ELKey, ensuring it is never available in plaintext outside the secure environment. When the enclave restarts, the KMS decrypts the ELKey using EMKey, reestablishing a secure state.

Figure: Enclave initialization

Storage and key management

Because enclaves lack persistent storage, all data leaving the enclave is encrypted before transmission as described in the following sequence diagram:

Figure: Data encryption before transmission

The Enclave Encryption Key encrypts the set of encryption keys for features operated by enclaves, as:

• SSO Service Provider keys: An encryption key is generated per team to encrypt the User ServiceProvider Keys at rest (outside the enclave); these are the keys sent back to clients to decrypt their vault.
• Sub-intermediate keys: Encryption keys generated for specific features operated by the enclave, such as activity logs.

3.5.3 Secure channels

Figure: Protocol to build an encrypted channel using Libsodium

Secure channels are how clients securely communicate with enclaves. They are end-to-end encrypted channels between a client and enclaves, preventing a man-in-the-middle from eavesdropping on those communications.

The client generates ephemeral key pairs and requests the enclave to create a secure channel. Upon being requested to mount a channel, the enclave generates its own key pairs and embeds the public key within a cryptographically signed attestation.

Nitro attestations are a set of properties of the runtime environment issuing the attestation, signed by the Nitro Hypervisor underlying the workload. Those properties are sealed as measurements called Platform Configuration Registers (PCRs)—basically hashes—into the attestation, to be verified by clients when checking the attestation.

Once the Dashlane app has verified the attestation and agreed on the PCRs within, the client is guaranteed that the public key embedded into the attestation is the one of a genuine enclave. Dashlane applications base their verification on two PCRs:

• PCR3: A contiguous measurement of the IAM role assigned to the parent instance; ensures that the attestation process succeeds only when the parent instance has the correct IAM role.
• PCR8: A measure of the signing certificate specified for the enclave image file; ensures that the attestation process succeeds only when the enclave was booted from an enclave image file signed by a specific certificate.

Therefore, the client can proceed with the key exchange and generate the cryptographic material to encrypt communication to the secure enclave.

Secure channels are based on the Libsodium library. As stated in the documentation of the library, the following primitives are used:

• X25519 and BLAKE2B-512 for the key exchange
• XChaCha20-Poly1305 for secretstreams

3.6 Data & analytics

Dashlane's analytics infrastructure is governed by the same zero-knowledge principle as its product architecture. Vault contents are, by design, never accessible to Dashlane. Similarly, sensitive behavioral signals can’t be reviewed by Dashlane's analytics systems or Dashlane personnel in an identifiable form. All collected data is classified under Dashlane’s internal Client and User Data Acceptable Use Policy (AUP), which defines four data categories, each with explicit access rules and permitted usage. Analytics infrastructure runs in a dedicated, private AWS environment isolated from production systems. Privacy commitments are documented in Dashlane's public Privacy Policy.

3.6.1 Data collection principles

Dashlane applies data minimization principles across its entire analytics stack. The foundational architectural constraint is that no analytics system, no Dashlane employee, and no third-party sub-processor can access vault contents or sensitive behavioral signals. Where behavioral signals are collected for analytics purposes, they enter the pipeline exclusively anonymized and aggregated.

3.6.2 Data categories

All collected data is classified and access-controlled under the Dashlane internal Client and User Data Acceptable Use Policy, which applies uniformly across all teams, systems, and geographies.

It defines four data categories, each with its own protection level and permitted uses.

3.6.3 Event architecture

Privacy guarantees are enforced through two distinct event types, defined in Dashlane's tracking schemas:

• Anonymous events log sensitive behavioral data, including domain-level information, such as autofill events. The schema structurally prohibits user identifiers, device identifiers, and vault content from these events. Dates are truncated to the day. There is no technical means to correlate anonymous events across users or sessions.

• User events log product usage data: feature activations, UI interactions, navigation, and session sequences (example: a user clicking a banner or enabling a feature). Domain information and vault content are explicitly prohibited from this event type at the schema level. User events include a pseudonymous analytics user identifier, which is not an account email or personal identity.

This two-track architecture means the pipeline's privacy guarantees do not rely on access controls or downstream anonymization after the fact. The separation between sensitive domain-level signals and user-linked product usage is enforced before any data leaves the client application.

3.6.4 Infrastructure and data flows

Dashlane's data infrastructure runs in a dedicated private AWS environment, isolated from production server infrastructure at the network level.

Figure: High-level view of data infrastructure

Product event pipeline

Client applications (browser extension, mobile application) emit product analytics events through Dashlane's internal event logging library. Events are classified at instrumentation time as either anonymous or user events. Events stream through AWS-managed streaming services into an AWS data lake, are transformed through an SQL-based transformation layer in an orchestrated pipeline, and land in a Redshift data warehouse. Access to warehouse data is role-gated and logged.

Server and backend data

Operational backend data (account management, subscription state, error telemetry) flows through a separate ingestion path into the same warehouse, maintaining pipeline separation from client event data.

Third-party data

A defined set of business tool integrations, including CRM, customer support, marketing automation, and payment reporting, flows into the warehouse through a managed data integration platform. All third-party data sharing is governed by Dashlane's Vendor Management Policy. No personal data is shared with any sub-processor without review and approval. All data transfers use security-approved, encrypted channels.

Infrastructure isolation

Analytics infrastructure operates in a private VPC, separated from Dashlane's production server infrastructure at the network level. The data warehouse (Redshift) is not directly internet-accessible; access routes through internal network controls.

3.6.5 Data governance and controls

Dashlane's analytics and observability infrastructure is governed within the same compliance framework as the broader platform:

• SOC 2 Type II and ISO 27001
• GDPR: Dashlane operates as Data Controller for personal users and Data Processor for enterprise customers. Analytics data flows are maintained in internal data processing records. Standard DPA is provided at contract time.
• Access controls: Access to analytics infrastructure is role-gated and logged.
• Data retention: Analytics data retention is governed by Dashlane's Data Management and Retention Policy.
• Third-party oversight: All sub-processors are approved pursuant to the Vendor Management Policy, which requires heightened review when personal data is involved and mandates legal and security review at initial contracting and renewal.
• Incident response: Unauthorized access to analytics systems is subject to Dashlane's Security Incident Response process.

3.6.6 Omnix anonymized metrics

Omnix anonymized metrics are anonymized and aggregated usage metrics, providing counts and trends of safe, weak, or compromised passwords a device encounters and how users respond to Credential Risk Alerts & Notifications.

To measure these at a population level without exposing individuals’ or companies’ behavior, we route the data through a hardened, logically separate pipeline that runs on Dashlane's existing Nitro infrastructure rather than the standard product-event pipeline described in 3.6.3.

Omnix events are counted locally on Dashlane extensions, sent over the existing Nitro secure tunnel, aggregated inside the Nitro Enclave into anonymized cohorts, and only then flowed into the data warehouse. Additionally, only large enough cohorts are generated to guarantee anonymity. The architecture follows certain principles:

• Data is sent securely through Dashlane's Nitro tunnel and enclave but is isolated as its own pipeline: a distinct analytics endpoint, its own aggregation logic, and a separate S3 bucket with its own retention lifecycle.
• Extensions send the minimum information required to build cohorts; cohort construction happens inside the cloud secure enclave.
• Logs do not carry any identifiers, domains, or vault information. A log carries only event counters, non-identifying cohort dimensions, a random per-log uuid (retry key for unprocessed logs), and a timestamp. No account identity, no domain-level data, and no vault content ever leaves the client application.
• Individual logs never reach the data warehouse. Nitro builds cohorts and shares a cohort only when its data originates from at least 50 sources.

Figure: High-level flow of Omnix anonymized metrics