CRA compliance reshapes password manager security requirements

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Dashlane's blog post: The EU Cyber Resilience Act will push password managers into a regulated security baseline with CE marking, self-assessment, and tighter reporting duties.

Why it matters: This matters because password managers sit at the center of credential storage and access, so CRA requirements will affect procurement, audit evidence, and control design across NHI and human IAM programmes.

By the numbers:

• Starting September 2026, manufacturers must notify ENISA and their national CSIRT within 24 hours of discovering an actively exploited vulnerability or a severe security incident.
• A fuller notification is due within 72 hours and a final report within 14 days.
• By December 2027, all password managers sold in the EU will have to self-assess conformity to the new standard.

Context

The Cyber Resilience Act changes how a password manager is governed because it is no longer treated only as a convenience tool. A product that stores secrets, issues authentication events, and logs vault access now sits inside a formal compliance regime that links security design to market access.

Dashlane's analysis points to a wider shift in which security expectations for credential platforms become explicit, testable, and auditable. For identity teams, that means procurement, security architecture, and assurance evidence have to line up with the same control baseline rather than being handled as separate conversations.

Key questions

Q: How should teams evaluate password managers under new product-security rules?

A: Evaluate password managers against secret storage, sharing, and recovery controls, plus how they support account ownership, least privilege, MFA, and emergency access. Check whether they can produce tamper-evident logs, enforce admin separation, and support incident reporting readiness for credential theft or vault compromise. The tool should also allow rapid rotation, export control, and offboarding of shared secrets.

Q: What should security teams look for in password manager audit logging?

A: Look for logs that record who accessed which vault, which secret was viewed, copied, shared, edited, or rotated, and from where. Good audit logging ties each event to a named user or service account, preserves timestamps, supports alerting on unusual vault access, and is protected from alteration so investigations can trust it.

Q: How do product security regulations affect identity governance programmes?

A: Product security regulations push identity governance programmes to prove who has access, why they have it, and how it is reviewed. That usually means tighter joiner-mover-leaver controls, stronger privileged access oversight, more frequent access recertification, clearer ownership of accounts and entitlements, and evidence that access changes and exceptions are tracked end to end.

Q: What is the best way to manage reporting deadlines after a severe security incident?

A: Manage reporting deadlines with a documented incident response process that assigns roles, preserves evidence, and tracks when the incident was detected, contained, and assessed. Build in legal and regulatory triage, escalation paths, and time-stamped decision logs so the team can meet notification windows even while containment and recovery are still under way.

Technical breakdown

Why password managers fall into the CRA's important-products class

The CRA separates digital products into risk-based classes, and password managers are treated as important products because they handle credentials, authentication material, and protected access paths. That classification matters because it moves the product from generic security expectations into a regime with defined conformity obligations. In practice, the product is judged not just on features but on whether its security properties can be demonstrated, documented, and maintained across its lifecycle. For identity programmes, this is the point where a password manager becomes part of regulated control evidence rather than a standalone consumer or enterprise utility. See the Password Manager Buyer's Guide.

Practical implication: Treat password manager selection as a regulated control decision, not a tooling preference.

What EN 304 618 is trying to standardise

EN 304 618 is the draft standard that will define the requirements password managers are assessed against under the CRA. The controls described in Dashlane's analysis focus on the core trust functions of a credential vault: secret generation, encryption, authentication, session management, and audit logging. That combination shows the standard is not only about protecting stored passwords but about controlling how credentials are created, used, and evidenced in operation. The security model therefore spans both data protection and access integrity, which is why it has implications for NHI and human identity governance alike. See the Password Security and Password Manager Guide.

Practical implication: Map vault and credential controls to the draft standard early so gaps are visible before formal assessment.

How incident reporting changes the operating model for vendors

The CRA introduces tight reporting clocks for actively exploited vulnerabilities and severe security incidents, which means product security and incident response can no longer be handled as slow, discretionary processes. Once a vulnerability is discovered, the reporting timeline becomes part of the compliance path, not an afterthought. For a password manager vendor, that creates pressure for asset inventory, vulnerability triage, evidence capture, and decision ownership to be aligned before an incident occurs. The requirement also changes how customers should evaluate assurance, because responsiveness now sits inside a regulatory duty rather than a best-effort support commitment.

Practical implication: Build incident escalation paths that can support same-day notification decisions and evidence capture.

NHI Mgmt Group analysis

CRA regulation turns password managers into governed identity infrastructure: Once a password manager stores credentials, authenticators, and vault events, it is no longer just a productivity layer. The CRA effectively treats it as regulated security infrastructure whose controls must be demonstrable, not assumed. That matters because identity programmes often buy these tools for convenience and only later discover they are part of audit, procurement, and risk governance. Practitioners should treat this as a boundary shift in how the category is managed.

Security by design becomes measurable when compliance ties controls to the product category: Dashlane's framing shows that the market is moving from voluntary claims about secure architecture to a standardised baseline for secret generation, encryption, session handling, and logging. That creates a clearer expectation for evidence, but it also narrows the room for vague assurances. The implication is that control design and proof will matter together, especially when evaluating password security controls against regulated expectations.

Credential platforms now sit at the intersection of human IAM and NHI governance: Password managers are often discussed as human tools, but the operational reality is broader because they store reusable secrets that support APIs, service workflows, and delegated access paths. Regulation that reaches this layer has knock-on effects for how organisations inventory credentials, attribute ownership, and prove lifecycle control across identity types. Teams should read the CRA as a signal that one vault can no longer be governed as if it only served one identity population.

Named concept, regulated security baseline: The most useful way to describe this shift is as a regulated security baseline for credential platforms. That baseline does not replace architectural judgement, but it does define the minimum evidence a supplier must be able to produce before a customer can rely on the product. The practical consequence is that procurement, security review, and compliance evidence will increasingly converge on the same control set.

What this signals

Credential platforms are becoming compliance objects: once a password manager is regulated as an important product, the control conversation shifts from feature choice to evidence quality. That changes how IAM, procurement, and security teams should assess suppliers, because the question is no longer whether the tool is convenient but whether it can stand up to scrutiny across its full lifecycle.

The next governance pressure point is assurance consistency. Organisations that rely on one vault for user access, shared credentials, and delegated workflows will need a clearer inventory of who owns each credential path, what evidence exists for each control, and which reporting obligations are triggered when risk turns into an incident.

For practitioners

• Assess password managers against regulated control evidence Require suppliers to show how secret generation, encryption, authentication, session management, and audit logging are implemented and evidenced.
• Align procurement with CRA conformity milestones Track whether the product class, self-assessment path, and reporting obligations fit your buying cycle and assurance calendar.
• Review incident notification ownership now Define who decides whether a vulnerability or incident meets the 24-hour, 72-hour, and 14-day reporting thresholds.
• Separate vault assurance from generic security claims Ask for control mapping, test evidence, and logging detail rather than relying on broad statements about security or privacy by design.

Key takeaways

• The CRA reframes password managers as regulated security infrastructure, not just productivity software.
• The most important evidence areas are secret generation, encryption, authentication, session management, and logging.
• Identity teams will need tighter supplier assurance, clearer incident ownership, and better lifecycle evidence for credential platforms.

Related NHI Mgmt Group resources: Password Security and Password Manager Guide · Password Manager Buyer's Guide · Cyber Resilience Guide

Key terms

• Cyber Resilience Act (CRA): The Cyber Resilience Act is an EU law that sets cybersecurity requirements for products with digital elements before they are placed on the market. It requires vendors to build in secure development, vulnerability handling, and update processes, while helping reduce supply chain risk across devices, software, and connected services.
• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Zero-Knowledge Architecture: A design pattern in which the service provider cannot decrypt customer data because it never receives the keys needed to do so. The provider may store encrypted data and coordinate sync or processing, but it remains technically unable to read plaintext unless the architecture is broken.
• Conformity assessment: A conformity assessment is the formal process used to show that a high-risk AI system meets the obligations required before it is placed on the market. It combines documentation review, technical verification, and evidence of operational controls, rather than relying on policy statements alone.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.