Deep Dive: CRA Requirement (d) – Protection from Unauthorised Access

In IoT and OT systems, one of the biggest risks is unauthorised access to devices, services, or data. Weak passwords, open interfaces, or insecure protocols can provide attackers with an easy entry point. Requirement (d) of the EU Cyber Resilience Act introduces a clear duty for manufacturers: connected products must include appropriate access control mechanisms such as authentication and identity management, and they must be able to detect and report attempts of unauthorised access. The Cyber Resilience Act introduces a clear duty for manufacturers of connected products:

“(d) 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;”

This requirement is broad but essential. It covers everything from preventing attackers from logging into a smart device with stolen credentials, to controlling which operators can change critical settings in an industrial plant. Just as importantly, it obliges manufacturers to detect and report when unauthorized access is attempted. In this blog, we will explore what the rule means in practice, which standards already exist, where gaps remain, and how to approach implementation across different environments.

What This Requirement Means

Think about boarding a plane. Before you even get near the gate, you pass through multiple checks: passport control, baggage scans, boarding passes. If anything suspicious shows up, alarms go off and staff act immediately. In the digital world, authentication and access management are those checkpoints, preventing unauthorized travelers from ever reaching critical systems.

This means your product must have sound identity and access control, so only authorised people, devices, or services can use sensitive functions or data. The product should also notice suspicious access attempts and surface them to the right audience, for example an admin or a support team, so action can be taken. In other words, do not just prevent, also detect and report.

Form a technical point of view, this implies strong authentication, lifecycle management of identities, policy driven authorisation, and session control across device, cloud, and app surfaces. It also requires recording and monitoring of access events so that possible unauthorised access can be reported in a timely and useful way. The logging and monitoring duty in Annex I point 2(l) supports this outcome by requiring recording of relevant internal activity including access to or modification of data, services, or functions.

Relevant Standards and Guidelines

There is already a solid stack of well known standards that cover identity, authentication, and access control. While the Act may introduce new harmonised standards, these existing works are the natural starting point and are very likely to be referenced or built upon. They differ in scope, with some aimed at general IT, some at IoT, and some at industrial systems.

• EN IEC 62443-4-2 (industrial systems): Specifies technical security requirements for industrial automation and control components, including confidentiality of data at rest and in transit. Tailored for OT environments.

• EN 18031 (RED – Radio Equipment Directive): Addresses secure update and authentication mechanisms for radio equipment, including use of encryption and digital signatures.

• ETSI EN 303 645 (consumer IoT): Sets baseline requirements for IoT devices, including secure communication, cryptography, and protection of personal data. Strong for consumer products, but limited for industrial and embedded contexts.

• ITU-T X.814 (general IT): Defines confidentiality services, mechanisms, threats, and attacks. A generic framework, useful for design concepts but not detailed in protocol exchanges.

• ITU-T X.805 (general IT): Provides a generic architecture for end-to-end communication security, independent of protocol stacks. Covers principles but not specific mechanisms.

• ISO/IEC 18033 (general IT): Describes encryption algorithms for stored and transmitted data, covering both symmetric and asymmetric ciphers. Does not cover key management in detail.

Despite this coverage, significant gaps remain in the most relevant standards. IEC 62443-4-2, while strong for industrial automation, defines confidentiality and access requirements at a generic level and assumes the presence of mature infrastructure such as centralised identity systems. It does not provide detailed guidance for constrained or embedded devices often used in industrial settings. ETSI EN 303 645 sets important consumer IoT baselines, but it mostly addresses authentication and basic cryptography, leaving gaps around fine-grained access control and especially around reporting of unauthorized access attempts to users or operators. EN 18031, developed under the Radio Equipment Directive, defines methods for secure updates and use of cryptography, but it focuses on communication channels rather than full identity and access management. None of these standards provide comprehensive mechanisms for detecting and reporting unauthorized access, which is the gap the CRA requirement is designed to fill.

How to Approach Implementation

Start by breaking the regulation down into practical product capabilities. Build an access control stack that matches your risk profile and use case. Ensure it not only blocks unauthorized access but also provides a clear way to alert users or operators when something suspicious happens.

To effectively meet this requirement, the following steps and capabilities should be considered:

• Strong authentication for users, devices, and services

• Identity lifecycle management including provisioning, update, and revocation

• Policy based authorisation and least privilege for every sensitive function

• Protected administrative interfaces and separation of duties

• Session management, timeouts, and re authentication for sensitive operations

• Rate limiting, lockouts, and other brute force defences

• Physical access protections and tamper resistance where relevant

• Comprehensive logging of access attempts and outcomes

• Alerting and user facing notification of possible unauthorised access

• A clear path to escalate serious findings into your incident and reporting process

For industrial systems, this means implementing access control across multiple layers: local human machine interfaces, edge gateway management interfaces, remote APIs, and device-to-cloud connections. Role-based access control, audit logging, and session management are essential. Often, these systems also require integration with external identity providers, such as LDAP or Active Directory. Additionally, they must be able to report failed login attempts, unauthorised API calls, or tampering attempts on configuration files or system binaries.

For embedded systems, the challenges are different but just as critical. Devices with limited resources must still enforce authentication at bootloaders, serial interfaces, or configuration tools. Debug and test interfaces must be disabled or locked before production. Identity management may be based on cryptographic identifiers or secure elements, and logging capabilities may need to be implemented in lightweight, tamper-evident ways. If logging to the cloud is not feasible, local event logs should be available for diagnostic purposes and traceability.

Reporting of unauthorised access should not be overlooked. This can range from simple event logging and local status flags to full integration with remote monitoring platforms. What matters is that the device does not fail silently. It must leave evidence of attempted or successful bypasses that operators or compliance processes can detect.

Compliance and strategic considerations

CRA compliance requires not just that access control mechanisms exist, but that they are effective, testable, and clearly documented. According to Annex VII, manufacturers must describe how access is granted, how identities are managed, how failed access attempts are detected, and what reporting mechanisms are in place.

If key security functions such as identity or access management are outsourced to third-party vendors, a detailed review is essential. Many industrial and embedded products still rely on legacy components or designs that were never built with access control in mind. These systems may lack proper logging, use insecure defaults, or expose interfaces that are difficult to secure retroactively.

From a strategic point of view, Requirement (d) reinforces the idea that access control is no longer a feature—it is a baseline expectation. Products that do not enforce access controls or report misuse will be noncompliant by default. Building access protection into the product from the start reduces risk, lowers long-term maintenance costs, and supports the broader goals of secure product lifecycle management.

In our next post, we will explore Requirement (e): Protection from Known Exploited Vulnerabilities During Operation—focusing on how to maintain protection throughout a product’s lifetime, not just at the point of release.

Previous Blog CRA Requirement (c): https://www.tributech.io/blog/cra-requirement-c-security-updates-and-opt-outNext Blog CRA Requirement (e):https://www.tributech.io/blog/cra-requirement-e-protecting-confidentiality-of-data