Authentication proves or establishes identity; authorisation determines what that identity may do. CRA-ready access-control design should define both, together with privilege boundaries, service identities, administrative functions, sessions, recovery and negative tests showing that unauthorised paths are rejected.
Annex I Explicitly Addresses Unauthorised Access
Annex I Part I point 2(d) requires protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access-management systems, and requires reporting on possible unauthorised access. The Regulation does not mandate one universal authentication protocol. The manufacturer needs to select mechanisms appropriate to the product's cybersecurity risk assessment, intended use and architecture.
- Identify who or what needs access.
- Identify protected functions and assets.
- Select risk-appropriate control mechanisms.
- Design evidence and testing around unauthorised-access scenarios.
Separate Authentication From Authorisation
Authentication and authorisation solve different security problems. Authentication establishes or verifies the identity of a user, device or service. Authorisation determines whether that authenticated identity may perform a requested action. A product can authenticate correctly and still be insecure if every authenticated user receives excessive privilege. Security requirements and tests should therefore distinguish identity verification from access decisions.
- Define authentication requirements.
- Define authorisation requirements separately.
- Test valid identities with insufficient privilege.
- Avoid assuming authenticated means fully trusted.
Define the Identity Model Before Building Login Screens
Authentication design starts with the identity model rather than the user interface. Products may contain end users, administrators, service accounts, devices, applications and cloud services, each with different trust and privilege. The architecture should define which identities exist, how they are established, what credentials they use and which component is authoritative for identity. This reduces ad hoc account types and unclear privilege relationships later in development.
- Identify user identities.
- Identify administrative identities.
- Identify device identities.
- Identify service identities.
- Define identity ownership and trust.
Apply Least Privilege to Product Roles
Least privilege means an identity receives only the access needed for its intended function rather than broad rights for convenience. Product design should identify privileged operations, separate administrative functions from ordinary use and avoid unnecessary default administrator access. Role-based, attribute-based or other access-control models can be appropriate depending on the product. The CRA does not mandate one model, but excessive privilege can undermine the requirement to protect against unauthorised access.
- Identify privileged operations.
- Separate normal and administrative roles.
- Limit default privileges.
- Review privilege escalation paths.
- Test lower-privileged identities against protected operations.
Administrative Interfaces Need Stronger Boundaries
Administrative functions can change security-sensitive configuration, accounts, updates and product behaviour. They therefore deserve particular architectural attention. Products should minimise unnecessary administrative exposure, authenticate administrators appropriately and enforce authorisation on the trusted side of the interface. Remote administration may require additional controls compared with local or physically restricted access, depending on the cybersecurity risk assessment.
- Minimise administrative exposure.
- Protect remote administration.
- Enforce server-side or trusted-side authorisation.
- Record important administrative activity where appropriate.
- Test direct attempts to reach protected functions.
Service and Device Identities Need Access Control Too
Access-control design should not focus only on human users. Devices, background services, APIs and cloud components may authenticate to each other and can hold substantial privilege. Service identities should have defined scopes, protected credentials and controlled lifecycle. One shared high-privilege service credential can create a large blast radius if compromised. Where practical, product architecture can separate identities by component or function.
- Inventory machine identities.
- Define service privileges.
- Avoid unnecessary shared service credentials.
- Protect service tokens and certificates.
- Support revocation where needed.
Session Management Is Part of Authentication Design
After authentication, products often maintain a session or token representing the authenticated identity. Session security should define lifetime, renewal, invalidation, logout and behaviour after credential changes. Sensitive privilege changes may justify reauthentication. Session tokens should be protected from disclosure or unauthorised modification because theft of a valid session can bypass otherwise strong login controls.
- Define session lifetime.
- Define logout and invalidation.
- Protect session tokens.
- Review privilege changes.
- Test expired and revoked sessions.
Recovery Must Not Become an Authentication Bypass
Password reset, account recovery and device recovery are alternative paths into an identity and can be weaker than normal authentication if not designed carefully. Recovery should establish sufficient confidence that the requester is authorised to regain access. Products should also define what happens to existing sessions and credentials after recovery. A strong primary authentication mechanism can be undermined if recovery depends on easily obtained information or a universal fallback credential.
- Threat-model recovery paths.
- Protect reset tokens.
- Avoid universal fallback credentials.
- Invalidate credentials or sessions where appropriate.
- Test recovery abuse cases.
Failures Should Default Toward Denying Unauthorised Access
Authentication dependencies can fail through unavailable identity services, expired certificates, corrupted credential stores or network loss. Product teams should define how access control behaves under those conditions. Automatically granting broader access because the normal identity service is unavailable can create a severe security weakness. Some products may need emergency or offline access, but that behaviour should be deliberately designed, constrained and tested rather than emerging accidentally from error handling.
- Define authentication-service failure behaviour.
- Avoid accidental fail-open access.
- Constrain emergency-access mechanisms.
- Test offline and degraded states.
- Document product-specific exceptions.
Test Access Control With Negative Cases
Access-control testing should demonstrate that prohibited behaviour fails, not only that legitimate users can complete normal workflows. Tests can cover unauthenticated requests, insufficient privileges, attempts to access another user's resources, direct calls to administrative endpoints, revoked credentials and expired sessions. High-risk roles and administrative interfaces deserve deeper adversarial testing because mistakes there can bypass multiple security controls.
- Test unauthenticated access.
- Test insufficient privileges.
- Test cross-user access.
- Test administrative endpoints.
- Test revoked credentials and sessions.
Retain Identity and Access-Control Design Evidence
Useful evidence can include the identity model, role or permission matrix, trust-boundary diagrams, authentication architecture, administrative-access design, credential lifecycle decisions and negative access-control tests. The evidence should explain how access decisions reflect product risks rather than merely naming the identity technology used. Significant changes to roles, authentication methods or privileged interfaces should trigger review of the cybersecurity risk assessment and related tests.
- Identity model.
- Role and permission matrix.
- Authentication architecture.
- Administrative-access design.
- Recovery design.
- Negative access-control tests.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.