Date
July 6, 2026
Typ
Audit

Re-tested: heylogin against the criteria of the BSI password manager test

On December 1, 2025, the BSI (Germany's Federal Office for Information Security) published a study on the IT security of password managers, carried out by the FZI Research Center for Information Technology. Ten products were assessed against a uniform test scheme; heylogin was not among them. At the end of January 2026, we commissioned the FZI to re-test heylogin (the "Private" variant) against the same standard. The final report has been available since May 4, 2026.

The overall verdict is clear: No fundamental concerns emerged that would speak against using heylogin. We are publishing the full report and, below, put into context where we are fundamentally stronger than the market and which points of criticism we have already addressed since the test.

Where we are fundamentally stronger

The FZI report places the results for heylogin directly alongside the ten products of the BSI study. Several points stand out where we set ourselves apart from the field:

  • No master password. heylogin uses a paired smartphone for unlocking instead of a master password. This makes the password manager two-factor secure by default, and entire classes of attack such as shoulder-surfing a master password (attacker model A01) are eliminated from the outset.
  • The entire content is encrypted. In the FZI's comparison table, this is the case for only a few of the products examined; with many well-known managers, the entire content is in fact not encrypted. heylogin belongs to the small group rated with "Yes" here.
  • Re-encryption after key rotation (post-compromise security). This is the point that sets us apart most clearly. heylogin re-encrypts the stored content after a change of keys, for example when a login device is removed. As a result, passwords stored after a possible compromise remain protected, rather than staying readable with a key that was obtained once. In the FZI comparison table, only two of the eleven products considered meet this: KeePassXC and heylogin. For a local password manager like KeePassXC, re-encryption is technically simple; for a cloud-based manager it is considerably more demanding. heylogin is therefore the only cloud password manager tested that offers post-compromise security. Details on this are in our Security Whitepaper, section "Post-Compromise Security".
  • No provider access to your data. The FZI confirms: the provider cannot access the stored data. Several other products are listed here with "Yes" or "not assessable".

In addition, there are secure, brute-force-resistant cryptographic methods. Hosting is exclusively in Europe, and we use exclusively European subprocessors. Your data does not leave the European legal area.

What we have improved since the test

An independent test is only worth something if you act on the results. Based on the report and several technical discussions with the FZI, we have implemented the following:

  • Password quality in the private plan. Analogous to the password policy feature for organizations, heylogin now also displays a quality indicator for stored passwords for private accounts. The criteria are based on the recommendations of the BSI (factsheet "Secure Passwords") and on NIST SP 800-63B: with at least 16 characters and all four character types, the passwords generated by heylogin exceed the BSI requirements, while length and automatic leak checking match the focus of NIST on what matters most. The FZI had suggested assessing stored passwords for their quality; that is exactly what we implemented.
  • Shorter lock times. We removed the longest option of "1 day". The new maximum and default value for automatic locking is now 8 hours instead of the previously criticized value of "2 a.m. the following day" (attacker model A02). Importantly: this timer only runs during inactivity. Any user action in the browser (scrolling, switching tabs, typing) resets it; the configured time only begins to elapse once the browser has been continuously idle. A shorter value therefore means no noticeable usability drawback in normal operation, and only takes effect when a device is actually left unattended.
  • Protection against screenshots. On Android, screenshots are now prevented, including while a password is displayed in plain text. On iOS, the absence of a media capture API means there is no corresponding risk (attacker model A05).
  • Modernized cryptography library. We replaced TweetNaCl with the actively maintained library noble. This reduces the risk from the supply-chain scenario (A03b) that the report raises in connection with the outdated TweetNaCl version. Details on this are in our Security Whitepaper (v3.8), section 6.1 "Cryptographic algorithms and key notation".

In addition: publicly available SBOMs (Software Bill of Materials), which the report also raises, will be implemented over the course of 2027 as part of our CRA preparation.

Two points for context

Two findings of the report we deliberately did not answer with a product change, but want to put into context:

  • Clipboard on Android. The report notes that the Android app does not clear the clipboard itself after manual copying (attacker model A05). However, the operating system handles this here: starting with Android 13, the clipboard is automatically cleared by Android after a short time. We assume that an Android version with current security updates is being used; for these, the protection is thus in place. The FZI refers to the same mechanism in its comparison table.
  • Domain matching in auto-fill. The FZI notes that our domain matching also suggests a login on related subdomains (attacker model A06). This is a deliberate trade-off: a login saved for dash.example.com should also work on auth.dash.example.com, as well as across related domains such as amazon.com and amazon.de. Overly strict matching would break these everyday cases and force users into manual copying, which is a risk in its own right. Naive suffix matching (example.com.evil.de) and matching up to the parent domain are, on the other hand, ruled out. The FZI made the same finding in the BSI report for 1Password as well, with the same conclusion that no fundamental concerns speak against its use. Details in our Website Matching help article.

Full transparency

We are publishing the full documents so you can form your own picture. The FZI report and the BSI study are available in German only:

Timeline

  • December 1, 2025: Publication of the BSI study (carried out by the FZI).
  • January 30, 2026: heylogin commissions the FZI for a re-test against the same scheme.
  • March 9, 2026: heylogin answers the FZI's questions to the manufacturer.
  • May 4, 2026: Final report available.
  • July 6, 2026: Implementation of the improvements (password quality, lock times, screenshot protection, noble) and publication of this report.