CRA Access Control and Authentication Requirements

The Cyber Resilience Act (CRA) requires products with digital elements to protect against unauthorised access through appropriate control mechanisms. Annex I Part I point 2(d) explicitly includes authentication, identity and access-management systems in that requirement. It does not, however, prescribe one login method, password policy or identity architecture for every product. Manufacturers need to select controls that are appropriate to the product's cybersecurity risks and then be able to show why those controls are suitable and effective.

For product teams, the practical task is broader than adding a sign-in screen. Access control has to cover human users, administrators, service identities, APIs, local maintenance interfaces, remote management, recovery paths and any other route that can reach security-relevant functions or data. The resulting design should be tied to the cybersecurity risk assessment, verified by testing and retained as product-specific security evidence.

The CRA's main product requirements apply from 11 December 2027. Manufacturers can use the implementation period to make access-control decisions explicit in product architecture and release evidence rather than reconstructing them during conformity work.

Start from the CRA requirement, not a preferred authentication technology

Annex I Part I point 2(d) requires products, on the basis of the cybersecurity risk assessment and where applicable, to protect against unauthorised access by appropriate control mechanisms. The text gives authentication, identity and access-management systems as examples and also requires products to report possible unauthorised access.

Two points follow from that wording.

First, the legal objective is protection against unauthorised access. Authentication is one mechanism for achieving that objective, not the entire requirement. A product can authenticate a user correctly and still fail to control what that user may do.

Second, the controls are risk-based. A simple local product with no privileged remote functions may need a different access model from an internet-connected management appliance controlling critical operations. The manufacturer should be able to connect the chosen mechanisms to the product's intended purpose, reasonably foreseeable use, attack surface and identified cybersecurity risks.

The European Commission's manufacturer guidance summarises access control alongside secure-by-default configuration, cryptography and automatic updates as part of the CRA's foundational security expectations. That reinforces the engineering interpretation: access control belongs in the product design, not only in operational documentation.

Separate authentication, identity and authorisation

These concepts are related but answer different questions:

identity establishes which user, device, service or process is represented;
authentication provides confidence that the claimant is that identity;
authorisation determines which actions or resources the authenticated identity may access; and
access management governs how identities, credentials, roles and permissions are created, changed, reviewed and removed.

A useful CRA access-control design should address all four where they are relevant.

For example, an administrative web interface may require strong authentication, but that alone does not prevent every authenticated operator from changing firmware-signing settings or exporting sensitive configuration. Those actions may need narrower permissions, re-authentication, separation of duties or other safeguards based on the risk assessment.

Similarly, a device-to-cloud API may have no human login at all. Its access-control problem concerns machine identity, credential provisioning, endpoint authorisation, credential rotation and revocation.

Build an inventory of protected entry points

Access-control gaps often occur outside the primary user interface. Product teams should inventory every path that can reach protected functions or data.

Typical entry points include:

local graphical or command-line interfaces;
web administration interfaces;
mobile or desktop clients;
public and private APIs;
remote-support channels;
debug and maintenance interfaces;
update and recovery mechanisms;
device-to-device or device-to-cloud connections;
service accounts and automation identities;
bootloader, console or factory-service modes; and
physical interfaces that expose privileged digital functions.

For each entry point, record what can be reached, which identities are expected, how they are authenticated, which permissions they receive and what happens after authentication failure or credential loss.

This inventory should match the real product architecture. An access-control document that covers only the customer-facing login while ignoring a maintenance API or factory credential provides weak evidence of the actual security boundary.

Define roles and privileges before selecting controls

A practical access model starts with permissions rather than credentials.

Identify the actors that need access and the operations each actor legitimately requires. Depending on the product, roles may include ordinary users, tenant administrators, service technicians, manufacturer support staff, automated deployment systems and internal product services.

Then apply least privilege: grant only the permissions required for the role and product function. High-impact actions should receive particular attention, such as:

changing security configuration;
creating or elevating accounts;
resetting credentials;
disabling security controls;
installing software or firmware;
accessing sensitive user or system data;
exporting secrets or credentials;
changing trust anchors or certificates; and
enabling debug or maintenance functionality.

The risk assessment should explain why an operation is protected and which actor is allowed to perform it. This makes later testing much more concrete: testers can verify both permitted and forbidden actions instead of checking only whether a login succeeds.

Treat default credentials as a product-design problem

The Commission's CRA manufacturer guidance explicitly uses the end of generic default passwords as an example of secure-by-default design. Shared, predictable or permanently embedded credentials can undermine access control even when the surrounding authentication mechanism is technically sound.

Product teams should examine how credentials are established at manufacturing, first use, provisioning and recovery. Relevant questions include:

Is a credential unique to the product or installation?
Must the user establish a new secret before privileged use?
Can factory credentials remain active after commissioning?
Are service credentials shared across customers or products?
Can credentials be rotated and revoked?
What happens when ownership changes?
Are credentials exposed in logs, configuration exports or support bundles?

The correct answer depends on the architecture. The evidence should show that credential lifecycle risks were considered rather than relying on an undocumented assumption that users will change insecure defaults themselves.

Design recovery paths to the same security standard

Password reset, account recovery, emergency access and factory-reset flows frequently bypass normal authentication. Attackers know this, so recovery mechanisms belong inside the access-control threat model.

For each recovery path, document:

who may initiate it;
what evidence of identity or possession is required;
which privileges become available after recovery;
whether existing sessions or credentials are invalidated;
whether the event is visible to the legitimate user or administrator; and
how abuse can be detected or investigated.

A recovery mechanism should not silently create a weaker route to the same privileged capability. If physical possession is used as part of the trust model, document what physical access actually proves and whether reasonably foreseeable attackers may also obtain it.

Control machine identities and service-to-service access

Modern products often depend on services that authenticate to each other. These identities need lifecycle controls just as human accounts do.

Useful design evidence can cover:

how a device or service identity is provisioned;
whether credentials are unique or shared;
where secrets are stored;
how authentication material is renewed;
how compromised identities are revoked;
how permissions are scoped to the minimum required API or resource;
whether development and production identities are separated; and
how an identity is retired when a device, tenant or service is decommissioned.

Do not equate encrypted transport with authentication. TLS can protect a channel while still leaving uncertainty about which application identity is authorised to invoke a sensitive operation. Conversely, authentication without appropriate transport protection may expose credentials or session material.

Include local and physical interfaces in the threat model

A network login is not the only path to unauthorised access. Products may expose serial consoles, USB maintenance modes, diagnostic ports, boot menus or removable storage interfaces that bypass application-level controls.

Whether such an interface requires authentication depends on the risk assessment and intended environment, but the decision should be explicit. Consider:

whether the interface is available in the shipped product;
whether enabling it changes the security state;
whether it can read or modify protected data;
whether it can install executable code;
whether access persists after a reset;
whether the interface is intended for end users, service staff or manufacturing only; and
what prevents a manufacturing-only mechanism from remaining usable in the field.

Physical access can be part of a control model, but it should not be used as an automatic justification for leaving high-impact digital functions unrestricted.

Make failed and suspicious access observable

Annex I point 2(d) goes beyond preventing unauthorised access by referring to reporting possible unauthorised access. That creates a connection between access control and product security logging or user/admin notification where applicable.

A product team should decide which events provide useful evidence of attempted or possible compromise. Examples may include repeated authentication failures, privileged-account changes, use of recovery functions, unexpected credential resets, blocked authorisation attempts or activation of sensitive maintenance modes.

Avoid collecting events without a defined security purpose. Logging decisions also interact with confidentiality, integrity, data-minimisation and storage constraints. The useful question is: what information is needed to identify and investigate a plausible unauthorised-access event for this product?

Test negative paths, not only successful login

Access-control testing should demonstrate that the product rejects operations that should not be allowed.

A release-oriented test plan can include:

valid and invalid authentication attempts;
expired, revoked and malformed credentials;
privilege escalation attempts;
direct API calls that bypass the user interface;
access to another user's or tenant's resources;
session expiration and logout behavior;
credential-reset and recovery abuse cases;
rate or lockout behavior where applicable;
service-account scope violations;
attempts to invoke privileged functions from lower-privilege roles;
maintenance and debug-interface access; and
behavior after account, device or credential revocation.

The goal is not to prove that no access-control vulnerability can ever exist. It is to retain evidence that the implemented controls were systematically challenged against the identified risks and expected permission model.

Keep access-control evidence tied to the release

Access models change. New APIs appear, roles gain permissions, recovery mechanisms are redesigned and remote-management functions are added. A static access-control matrix that is not connected to product versions can become misleading.

For each relevant release, useful evidence may include:

the protected-interface inventory;
identity and role definitions;
permission or policy matrices;
authentication and credential-lifecycle decisions;
architecture and trust-boundary diagrams;
risk-assessment references;
threat-model findings;
access-control test cases and results;
security-relevant defects and remediation records;
approved exceptions with rationale; and
change records showing why permissions or mechanisms changed.

The evidence does not need to live in one document. It does need enough traceability to show which product, variant and release a decision or test result supports.

Review third-party identity components as part of the product

Using an identity provider, authentication library or external access-management component can reduce implementation work, but it does not remove the manufacturer's need to assess the product's access-control behavior.

Review the integration boundary: which security decisions are delegated, which remain in product code, how configuration is controlled, how vulnerabilities in the component are handled and how the product behaves if the external identity service is unavailable or misconfigured.

For remote services that form part of the product under the CRA's remote-data-processing definition, access-control evidence should cover the combined local and remote product boundary. A strong cloud identity service cannot compensate for an API endpoint that fails to enforce product-level authorisation correctly.

Use BSI TR-03183 as implementation support, not as the law itself

BSI TR-03183 Part 1 is a technical guideline intended to translate CRA-oriented manufacturer and product requirements into more implementable technical expectations. It can help engineering teams structure controls and evidence, but the CRA remains the binding legal source.

This distinction matters when building internal checklists. Cite Annex I for the legal requirement, then use technical guidance and applicable standards to inform how the control is engineered and verified for the specific product.

As harmonised CRA standards mature, manufacturers should review whether their chosen conformity-assessment path and applicable standards introduce more specific access-control test or documentation expectations.

Keep the access decision connected to security evidence

Access control is rarely one isolated requirement. A role change may affect threat models, API tests, release blockers, vulnerability decisions and technical documentation at the same time. When those records live in separate systems, teams can lose the connection between the requirement, the implemented control and the evidence for a specific release.

AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. That model can support access-control work by keeping the applicable requirement and supporting evidence connected to the relevant product and release, while the manufacturer remains responsible for engineering decisions and CRA conformity.

Practical access-control evidence checklist

Before treating an access-control requirement as release-ready, verify that the team can answer:

Which product functions and data require protection from unauthorised access?
Which human and machine identities can reach them?
How is each identity authenticated where authentication is applicable?
What is each identity authorised to do?
Are privileged operations separated from ordinary access?
How are credentials provisioned, rotated, revoked and recovered?
Are factory, debug and maintenance paths controlled in the shipped state?
Are failed or suspicious access attempts observable where appropriate?
Have negative authorisation and recovery cases been tested?
Are findings, exceptions and remediation decisions retained?
Can the evidence be tied to the exact product, variant and release?

If several answers depend on tribal knowledge, the engineering controls may exist but the evidence model is not yet robust enough for repeatable lifecycle governance.

Key takeaway

The CRA does not reduce access control to a mandatory password rule or a single authentication standard. Annex I Part I point 2(d) sets an outcome: products should protect against unauthorised access through appropriate control mechanisms, including authentication, identity or access-management systems where applicable, based on the cybersecurity risk assessment.

Product teams should therefore map protected interfaces and functions, define identities and privileges, secure credential and recovery lifecycles, test forbidden paths, make suspicious access observable where appropriate and retain release-specific evidence for those decisions. The strongest implementation is one where the access model, risk rationale, test results and product version remain connected as the product evolves.

Official sources

Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
Cyber Resilience Act - Manufacturers — European Commission
BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products — German Federal Office for Information Security (BSI)