Where the CRA puts password managers Annex III, Art. 7(1), Art. 7(4)
Annex III of the CRA lists the product categories the regulation treats as "important products with digital elements", split into Class I and Class II. "Password managers" appear by name in Class I, item 3. A product with digital elements that has the core functionality of a listed category is an important product and becomes subject to the stricter conformity assessment procedures of Article 32(2) and (3).
The Commission has specified the technical description of each category in an implementing act, as Article 7(4) required it to do by 11 December 2025 (Implementing Regulation (EU) 2025/2392). That description, not the plain-language label, decides whether your product matches the category.
The core functionality test Art. 7(1)
Classification turns on core functionality. A standalone password manager, or the password vault at the heart of a broader security suite, has the core functionality of the category. The reverse also holds: integrating a password manager into a product does not in itself make that product an important product. Article 7(1) says so explicitly for integrations.
The practical gray zone is a product that stores credentials as one feature among many, such as a browser with a built-in vault or a business app that remembers logins. Whether that crosses the line is exactly the judgment the technical descriptions exist to settle, so resolve it against Implementing Regulation (EU) 2025/2392 and record your reasoning.
Judgment call: The line between "core functionality" and "a feature" has no bright-line rule in the CRA itself; the technical descriptions control, and close calls deserve documented reasoning.
What Class I changes: your conformity route Art. 32(1), Art. 32(2), Annex VIII
Manufacturers of default-category products choose their conformity assessment procedure freely, including plain self-assessment under internal control (module A). For a Class I important product that choice narrows: internal control remains available only where you apply harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least "substantial", in full, to the relevant essential requirements.
Where you do not, or where such standards do not exist for the requirement in question, the product must go through EU-type examination followed by conformity to type (modules B and C), or full quality assurance (module H). Both involve a notified body, which means lead time and cost worth planning for well before 11 December 2027.
Everything else is the ordinary manufacturer programme Art. 13, Art. 14, Annex I
Class I status changes the conformity route, not the substance. The essential cybersecurity requirements, the vulnerability handling duties including a coordinated vulnerability disclosure policy, technical documentation, CE marking, and the reporting duties for actively exploited vulnerabilities and severe incidents apply to a password manager exactly as they do to any other product in scope.
Open-source password managers Art. 3(22), Recital 15, Recital 18, Art. 32(5)
Two distinct reliefs can matter here. First, free and open-source software supplied outside a commercial activity is not "made available on the market" at all, so the CRA does not bite; paid tiers, paid hosting, or dual licensing change that. Second, where an open-source password manager is in scope, Article 32(5) lets its manufacturer use the ordinary Article 32(1) procedures, including internal control, despite the Class I listing, provided the technical documentation is made available to the public when the product is placed on the market.