Access Control Under the CRA: More Than Just a Login Screen
This post is the #6 in our blog series about the Cyber Resilience Act (CRA) requirements, specifically about Annex I Part I essential requirement 2(d). The requirement states that products with digital elements "ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access;" (Annex I, I.2d).
Foundation
The requirement lists authentication, identity, and access management as access control mechanisms, but this list is not exhaustive. The appropriate techniques are dictated by the risk-based framing set out for the CRA essential requirements: "an appropriate level of cybersecurity based on the risks," (Annex I, I.1). The regulation tells you that access must be controlled appropriately for the risk; it doesn't tell you how.
Traditionally, access control is divided into authentication (who is logging in) and access control (what actions are allowed). On simple systems these are the same thing; a validated user can do everything. On many systems users must only perform a limited set of actions, and more granular access control such as role-based access control is required. Sometimes the roles are simply administrator and user, but it can get arbitrarily complex. You may need to implement user management features, making the overall system more complex and error-prone.
How to implement user authentication
For user authentication, multi-factor authentication or hardware-backed credentials provides security improvement over mere passwords. In API authentication for machine-to-machine connections access is often certificate-based e.g. TLS with or without mutual authentication. For administration access, you may use SSH which allows public/private key based authentication. There are also many decisions to be made on session and credential lifecycle and expiry. None of this is mandated directly by the CRA text, but choices should be selected to match results of the risk assessment the CRA expects.
Reporting requirements
The reporting half of the requirement I.2(d) says "report on possible unauthorised access". The product needs to surface attempted or suspected unauthorised access events. This is closely related to I.2(l), which requires "recording and monitoring relevant internal activity, including the access to or modification of data, services or functions" and explicitly gives users an opt-out mechanism (Annex I, I.2l). This is quite close to I.2(d) text. It is not explicit if users should be allowed to opt-out from unauthorized access reporting, but to me it looks like a reasonable interpretation.
Limit the interfaces and secure confidentiality
Requirement I.2(d) is related to the requirement I.2(j) “limit attack surfaces, including external interfaces” which asks whether an interface should exist at all, or how exposed it should be. I.2(d) assumes the interface is necessary and asks whether access to it is properly controlled. A device that exposes an unnecessary debug port is an I.2(j) problem, a device with a necessary admin interface but a default password is an I.2(d) problem. Conflating the two may lead you to solve the wrong half of the problem, hardening an interface's authentication when the real fix was removing the interface.
Confidentiality is a similar trap, I.2(e) requires protecting the confidentiality of stored, transmitted or processed data, "such as by encrypting relevant data at rest or in transit" (Annex I, I.2e). It's tempting to treat access control as the mechanism that delivers confidentiality, but they're separate obligations addressing separate failure modes. An authorised session with weak transport encryption can still leak data in transit. Conversely, strong encryption doesn't help if the access control is weak.
Changes to access control mechanism might trigger a re-assessment
In relation to implementing access control, the Commission's guidance (Annex to Communication to the Commission "Approval of the content of the draft Communication from the Commission," C(2026) 5252 final, Brussels, 27 July 2026.) example 44 illustrates how an access-related change can trigger compliance consequences. In the example, a manufacturer adds a new "remember me" persistent-login feature that stores authentication tokens locally purely for convenience. The change introduces new risks around token theft and session hijacking that aren’t in a version which does not store the tokens. The guidance treats this as a substantial modification, meaning the essential requirements need to be re-evaluated. The lesson is that access control elements, like sessions, tokens, or credentials, have an impact on your product’s risk profile and implementation of access control mechanisms should be carefully considered.
Identity management and access management products
Finally, if your product is an identity or access management component itself, Annex III may classify it as an important product class I. The exact definition is "Identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers". If this matches, it pulls the product into stricter conformity assessment procedures, see CRA Articles 7 and 32.
Taken together, I.2(d) is less a single checkbox than a small cluster of obligations: risk-appropriate preventive controls, a runtime reporting capability, and careful documentation of how it's scoped against I.2(j), I.2(e), and I.2(l).
Read other posts on this CRA expert series to get a comprehensive view on CRA requirements:
