The Cyber Resilience Act for identity teams: four dates, two roles, one reporting clock already running

The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, matters to identity teams in two ways. If you ship a product with a login, it makes authentication, access control and secure defaults legal requirements for selling it in the EU. If you build identity software, it goes further: identity management systems, privileged access management and password managers are listed as Class I important products, with a stricter route to conformity. The part most teams have missed is that one obligation is already live. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities in their products, including products placed on the market years ago.

Key takeaways

• The CRA regulates products, so its duties fall on manufacturers, importers and distributors. Identity teams inside other companies feel it mainly through procurement.
• Annex I turns "protect from unauthorised access" and "secure by default" into conditions of market access.
• Identity management, PAM and password manager products are Class I, which limits self-assessment.
• Reporting of actively exploited vulnerabilities applies from 11 September 2026, with a 24-hour early warning.
• That reporting duty covers products already on the market, not only new ones.
• 11 December 2027 is the date the main obligations apply. For a product roadmap that is close.

The four dates

The June 2026 date mostly concerns the bodies that will assess products. The September and December dates are the ones that create work for vendors and, through them, for their customers.

Role one: you build a product that has a login

Most software and connected hardware sold in the EU is a "product with digital elements." If yours has users, Annex I Part I applies to how they sign in. The text requires products to "ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems," to report on possible unauthorised access, and to ship with "a secure by default configuration," including the ability to reset to the original state.

The Regulation does not say "no default passwords" in those words. But a shared factory credential that works on every unit is hard to describe as secure by default, and the reports of possible unauthorised access imply logging that a security team can actually read. For an identity architect working on a product, the practical reading is:

• Unique credentials per device or tenant, or a forced setup step that creates them.
• Admin interfaces that support strong authentication, and preferably federation to the customer's identity provider over SAML or OpenID Connect.
• Sign-in and access events written somewhere a customer can collect them.
• A documented support period, during which you ship security updates. Manufacturers must decide it and tell buyers the end date at the time of purchase, per the Commission summary.

Role two: you build identity software

Annex III names "identity management systems and privileged access management software and hardware," including biometric readers, and password managers among the Class I important products. The consequence is about how you prove conformity. According to the Commission summary, Class I products may use self-assessment only if the manufacturer has applied harmonised standards, common specifications or a European certification scheme. Otherwise a notified body has to assess them.

That puts timing pressure on identity vendors. If the harmonised standards you plan to rely on are not finished, or you cannot apply them in full, you need a notified body, and the rules for notifying those bodies have applied only since 11 June 2026. Vendors who sell into the EU should already know which route they are taking. Customers can reasonably ask.

There is a second consequence that is easier to overlook. Products that broker access are among the most targeted software in any estate. Two of the four cases in our remote access appliance analysis were zero-days exploited before a fix existed, in BeyondTrust and Ivanti appliances. For a product in the CRA's scope, an event like that is now a reportable actively exploited vulnerability for the manufacturer, on a clock.

The reporting clock

The Commission describes the sequence: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident, then a full notification within 72 hours. Its summary adds a final report no later than 14 days after a fix or mitigation is available for a vulnerability, and within one month for a severe incident. Reports go through the Single Reporting Platform, which ENISA launched on 11 September 2026 and which routes each notification to the coordinating CSIRT and to ENISA.

The Commission's 11 September announcement says the reporting duty covers all products with digital elements made available in the EU, including those already on the market, and ENISA's platform FAQ says the same about products placed on the market before 11 December 2027. A vendor cannot wait for its next major release to start. The Commission's reporting page has the detail.

For an identity team on the customer side, this is mostly good news. It means a vendor whose SSO gateway or PAM appliance is being exploited now has a legal duty to tell authorities within a day. It does not, by itself, oblige the vendor to tell you on the same timeline, so your contract and the vendor's advisory process still matter.

What to ask your identity vendors now

You do not need to become a CRA lawyer to use the Regulation in procurement. These questions are reasonable for any identity product you buy, renew or already run in the EU:

1. What is the declared support period for this version, and where is it published?
2. Which conformity route will you use for 11 December 2027: harmonised standards, a certification scheme, or a notified body?
3. How will we hear about an actively exploited vulnerability, and how quickly relative to your 24-hour CRA early warning?
4. Does the product ship with any shared or default administrative credential? If so, how is it forced to change?
5. Can every administrative interface sit behind our identity provider and phishing-resistant MFA?
6. Which sign-in and access events can we export, and in what format?

Answers to questions 4 and 5 are useful whether or not the CRA ever reaches your contract. They are the same checks the NIS2 identity controls guide asks operators to evidence for their own systems.

What we do not know yet

Two things are worth watching. First, the Commission can adopt delegated and implementing acts that refine categories and procedures, so the technical boundary of "identity management system" may sharpen. Second, the harmonised standards that make self-assessment possible for Class I products are still the subject of European standardisation work; check their status with your conformity advisor before planning around them. We will update the CRA entry in the regulations hub as either changes.

Related reading

• Cyber Resilience Act in the glossary
• NIS2 and identity controls for NIS2
• What is PAM and password manager
• Security tools are identity infrastructure