Deep Dive: CRA Requirement (c) – Security Updates and Opt-Out

The third essential cybersecurity requirement under the EU Cyber Resilience Act introduces a lifecycle dimension: products must support security updates after deployment, and those updates must be installed automatically, unless the user decides otherwise.

“(c) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;”

This requirement ensures that vulnerability management is not just a one-time effort but an ongoing responsibility. It pushes manufacturers to implement secure update mechanisms and make sure that staying secure doesn’t rely on user behavior or manual processes.

What This Requirement Means

Think about your smartphone. When a security flaw is discovered, you usually don’t need to visit a website, download a file, or call support. Instead, your phone checks for updates automatically, installs them in the background, and notifies you only if a restart is needed. You stay protected without even thinking about it.

That’s the mindset behind CRA Requirement (c). Security updates must be built into the product as a default behavior. Devices must automatically apply patches to fix vulnerabilities, without requiring the user to take action. This auto-update feature should be enabled by default, but users must still be given clear options to delay or opt out when needed.

For technical teams, this means the update mechanism must be tightly integrated into the system architecture. It must verify the origin and integrity of updates using cryptographic signatures and provide auditability, whether through logs, dashboards, or version tracking. While a home router, an industrial controller, and a battery management system will all have different update strategies, the objective is the same: ensure vulnerabilities can be resolved reliably, securely, and in a way that fits the product’s risk profile and operational context.

Relevant Standards and Guidelines

Several existing standards offer a foundation for implementing secure update mechanisms and update-related policies:

• ISO/IEC 27001 and 27002 offer broader guidance on update management and patching from an information security perspective.

• IEC 62443-4-1 and 62443-2-1 provide security update guidance specifically for industrial automation systems, including timely patch delivery, update qualification, and deployment processes.

• ETSI EN 303 645 requires consumer IoT products to support secure updates and makes auto-update the default setting.

• ISO/IEC 30111 and ISO/IEC 29147 support structured vulnerability handling and disclosure, including the process for distributing fixes.

• RED EN 18031 provides guidance for radio equipment, incorporating secure update methods like digital signatures or encrypted channels.

Although these standards provide useful building blocks, the CRA introduces new emphasis on default auto-update behavior, opt-out transparency, and postponement options, which are not fully detailed in current standards. This highlights the need for manufacturers to combine best practices with CRA-specific requirements.

How to Approach Implementation

To meet this requirement, manufacturers must build a reliable and secure update process that covers the entire product stack, from patch creation and signing to secure deployment on devices in the field. This process must not rely on user action to function, and it must support timely, authenticated, and verifiable delivery of security fixes.

At a minimum, the update mechanism should be able to:

• Verify the authenticity and integrity of updates using cryptographic signatures

• Apply security updates automatically, with this behavior enabled by default

• Notify users when updates are available and allow for opt-out or postponement

• Record update events for traceability and compliance

The practical implementation of these capabilities depends heavily on the system architecture.

In Industrial IoT and OT systems, the software stack is typically layered. Devices like industrial IoT gateways often run a hardened Linux-based operating system, include a container runtime (such as Azure IoT Edge or Balena), and use Docker containers to host application-specific workloads. In this architecture, all layers – the OS, the runtime, and the containers – must be manageable from an update perspective. If a vulnerability is identified, it is not sufficient to patch only the application. All components must support timely and secure updates, and the full chain of dependencies must be considered when planning lifecycle support. This requires careful selection of hardware platforms and vendors, as well as a structured approach to update orchestration across layers.

For embedded IoT devices, the update process is often technically simpler, typically involving a single firmware image (if there are no sub-components). However, it must be implemented in a constrained environment with limited compute resources and memory. Most embedded platforms lack mature open-source tools and standard update frameworks, which means key functionality must often be developed in-house. This includes the update process, rollback mechanisms, digital signature validation, and failure recovery. Even though the process may be single-layered, the effort required to implement a secure, CRA-compliant update mechanism remains significant.

Even when using off-the-shelf or plug-and-play solutions from third-party vendors, manufacturers cannot assume CRA compliance by default. Features such as automatic security update enablement, opt-out transparency, and postponement options are typically not fully implemented out of the box. This means additional effort may be required to implement these functions on top of the existing platform, if the architecture allows it. Where that is not feasible, it becomes critical to assess whether the vendor’s product roadmap explicitly supports CRA requirements and whether their update model aligns with your compliance strategy.

This topic builds on all key aspects of the CRA, explore our CRA Guide to access all related resources.

Compliance and Strategic Considerations

From a compliance standpoint, the update mechanism must not only be technically secure, but it must also be properly documented. According to Annex II, manufacturers are required to include clear instructions for users in the product’s user guide, including how updates are performed and how to opt out or postpone them. Annex VII further requires that the update process and how CRA requirements are fulfilled is documented as part of the product’s technical documentation.

If the update mechanism is provided by an external vendor, a careful evaluation is essential. This is especially true for features not yet standard in many industrial or embedded IoT systems, such as automatic updates by default or transparent opt-out options. Manufacturers must confirm that the vendor’s architecture supports these requirements and that their roadmap aligns with CRA expectations. Otherwise, compliance issues may emerge later that are difficult and costly to resolve.

From a strategic perspective, CRA Requirement (c) represents a shift in how updates are managed, particularly in the industrial domain, where automatic updates have so far been the exception rather than the norm. While the CRA does not mandate automatic updates in every case, it does require timely delivery, which increases the pressure on manual workflows. As the pace of required updates grows, automation will become the practical default. Manufacturers that act early and build a CRA-compliant update process can gain a competitive edge by reducing risk, improving efficiency, and ensuring long-term compliance.

In our next post, we will explore Requirement (d): Protection Against Unauthorized Access, an area that defines the minimum expectations for authentication, identity management, and access control in connected products.

Previous Blog CRA Requirement (b): https://www.tributech.io/blog/cra-requirement-b-secure-by-defaultNext Blog CRA Requirement (d):https://www.tributech.io/blog/cra-requirement-d-protection-from-unauthorised-access