Introduction
These comments identify unclear, incomplete and potentially difficult-to-implement requirements in the draft standard for password managers. Particular attention is given to Annex K on cryptography, which is important for implementing the requirements but is not linked clearly to specific obligations. This may make it difficult for small companies to determine what they actually need to implement and how compliance should be assessed.
Below are our comments on the draft, reproduced as submitted.
This review was made possible thanks to a grant from the CYBERSTAND programme.
Draft ETSI EN 304 618 V0.2.2 (2026-06) Cyber Security (CYBER); CRA; Cybersecurity requirements for password managers
- Comment 1 – Clause 5.1 – Justification of risk levels
Clause 5.1 assigns risk levels to the different use cases without explaining the rationale. The justification can be found in Annex B, but there is no reference to it from clause 5.1.
=> Proposed change:
Add a reference to Annex B for the justification of the assigned risk levels.
- Comment 2 – Clause 5.2.1.1 – REQ-AC-NORM-1 – CSRNG requirements are unclear
REQ-AC-NORM-1 requires a Cryptographically Secure Random Number Generator (CSRNG), but does not specify the requirements it needs to fulfil. Annex K does not make this clear either. The intended requirements appear to be those of ACM v2, section 7.
Random generation is critical for password generation, so the applicable requirements should be explicit. In particular, the requirement does not specify testing of the random generation.
=> Proposed replacement:
“Secure secret generation shall use Cryptographically Secure Random Number Generators (CSRNG) as defined in ACM section 7.”
- Comment 3 – Clause 5.2.3.1 – REQ-AC-CRIT-1 – Minimum p-value is not defined
REQ-AC-CRIT-1 leaves the minimum p-value to the implementer. This effectively allows any value to be selected, including one that does not provide an appropriate threshold for a Critical Risk use case.
=> Proposed change:
Split the requirement into two requirements:
- The manufacturer shall document the minimum p-value used.
- Define a minimum p-value appropriate for Critical Risk use cases.
- Comment 4 – Clause 5.3.1.1 – REQ-KEV-NORM-1 – Missing assets
REQ-KEV-NORM-1 does not include the assets described in B.1.1.5, which includes copies of the vault, or B.1.1.6, which includes decrypted vault content in memory.
=> Proposed change:
Add the assets from B.1.1.5 and B.1.1.6 to REQ-KEV-NORM-1.
More generally, the list of referenced assets is long. It is unclear whether listing the individual B clauses adds value compared with defining the applicable asset set directly.
- Comment 5 – Clause 5.4.1.1 – REQ-SD-NORM-1 – Master password complexity reference is unclear
REQ-SD-NORM-1 requires an entropy level “with a cited standard in line with Annex K”. The recommendations cited in the notes are informative and provide different recommendations. It is therefore unclear which value or method the manufacturer is expected to use.
=> Proposed change:
Clarify which normative entropy requirement, calculation method or threshold the manufacturer shall apply.
- Comment 6 – Clause 5.5.1.1 – REQ-SU-NORM-1 – Products without network access
REQ-SU-NORM-1 may not be implementable by a local-only or hardware-based password manager without Internet access. The requirement does not specify the expected behaviour when the product cannot access an update service.
=> Proposed change:
Define the expected update behaviour for products that cannot directly access an update service.
- Comment 7 – Clause 5.6.1.3 – REQ-AC-NORM-3 – MFA methods have different security levels
REQ-AC-NORM-3 lists MFA methods with different security properties, including SMS-based authentication. The same methods should not necessarily be accepted for all risk levels.
=> Proposed change:
Define allowed MFA methods according to the applicable use case or risk level. For example, SMS-based authentication should not be accepted for High and Critical Risk use cases.
- Comment 8 – Clauses 5.7.2.1, 5.7.2.2 and 5.7.2.3 – REQ-CON-HIGH-1, REQ-CON-HIGH-2 and REQ-CON-HIGH-3 – References to Annex K are not specific
REQ-CON-HIGH-1, REQ-CON-HIGH-2 and REQ-CON-HIGH-3 refer generally to Annex K without identifying which provisions apply. This makes the requirements difficult to implement and assess consistently (especially for SMEs).
=> Proposed change:
For each requirement, identify the specific provisions of Annex K that shall be taken into account.
- Comment 9 – Clause 5.8 – Missing requirement for integrity and removal protection
Clause 5.8 does not include a requirement protecting the integrity of stored vault data against unauthorized removal. Encryption at rest may provide integrity protection in some implementations, but this is not sufficient where a product uses multiple vault files or separately stored data.
An unauthorized user should not be able to remove part of a vault or an entire vault without appropriate authorization.
=> Proposed addition:
New requirement: “The product shall protect vault data against unauthorized partial or complete removal.”
- Comment 10 – Clause 6.3.1.1.3 – Vulnerability and VEX assessment timing
The current assessment effectively requires the manufacturer to provide VEX information for vulnerabilities in dependencies within 24 hours of their publication. This is not feasible in practice because the manufacturer needs time to identify, analyze and assess a newly published vulnerability.
=> Proposed change:
Assess vulnerabilities known at the product release date against the manufacturer’s most recent vulnerability verification performed before that release.
- Comment 11 – Clause 6.5.1.1 – ACC-SU-NORM-1 – Assessment requires network access
ACC-SU-NORM-1 cannot be performed as specified when the password manager has no direct network access and the manufacturer does not provide a custom driver or other management software capable of performing the update.
=> Proposed change:
For products without direct network access or manufacturer-provided update management software, allow the assessment to verify that the user is informed that an update is available and instructed to apply it.
