This guide explains how to build a CRA secure development lifecycle that fits your organisation and product portfolio. It covers SDL phases, concrete security activities, documentation requirements and how SDL links to CRA obligations such as risk assessment, vulnerability handling, updates, logging and technical documentation.

For broader context on Cyber Resilience Act obligations, you may want to review our articles on CRA requirements, scope and how to prepare, CRA risk assessment and CRA technical documentation.

1. Why the CRA Secure Development Lifecycle Matters

The Cyber Resilience Act does not use the term “SDL” formally, but its core ideas are embedded in the essential cybersecurity requirements and lifecycle obligations. A CRA secure development lifecycle matters because it:

• Translates high-level CRA security requirements into repeatable engineering activities.
• Reduces the risk of introducing avoidable vulnerabilities during development.
• Provides evidence that security-by-design and security-by-default are applied in practice.
• Supports vulnerability handling, updates and post-market monitoring across the product lifecycle.

Without an SDL, security improvements tend to be reactive, ad hoc and difficult to document in the CRA technical file. With a lightweight but structured CRA secure development lifecycle, security becomes an integral part of how products with digital elements are built and maintained.

2. What the CRA Expects from Secure Development

The Cyber Resilience Act expects manufacturers to ensure that products with digital elements:

• Are designed, developed and produced in accordance with essential cybersecurity requirements.
• Implement security-by-design and security-by-default principles.
• Support secure configuration, secure updates and secure communication.
• Remain secure throughout their expected lifecycle, with appropriate vulnerability handling.

These expectations are not satisfied by a single technical control or penetration test. Instead, they require an underlying CRA secure development lifecycle that connects requirements, design, implementation, testing and maintenance in a coherent way.

To build this lifecycle, you should align it with your CRA risk assessment, your vulnerability handling processes and your CRA logging and monitoring approach.

3. Core Phases of a CRA Secure Development Lifecycle

A CRA secure development lifecycle can be implemented in various ways, but most organisations follow a set of recurring phases. Whether you use agile, waterfall or hybrid models, you can map these phases to your existing process.

3.1 Requirements and planning

In the requirements phase, your SDL should ensure that:

• Product requirements explicitly include security and CRA-related objectives.
• Non-functional requirements cover security, privacy and resilience.
• Regulatory requirements, including CRA and other EU acts, are identified for the product.
• Assumptions about the operating environment, threats and dependencies are documented.

This is where you connect your CRA secure development lifecycle to your product classification and requirement mapping work.

3.2 Architecture and design

In the design phase, CRA expectations around security-by-design become concrete:

• Architectural diagrams show components, interfaces and trust boundaries.
• Security controls are selected to mitigate assessed risks.
• Security-by-default decisions are documented (e.g. default disabled services, minimum privileges).
• Threat modelling is performed for critical components and data flows.

Design reviews should explicitly verify that CRA security requirements are addressed by the proposed architecture.

3.3 Implementation and secure coding

During implementation, the CRA secure development lifecycle focuses on secure coding and dependency hygiene:

• Developers follow secure coding guidelines relevant to the languages and platforms used.
• Static application security testing (SAST) or linters are integrated into the build pipeline where feasible.
• Dependencies are managed carefully, feeding into your CRA SBOM.
• Sensitive information such as secrets, keys or credentials is handled via secure mechanisms, not hard-coded.

3.4 Verification, validation and security testing

Testing under a CRA secure development lifecycle goes beyond functional checks:

• Unit and integration tests include security-relevant behaviours (e.g. access control, error handling).
• Security testing methods, such as SAST, DAST (dynamic testing) or fuzzing, are applied where appropriate.
• Abuse cases and negative scenarios are tested, not only normal user flows.
• Findings are triaged, tracked and fixed, with evidence stored for the technical file.

3.5 Release and deployment

Before release, CRA SDL activities should include:

• Security sign-off or a final review of high and critical findings.
• Verification that security configuration defaults are correct in production builds.
• Packaging of release artifacts in a way that supports secure update mechanisms.
• Documentation updates, including user-facing security information and internal technical documentation.

3.6 Maintenance, updates and post-market monitoring

After release, the CRA secure development lifecycle connects to vulnerability handling, monitoring and updates:

• Field feedback, vulnerability reports and incident data feed back into the SDL.
• Security updates follow a documented process with regression and security testing.
• Configuration of logging and monitoring is periodically reviewed and improved.
• Lessons learned are incorporated into future design and coding practices.

4. Mapping CRA Requirements to SDL Activities

To be useful for CRA compliance, your SDL should directly support Cyber Resilience Act requirements. A practical way to approach this is to map requirements to activities and artifacts.

4.1 Risk assessment and design decisions

Your CRA risk assessment should be an input to SDL activities:

• Identified threats and vulnerabilities drive architectural choices.
• High-risk areas receive additional security testing and scrutiny.
• Risk acceptance decisions are documented and visible in SDL reviews.

This mapping shows that SDL is not isolated from your risk analysis but actively implements its results.

4.2 Security-by-default and configuration management

CRA expects secure defaults at deployment. SDL contributes by:

• Documenting default configurations and their rationale.
• Ensuring that insecure options are either unavailable or clearly documented with warnings.
• Including configuration validation in test suites.

4.3 Logging, monitoring and evidence generation

SDL should ensure that logging and monitoring are considered from the start:

• Security-relevant events are identified in design and implemented as part of development.
• Log formats and fields are standardised for later analysis.
• Tests verify that critical events are logged as expected.

This supports your CRA logging and monitoring approach and the evidence required in the technical file.

4.4 Vulnerability handling and update mechanisms

A CRA secure development lifecycle also defines how code changes, updates and patches are integrated:

• Bug and vulnerability tracking systems are aligned with your CRA vulnerability handling process.
• Update mechanisms are designed for secure delivery and validation from the beginning.
• Release notes and documentation capture security-relevant changes.

5. Practical Controls in a CRA Secure Development Lifecycle

Beyond phases and mappings, the SDL becomes real through specific controls and practices. Below is a non-exhaustive list of practical measures that support a CRA secure development lifecycle.

5.1 Secure coding guidelines and training

• Adopt secure coding standards relevant to your technologies (for example, CERT, MISRA, OWASP).
• Provide periodic training on secure coding and CRA-related security expectations.
• Maintain quick-reference materials for common pitfalls in your stack.

5.2 Code review with security focus

• Mandate peer review for changes in security-sensitive components.
• Use review checklists that include access control, error handling, logging and data validation.
• Ensure reviewers have the necessary context about CRA and product-specific risks.

5.3 Automated security testing

• Integrate SAST tools into CI pipelines where appropriate.
• Use DAST or integration-level security tests for exposed interfaces and APIs.
• For critical components, consider fuzz testing to uncover edge-case failures.

5.4 Dependency and SBOM management

• Use a package and dependency management strategy that avoids uncontrolled libraries.
• Generate and maintain an SBOM as part of your build process.
• Monitor public vulnerability feeds and advisories relevant to your SBOM components.

5.5 Secure build and release

• Protect build pipelines against tampering (access control, isolation, integrity checks).
• Use reproducible or deterministic builds where feasible for critical products.
• Sign release artifacts and updates to support secure distribution.

6. Documenting the CRA Secure Development Lifecycle

From a CRA perspective, it is not enough to run a secure development lifecycle; you must be able to show how it works. Documentation of the CRA secure development lifecycle should include:

• High-level description of the SDL process and phases.
• Roles and responsibilities for security-related activities.
• Templates or examples of threat models, risk assessments and review checklists.
• Policies for code review, testing and release approval.
• Links between SDL artifacts and CRA technical documentation sections.

This documentation becomes part of your CRA technical file and can be referenced in conformity assessments and audits.

7. Adapting CRA SDL to Different Product Types

Not all products with digital elements are the same. A good CRA secure development lifecycle is tailored to your product category and constraints, while keeping core security principles intact.

7.1 IoT and consumer devices

• Focus on secure onboarding, pairing and remote update mechanisms.
• Address constrained hardware in logging, encryption and update design.
• Consider usability when designing secure defaults for non-technical users.

7.2 Industrial and OT systems

• Account for safety implications in risk assessment and SDL decisions.
• Address long product lifecycles and legacy integration constraints.
• Align SDL practices with existing industrial security standards where relevant.

7.3 Software-heavy and hybrid products

• Integrate SDL with existing DevOps or DevSecOps practices.
• Pay special attention to cloud connectivity, APIs and data flows.
• Ensure that distributed components (clients, agents, services) are all covered by the SDL.

8. Common Mistakes in CRA Secure Development Lifecycles

When organisations start formalising a CRA secure development lifecycle, they often encounter similar pitfalls.

8.1 Treating SDL as a document, not a process

Writing an SDL policy is easy; changing how development is actually done is harder. CRA compliance depends on the process being followed in practice, not only on having a documented procedure.

8.2 Overloading teams with heavyweight processes

An SDL that is too heavy can slow development to a crawl and generate resistance. A practical CRA SDL focuses on a small number of high-impact security activities that fit the team’s way of working.

8.3 Ignoring feedback from post-market incidents

If lessons from incidents, customer feedback or penetration tests are not fed back into the SDL, the same issues will recur. CRA expects lifecycle security, which includes continuous learning.

8.4 SDL disconnected from suppliers and components

Many products rely on third-party software, libraries and hardware modules. A CRA secure development lifecycle must include mechanisms to evaluate, integrate and monitor these components, not just your own code.

8.5 No link between SDL and technical documentation

If SDL outputs and CRA documentation are maintained in silos, you will struggle to build a coherent technical file. Aligning templates, identifiers and structure from the start reduces friction later.

9. How Regulus Helps with CRA Secure Development Lifecycle

Regulus is focused on helping manufacturers, IoT vendors and embedded system teams implement the practical building blocks of Cyber Resilience Act compliance, including a CRA secure development lifecycle. Instead of relying solely on static documents, our goal is to provide:

• Guided mappings from CRA requirements to SDL activities across phases.
• Templates for risk assessment, threat modelling, review checklists and test evidence.
• Structure for integrating SBOM, logging and vulnerability handling into your SDL.
• Support for aligning SDL documentation with your CRA technical file and Declaration of Conformity.

To move forward:

1. Download the CRA Readiness Checklist to identify gaps in your SDL and documentation.
2. Explore our CRA documentation and requirements articles in the Resources section.
3. Join the Regulus Early Access program to get early access to CRA workflows for documentation and development practices.

La entrada CRA Secure Development Lifecycle (SDL): Practical Guide for Manufacturers se publicó primero en Regulus.

This guide explains how to design CRA logging and monitoring for your product: what to log, how to protect logs, how long to retain them, how to implement monitoring in constrained IoT and embedded environments, and how logging connects to vulnerability handling, incident response and your CRA technical documentation.

If you are building your overall CRA documentation, you may also want to review our guides on CRA risk assessment, CRA vulnerability handling requirements and CRA technical file structure.

1. Why CRA Logging and Monitoring Matter

The Cyber Resilience Act expects products with digital elements to support appropriate logging and monitoring of security-relevant events. This serves several purposes:

• Detection: identify attacks, misuse and abnormal behaviour before they escalate.
• Investigation: reconstruct what happened after an incident using reliable audit trails.
• Evidence: demonstrate that security controls operate as intended in real deployments.
• Feedback: feed real-world data back into your CRA risk assessment and hardening efforts.

Without structured CRA logging and monitoring, you risk being unable to detect incidents that must be reported, unable to understand their root cause, and unable to prove that your product behaves in line with your technical documentation and security claims.

2. Principles for CRA Logging and Monitoring

Before defining specific events and fields, it helps to anchor logging and monitoring design on a small set of principles that align with Cyber Resilience Act expectations.

2.1 Security-relevant, not everything

CRA does not require logging every possible event. Instead, you should identify security-relevant events based on your risk assessment: authentication, authorisation, configuration changes, security control status, update failures and so on. Log what is necessary to detect and investigate security issues, not every minor detail.

2.2 Privacy-aware and data-minimising

Logs should not become a source of unnecessary personal data exposure. Under the CRA and broader EU law, you must balance security visibility with data minimisation, pseudo­nymisation or anonymisation where feasible. Avoid including full credentials, sensitive payload data or unnecessary identifiers in logs.

2.3 Integrity and tamper resistance

For CRA logging and monitoring to be meaningful, logs must be trustworthy. You should protect logs against tampering and unauthorised deletion, for example by:

• Restricting access to log storage
• Using append-only or write-once mechanisms where possible
• Applying cryptographic integrity checks or signatures for critical logs

2.4 Lifecycle-oriented

Logging and monitoring must cover the entire product lifecycle: boot and installation, normal operation, updates, configuration changes and decommissioning. CRA expects lifecycle security, and your logs should reflect that lifecycle.

3. What to Log Under CRA Logging and Monitoring Requirements

The specific events to log depend on your product, but most CRA-compliant logging strategies include at least the following categories.

3.1 Authentication and access control events

These are central to CRA logging and monitoring because they show who accessed what, when and how:

• Successful and failed login attempts (user, admin, API keys, device credentials)
• Multi-factor authentication challenges and failures
• Account lockouts, password resets and credential changes
• Privilege changes (e.g. user granted or revoked administrator role)

3.2 Configuration and security setting changes

Changes that affect security posture or behaviour should always be logged:

• Enabling or disabling security features (firewalls, encryption, logging itself)
• Changes to access control lists, roles or permissions
• Modification of network endpoints, APIs or integration settings
• Changes in update policy or patch channels

3.3 Software, firmware and configuration updates

Because the Cyber Resilience Act emphasises secure updates, you should log:

• Attempts to download and apply updates (including failures)
• Successful installation of firmware or software updates
• Verification of update signatures or integrity checks
• Rollback events or reversion to previous versions

These logs are crucial when demonstrating that you applied patches in a timely manner and that your update mechanisms worked as documented.

3.4 Security control status and anomalies

Key security controls in the product should generate logs when:

• They are enabled, disabled or misconfigured
• They detect unusual or suspicious behaviour (e.g. rate limits triggered, brute-force attempts)
• They fail or degrade (for example, logging pipeline is full or offline)

3.5 Application- and domain-specific events

Depending on your product category, you may need to log additional domain-specific events, for example:

• For industrial devices: safety overrides, emergency stops, unexpected state transitions
• For IoT: pairing/unpairing events, device resets, remote commands received
• For security products: detection of malware, blocked connections, quarantine actions

4. Log Content: Fields and Structure

Effective CRA logging and monitoring depends not only on which events you log but also on how you structure log entries. A minimum set of fields typically includes:

• Timestamp with timezone
• Event type (e.g. auth_success, auth_failure, config_change, update_start, update_success)
• Actor (user ID, device ID, process ID, API client)
• Origin (IP address, hostname, interface)
• Target (resource modified or accessed)
• Outcome (success, failure, partial)
• Diagnostic data (codes, reason messages, error identifiers)

Using a consistent, machine-readable format (such as JSON) greatly simplifies downstream analysis and integration into SIEM or log management platforms.

5. Log Retention, Protection and Access Control

Once you generate logs, you must retain and protect them appropriately to support Cyber Resilience Act compliance.

5.1 Retention period for CRA logs

The CRA does not define a universal retention period, but you should select periods that:

• Support detection and investigation of security incidents over a reasonable timeframe
• Align with your vulnerability handling and incident reporting obligations
• Respect data protection and storage limitation principles

Many organisations adopt retention policies in the range of several months to a few years for security logs, depending on risk and regulatory expectations in their sector.

5.2 Protecting log integrity

From a CRA perspective, logs must be reliable as evidence. Protection techniques can include:

• Storing logs in separate, hardened infrastructure
• Using append-only storage or write-once media for high-value audit logs
• Applying cryptographic signatures or hash chains to detect tampering
• Replicating logs to a central server external to the device or product

5.3 Controlling access to logs

Access to raw and aggregated logs should be restricted to authorised personnel and tools. Good practices include:

• Role-based access control for log platforms
• Separation of duties between administrators and auditors
• Logging access to logs themselves for auditability

6. Monitoring, Alerting and Integration with Incident Response

Logging alone is not enough. CRA logging and monitoring also implies that you actively monitor and act on log data.

6.1 Baseline monitoring

Baseline monitoring includes dashboards and alerts for:

• Authentication failures above normal thresholds
• Unusual patterns of configuration changes
• Update failures across a fleet of devices
• Repeated triggering of security controls (e.g. rate limits or WAF blocks)

6.2 Integration with incident response processes

Logs and monitoring must feed into your vulnerability handling and incident response processes. When an incident is suspected:

• Monitoring should trigger an alert and open an investigation record
• Investigators should have access to correlated logs from relevant components
• Response actions (blocking accounts, isolating devices, applying patches) should themselves be logged

For a deeper view of incident-related processes, see our guide on CRA vulnerability handling requirements.

6.3 Fleet and cloud-side monitoring for IoT and embedded products

For IoT and embedded devices, local logging may be limited due to storage and power constraints. In these cases, CRA logging and monitoring typically involves:

• Lightweight local logs for critical events
• Periodic upload or streaming of key events to a backend
• Aggregation, correlation and alerting in a central platform

The CRA does not prescribe specific architectures, but expects that your overall design supports effective detection and response across the lifecycle of the product.

7. Documenting CRA Logging and Monitoring in the Technical File

From a documentation perspective, your CRA technical file should describe your logging and monitoring approach clearly enough that auditors and authorities can understand it.

Typical elements in the technical file include:

• Overview of logging architecture (on-device, edge, cloud, SIEM)
• List of main event categories logged (auth, config, updates, security controls)
• Retention and protection measures for logs
• How monitoring is performed and how alerts are integrated into incident response
• How log data contributes to post-market monitoring and risk reassessment

For structuring this documentation, you can reuse the structure suggested in our CRA technical file structure guide.

8. Common Pitfalls in CRA Logging and Monitoring

When implementing CRA logging and monitoring requirements, manufacturers often encounter similar pitfalls. Being aware of them helps you design a more robust approach.

8.1 Logging too little

Under-logging may save storage and bandwidth but leaves you blind when incidents occur. If you cannot reconstruct what happened, you weaken both your security posture and your CRA compliance position.

8.2 Logging too much, without structure

On the other hand, logging everything without structure can overwhelm your monitoring tools and teams. Focus on security-relevant events, and standardise fields and formats to keep logs usable.

8.3 Storing logs only on the device

If all logs are stored locally and can be wiped by an attacker or by a device reset, they are of limited value. Wherever possible, forward at least summary logs to a central location under your control.

8.4 Ignoring privacy considerations

Logs that contain excessive personal data or sensitive payloads may create GDPR and privacy risks. Align CRA logging and monitoring with data protection principles and minimise what you store.

8.5 Monitoring that is not actionable

Dashboards and metrics are useful, but CRA expects that security events lead to action when needed. Alerts must be tuned, assigned and integrated into real incident response workflows.

9. How Regulus Helps with CRA Logging and Monitoring

Regulus is building tools to help manufacturers, IoT vendors and embedded system teams operationalise Cyber Resilience Act compliance, including CRA logging and monitoring requirements. Instead of dealing with scattered documents and ad-hoc log designs, our goal is to provide:

• Guided mappings from CRA security requirements to concrete logging and monitoring needs
• Templates for logging and monitoring sections in your CRA technical file
• Checklists to validate that key event categories and lifecycle phases are covered
• Support for aligning logging with vulnerability handling, update management and post-market monitoring

To move forward:

1. Download the CRA Readiness Checklist to assess your current logging and monitoring gaps.
2. Review our CRA documentation and requirements guides in the Resources section.
3. Join the Regulus Early Access program to get priority access to CRA compliance tooling.

La entrada CRA Logging and Monitoring Requirements: Complete Guide se publicó primero en Regulus.

For context, an SBOM is a structured inventory of all software components within a product, including dependencies, libraries, open-source packages, firmware modules and third-party code. SBOMs play a critical role in vulnerability management, supply-chain security and regulatory transparency. Similar initiatives have already been adopted by the U.S. Department of Commerce (NTIA), NIST (NIST), and CISA (CISA SBOM Program), meaning CRA SBOM obligations follow an international trend toward greater software transparency.

This guide explains everything you need to know to comply with SBOM obligations under the Cyber Resilience Act.

What Are SBOM Requirements Under the Cyber Resilience Act?

The CRA SBOM requirements aim to ensure transparency and traceability of every software component included in a digital product. The CRA explicitly requires manufacturers to maintain a comprehensive set of technical documentation, including an inventory of software components, third-party libraries and dependencies. While the CRA does not mandate a specific SBOM format, the structure aligns closely with international SBOM standards such as SPDX, CycloneDX and SWID.

Under the Cyber Resilience Act, an SBOM must help regulators and customers understand:

• What software components are included in a product
• Which components are open-source or third-party
• Known vulnerabilities associated with each component
• Licensing requirements of included components
• Update history and versioning
• Supplier dependency chains

In short, the SBOM becomes the backbone of CRA vulnerability handling, documentation, and post-market surveillance requirements.

Why SBOMs Are Critical Under the CRA

Several CRA obligations depend directly on maintaining an up-to-date SBOM. For example:

• Annex I Section 2 requires manufacturers to identify, assess and remediate vulnerabilities.
• Annex II Technical Documentation requires providing information about product architecture, components and dependencies.
• Post-market surveillance obligations rely on awareness of component-level vulnerabilities.
• Supply-chain security requires understanding which third-party elements may introduce risk.

This means manufacturers cannot comply with the Cyber Resilience Act without a functioning SBOM practice, updated throughout the lifecycle of the product.

CRA SBOM Requirements in Detail

Below is the most detailed breakdown of CRA SBOM requirements currently available, based on the final text of the regulation and authoritative interpretations from ENISA and EU cybersecurity experts.

1. A Complete Inventory of Software Components

The SBOM must list every software element included in a product, including:

• Proprietary code
• Open-source libraries
• Firmware modules
• Third-party binaries
• Dynamic or runtime-loaded modules
• Build-time dependencies

The CRA does not allow manufacturers to exclude components because they “seem low risk.” If it is in the product, it must be documented.

2. Versioning and Update Tracking

Manufacturers must maintain historical and current versions for each component to support CRA vulnerability handling and update obligations. This requirement is aligned with the NIST SP 800-218 framework.

3. Supplier and Licensing Metadata

An SBOM under the CRA must document:

• Component origin and supplier
• Licensing information (for open source)
• Security contact information when available

This supports supply-chain verification and license compliance—two areas regulators consider critical.

4. Link to Known Vulnerabilities (EPSS, CVE, NVD)

The CRA requires manufacturers to identify vulnerabilities affecting their product. An SBOM is the tool that enables automatic correlation between included components and vulnerability databases such as:

• CVE List
• NVD (National Vulnerability Database)
• EPSS (Exploit Prediction Scoring System)

Without an SBOM, CRA-compliant vulnerability management is impossible.

5. Lifecycle Updates (Not a One-Off SBOM)

The CRA SBOM requirements clearly state that documentation must be updated throughout the product lifecycle, especially after:

• Firmware or software updates
• Component upgrades or replacements
• Third-party library patching
• Security incident remediation

This requirement aligns with CISA’s position that SBOMs must reflect “software as built” and “software as deployed.”

6. Format Requirements: SPDX, CycloneDX or SWID

The CRA does not mandate a specific SBOM format. However, European regulators strongly recommend using standardized, machine-readable formats. The three dominant standards are:

• SPDX – Supported by the Linux Foundation
• CycloneDX – Widely used in IoT and embedded products; supported by OWASP
• SWID tags – NIST-backed, used for enterprise environments

Most manufacturers choose CycloneDX because it maps cleanly to embedded systems and firmware.

7. SBOM Distribution Requirements (On Request)

Under the CRA, manufacturers must provide an SBOM:

• To authorities upon request
• To conformity assessment bodies
• To customers when needed for security purposes

This mirrors U.S. practices where SBOMs are increasingly required by enterprise customers for procurement processes.

How SBOMs Support CRA Vulnerability Handling Requirements

SBOMs are directly tied to Annex I Section 2 of the CRA, which defines vulnerability handling rules. An SBOM enables:

• Automatic detection of vulnerable dependencies
• Impact assessment of new CVEs
• Faster patch prioritization
• Evidence for CRA documentation and audits

According to ENISA, 72% of IoT vulnerabilities originate in third-party components. SBOMs offer the transparency required to address this problem.

SBOMs serve as the foundation for CRA vulnerability management and post-market surveillance.

SBOM Requirements for Embedded Systems Under the CRA

Embedded and firmware-driven products are among the most impacted by CRA SBOM requirements. These manufacturers must document:

• Bootloader versions
• Firmware modules and microcontroller firmware
• Real-time operating systems (RTOS)
• Chipset drivers
• Security modules and cryptographic libraries

CRA assessors often scrutinize firmware SBOM completeness because firmware vulnerabilities pose higher systemic risk.

Common Mistakes Manufacturers Make with CRA SBOM Requirements

• Creating a single SBOM snapshot instead of continuous updates
• Excluding “internal” or proprietary modules
• Failing to track transitive dependencies
• Using unstructured lists instead of machine-readable SBOM formats
• Not linking SBOM updates with release management

A non-compliant SBOM can jeopardize the entire CRA conformity assessment.

Recommended Tools for Generating SBOMs

Although the CRA does not mandate specific tools, popular options include:

• CycloneDX tooling
• Anchore Syft
• Tern (for container SBOMs)
• SPDX tools

Manufacturers should select tools that support continuous integration and automated build pipelines.

SBOMs connect directly to CRA documentation, classification and conformity requirements.

Conclusion

SBOMs are not optional under the Cyber Resilience Act—they are a foundational requirement that enables vulnerability management, regulatory documentation, supply-chain visibility and post-market cybersecurity controls. Manufacturers should begin implementing SBOM processes in 2025 to ensure full CRA compliance by 2027.

To continue preparing for CRA conformity, explore additional Regulus resources:

• CRA Readiness Checklist
• CRA Applicability Guide

La entrada CRA SBOM Requirements: Complete Guide for Manufacturers, IoT Vendors and Software Teams se publicó primero en Regulus.

This guide explains the complete set of update requirements introduced by the CRA, including secure delivery, lifecycle support, validation, rollback prevention, user communication and documentation duties under Annex II and Annex VII.

1. Why Update & Patch Management Matters Under the CRA

Historically, many IoT devices, embedded systems and software products received minimal or inconsistent security updates. The CRA addresses this gap by requiring manufacturers to:

• Deliver security updates throughout the product’s support period
• Ensure updates are secure, authenticated and verified
• Maintain an update policy and lifecycle security plan
• Document update procedures and evidence for authorities

Poor update practices are one of the main causes of long-term insecurity in digital products. The CRA makes update management a legal obligation.

2. Legal Basis for Update Requirements in the CRA

Update obligations appear in three main sections of the regulation:

2.1 Annex I – Essential Cybersecurity Requirements

Annex I mandates that:

• Updates must be delivered securely
• Update mechanisms must prevent unauthorized access
• Update validation must avoid introducing new vulnerabilities
• Rollback to insecure versions must be prevented

2.2 Annex II – Technical Documentation

Manufacturers must document:

• Update architecture
• Validation procedures
• Cryptographic protections
• Testing evidence for updates

2.3 Annex VII – Post-Market Monitoring

Manufacturers must maintain:

• Update history
• Patching timelines
• Verification logs
• Remediation evidence

3. CRA Update & Patch Management Requirements (Full Breakdown)

3.1 Updates Must Be Delivered Securely

Manufacturers must implement secure update delivery mechanisms that ensure:

• Authenticity (updates are signed by the manufacturer)
• Integrity (updates cannot be tampered with)
• Confidentiality where relevant

Unsigned or unverified updates constitute a direct CRA violation.

3.2 Updates Must Be Validated Before Deployment

Manufacturers must:

• Test updates for security regressions
• Validate compatibility with the product
• Document testing results

Annex II requires explicit evidence of update validation.

3.3 Rollback Prevention

Manufacturers must ensure:

• Devices cannot revert to insecure firmware
• Attackers cannot install outdated or vulnerable versions

This requires version control, signing enforcement and secure boot integration.

3.4 Update Transparency for Users

Users must be informed of:

• Available security updates
• The need to apply updates when manual action is required
• Critical vulnerabilities addressed by updates

In many cases, automatic updates are strongly recommended.

4. Lifecycle Support Requirements

One of the most misunderstood CRA obligations is lifecycle support. Manufacturers must:

• Provide security updates for the full support period
• Define how long the product will receive updates
• Communicate this period to users

Support periods must be “reasonable”, meaning aligned with product category and risk.

4.1 Examples of Support Periods

• Consumer IoT: typically 3–5 years
• Industrial controllers: 7–12 years
• Developer tools: until obsolete or replaced
• Automotive-adjacent PDEs: aligned with vehicle lifecycle

Under-supporting products is a risk for market surveillance action.

5. Secure Update Architecture (Recommended)

A secure update architecture typically includes:

• Cryptographically signed firmware/software
• Secure boot enforcing authenticity
• Encrypted update channels
• Fallback protection
• Atomic installation mechanisms

These are essential to prevent attackers from exploiting update mechanisms.

6. Update Lifecycle Workflow

1. Identify vulnerability requiring a patch
2. Develop update or mitigation
3. Validate update for regressions
4. Cryptographically sign update
5. Deliver update securely to users/devices
6. Verify installation success
7. Document validation and deployment
8. Monitor post-update security

This workflow is required for both Default Class and Critical Class products.

7. Relationship Between Updates and Vulnerability Handling

Update management is directly linked to vulnerability handling:

• Remediation relies on updates
• Incident reporting may trigger updates
• Annex VII documentation connects updates to vulnerabilities

Failure to provide timely updates can breach multiple CRA obligations simultaneously.

8. Documentation Requirements for Updates (Annex II & VII)

Manufacturers must keep:

• Update testing evidence
• Security validation logs
• Signing procedures
• Version history
• Remediation timelines

Authorities may request this documentation at any time.

9. Common Compliance Mistakes

• No signed updates
• No rollback protection
• Incomplete update history
• Insufficient testing logs
• No clear support-period definition
• Failure to notify users of required updates

10. How Regulus Helps Manufacturers

Regulus automates CRA update and patch management compliance with:

• Update policy templates
• Automated Annex I requirements mapping
• Version tracking and evidence logs
• Secure update architecture guidance
• Lifecycle support recommendations

Start here: CRA Applicability Checker

Conclusion

Update and patch management is one of the most critical CRA obligations. Manufacturers must implement secure update mechanisms, maintain rigorous documentation, define lifecycle support periods and validate updates before release.

For templates, checklists and guidance, explore: Cyber Resilience Act Resources

La entrada CRA Update & Patch Management Requirements: Complete Guide for Manufacturers and Software Teams se publicó primero en Regulus.

This guide provides a detailed technical interpretation of every vulnerability handling requirement under the CRA, including reporting timelines, remediation expectations and documentation duties under Annex VII. If your product includes software, firmware or connectivity, these obligations apply to you.

1. What Vulnerability Handling Means Under the CRA

In the context of the Cyber Resilience Act, vulnerability handling refers to a structured, documented and continuous set of activities that ensure a product remains secure throughout its supported lifetime. These activities must include:

• Continuous vulnerability identification (internal + external sources)
• Assessment and prioritization based on risk and exploitability
• Mitigation and remediation within a reasonable timeframe
• Secure deployment of patches and updates
• Communication of vulnerabilities to users when necessary
• Mandatory reporting of actively exploited vulnerabilities
• Record-keeping under Annex VII

This is more than a “best practice”: it is a legal obligation that applies to all manufacturers under the CRA.

2. Legal Basis: Where Vulnerability Handling Appears in the CRA

The CRA integrates vulnerability handling across several sections:

2.1 Annex I – Essential Cybersecurity Requirements

Section 2 mandates:

• Processes for handling vulnerabilities
• Mechanisms for secure update delivery
• Protection against exploitation
• Communication obligations toward users

2.2 Articles 15 & 16 – Reporting Obligations

Manufacturers must report:

• Actively exploited vulnerabilities
• Significant cybersecurity incidents

Reports must follow strict timelines.

2.3 Annex VII – Post-Market Monitoring Documentation

Annex VII requires manufacturers to maintain:

• A vulnerability register
• Remediation evidence
• Incident reports
• Update history and validation logs

This documentation must be provided to authorities upon request.

3. CRA Vulnerability Handling Requirements (Annex I Section 2)

Below is a breakdown of each obligation in Annex I Section 2.

3.1 Continuous Vulnerability Identification

Manufacturers must continuously monitor:

• Internal testing and QA findings
• User-reported vulnerabilities
• Threat intelligence feeds
• Open-source vulnerability disclosures (for SBOM components)
• Supplier and third-party advisories

This implies the need for a formal intake process and a designated security contact point.

3.2 Assessment and Prioritization

Every identified vulnerability must be evaluated based on:

• Severity (CVSS or equivalent)
• Exploitability (public exploit, active exploitation)
• Impact (confidentiality, integrity, availability)
• Exposure (network vs local)

The CRA does not mandate CVSS specifically, but requires a structured and repeatable assessment methodology.

3.3 Remediation and Mitigation

Manufacturers must:

• Address vulnerabilities within a “reasonable timeframe”
• Apply temporary mitigations when necessary
• Document remediation decisions

Critical vulnerabilities, or those with active exploitation, require accelerated handling.

3.4 Deployment of Security Updates

Under CRA, updates must be:

• Delivered securely (signed, authenticated)
• Installed reliably
• Validated to avoid introducing new vulnerabilities

Manufacturers must also maintain a version history and a record of validation.

3.5 User Notification Requirements

In certain scenarios, manufacturers must notify users:

• When no patch is available for a known high-risk vulnerability
• When user action is required to mitigate impact
• When security updates include important fixes

4. Reporting Obligations: Vulnerabilities & Incidents

The CRA requires manufacturers to report:

4.1 Actively Exploited Vulnerabilities

If a vulnerability is being exploited in the wild, the manufacturer must notify:

• ENISA
• Relevant CSIRTs

Reports must be submitted without undue delay (interpreted as 24 hours in most regulatory guidance).

4.2 Significant Cybersecurity Incidents

Manufacturers must report:

• Exploitation causing substantial service disruption
• Widespread compromise of devices
• Incidents affecting critical infrastructure

5. Post-Market Monitoring Obligations (Annex VII)

Annex VII requires ongoing documentation of:

• A vulnerability register
• Assessment and prioritization records
• Mitigation steps taken
• Update verification logs
• Incident reports and timelines

Manufacturers must keep documentation for the entire support period.

6. Vulnerability Handling Workflow (Recommended)

1. Receive vulnerability report
2. Validate and acknowledge
3. Assess severity and risk
4. Define mitigation or remediation plan
5. Develop and test the patch
6. Deploy securely to devices/users
7. Document all actions
8. Report exploited vulnerabilities

This workflow ensures full alignment with Annex I and Annex VII.

7. Relationship with SBOM and Supply Chain Security

Vulnerabilities in third-party libraries and open-source components (SBOM items) are fully the responsibility of the manufacturer. You must:

• Monitor SBOM components for new CVEs
• Update libraries when fixes become available
• Document remediation

Neglecting SBOM monitoring is a direct violation of CRA obligations.

8. Common Compliance Mistakes to Avoid

• No formal intake process for vulnerability reports
• Missing or incomplete vulnerability register
• No evidence of update validation
• Failure to monitor SBOM components
• Not documenting mitigations
• No post-market monitoring plan
• Not reporting exploited vulnerabilities

9. How Regulus Helps

Regulus automates vulnerability handling compliance with:

• Centralized vulnerability register
• Automatic SBOM monitoring
• Annex I & Annex VII requirements mapping
• Evidence tracking for security updates
• Conformity risk scoring

Try the CRA Applicability Checker to determine requirements for your product.

Conclusion

Vulnerability handling is one of the most operationally complex aspects of CRA compliance. Manufacturers must adopt continuous monitoring, structured remediation processes, secure update mechanisms and strong documentation practices before the 2027 deadline.

For templates and workflows, explore: Cyber Resilience Act Resources

La entrada CRA Vulnerability Handling Requirements (Annex I – Section 2): Complete Guide for Manufacturers and IoT Vendors se publicó primero en Regulus.