KeePass and KeePassXC Security: Encryption, Enforced Settings and Safe Deployment

KeePass and KeePassXC keep credentials in a local encrypted database file, so the strength of the master key, the key derivation settings, the configuration the organisation enforces and the integrity of the installed software decide how well that file is protected. This guide explains how to deploy and run both applications securely in an organisation, using each project's own documentation for every product detail (checked 8 November 2026). It covers database encryption and key derivation, master key composition, enforced configuration on Windows, plugins and integrations, download verification, endpoint monitoring and a hardening baseline. It is for security engineers, desktop and endpoint teams, and technical users who manage KeePass or KeePassXC databases. The two applications are listed alphabetically throughout, and each has its own settings; neither is ranked. Because the database is a file on infrastructure you own, these controls sit with you in a shared responsibility model. For the wider discipline see the Secrets Management Guide.

This is an independent guide from NHI Mgmt Group, based on KeePass's public documentation and KeePassXC's public documentation as of November 2026. It is not sponsored or reviewed by either project. Product features change, so confirm settings against each project's current documentation.

Key takeaways

• The master key is the whole access model. Every component (password, key file, hardware key or Windows account) is needed to open the database, and the projects describe no backdoor, so key backup is part of security design.
• Use a memory-hard key derivation function. Both applications offer Argon2 for KDBX 4 databases; tune it to about one second of unlock time on the slowest device that opens the file.
• Enforce settings centrally on Windows. KeePass reads KeePass.config.enforced.xml from its application directory, and KeePassXC reads policy values from HKLM\SOFTWARE\Policies\KeePassXC.
• Protect the application directory. Plugins and enforced settings live beside the executable, so users should have read and execute rights only, as a Program Files install provides.
• Verify every download. Both projects publish signatures and hashes; check them and distribute a single approved build through your software deployment tool.

How identity and access work in KeePass and KeePassXC

Both applications are local password managers. There is no server account: whoever can supply the master key for a database file can open it. Identity therefore means the composition of the master key, and access control means who can reach the file and the machine it is opened on.

Encryption and key derivation

Each application documents its own settings, listed here alphabetically.

KeePass (2.x)

• Ciphers: AES-256 or ChaCha20, with further algorithms available through plugins.
• Integrity: HMAC-SHA-256 over the ciphertext (encrypt-then-MAC), with a new random IV on each save.
• Key derivation: AES-KDF or Argon2; the docs currently recommend Argon2d, and Argon2id where side-channel attacks are a concern.
• Tuning: the 1 Second Delay button, or manual Argon2 parameters.
• Memory protection: sensitive data kept encrypted in process memory using Windows DPAPI, with a ChaCha20 fallback.

KeePassXC

• Ciphers and format: choose the encryption settings under Database Settings; Argon2 key derivation requires the KDBX 4 format.
• Key derivation: AES-KDF or Argon2 (recommended with KDBX 4); the guide recommends Argon2id against timing attacks and notes Argon2d for compatibility with other KeePass-based apps.
• Tuning: the decryption time setting; the guide recommends about one second.
• Screen capture: recordings and screenshots of the application window are blocked by default on Windows and macOS.

Decision guidance: use Argon2 for new databases, choosing the Argon2 variant from the recommendation in each application's own documentation and confirming that every client in your estate can open the result. Set the unlock time on the slowest device that must open the database, including phones used with compatible mobile apps, then check that it stays near one second. Higher memory cost raises the price of offline guessing against a copied file.

Master key composition

KeePass

• Master password: minimum length and quality can be enforced with Security/MasterPassword/MinimumLength and MinimumQuality.
• Key file: XML key file (default, with a verifiable hash), 32 bytes, 64 hex characters or any file.
• Windows user account: DPAPI-based key, best paired with a password or key file.

KeePassXC

• Master password: password with strength feedback.
• Key file: randomly generated key file.
• Hardware or OS factor: YubiKey or OnlyKey challenge-response; Quick Unlock with Windows Hello or Touch ID after a full unlock.

Operational notes for both: use a long passphrase unique to the database; keep any key file apart from the database and back it up on independent storage; register a backup hardware key with the same HMAC secret and record any Windows account dependency.

Two documented recovery points deserve attention. KeePass notes that resetting (not changing) a Windows account password, or deleting the account, can make a database protected by the Windows user account key unopenable, so always pair that option with a password or key file. KeePassXC describes creating a backup YubiKey programmed with the same HMAC key, which keeps the database recoverable if the primary token is lost. In both cases, a sealed escrow copy of shared database credentials (for example in a safe, under dual control) is the organisational equivalent of account recovery. See the Break-Glass Account Guide.

SSO and MFA in a file-based model

Because the database is unlocked locally, single sign-on is achieved through the operating system: the Windows user account key in KeePass, and Windows Hello or Touch ID Quick Unlock in KeePassXC (enabled by default and controlled in Security settings). Multi-factor protection comes from combining a password with a key file or hardware key. Control which devices may hold a database through your device management and disk encryption policy.

Admin roles and privileged access

Administrative control in both applications comes from the endpoint, not from an admin console. The people who can write to the application directory, the enforced configuration file or the policy registry key effectively set policy for every user of that installation.

KeePass enforced configuration

• File: KeePass.config.enforced.xml in the application directory beside KeePass.exe. It overrides the global and local configuration files and applies only to that copy.
• Write access: users must not be able to modify the application directory or this file; the default Program Files location provides this.
• User settings: the global KeePass.config.xml should contain only PreferUserConfiguration set to true, so user preferences go to the local file.
• Policy flags: set Security/Policy/Export, Security/Policy/Print and Security/Policy/ChangeMasterKey to false where those actions should be blocked, and Security/Policy/Plugins to false where no plugins are approved.
• Other controls: Application/TriggerSystem/Enabled set to false switches off the trigger system where it is not used; MasterKeyExpiryRec and MasterKeyExpiryForce recommend or force master key changes after a period; KeyCreationFlags and KeyPromptFlags control which key sources are offered.
• Merge behaviour: MergeNodeMode and MergeContentMode decide whether user settings are kept, merged or replaced.

The KeePass policy page adds that the policy applies to the copy users launch, so pair it with application control and removable media rules that keep users on the approved installation.

KeePassXC Group Policy

• Location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\KeePassXC on Windows.
• Naming: each value matches an INI setting name; a slash becomes a subkey, so Security/LockDatabaseIdle is a LockDatabaseIdle DWORD under a Security subkey.
• Effect: enforced values apply to all users and are greyed out in the interface.
• Examples from the guide: BackupBeforeSave set to 1, BackupFilePathPattern, and Security/LockDatabaseIdle set to 1.
• Other platforms: settings live in keepassxc.ini under the user profile; manage the file through your macOS or Linux configuration management.

Shared databases

Teams often share one database on a network share or synced folder. KeePass synchronises per entry, keeps the losing version of a conflicting edit as history, and offers to synchronise when Save finds the file changed on disk. KeePassXC KeeShare exports, imports or synchronises a group through a container protected by a password. Restrict the share with file system permissions to the team that needs it, split databases by team so each person holds only what they need, and change the master key when a member leaves.

Integrations, API tokens and service accounts

Each integration extends who or what can read the unlocked database, so approve each one deliberately.

Machine credentials

Desktop password managers are designed for people. When a script or service needs a credential, move that secret into a server-side secrets manager with its own identity, scoping and audit, and keep the KeePass or KeePassXC database for human use. SSH keys used by people can live in KeePassXC's SSH agent integration; keys used by automation belong in a managed store. See the API Key Management Guide.

Passkeys and exports

KeePassXC stores passkeys as entries used through the browser extension. Its guide notes that exported .passkey files are unencrypted JSON, so treat any export as a secret and delete it after import. For KeePass, block unencrypted export with Security/Policy/Export where users have no need for it.

Logging and detection

Both applications run on the endpoint, so monitoring uses endpoint and file telemetry. Plan these signals with your EDR and SIEM teams.

Metrics that show it is working: percentage of endpoints running the approved signed build; databases using Argon2 (target 100 percent); shared databases with a named owner and review date; endpoints with enforced configuration or policy applied; time to rotate shared database keys after a leaver.

Hardening baseline

Rollout order

1. Choose and verify a build: download from the official site, check signatures, and package it for your deployment tool.
2. Write enforced settings: build KeePass.config.enforced.xml or the KeePassXC policy key on a test machine, confirm each setting is locked in the interface, and document the rollback (remove the file or key).
3. Pilot: deploy to a small group for two weeks; confirm unlock time, Auto-Type and backups work.
4. Migrate databases: move existing files to KDBX 4 with Argon2 and new master keys; keep a sealed copy of the old file until the migration is confirmed.
5. Restrict alternatives: apply application control so only the approved build runs.
6. Operate: apply new releases promptly through your deployment tool, following each project's release and security notes, and review shared database owners quarterly.

Framework mapping

Common misconfigurations

• Enforced file in a writable folder: a portable copy in a user-writable directory lets users edit or delete the enforced configuration. Install under Program Files or set a restrictive ACL.
• Windows account key on its own: a password reset later locks everyone out. Pair it with a password or key file, as KeePass advises.
• Key file stored beside the database: both factors in one synced folder make the second factor a formality. Store the key file on separate media.
• One hardware key and no backup: a lost YubiKey means a lost database. Register a backup token with the same HMAC secret.
• Broad Auto-Type rules: a * window title can type a password into the wrong application. Use specific title matches.
• Unreviewed plugins: plugins run with the user's rights inside the password manager. Keep an approved list or switch plugins off.
• Shared database keys never changed: leavers who knew the master password keep the ability to open copies. Rotate the master key and the credentials inside when membership changes.

Practitioner checklist

• Distribute one approved, signature-verified build of each application through your deployment tool.
• Install under Program Files and keep the application directory writable by administrators only.
• Deploy KeePass.config.enforced.xml or the KeePassXC policy key with export, plugin and locking settings.
• Use KDBX 4 with Argon2 tuned to about one second on the slowest device.
• Combine a passphrase with a key file or hardware key for shared and sensitive databases, with documented backups.
• Monitor the application directory, enforced settings and .kdbx file access with EDR.
• Move machine credentials used by scripts into a server-side secrets manager.
• Rotate shared database master keys when team membership changes.

Standards and references

• KeePass: Security
• KeePass: Enforced Configuration
• KeePass: Composite Master Key
• KeePass: Plugins
• KeePassXC: User Guide
• KeePassXC: Verifying Releases
• NIST: SP 800-63B Digital Identity Guidelines, Authentication

Related NHI Mgmt Group resources: Secrets Management Guide · Password Manager Setup Guide · API Key Management Guide · Break-Glass Account Guide