The CRA does not prescribe one universal authentication technology. Manufacturers need access-control mechanisms appropriate to the product's cybersecurity risks. Depending on the product, that can include user, administrator, service or device authentication, identity lifecycle controls, authorisation, privilege separation, session protections and mechanisms that provide information about possible unauthorised access.
The CRA Requirement Is Broader Than Authentication Alone
Annex I Part I point 2(d) requires products with digital elements, on the basis of the cybersecurity risk assessment and where applicable, to ensure protection from unauthorised access by appropriate control mechanisms. Authentication is specifically named, but it is one part of the broader requirement. Identity management and access management systems are also identified, and the provision includes reporting on possible unauthorised access. A compliance analysis should therefore avoid reducing the requirement to the existence of a login screen. The manufacturer needs to understand which users, administrators, services, devices or external systems can reach security-relevant functions or data and then apply controls appropriate to those trust relationships and risks.
- Identify security-relevant access paths.
- Identify human and machine identities.
- Determine which actions require authentication.
- Define authorisation and privilege boundaries.
- Provide suitable information about possible unauthorised access.
Authentication Establishes Identity or Access Claims
Authentication provides assurance that an actor presenting an identity or credential is permitted to use that identity. The appropriate mechanism depends on the product and risk. Passwords, cryptographic keys, certificates, hardware-backed credentials, federated identity, passkeys, tokens or other mechanisms can all appear in product architectures. The CRA does not prescribe one method for every product. A local consumer product and a remotely administered enterprise security appliance may require different assurance. Manufacturers should consider the consequences of account compromise, exposure of the authentication interface, privilege level, recovery processes and the security of credential storage. Authentication should also be evaluated for non-human access where services, APIs, devices or components act as authenticated principals.
- Match authentication strength to product risk.
- Protect stored authentication secrets.
- Review account recovery and enrolment paths.
- Consider API, service and device authentication.
- Test bypass and authentication-state failures.
Authentication and Authorisation Solve Different Problems
A product can authenticate a user correctly and still permit excessive access. Authentication determines whether an identity can be trusted to the required level. Authorisation determines what that identity is permitted to do. CRA protection from unauthorised access therefore requires attention to both. Product teams should identify roles, privileges, protected functions and data boundaries. Administrative functions, security configuration, update mechanisms, secrets, logs and sensitive data can require stronger access restrictions than ordinary product functions. Least privilege and separation of duties can be useful design principles where appropriate. The implementation should also prevent a user from changing identifiers, parameters or API requests to cross access boundaries that the interface appears to enforce.
- Define roles and permissions.
- Protect privileged functions.
- Enforce access controls server-side or at the authoritative component.
- Avoid relying only on user-interface restrictions.
- Test horizontal and vertical privilege escalation.
Identity Management Covers the Identity Lifecycle
Identity management includes more than the authentication event. Depending on the product, manufacturers may need to consider how identities are created, associated with users or systems, changed, suspended, revoked and removed. Products integrated with external identity providers should document the trust boundary and assumptions involved. Products with local identities should define how administrators manage accounts securely. Machine identities can require certificate, key or token lifecycle controls. Stale accounts, unrevoked credentials and unclear ownership can create unauthorised access even when the authentication protocol itself is technically strong. The product's identity model should therefore be part of the architecture evidence supporting Annex I point 2(d).
- Document identity creation and enrolment.
- Document suspension and revocation.
- Control privileged identity assignment.
- Manage service and machine identities.
- Remove access when identities are no longer required.
Access Management Should Follow the Product's Trust Model
Access management determines how permissions are assigned and enforced across product functions and resources. The design should reflect the product's real trust boundaries rather than assume that every authenticated user has equivalent privileges. Products can include administrators, operators, ordinary users, automated services, integration accounts, support personnel and remote management systems. Each can require a different access profile. Where the product supports externally managed permissions, the manufacturer should still understand which decisions remain under product control and how failures in the external service affect security. Access decisions should fail safely where appropriate, and administrative interfaces deserve particular attention because compromise can expose the rest of the product.
- Map roles to permitted actions.
- Limit administrative privileges.
- Review remote support access.
- Protect access-control configuration.
- Test failure behaviour when external identity services are unavailable.
Possible Unauthorised Access Must Be Reportable
Annex I point 2(d) also refers to reporting on possible unauthorised access. The appropriate implementation depends on the product and cybersecurity risk assessment. For some products, this can involve security events, administrative notifications, audit records or other mechanisms that allow relevant parties to identify suspicious access attempts or successful access that may not have been authorised. The requirement should be considered together with the CRA's separate provisions on recording and monitoring relevant security activity, but the two should not be collapsed into one generic logging statement. Authentication and access-control design should identify which events materially indicate possible unauthorised access and how those events become usable information.
- Identify meaningful unauthorised-access indicators.
- Record or surface relevant events.
- Protect access records against inappropriate modification.
- Avoid exposing sensitive authentication information in reports.
- Test that relevant events can actually be detected.
Authentication Should Work With Secure Default Configuration
Authentication controls can be undermined by insecure default configuration. A strong authentication mechanism offers limited protection if an unnecessary unauthenticated management interface is enabled by default, a universal administrator credential is active, or privileged access is automatically granted too broadly. Manufacturers should therefore review Annex I point 2(d) together with the secure-by-default requirement in point 2(b), while still maintaining separate requirement evidence. The product should begin from a configuration in which access protections are active where the risk assessment requires them. Setup and recovery workflows should not create temporary bypasses that remain active after commissioning.
- Enable required access protections in the default state.
- Avoid unnecessary unauthenticated interfaces.
- Review initial administrator provisioning.
- Test setup and recovery workflows.
- Remove temporary commissioning access when no longer required.
Evidence for CRA Authentication Requirements
Evidence can include identity and access architecture, role and permission matrices, authentication protocol design, credential-management specifications, administrative access rules, security tests and records showing how possible unauthorised access is surfaced. Testing can include authentication bypass, brute-force resistance where relevant, session management, privilege escalation, object-level authorisation and recovery flows. The evidence should identify the product version and applicable configuration. Where the manufacturer relies on an external identity service, documentation should explain the boundary between product controls and external controls so that the security assumptions remain visible in the cybersecurity risk assessment and technical documentation.
- Identity and access architecture.
- Role and permission matrix.
- Authentication and credential design.
- Access-control verification.
- Privilege-escalation testing.
- Unauthorised-access reporting evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.