Using KeePassPasskey in a Corporate Environment

This guide is for IT administrators who want to roll out KeePassPasskey on managed Windows PCs, and for users who want to know what to ask their IT department for. For everyday use, see the User Guide; for individual problems, see FAQ & Troubleshooting.

Overview

KeePassPasskey consists of two parts, which are deployed separately:

Both must be present, and both must be on compatible versions (see Keeping the app and plugin versions matched).

Passkeys are stored in the KeePass database (KDBX) as ordinary entries. Nothing is stored in the cloud, and neither part makes network connections of its own. The only data that leaves KeePass is passkey metadata (credential ID, site and user name, never the private key) written to the Windows credential cache so Windows can offer the passkeys in its sign-in dialogs.

Prerequisites

Check these on your client baseline before anything else, because none of them can be worked around by KeePassPasskey:

Things to look out for in managed environments:

• Windows Hello policies. If Windows Hello or Windows Hello for Business is disabled by Group Policy or Intune, users cannot set up a PIN and KeePassPasskey cannot register. Windows Hello for Business is fine; the regular Windows Hello PIN is enough as well.
• Remote Desktop and VDI. Windows does not offer PIN setup over a Remote Desktop session. Virtual machines need a virtual TPM. See I cannot set up a Windows Hello PIN.
• Feature update rollout. If your organisation holds back feature updates, PCs may still be on 23H2.

Choosing a distribution channel

KeePassPasskey is published through two channels with identical functionality:

Pick one channel per PC. Both can be installed side by side, but then users see two KeePassPasskey entries in Windows and the plugin talks to whichever it prefers. Mixing them only makes support harder.

As a rule of thumb: use the Store channel if your PCs can reach the Microsoft Store (directly or through Intune), and the GitHub channel if the Store is blocked or you need to pin a version.

Deploying the app

Microsoft Store channel

• Intune: add the app as a Microsoft Store app (new) and search for KeePassPasskey, or use Store ID 9NWNFHJPSPGZ.

• winget (for scripts or other management tools):

  winget install 9NWNFHJPSPGZ --source msstore --accept-package-agreements --accept-source-agreements

The Store keeps the app up to date by itself. Read Keeping the app and plugin versions matched before relying on that.

GitHub channel

Download KeePassPasskey-<version>.zip from the releases page. It contains the MSIX package, the certificate (KeePassPasskey.cer) and the plugin.

1. Trust the certificate. Deploy KeePassPasskey.cer to the Local Machine → Trusted People store, through Group Policy (Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted People), an Intune trusted certificate profile, or:

certutil -addstore TrustedPeople KeePassPasskey.cer

Keep the certificate deployed for as long as the package is provisioned, so that the app can be registered for users who sign in for the first time later.

2. Install the package. Either provision it for every user of the PC (run elevated):

Add-AppxProvisionedPackage -Online -PackagePath KeePassPasskeyProvider.Package_<version>_x64.msix -SkipLicense

or install it for the current user only (run as that user, not elevated):

Add-AppxPackage -Path KeePassPasskeyProvider.Package_<version>_x64.msix

Sideloading must be allowed, which is the default on Windows 11 unless a policy turns it off (Allow all trusted apps to install).

The InstallMsix.bat script from the release zip is meant for interactive installs on a single PC. It installs for the signed-in user through a scheduled task, so do not use it from a deployment tool that runs as SYSTEM.

3. Updates. Deploy each new release the same way. A newer version installs over the old one and keeps the users’ settings.

Deploying the plugin

Copy KeePassPasskey.dll into KeePass’s Plugins folder, for example C:\Program Files\KeePass Password Safe 2\Plugins\. KeePass loads it at its next start.

The DLL is in the GitHub release zip. It also ships inside the app package, in its KeePassPasskeyPlugin\ folder, so the plugin always matches the app installed on the PC:

$pkg = Get-AppxPackage -AllUsers -Name '*KeePassPasskey*' | Select-Object -First 1
Copy-Item (Join-Path $pkg.InstallLocation 'KeePassPasskeyPlugin\KeePassPasskey.dll') `
	'C:\Program Files\KeePass Password Safe 2\Plugins\' -Force

Close KeePass before overwriting the file, or the copy fails because KeePass has it loaded.

For KeePass Portable or per-user installations, users can install the plugin themselves from the app (Install plugin) without administrator rights.

Application control

The plugin DLL is not code-signed. If you use AppLocker DLL rules or App Control for Business (WDAC), allow KeePassPasskey.dll by path or by file hash. The hash changes with every release.

Smart App Control may block the plugin until Microsoft has cleared a new release, see Smart App Control blocks KeePassPasskey.dll. Smart App Control is usually off on managed PCs.

Keeping the app and plugin versions matched

The app and the plugin check each other’s protocol version on every request:

• Version mismatch (yellow): different but compatible versions. Passkeys keep working.
• Incompatible version (red): passkey operations are blocked until the older side is updated.

Most releases are compatible with the previous ones, but plan for the case where they are not:

• Users without administrator rights cannot update a plugin under C:\Program Files\. KeePass offers the update from the installed app at its next start, but writing to Program Files needs elevation. Without it the user sees an administrator prompt they cannot complete.
• Store installs update the app on their own, while the plugin only changes when someone copies it. Over time the app gets ahead of the plugin.

The simplest setup is to deploy the app and the plugin together in the same job, with the plugin copied from the installed package as shown above, and to rerun that job whenever the app changes. With the Store channel, an Intune remediation script or a scheduled task that compares the two versions and copies the DLL works well. If that is not practical, the GitHub channel gives you full control over when the app version changes.

When IT owns plugin updates, turn off the in-KeePass update prompt so users are not asked to do something they cannot do (checkForPluginUpdates, see below).

Enabling the provider for each user

Two steps are per user and happen on the PC itself:

1. Registration with Windows. Happens automatically the first time the user opens the KeePassPasskey app, or the first time KeePass opens a database with the plugin loaded. No administrator rights are needed.
2. Turning the provider on. The user switches on KeePassPasskey under Settings → Accounts → Passkeys → Advanced options. The app’s Setup Guide links straight to that page. Windows keeps this switch per user, and it stays on across app updates.

Both status indicators in the KeePassPasskey app then show green. To check this from a script, run KeePassPasskeyProvider.exe /status as the user, see Command-line options.

Preconfiguring settings

The KeePassPasskey settings are stored by the plugin in KeePass’s configuration, as a single JSON value under the key KeePassPasskey.Settings. That means you can preset them with KeePass’s own configuration mechanisms, the same way as other KeePass settings.

To enforce settings, add them to KeePass.config.enforced.xml next to KeePass.exe (see Enforced Configuration in the KeePass documentation):

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<Custom>
		<Item>
			<Key>KeePassPasskey.Settings</Key>
			<Value>{"registrationVerification":3,"signInVerification":3,"checkForPluginUpdates":false,"syncCredentialsToWindows":true}</Value>
		</Item>
	</Custom>
</Configuration>

Keep in mind:

• The value is all or nothing. It holds every KeePassPasskey setting at once, so enforcing it locks all of them. Settings left out of the JSON fall back to their defaults.
• Changes in the app do not stick. Users can still change settings in the app, but the enforced value is applied again at the next KeePass start.
• The JSON must be valid and XML-escaped where needed (&, <).
• Users must not be able to write to the KeePass folder, or they can simply edit the enforced file. That rules out enforcing settings for KeePass Portable in a user-writable location.

The settings you are most likely to care about:

The full list of settings is described in Settings in the User Guide.

Settings that belong to the app window only (theme, tray icon) and the spoofed AAGUID are stored per user in the app’s own storage and cannot be preset this way.

Security considerations

Questions security teams usually ask, with short answers:

Where are the private keys? In the KeePass database, protected by the database’s master key and, while KeePass runs, by KeePass’s in-memory protection. Signing happens inside the KeePass process; the key is never sent to the app or to Windows. See How is the private key protected? Back up and protect the database according to your existing KeePass policy.

Who can talk to the plugin? Only the official KeePassPasskey package (checked by package family name), running as the same user at medium integrity. Other users on the same PC, including with fast user switching, each get their own connection.

Can passkeys leave the PC? Yes, together with the database. That is by design: passkeys in KeePass are portable, can be backed up, and can be opened with other compatible KDBX software like KeePassXC. If your policy requires device-bound passkeys, KeePassPasskey is not the right authenticator for those accounts.

Backup flags and attestation

Relying parties, including your own identity provider, may look at two properties of a passkey:

• Backup flags (BE/BS). By default, KeePassPasskey marks new passkeys as backed up (synced), which is accurate for a passkey stored in a database file. Some services accept only device-bound passkeys. You can change the default for new passkeys (newPasskeyBackupEligible, newPasskeyBackupState), but marking a portable passkey as device-bound is a claim KeePassPasskey cannot back up.
• Attestation. KeePassPasskey creates passkeys without attestation, since a software authenticator has no manufacturer-signed key to prove its identity with. Services that enforce attestation, as identity providers such as Microsoft Entra ID can be configured to, will reject KeePassPasskey passkeys. See A site asks for enterprise attestation.

If your identity provider restricts passkeys by authenticator model (AAGUID), KeePassPasskey’s AAGUID is:

9addb28c-b46f-4402-808f-019651441ff3

Whether to allow it there is a policy decision: an AAGUID is a claim by the authenticator, not proof, so allowing it means allowing passkeys that can be copied with the database.

Other things that interfere

• Browser extensions of other password managers can intercept passkey requests before they reach Windows. If you deploy such an extension by policy, KeePassPasskey is never called in that browser. See Passkey prompts never show the Windows provider selection.
• Other passkey providers can be enabled at the same time. Windows asks the user which one to use.
• Focus Assist / Do Not Disturb only matters if the legacy notification prompts are turned on; the default dialog prompts are not affected.

Removing KeePassPasskey

1. Remove the app:

   # Stop provisioning it for new users (GitHub channel or provisioned installs)
   Get-AppxProvisionedPackage -Online | Where-Object DisplayName -like '*KeePassPasskey*' | Remove-AppxProvisionedPackage -Online
   # Remove it for all existing users
   Get-AppxPackage -AllUsers -Name '*KeePassPasskey*' | Remove-AppxPackage -AllUsers

   For Store installs deployed through Intune, use an uninstall assignment instead. Windows removes KeePassPasskey as a passkey provider together with the app.

2. Delete KeePassPasskey.dll from the KeePass Plugins folder while KeePass is closed.

3. For the GitHub channel, remove the certificate from Trusted People once no PC needs it any more.

4. Optionally remove the KeePassPasskey.* entries from KeePass’s configuration and the plugin log folder %LOCALAPPDATA%\KeePassPasskey.

The users’ passkeys stay in their databases as ordinary entries.

Troubleshooting for administrators

The Diagnostics page also shows both logs live and can write the state of the Windows credential cache to the log, which is the most useful thing to attach to a support ticket. Usernames are not written to the log in full.

Command-line options

The app installs the command KeePassPasskeyProvider.exe for every user it is installed for, so it can be run from any command prompt or PowerShell window without a path. The same actions are available as buttons on the app’s Diagnostics page.

The commands return exit code 0 on success and 1 on failure, so they can be used in scripts such as Intune remediations.

Everything here is per user: registration, the provider switch and the credential cache all belong to the signed-in user. Run the commands as that user and not elevated. From a tool that runs as SYSTEM, or as an administrator account, they report on that account, not on the user.

For specific error messages, see FAQ & Troubleshooting.