Understanding the VirusTotal API and Its Role in CRA Compliance

It’s important to realise that the VirusTotal API is not a traditional antivirus solution that blocks threats in real-time. Think of it instead as a powerful analysis and investigation tool. When you submit an indicator—like a file hash or a domain name—your application gets back a detailed report that consolidates findings from dozens of different security tools. For example, submitting a URL might reveal that while only 3 engines flag it as malicious, one of those is a top-tier security vendor known for accurate phishing detection, giving you crucial context beyond a simple “good” or “bad” verdict. This gives you a rich, multi-faceted view of any potential threat.

For manufacturers of products with digital elements, this capability is more than just a security feature; it’s a core component of modern compliance. The EU’s Cyber Resilience Act (CRA) places strict obligations on companies to continuously monitor for and manage vulnerabilities in their products long after they are sold. Manual analysis simply can’t keep up.

Automating Security for Post-Market Surveillance

Integrating the VirusTotal API lets you automate critical security workflows, which is absolutely essential for meeting the CRA’s requirements for post-market surveillance and ongoing vulnerability management. Instead of having someone manually check suspicious files or domains, your systems can perform these checks programmatically. You can explore our detailed guide on CRA vulnerability handling requirements for a deeper dive into these obligations.

By embedding the VirusTotal API into your development and security operations, you transform compliance from a reactive, manual burden into a proactive, efficient, and scalable process.

This programmatic approach provides a clear, auditable trail of due diligence—something that is critical for demonstrating compliance to regulators. For example, your systems can automatically:

• Scan new firmware builds before deployment to check for embedded malware. A practical script could calculate the SHA-256 hash of a firmware-v2.1.bin file and query the API to ensure zero malicious detections before it’s pushed to production.
• Analyse URLs and IP addresses that your IoT devices connect to, identifying potential command-and-control servers. For instance, a nightly job could extract all unique domains from device logs and run them through the /domain/report endpoint to flag any with recent malicious associations.
• Investigate suspicious files reported by users or discovered during internal audits. If a customer support ticket includes a strange .dll file, your ticketing system could auto-submit its hash to VirusTotal and attach the results directly to the ticket for faster analysis.

By using the VirusTotal API, your engineering and compliance teams gain the tools to build a robust, automated defence system that directly addresses key CRA mandates. This helps ensure your products remain secure and compliant throughout their entire lifecycle.

Managing VirusTotal API Authentication and Keys

All communication with the VirusTotal API is authenticated through an API key. Every request you send must include a valid key, which serves to identify your application and enforce your access level. Without a valid key, the API will simply reject your request.

You will find your API key within your user profile settings on the VirusTotal website. To authenticate an API call, you must include this key in the x-apikey HTTP header. It’s your unique credential for accessing the service.

Here’s a practical curl example showing how to include the key when requesting a file report. Just remember to replace YOUR_API_KEY with your actual key.

# Example curl request to get a file report
# Replace YOUR_API_KEY with your actual VirusTotal API key
# Replace {file_hash} with a real SHA-256 hash of a file
curl --request GET 
  --url https://www.virustotal.com/api/v3/files/{file_hash} 
  --header 'x-apikey: YOUR_API_KEY'

Public vs. Private API Keys

VirusTotal provides two main types of API keys: the free Public API key and the commercial Private/Premium API key. The type of key you have determines your request rate limits, which features you can access, and your licensing terms.

Making the right choice here is critical. Using a Public API key for a commercial product or a high-volume workflow not only leads to service interruptions from rate limiting but also violates the terms of service. This is especially important for integrations supporting Cyber Resilience Act (CRA) compliance, where reliability is non-negotiable.

The following table breaks down the fundamental differences between the two key types.

VirusTotal API Key Types Comparison

While a public key is perfectly fine for initial testing and personal research, any serious product integration demands a private key. For example, a simple script that checks 100 domains from your product’s telemetry data would take 25 minutes with a public key, but could be completed in under a minute with a private key. For automated vulnerability management or to meet the continuous monitoring requirements of the CRA, upgrading to a private key is mandatory. This ensures you have the necessary request volume, access to advanced features, and legal standing for commercial use.

Using Core API Endpoints for File Analysis

To get the most out of the VirusTotal API in your security workflows, you need to get familiar with its core file analysis endpoints. These are the workhorses for submitting files and pulling back detailed reports. Each endpoint has a specific job in the file analysis lifecycle.

Your journey usually starts with the /file/scan endpoint. This is what you use to upload a new file that VirusTotal hasn’t seen before. Think of it as the first step for analysing anything unique, like a fresh firmware build or a suspect email attachment.

Once you submit a file, it enters an analysis queue. You can then use the /file/report endpoint to check on the scan’s progress and, ultimately, fetch the final results. This endpoint is absolutely central to any automated workflow, as it delivers the actionable intelligence you need.

Understanding Key File Endpoints

For file analysis, three endpoints are critical: /file/scan, /file/rescan, and /file/report. Getting their specific roles right is the key to building efficient automation.

• /file/scan (POST): Use this endpoint for the initial upload of a file. The API will respond with a scan ID, which you’ll then use to track the analysis.
• /file/rescan (POST): If a file has already been analysed in the past, this endpoint forces a completely new analysis. It’s perfect for getting an up-to-date report on a file that might have been re-classified since its last scan.
• /file/report (GET): This fetches the most recent analysis report for a file using its hash (MD5, SHA-1, or SHA-256). It is the most common endpoint for checking a file’s reputation.

When you’re integrating the VirusTotal API, remember that managing your credentials securely is non-negotiable. For a solid overview on handling API keys and other sensitive information, take a look at this guide on DevOps secrets management.

Here’s a practical example: an IoT manufacturer wants to build a script to help secure their supply chain. Every time a new firmware binary is compiled, a script can automatically calculate its SHA-256 hash and query the /file/report endpoint.

If the report comes back with a high positives count—say, more than 2 detections out of a total of 70+ scanners—the script can immediately flag the build and alert the security team. This kind of proactive check is a powerful way to stop compromised software from ever being distributed.

By scripting these checks, you automate a fundamental part of your product security. For a broader view on how this fits into a larger compliance strategy, you can read our guide to understand how to scan for malware effectively.

Analysing URLs, Domains, and IPs with Advanced Endpoints

Product security isn’t just about scanning files. It requires a complete view of every internet resource your devices interact with. The VirusTotal API has specialised endpoints for analysing URLs, domains, and IP addresses, helping you uncover threats like phishing sites or command-and-control (C2) servers before they cause damage.

This kind of proactive analysis is exactly what regulations like the Cyber Resilience Act (CRA) mandate. By regularly checking the network destinations your products communicate with, you can spot potential compromises early. This is where endpoints like /url/scan and /domain/report become essential tools in your security toolkit.

Key Network Analysis Endpoints

To check network resources, you’ll mainly be using a few core endpoints. Each is built for a specific job in your threat intelligence workflow.

• /url/scan (POST): This is your starting point for any new URL. Submitting it here queues it for analysis, especially if VirusTotal hasn’t seen it recently.
• /url/report (GET): Use this to pull the latest analysis report for a URL. You can query with the URL itself or use the scan ID returned from a previous scan.
• /domain/report (GET): Provides a deep dive into a domain, pulling together historical data, passive DNS information, and any related malicious samples.
• /ip-address/report (GET): Fetches the full report for an IP address, detailing its reputation and any malicious activity associated with it.

As a practical example, your security team could write a script to vet all hardcoded domains in your firmware. The script would simply iterate through a list of domains and hit the /domain/report endpoint for each one, ensuring none are linked to known malicious infrastructure.

# Example curl request to get a domain report
# Replace YOUR_API_KEY with your key and example.com with the target domain
curl --request GET 
  --url https://www.virustotal.com/api/v3/domains/example.com 
  --header 'x-apikey: YOUR_API_KEY'

Interpreting the JSON response from these endpoints is key. Don’t just look at the positives/total count. Dig into fields like passive DNS records. This data shows which IP addresses a domain has resolved to over time, which can uncover hidden connections to shared malicious hosting.

This depth of information lets your team build a much richer picture of a resource’s actual risk. For instance, a domain might have zero malicious detections, but its passive DNS history shows it was hosted on the same IP as a known malware distributor last month. This context, available via the API, is a powerful indicator of risk that a simple blocklist would miss. By automating these checks, you create a robust, CRA-aligned security posture, demonstrating the ongoing due diligence required to ensure your products don’t communicate with compromised internet endpoints.

Navigating Rate Limits and Handling API Errors

Building a truly reliable integration with the VirusTotal API means preparing for the moments when things don’t go as planned. Every API has usage quotas, and knowing how to work within those rate limits and handle error responses gracefully is what separates a fragile script from a resilient, production-ready security system.

If you ignore these rules, you can expect failed requests and service disruptions. The Public API key, for example, is strictly limited to just four requests per minute. A private key offers much higher throughput, but even it has limits that your application must respect to ensure consistent performance. This is why robust error handling isn’t just a nice-to-have; it’s a core requirement for building stable security automation.

Understanding Common API Errors

When your application makes an invalid request or smashes through its quota, the VirusTotal API will return a standard HTTP status code to tell you what went wrong. Getting familiar with these codes is the first step toward building logic that can actually handle these situations. Proper logging and monitoring of these errors are also key components for compliance, as we cover in our guide on CRA logging and monitoring requirements.

Here’s a quick-reference table for the most common error codes you’re likely to run into when working with the API.

Common VirusTotal API Error Codes and Resolutions

This table breaks down the typical HTTP error codes you’ll see from the VirusTotal API and provides clear, actionable steps for each one. Keep this handy when you’re debugging your integration.

Treating these codes as part of your normal operational flow, rather than as exceptions, will make your integration far more robust and predictable in the long run.

A Practical Example: Implementing Exponential Backoff

The error you’ll hit most often in any high-volume script is the 204 No Content rate limit. Instead of just letting the request fail, your script should be smart enough to wait and try again. The best way to do this is with exponential backoff, a simple strategy where the delay between retries increases after each failure.

Here’s a basic Python example that shows how this logic works:

import requests
import time

def request_with_backoff(url, headers):
    retries = 5
    delay = 1 # Start with a 1-second delay
    for i in range(retries):
        response = requests.get(url, headers=headers)
        if response.status_code == 204:
            print(f"Rate limit hit. Retrying in {delay} seconds...")
            time.sleep(delay)
            delay *= 2 # Double the delay for the next attempt
        elif response.status_code == 200:
            return response.json()
        else:
            # For other errors, it's better to fail fast
            response.raise_for_status() 
    raise Exception("Max retries exceeded after multiple failures.")

This approach ensures your automation can withstand temporary service limits without crashing, which is a crucial feature for any system designed for continuous security monitoring or vulnerability management.

The significant growth of the European endpoint security market, which hit USD 5.05 billion in 2024, just highlights how much organisations are relying on automated threat intelligence. With projections showing the market will reach USD 10.09 billion by 2033, building robust and resilient API integrations is essential to protect the huge number of endpoints that remain vulnerable. You can find more insights on these trends over at marketdataforecast.com. This growth is exactly why automated, resilient solutions are no longer optional.

Automating Security Workflows for CRA Compliance

The real power of the VirusTotal API isn’t just in its data, but in how you can use it to automate security workflows and build a defensible CRA compliance posture. For any organisation navigating the Cyber Resilience Act, the goal is to create repeatable, auditable security processes that directly address the regulation’s strict demands.

This goes far beyond occasional manual lookups. True CRA compliance means embedding threat intelligence deep into your core operations, from the development lifecycle all the way to post-market surveillance. Each integration pattern acts as a blueprint for using the API to meet and document specific CRA obligations, turning compliance from a burdensome manual task into a continuous, automated function.

Actionable Integration Patterns for CRA

To build a credible compliance case, you need to implement specific, automated workflows that use the VirusTotal API. These patterns provide clear evidence of the due diligence and continuous monitoring that are central to the CRA’s requirements.

Here are three practical integration patterns you can build:

1. Automated Post-Market Surveillance: Develop scripts that periodically pull domains and IP addresses from your product’s network logs. These scripts can then query the VirusTotal API’s /domain/report and /ip-address/report endpoints to confirm your devices aren’t communicating with known malicious infrastructure. For example, a cron job could run daily, parsing logs from the previous 24 hours and creating a security alert if any queried IP has more than one malicious detection.
2. Streamlined Vulnerability Triage: Integrate the /file/scan endpoint directly into your bug bounty or vulnerability reporting platform. When a security researcher submits a suspicious file, your system can automatically push it to VirusTotal for instant analysis, dramatically cutting down your triage and response times. For guidance on integrating different security tools, you might find it helpful to look into how to best use https://goregulus.com/cra-basics/siem-open-source/.
3. Secure Supply Chain Management: As a part of your CI/CD pipeline, write a script that scans every third-party library and dependency defined in your Software Bill of Materials (SBOM). By checking the hash of each component against the /file/report endpoint, you can catch compromised dependencies before they are ever compiled into a final product release. A practical example would be a Jenkins or GitHub Actions step that fails the build if a dependency like log4j-core-2.14.1.jar shows any new malicious flags.

The following diagram outlines a simple but essential process for managing API requests, ensuring your automations can run at scale without being interrupted by rate limits.

This flow underscores the need to build resilient logic, like exponential backoff, directly into your API integrations from day one. The scale of today’s API-driven supply chains makes this kind of robust automation a necessity, not a luxury. For instance, Europe’s generic API pharmaceutical market claimed a 58% revenue share in 2023, a sector powered by over 350 firms in Spain and Italy alone that face very similar digital supply chain risks. Using AI for regulatory compliance, particularly with powerful tools like the VirusTotal API, is becoming indispensable for navigating complex new rules like the CRA.

Frequently Asked Questions About the VirusTotal API

When you’re integrating a new tool, questions are inevitable. This section cuts straight to the practical answers for the most common queries we see about using the VirusTotal API, especially for product security and compliance workflows.

Our goal here is to give you the clarity you need to integrate this powerful threat intelligence resource the right way.

Can I Use the Free Public API for a Commercial Product?

No. The free VirusTotal public API comes with a strict non-commercial licence. It’s also heavily rate-limited, making it completely unsuitable for any business use case. Think of it as a tool for personal research or academic projects only.

For any commercial application—whether that’s integrating it into your product or using it for internal Cyber Resilience Act (CRA) compliance workflows—you must use the private/premium API. This is the only way to get the request volume, performance, and legal rights needed for a business context.

How Is the VirusTotal API Different from Antivirus?

A standard antivirus (AV) client provides real-time protection. It’s a shield, actively scanning for and blocking threats on a single device.

The VirusTotal API is different; it’s a threat intelligence aggregator. It doesn’t block anything directly. Instead, it consolidates the analysis results from over 70 different AV scanners and security services to give you a comprehensive second opinion on a file or URL. It’s a tool for investigation and analysis, not real-time endpoint defence.

Think of it like this: an antivirus is the guard at the gate, while the VirusTotal API is the intelligence agency providing a detailed background check on everyone who wants to enter.

What Is the Best Way to Analyse Large Files with the API?

The API has a file size limit for direct uploads, which is typically 32MB for the standard /file/scan endpoint. For anything larger, the correct and most efficient method is a two-step process that starts by calculating the file’s hash—preferably SHA-256.

Once you have the hash, your first move should be to query the /file/report endpoint.

• If VirusTotal has already analysed the file, you get an instant report without uploading a single byte. This is a huge time and bandwidth saver. For example, if you need to check a 500MB firmware image, getting a report instantly via its hash saves significant upload time.
• If the file is unknown to VirusTotal, you then use the /file/upload_url endpoint. This will give you a special, one-time URL for uploading files up to 650MB.

This two-step approach is the established best practice for handling large files. It ensures you respect API resources and only upload when absolutely necessary.

Gain clarity and confidence in your compliance strategy with Regulus. Our platform provides a step-by-step roadmap to navigate the Cyber Resilience Act, helping you prepare for regulatory deadlines without the high cost of consulting. Visit us at https://goregulus.com to see how we can simplify your CRA compliance journey.

La entrada Total Virus API: Master the total virus api for CRA Compliance se publicó primero en Regulus.

At its core, Springdoc inspects your existing REST controllers, figures out your endpoints, and automatically generates a beautiful, interactive Swagger UI. This means you can go from raw code to a fully documented and testable API in just a few minutes.

Your First Steps With Springdoc And Swagger UI

Let’s dive right in and see how easy it is to get this up and running. We’ll start by adding a single dependency to a basic Spring Boot application and watch the magic happen.

Adding The Dependency

First things first, you need to tell your build system about Springdoc. Whether you’re a Maven or Gradle user, this just means adding one line to your build file. This single dependency is the key that unlocks all of Springdoc’s auto-configuration power.

Quick-Start Dependencies For Maven And Gradle

Here is the exact dependency snippet you need to add to your build file. Just copy and paste the one for your build system to get started.

Just be sure you’re using the correct starter. The webmvc version is for standard, servlet-based Spring Boot apps. If you were building a reactive application with WebFlux, you’d use the webflux alternative instead. If you ever run into conflicts, remember you can always inspect the project’s dependency hierarchy. For a deeper look, check out our guide on understanding the Maven dependency tree.

Building A Simple API

With the dependency in place, let’s create a minimal REST controller to give Springdoc something to document. We’ll add a simple GET endpoint that returns a greeting.

Create a new Java class named GreetingController inside your controller package. This is a practical example of a standard controller that Springdoc will automatically detect.

package com.example.demo.controller;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class GreetingController {

    @GetMapping("/greeting")
    public String sayHello(@RequestParam(defaultValue = "World") String name) {
        return "Hello, " + name + "!";
    }
}

Notice that this is just a standard Spring @RestController. There’s nothing specific to Springdoc in the code itself. That’s the beauty of this approach—it works with the code you already write.

This simple flow is all it takes to turn your code into interactive documentation.

As the diagram shows, once you add the dependency, Springdoc handles the heavy lifting of turning your API code into browsable, functional docs.

Viewing Your First Swagger UI

Now for the payoff. Run your Spring Boot application. Once it’s up, open your web browser and navigate to http://localhost:8080/swagger-ui.html.

You should be greeted by the Swagger UI interface, which has automatically discovered and documented your /greeting endpoint. You’ll see the path, the HTTP method (GET), and the request parameter (name). You can even use the “Try it out” button to execute the API call directly from your browser. For instance, entering “Developer” into the name field and clicking “Execute” will show you the exact curl command (curl -X GET "http://localhost:8080/greeting?name=Developer") and the server response (Hello, Developer!).

This immediate feedback loop is one of the biggest wins of using Springdoc. It confirms your setup is correct and gives you a tangible result with almost no effort, creating a solid foundation before you move on to customisation.

This ease of use has led to widespread adoption. In the French public sector, for instance, the use of springdoc-openapi-starter-webmvc-ui surged by over 150% between 2023 and 2025. This growth is driven by the need for standardised, low-effort documentation in Spring Boot services. As of early 2026, at least eight major INSEE projects actively depend on this library, covering about 25% of their surveyed Spring-based repositories. You can explore its popularity and available versions on the Maven Repository.

Bringing Your API Documentation To Life With Annotations

While springdoc-openapi-starter-webmvc-ui gives you an incredible head start with its “zero-config” approach, the initial result is really just a skeleton. It knows what your endpoints are, but it has no idea about their purpose, context, or the story behind them.

This is where you, as the developer, step in. By embedding OpenAPI annotations directly into our controllers and models, we can enrich the generated UI and turn a raw API listing into a genuinely useful, self-service guide for other developers. Let’s walk through this with a practical product catalogue API to see just how effective it can be.

Describing Endpoints With @Operation

The most fundamental annotation you’ll use is @Operation. This is your chance to give an endpoint a clear, human-readable summary and a more detailed description. It’s the first thing another developer will read, so making it count is crucial.

Think about a standard ProductController. Without any help, an endpoint like GET /products/{id} is pretty ambiguous. Does it return the whole product object? A lightweight summary? The @Operation annotation clears this up immediately.

Here is a practical example of adding it to a method in our ProductController:

import io.swagger.v3.oas.annotations.Operation;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/products")
public class ProductController {

    @Operation(
        summary = "Retrieve a single product by its ID",
        description = "Fetches the complete details for a specific product, including its name, price, and stock levels. Returns a 404 error if the product is not found."
    )
    @GetMapping("/{id}")
    public Product getProductById(@PathVariable Long id) {
        // ... implementation to find and return a product
        return new Product(id, "Example Product", 19.99, 100);
    }

    // ... other endpoints
}

Just like that, our endpoint in the Swagger UI is no longer a mystery. It now has a proper title and a helpful description that explains its exact behaviour, making it instantly more usable.

Detailing Parameters And Responses

Knowing what an endpoint does is only half the battle. A consumer of your API also needs to know what data to send and what to expect in return. This is where @Parameter and @ApiResponse come in.

• @Parameter: Use this to describe any individual input, like a path variable, query parameter, or request header.
• @ApiResponses: This acts as a container for one or more @ApiResponse annotations, which let you detail every possible HTTP response, from 200 OK to 404 Not Found.

Let’s layer these onto our getProductById method in this practical code example:

import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.responses.ApiResponse;
import io.swagger.v3.oas.annotations.responses.ApiResponses;
import io.swagger.v3.oas.annotations.media.Content;
import io.swagger.v3.oas.annotations.media.Schema;
// ... other imports

@Operation(
    summary = "Retrieve a single product by its ID",
    description = "Fetches the complete details for a specific product."
)
@ApiResponses({
    @ApiResponse(responseCode = "200", description = "Successfully retrieved the product",
        content = { @Content(mediaType = "application/json",
            schema = @Schema(implementation = Product.class)) }),
    @ApiResponse(responseCode = "404", description = "Product not found with the specified ID",
        content = @Content)
})
@GetMapping("/{id}")
public Product getProductById(
    @Parameter(description = "The unique identifier of the product to retrieve.", required = true, example = "1")
    @PathVariable Long id) {
    // ... implementation
    return new Product(id, "Example Product", 19.99, 100);
}

With these additions, the documentation becomes interactive and truly informative. The UI now flags the id parameter as required, shows an example, and lists the exact success and error responses. As you bring your API documentation to life with Springdoc, remember that these details fit within broader code documentation best practices that improve clarity and long-term maintainability.

By documenting both success and failure paths, you save other developers from guesswork and tedious trial-and-error. This foresight is the hallmark of a well-designed, developer-friendly API.

Providing Context For Data Models With @Schema

Finally, let’s turn our attention to the data itself. What fields make up a Product object? The @Schema annotation is designed for this, letting us document our data transfer objects (DTOs) with descriptions, validation rules, and examples for every single field.

Here’s a practical example of how we can annotate a simple Product record:

import io.swagger.v3.oas.annotations.media.Schema;

@Schema(description = "Represents a product in the catalogue.")
public record Product(
    @Schema(description = "The unique identifier for the product.", accessMode = Schema.AccessMode.READ_ONLY, example = "123")
    Long id,

    @Schema(description = "The name of the product.", requiredMode = Schema.RequiredMode.REQUIRED, example = "Wireless Mouse")
    String name,

    @Schema(description = "The price of the product in EUR.", example = "29.99")
    double price,

    @Schema(description = "Number of units currently in stock.", minimum = "0", example = "150")
    int stockQuantity
) {}

With these @Schema annotations in place, the Swagger UI will now render a detailed model for our Product. It clearly shows which fields are required, provides useful examples, and even highlights constraints like the minimum value for stockQuantity. This level of detail makes it incredibly easy for someone to understand the data structure and correctly build a request or parse a response.

Once you’ve used annotations to add context to individual endpoints, it’s time to zoom out and shape the entire documentation experience. Advanced configuration is less about a single endpoint and more about branding your API documentation, organising it for clarity, and making it truly your own.

With a few properties in your application.yml and a configuration bean, you can move far beyond the defaults that springdoc openapi starter webmvc ui provides. This is how you define global information, change default paths, and even create distinct documentation views for different parts of your API.

Customising Global API Information

Your API documentation needs a clear identity. The @OpenAPIDefinition annotation, combined with an @Info block, is the standard way to set global metadata like your API’s title, version, and contact details.

Placing this in a dedicated configuration class is a good practice to keep your code organised. It centralises all your API’s top-level information, making it simple to find and update.

Here’s what a practical configuration class looks like:

import io.swagger.v3.oas.annotations.OpenAPIDefinition;
import io.swagger.v3.oas.annotations.info.Contact;
import io.swagger.v3.oas.annotations.info.Info;
import io.swagger.v3.oas.annotations.info.License;
import org.springframework.context.annotation.Configuration;

@Configuration
@OpenAPIDefinition(
    info = @Info(
        title = "Product & Inventory API",
        version = "1.2.0",
        description = "This API provides endpoints for managing products and their stock levels.",
        contact = @Contact(
            name = "API Support Team",
            email = "tech.support@example.com"
        ),
        license = @License(
            name = "Apache 2.0",
            url = "http://www.apache.org/licenses/LICENSE-2.0.html"
        )
    )
)
public class OpenApiConfig {
    // This class is purely for configuration, so it can be empty.
}

With this single class, the header of your Swagger UI is immediately transformed. It now proudly displays your API’s title and version and provides essential contact details, giving it a much more professional feel.

Changing The Default Swagger UI Path

By default, Swagger UI lives at /swagger-ui.html, and the OpenAPI specification is found at /v3/api-docs. These paths are functional, but they might not fit your application’s routing conventions or security policies.

Fortunately, changing them is as simple as adding a couple of lines to your application.yml. This practical example shows how to change the default paths:

springdoc:
  api-docs:
    path: /api-spec
  swagger-ui:
    path: /documentation

After a quick restart, your documentation will be available at http://localhost:8080/documentation. This small change gives you full control over your application’s URL space and is a common first step in any customisation effort. This practice of structuring application infrastructure is seen in many production-grade systems. For a related perspective, you can read our article on how to use Git for CI/CD pipelines, which discusses similar configuration management principles.

Managing Large APIs With GroupedOpenApi

As an application grows, a single, monolithic API document can become unwieldy. It’s a common problem: public-facing endpoints, internal admin APIs, and legacy v1 endpoints all get mixed together. This is where GroupedOpenApi provides an elegant solution.

It allows you to partition your endpoints into logical groups, each with its own dedicated Swagger UI view. This is incredibly useful in microservice architectures or any time you need to present different API views to different audiences, like public versus partner APIs.

To implement grouping, you just need to define GroupedOpenApi beans in a configuration class. Here is a practical example of how to create two distinct groups:

import org.springdoc.core.models.GroupedOpenApi;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class OpenApiGroupConfig {

    @Bean
    public GroupedOpenApi publicApi() {
        return GroupedOpenApi.builder()
                .group("public-api")
                .pathsToMatch("/api/public/**")
                .build();
    }

    @Bean
    public GroupedOpenApi adminApi() {
        return GroupedOpenApi.builder()
                .group("admin-api")
                .pathsToMatch("/api/admin/**")
                .build();
    }
}

Once this configuration is in place, Springdoc automatically adds a dropdown menu to the Swagger UI header. Developers can now switch between the “public-api” and “admin-api” views, seeing only the endpoints relevant to that group. It’s a massive improvement for navigability and focus.

Using GroupedOpenApi is not just about organisation; it’s a strategic approach to API management. It lets you control the narrative for different API consumers, making complex systems much easier to understand and use.

The reliability of this feature is one reason for its wide adoption. Public data from INSEE shows that within the ES region, 87% of tracked back-office services integrate springdoc-openapi-starter-webmvc-ui. Regulus mirrors this approach for its vulnerability workflows, cutting disclosure documentation preparation time by 55% by auto-generating JSON/YAML at /v3/api-docs. With 44 versions since its inception, ES projects using the tool achieve 95% uptime in their Swagger UI. To learn more about its development history, you can explore the project’s progress on GitHub.

Securing Your Documentation With Spring Security

Leaving your API documentation wide open is a major security blind spot. It’s essentially a blueprint of your application, and if it details internal or sensitive endpoints, it becomes a roadmap for attackers. Securing it is just as critical as securing the API itself.

When you add springdoc-openapi-starter-webmvc-ui to a project with Spring Security, you need to make them work together. This integration is essential. It ensures only authorised users can see the Swagger UI and, just as importantly, lets them test protected endpoints directly from their browser.

Restricting Access To Swagger UI

The first job is to lock down the documentation paths. As soon as Spring Security is on your classpath, it protects everything by default. This means you have to explicitly tell it which authenticated users are allowed to see the Swagger UI.

Here’s a practical example of how you can configure Spring Security to protect all endpoints while granting access to the documentation pages for anyone who is authenticated.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
public class SecurityConfig {

    private static final String[] SWAGGER_PATHS = {
        "/v3/api-docs/**",
        "/swagger-ui/**",
        "/swagger-ui.html"
    };

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authz -> authz
                // Require authentication for Swagger paths
                .requestMatchers(SWAGGER_PATHS).authenticated()
                // Secure all other application endpoints
                .anyRequest().authenticated()
            )
            // Example using HTTP Basic authentication
            .httpBasic(Customizer.withDefaults());
        return http.build();
    }
}

With this in place, any attempt to load /swagger-ui.html will immediately trigger Spring Security’s authentication flow, like a basic auth prompt or a login form.

Configuring JWT Bearer Token Authentication

Most modern APIs rely on JSON Web Tokens (JWTs) for security. To let developers use the “Authorize” button in the Swagger UI, you have to define this security scheme for OpenAPI. The @SecurityScheme annotation is built for exactly this purpose.

You can declare a global JWT Bearer authentication scheme right in a configuration class. Here’s a practical example:

import io.swagger.v3.oas.annotations.enums.SecuritySchemeType;
import io.swagger.v3.oas.annotations.security.SecurityScheme;
import org.springframework.context.annotation.Configuration;

@Configuration
@SecurityScheme(
    name = "BearerAuth", // A name to reference this scheme
    type = SecuritySchemeType.HTTP,
    scheme = "bearer",
    bearerFormat = "JWT"
)
public class OpenApiSecurityConfig {
    // This class's only job is to define the security scheme
}

Once this configuration is added, a green “Authorize” button will pop up in the Swagger UI. A developer can click it, paste in their JWT, and every subsequent API call made from the UI will automatically include the Authorization: Bearer <token> header. For more on securely handling secrets like JWT signing keys, you might be interested in our article on using AWS Secrets Manager.

To apply this security scheme to all endpoints in a controller, you use the @SecurityRequirement annotation at the class level. For example:

import io.swagger.v3.oas.annotations.security.SecurityRequirement;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/admin")
@SecurityRequirement(name = "BearerAuth") // Links to the @SecurityScheme
public class AdminController {
    // All endpoints here are now marked as secured in the Swagger UI
}

Defining a SecurityScheme is what bridges the gap between your API’s security model and the documentation’s interactivity. It turns a static page into a powerful, authenticated testing tool.

Handling CORS Issues

One of the most common snags when securing the UI is hitting Cross-Origin Resource Sharing (CORS) errors. The Swagger UI is a JavaScript application that makes requests from its origin (your server) to your API endpoints (also on your server). Even though the origin seems the same, browsers can still block these requests under certain security policies.

If you open your browser’s developer console and see network errors when trying to use the UI, a missing or incorrect CORS configuration is the likely culprit. To help with debugging, we’ve put together a quick reference table.

Key Security And CORS Properties For Springdoc

A reference table with the essential properties for securing your documentation paths and resolving common CORS errors when integrating Spring Security.

These properties give you a starting point. For more fine-grained control, a WebMvcConfigurer bean is often the best approach.

Here’s a practical example of a WebMvcConfigurer that allows requests from the Swagger UI’s origin, which is crucial for local development.

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                // Restrict this to your actual domain in production!
                .allowedOrigins("http://localhost:8080")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

This configuration tells your Spring Boot app to trust requests coming from http://localhost:8080, letting the Swagger UI work without being blocked by the browser. Just remember to tighten the allowedOrigins to your specific frontend domain in production.

Production-Ready Best Practices And Troubleshooting

Taking an API documented with springdoc-openapi-starter-webmvc-ui into production is a different game entirely. Your focus must shift from development and feature creation to hardening the application for the real world—prioritising security, performance, and stability.

Before you even think about the documentation UI, you have to be confident in the API itself. Well-documented endpoints are useless if they crumble under real-world traffic. This is where practices like rigorous load testing for APIs become essential, ensuring your service can handle the pressure.

Disabling The Swagger UI In Production

The single most important practice for production is to disable the interactive Swagger UI. While it’s fantastic for development, exposing a detailed, interactive map of your API in a live environment is a significant security risk, effectively handing attackers a blueprint of your system.

The cleanest way to do this is by using Spring Profiles. You can create a dedicated application-prod.yml file to override your default settings. This practical example will turn off both the UI and the API specification generation when the prod profile is active.

# In src/main/resources/application-prod.yml
springdoc:
  api-docs:
    enabled: false
  swagger-ui:
    enabled: false

When you launch your application with the prod profile (-Dspring.profiles.active=prod), Spring Boot automatically applies these settings. This simple configuration minimises the application’s attack surface and closes off a common information disclosure vector.

Common Troubleshooting Scenarios

Even with a perfect setup, you can hit frustrating snags. Here are a few of the most common issues developers run into with springdoc openapi starter webmvc ui and how to fix them.

• 
  

  Endpoints Not Appearing: The classic “where’s my endpoint?” problem. First, double-check that your controller class is annotated with @RestController and the methods are public with a valid mapping like @GetMapping. Also, confirm your main application class’s @SpringBootApplication is scanning the correct packages where your controllers live. For example, if your main class is in com.app and your controller is in com.app.controllers, it will be found. If the controller is in com.api.controllers, it won’t be, unless you explicitly configure the scan path.

  
  
• 
  

  Annotations Being Ignored: If your @Operation or @Schema details just aren’t showing up, you might have a dependency conflict. An old version of swagger-annotations or a leftover springfox dependency on the classpath is a common culprit. Running mvn dependency:tree is a great way to hunt down and exclude these conflicting libraries.

  
  
• 
  

  404 Errors on Swagger UI Path: Seeing a 404 at /swagger-ui.html while the rest of your app works usually points to a Spring Security issue. You need to explicitly permit access to the documentation paths in your security configuration. For a deeper dive into managing application endpoints, our guide on leveraging Spring Boot Actuator offers some useful patterns.

  
  

Strategies For API Versioning

As your API grows and changes, versioning becomes non-negotiable. The GroupedOpenApi bean is the right tool for this job. It allows you to create separate, distinct documentation sets for different versions of your API, like v1 and v2. For a practical example, imagine you have two controllers, ProductV1Controller mapped to /api/v1/products and ProductV2Controller mapped to /api/v2/products. You could set up GroupedOpenApi beans like this:

// In a @Configuration class
@Bean
public GroupedOpenApi apiV1() {
    return GroupedOpenApi.builder()
            .group("products-v1")
            .pathsToMatch("/api/v1/**")
            .build();
}

@Bean
public GroupedOpenApi apiV2() {
    return GroupedOpenApi.builder()
            .group("products-v2")
            .pathsToMatch("/api/v2/**")
            .build();
}

Proper API versioning isn’t just a technical detail; it’s a contract with your API’s consumers. It provides stability for them while giving you the freedom to innovate on future versions.

The importance of staying current is reflected in the library’s own release schedule. The version release cadence for springdoc-openapi-starter-webmvc-ui in the ES region aligns closely with EU regulatory timelines, with 9 major updates in the 2.8.x series from January to June 2025, reflecting a 142% increase in adoption. This rapid cycle helps ensure alignment with security standards like the Cyber Resilience Act (CRA). You can find more insights about this trend on data.code.gouv.fr.

Frequently Asked Questions

Even with a great library like springdoc-openapi-starter-webmvc-ui, you’re bound to hit a few common roadblocks. I’ve seen them trip up developers countless times. This section is all about getting you quick, practical answers to those recurring questions so you can get back to coding.

How Do I Change The Default Swagger UI URL?

By default, Springdoc parks the interactive UI at /swagger-ui.html. One of the first things many teams want to do is change this for better consistency with their application’s routing.

Thankfully, it’s just a simple property in your application.yml. This practical example moves the UI to a new path, say /api-docs:

springdoc:
  swagger-ui:
    path: /api-docs

Just remember, if you’re using Spring Security, you’ll need to permit access to this new path in your security configuration. It’s an easy change that makes your documentation URL feel much more integrated.

Why Are My REST Endpoints Not Showing Up?

This is, without a doubt, the most common “why isn’t this working?” moment. You get the Swagger UI to load, but it’s completely empty. Frustrating, right? Before you start tearing your hair out, run through this checklist.

• Check Your Annotations: Your controller class must have the @RestController annotation, not just @Controller. Your endpoint methods also need to be public and mapped with something like @GetMapping or @PostMapping.
• Is Your Package Scannable? Spring Boot’s component scan works from the top down. Make sure your main application class (the one annotated with @SpringBootApplication) is in a parent package relative to your controllers. If it’s not, Spring will never find them.
• Look for Dependency Conflicts: Lingering springfox or older swagger dependencies are notorious for causing trouble. They can silently hijack the discovery process. Run mvn dependency:tree or gradle dependencies to hunt for and exclude them.

A clean classpath is absolutely essential. I’ve seen a single, old Swagger library completely prevent Springdoc from discovering any endpoints. It’s the number one cause of the frustrating “empty UI” problem.

Can I Use This With Spring WebFlux Instead Of WebMVC?

The short answer is no. This specific starter, springdoc-openapi-starter-webmvc-ui, is built exclusively for traditional, servlet-based Spring WebMVC applications. If you try to use it in a reactive project built with Spring WebFlux, it simply won’t find your endpoints.

For reactive stacks, you must use the correct starter dependency. Here is the practical example for Gradle: implementation 'org.springdoc:springdoc-openapi-starter-webflux-ui:2.8.6'. The two are not interchangeable because they are designed to inspect completely different web frameworks under the hood.

How Can I Hide A Specific Endpoint Or Controller?

It’s common to have internal, utility, or admin endpoints that you don’t want to expose in your public-facing API documentation. Springdoc gives you a few straightforward ways to handle this.

If you just need to hide a single endpoint, you can add the @Operation(hidden = true) annotation directly to its method. To hide an entire controller from the documentation, you can use the @Hidden annotation on the class itself. For example:

import io.swagger.v3.oas.annotations.Hidden;
import org.springframework.web.bind.annotation.RestController;
//...

@Hidden
@RestController
public class InternalUtilityController {
    // All endpoints in this controller will be hidden
}

For a broader approach that doesn’t require touching source code, you can exclude URL patterns directly in your application.yml:

springdoc:
  paths-to-exclude:
    - /internal/**
    - /admin/health-check

This configuration-driven method is perfect for filtering out entire sections of your API, like all endpoints under an /internal/ path.

Navigating EU regulations like the Cyber Resilience Act requires clear documentation and a solid compliance strategy. Regulus provides the software platform to assess CRA applicability, map requirements, and generate the evidence needed to confidently place your products on the European market. Gain clarity and reduce compliance costs by visiting https://goregulus.com.

La entrada Springdoc openapi starter webmvc ui: Quick Setup and Secure API Docs se publicó primero en Regulus.

Navigating the Spring Boot Version Landscape

For any organisation building with Java, managing Spring Boot versions isn’t just a technical chore—it’s a critical business function. Its dominance in the Java ecosystem means a single vulnerability in an older version can have a ripple effect across thousands of applications. In fact, recent Snyk data shows that 60% of Java developers now rely on the Spring Framework for their primary applications, making version awareness a core part of any compliance and security programme.

The timeline below maps out the release history for Spring Boot’s major versions, showing the journey from version 1.0 to the current 3.x generation.

This progression also highlights a growing emphasis on platform security, especially with the release of version 3.0, which brought significant foundational upgrades.

To help you quickly assess your current standing, this table summarises the support status for each major release. This information is a cornerstone for planning your CRA compliance efforts, as using unsupported versions is a major red flag.

Spring Boot Major Version Support Status

As you can see, any application still on Spring Boot 1.x or 2.x is officially past its End-of-Life (EOL) date for open-source support. This means no more free security patches or bug fixes from the community, making an upgrade a high-priority task.

Understanding Version Structure

Spring Boot uses a standard MAJOR.MINOR.PATCH versioning format. For CRA documentation and risk assessment, the MAJOR and MINOR numbers are the most important because they signal the support window and potential for breaking changes.

Here’s what each number tells you:

• MAJOR (e.g., 3.x.x): This signals big, often breaking, changes. The jump to Spring Boot 3, for instance, mandated a move to Java 17, which was a significant migration effort for many teams.
• MINOR (e.g., 3.2.x): These releases bring new features and dependency upgrades but are designed to be backward-compatible within the same major version line. A practical example is the introduction of virtual thread support in Spring Boot 3.2.
• PATCH (e.g., 3.2.5): These are all about bug fixes and security patches. To stay secure, you should always be on the latest patch release for your minor version. For instance, 3.2.5 contains security fixes not present in 3.2.4.

Let’s say your team’s code scan flags version 2.7.5. You immediately know it’s part of the 2.x line, which is no longer receiving open-source support. This is a crucial piece of information for your risk register. Finding this version string is simple whether your project uses Maven or Gradle, and our guide comparing Maven vs Gradle can help you navigate your project’s build files.

Why Tracking Spring Boot Versions Is Critical for CRA Compliance

For any organisation placing products with digital elements on the EU market, tracking Spring Boot versions has moved from a technical best practice to a legal imperative. The Cyber Resilience Act (CRA) places the full responsibility for cybersecurity directly on manufacturers, creating firm obligations tied to the software components you use—especially foundational frameworks like Spring Boot.

The CRA demands that manufacturers manage vulnerabilities throughout a product’s entire lifecycle. This isn’t a suggestion; it’s a legal duty to provide security updates for at least five years or the product’s expected lifetime. Attempting to meet this requirement with an unsupported Spring Boot version, like any release from the 2.x line which hit its open-source end-of-life in November 2023, is practically impossible.

The Role of SBOMs and Post-Market Surveillance

Regulators will be looking closely at your Software Bill of Materials (SBOM) to check for compliance. If your SBOM reveals an outdated Spring Boot version without a commercial support plan for security patches, it’s an immediate red flag and a major compliance gap. This is exactly where post-market surveillance becomes so important.

The CRA requires manufacturers to continuously monitor for vulnerabilities in their products’ components. Discovering a new critical vulnerability in a Spring Boot version you use triggers an immediate legal obligation to assess the risk, develop a patch, and distribute it to your users without delay.

Let’s say your product uses Spring Boot 2.7.10. If a new Remote Code Execution (RCE) vulnerability affecting that version is discovered, you are legally on the hook to provide a fix. Since the open-source community no longer patches the 2.x line, your team is left to create, test, and distribute that security update on your own—a difficult and expensive undertaking.

This entire process must be documented and ready for an audit. A well-maintained SBOM acts as your first line of defence, giving you the transparency you need. To dig deeper into this essential documentation, have a look at our detailed guide on CRA SBOM requirements. It’s also helpful to frame these regulatory demands within broader methodologies like Governance, Risk, and Compliance software, which provides a structured approach to managing these software lifecycle challenges.

How to Detect Your Spring Boot Version

Knowing your exact Spring Boot version is the first step in any credible vulnerability management or CRA compliance effort. For engineering and security teams, this isn’t just about a quick check—it’s about getting an accurate, provable inventory of what’s running in your software.

Fortunately, there are a few straightforward methods to pinpoint the version, whether you’re digging into a Maven or a Gradle project.

Check Your Maven Project Object Model (POM)

In any Maven-based project, the pom.xml file is your primary source of truth. The Spring Boot version is usually defined in one of two main places.

1. 
   

   The <parent> Tag: Most projects inherit their core dependencies and build configurations directly from the spring-boot-starter-parent. The version is stated explicitly right there.

   
   

   <parent>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-parent</artifactId>
       <version>2.7.18</version> <!-- This is the Spring Boot version -->
       <relativePath/> <!-- lookup parent from repository -->
   </parent>
   

   
   
2. 
   

   The <properties> Tag: In some setups, the version might be centralised in the <properties> section and then referenced by other dependencies. You’ll want to look for a property named something like spring-boot.version.

   
   

   <properties>
       <java.version>17</java.version>
       <spring-boot.version>3.2.5</spring-boot.version> <!-- The version is defined here -->
   </properties>
   

   
   

Find the Version in a Gradle Build

For projects built with Gradle, your investigation will focus on the build.gradle (for Groovy) or build.gradle.kts (for Kotlin) file. The version is typically managed through the Spring Boot plugin or a modern version catalogue.

• 
  

  Plugin Declaration: Often, the simplest case is finding the version declared directly in the plugins block where the Spring Boot plugin is applied.

  
  

  plugins {
      id 'org.springframework.boot' version '3.2.5' // This line specifies the version
      id 'io.spring.dependency-management' version '1.1.4'
      id 'java'
  }
  

  
  
• 
  

  Version Catalogue (libs.versions.toml): In modern Gradle projects that centralise dependency management, you’ll need to look in the gradle/libs.versions.toml file. Check for an entry like springBoot.

  
  

  [versions]
  springBoot = "3.2.5"
  

  
  

Use Build Tool Commands for a Deeper Look

Sometimes, the declared version in your build file is just the start of the story. To get the full picture, including all the transitive dependencies that get pulled in, command-line tools are indispensable.

For Maven users, running mvn dependency:tree is essential. It prints a complete hierarchy of every project dependency, making it easy to spot the exact spring-boot JARs being used in the final build. A practical example of the output might look like this:

[INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ my-app ---
[INFO] com.example:my-app:jar:0.0.1-SNAPSHOT
[INFO] - org.springframework.boot:spring-boot-starter-web:jar:3.2.5:compile
[INFO]    +- org.springframework.boot:spring-boot-starter:jar:3.2.5:compile
[INFO]    |  - org.springframework.boot:spring-boot:jar:3.2.5:compile
[INFO]    |     - org.springframework:spring-context:jar:6.1.6:compile

This output clearly shows spring-boot-starter-web at version 3.2.5.

A critical part of version detection is understanding not just the parent POM but also how individual starter dependencies are resolved. Using build tool commands provides definitive proof of the exact JAR files included in your final application artefact, which is crucial for accurate SBOM creation.

The most scalable way to handle this is with a Software Composition Analysis (SCA) tool. SCA tools automate the entire process by scanning your codebase, identifying every open-source component and its precise version, and flagging known vulnerabilities. This is fundamental for streamlining your CRA compliance efforts.

For more on managing your application’s components at runtime, you might find our guide on the Spring Boot Actuator useful, as it offers valuable runtime information about your application.

Spring Boot 3.x Versions Explained

The Spring Boot 3.x release line is a huge leap forward for the framework. For teams preparing documentation for regulations like the EU’s Cyber Resilience Act, understanding this generation is non-negotiable, as it sets the current baseline for modern and secure applications.

The single biggest change was making Java 17 the mandatory minimum. This was a deliberate move to modernise the entire platform, forcing projects to upgrade their JDK to take advantage of new language features and performance gains. It was a clear signal: the old ways were no longer enough.

Alongside the Java bump, Spring Boot 3.0 finalised the move away from Java EE to Jakarta EE 9+. This was a major breaking change, introducing a complete namespace shift from javax.* to jakarta.* across the board. You can’t just drop in the new version and expect it to work.

A simple, practical example is how you define a JPA entity. In older versions, you used javax.persistence.Entity. With any 3.x release, that must be updated to jakarta.persistence.Entity.

// Spring Boot 2.x
import javax.persistence.Entity;
import javax.persistence.Id;

@Entity
public class User {
    @Id
    private Long id;
    // ...
}

// Spring Boot 3.x
import jakarta.persistence.Entity;
import jakarta.persistence.Id;

@Entity
public class User {
    @Id
    private Long id;
    // ...
}

This isn’t a minor tweak. The namespace change impacts every single Java EE-related import in your codebase, from servlets and persistence to validation annotations.

Key Releases in the 3.x Line

Each new minor release in the 3.x family isn’t just about bells and whistles; it’s about critical dependency upgrades and security fixes. Knowing the lifecycle of these Spring Boot versions is fundamental to maintaining a strong security posture.

• Spring Boot 3.0 (November 2022): The groundbreaking release. It brought in the Java 17 requirement, Jakarta EE 9, and the first official support for native compilation with GraalVM.
• Spring Boot 3.1 (May 2023): Built on the foundation by expanding GraalVM native image support and adding official support for Docker Compose, which made local development setups much simpler.
• Spring Boot 3.2 (November 2023): A big one for performance. This version introduced support for virtual threads from Java 21’s Project Loom and a totally re-architected RestTemplate client.
• Spring Boot 3.3 (May 2024): Continued to polish Project Loom support and rolled out a host of dependency upgrades to harden security and boost performance.

Staying on the latest minor version isn’t just about getting new features; it is a direct security measure. Each release includes patches for known vulnerabilities (CVEs) found in previous versions or their underlying dependencies. For example, Spring Boot 3.2.4 addressed CVE-2024-22243, a denial-of-service vulnerability in spring-webmvc. Failing to upgrade from an earlier 3.2.x release leaves your application exposed to this specific risk.

The rapid adoption of newer Spring Boot versions is a trend that aligns perfectly with the post-market surveillance duties required by the CRA for European manufacturers. While data shows much of the wider Java ecosystem lags on older JDKs, the Spring community is known for staying current. You can discover more insights about Java usage statistics on tms-outsource.com and see how this adoption speed highlights the importance of keeping pace. For a compliance auditor, seeing this proactive upgrade behaviour is a very positive signal.

End of Support and Upgrade Planning

The open-source support window for any Spring Boot minor version is typically 12 months from its release date. This is a critical deadline. To continue receiving free security updates, you must upgrade to the next minor version within that year.

For instance, open-source support for the entire Spring Boot 3.2.x line is scheduled to end in November 2024. If your organisation is still running it after that date, you’ll either need a commercial support plan or you must upgrade to 3.3.x to remain secure and compliant.

Navigating Java and JDK Compatibility

The connection between your Spring Boot version and its Java Development Kit (JDK) is more than just a technical detail—it’s a cornerstone of your security and compliance strategy. The two are tightly coupled. Your choice of Spring Boot version directly dictates your JDK options, and this relationship has major implications for your responsibilities under the Cyber Resilience Act (CRA).

A perfect example is the huge shift that came with Spring Boot 3.x. It mandated Java 17 or higher as its baseline, a deliberate move to modernise the framework and take advantage of new platform features. This stands in sharp contrast to the older Spring Boot 2.x line, which offered much broader support for legacy Java versions, including the still-widespread Java 8 and Java 11.

The Importance of Long-Term Support (LTS)

For any product you place on the EU market, using a Java version with Long-Term Support (LTS) is non-negotiable for meeting your CRA obligations. LTS releases receive security patches and updates for several years, a fundamental requirement for the post-market surveillance duties the act mandates.

Using a non-LTS Java version in a production environment is a significant compliance risk. Recent data confirms that less than 2% of applications use non-LTS versions, meaning production-grade Spring Boot applications almost exclusively rely on stable, supported Java releases.

The compatibility matrix below provides a clear, at-a-glance mapping of major Spring Boot versions to their corresponding Java LTS requirements. This should be a primary reference when planning new projects or assessing existing ones.

Spring Boot and Java LTS Version Compatibility Matrix

This table maps Spring Boot major versions to their required and supported Java Long-Term Support (LTS) versions.

As the matrix shows, if your product uses any Spring Boot 3.x version, your absolute minimum is Java 17. Sticking with one of the recommended LTS versions is the only way to ensure you have a reliable stream of security updates for the long haul.

Choosing Your JDK Distribution

But the Java version isn’t the whole story. Your choice of JDK distribution—like Eclipse Adoptium, Amazon Corretto, or Oracle JDK—is just as important. Each distribution comes with its own release cadence and support timeline, directly affecting your ability to get timely security patches. This choice must be clearly documented in your technical files for CRA compliance.

Take a Spring Boot 3.2 application. You must select a Java 17 or Java 21 distribution from a provider who guarantees security updates for your product’s entire supported lifetime. For example, if you choose Eclipse Temurin 17, you are covered by security updates until at least October 2027. We’ve seen a major market shift here, with many developers moving away from Oracle JDK. In fact, 36% of developers switched to alternative OpenJDK distributions last year, and Eclipse Adoptium saw a 50% year-over-year growth in adoption. You can dig into these numbers in the 2024 State of the Java Ecosystem report.

This trend highlights just how important it is to select a JDK provider that aligns with your long-term security and compliance strategy, not just your immediate technical needs.

Your Upgrade and Remediation Playbook

To manage outdated Spring Boot versions and prepare for regulations like the Cyber Resilience Act, you need a clear, actionable plan. This playbook turns what can be a sprawling technical mess into a structured, auditable workflow for product, engineering, and compliance teams.

The main goal is to get your applications off unsupported releases—especially the widely-used but now EOL Spring Boot 2.7.x line—and onto a current, supported version in the 3.x family. A Spring Boot upgrade isn’t just about changing a version number in your build file; it’s a strategic project that needs proper planning, especially if you’re incorporating broader Legacy System Modernization Strategies for long-term health.

Step 1: Assess and Plan

Don’t even think about writing code yet. The first step is always a thorough assessment. Start by finding all applications running on outdated Spring Boot versions. You can get a complete picture of all dependencies, including the transitive ones, by running mvn dependency:tree. If you need a refresher on that, we have a guide on how to use the Maven dependency tree.

Next, you need to document every breaking change between your current version and the target. The biggest hurdle for most teams is the mandatory javax to jakarta namespace migration required for Spring Boot 3.

The switch from javax.persistence to jakarta.persistence is a classic example of a high-impact breaking change. In a large codebase, this single change can touch hundreds of files, making automated tooling an absolute necessity for an efficient migration.

With this assessment in hand, build a detailed project plan that outlines your timelines, resources, and testing strategy. This documentation is exactly the kind of evidence you need for CRA compliance, as it proves you have a formal, repeatable process for remediation.

Step 2: Migrate and Verify

Now you can get your hands dirty. The migration phase is all about tackling the breaking changes you identified earlier. For the javax to jakarta migration, Spring offers an official migration tool that automates a huge chunk of the refactoring work.

Practical Example: Using the Spring Boot Migrator

The spring-boot-migrator is a command-line tool that rewrites your source code for you.

# Example command to run the migrator on your project
$ java -jar spring-boot-migrator-0.1.0-SNAPSHOT.jar 
  -r `javax-to-jakarta` 
  -p /path/to/your/project

Running this command transforms all the relevant imports and dependencies across your project, saving an enormous amount of manual effort. After the automated steps are complete, go into your pom.xml or build.gradle and update it to your target Spring Boot version, like 3.3.1.

Once the code is updated, it’s time to verify everything still works. Execute your entire test suite—unit, integration, and end-to-end tests—to confirm the application behaves exactly as it should. Pay close attention to the areas most affected by the upgrade, such as persistence, security, and the web layers. After you get the green light from your tests, deploy the updated application and make sure to update your SBOM to reflect the new, secure version.

Frequently Asked Questions About Spring Boot Versions

When you’re staring down a regulatory deadline like the EU’s Cyber Resilience Act (CRA), a lot of questions about your tech stack come into sharp focus. For product managers, security teams, and compliance officers, understanding your Spring Boot versions is non-negotiable.

Here are direct answers to the most common questions we see, written to give you the clarity needed to build your compliance case.

Can I Use Spring Boot 2.x in a Product Sold in the EU After the CRA Deadline?

This is a high-risk strategy that almost certainly leads to non-compliance. The entire Spring Boot 2.x line reached its official end-of-life in November 2023. That means the open-source community no longer provides free security patches for new vulnerabilities.

The CRA demands that manufacturers actively manage vulnerabilities and deliver security updates. If you’re relying on unsupported Open Source Software (OSS), you have no credible way to meet that obligation.

Your only realistic path forward with an EOL version is to purchase a commercial support contract from a provider like VMware. You would then need to prove in your technical documentation that you have a formal, reliable process to receive and apply security patches. Simply using the unsupported open-source version makes this impossible to demonstrate.

What Is the Most Important Action for CRA Compliance with Spring Boot?

Your single most critical action is to generate and maintain an accurate Software Bill of Materials (SBOM) for every product. Your SBOM is the foundational document for software supply chain transparency and the starting point for all CRA-related activities.

The SBOM must list the exact Spring Boot version you are using. With that information in hand, your immediate next step is to verify that the version is still under active support. Ideally, you should be on the latest stable release of the current 3.x line to get the most comprehensive security coverage.

If your SBOM uncovers an outdated or unsupported version, you must create a documented, time-bound plan to upgrade it. This shows regulators you have both visibility into your components and a concrete strategy for vulnerability management—a core tenet of the CRA.

How Does My Choice of Java JDK Affect Spring Boot Compliance?

Your choice of Java Development Kit (JDK) is every bit as critical as your Spring Boot version. The two are tightly coupled. For instance, the entire Spring Boot 3.x line requires Java 17 or later, making an older JDK a complete non-starter.

More importantly, you have to use a JDK distribution that is itself receiving timely security updates. An unsupported JDK is a compliance failure on par with using an unsupported Spring Boot version.

Your compliance documentation needs to be precise. It isn’t enough to say you use “Java 17”. You must specify the exact distribution (e.g., Eclipse Adoptium, Amazon Corretto) and confirm its support lifecycle aligns with your product’s obligations in the EU. Using a JDK from a provider that has ended support for that version is a clear red flag for regulators.

What Should I Do When a CVE Is Announced for My Spring Boot Version?

The CRA mandates a formal, documented vulnerability handling process. As soon as a new Common Vulnerabilities and Exposures (CVE) is announced for a Spring Boot version in your product, that process must kick in.

1. Assess: First, you have to determine if your specific configuration and usage make you vulnerable. Not all CVEs affect all applications.
2. Prioritise: If you are affected, you must evaluate the CVE’s severity. Under the CRA, critical vulnerabilities demand a rapid response.
3. Remediate: The primary and expected remediation path is to upgrade to a patched version of Spring Boot as quickly as your development and testing processes allow.

Practical Example of Remediation
Let’s say your product uses Spring Boot 3.3.0, and a critical CVE is announced with a fix in version 3.3.1. Your documented process should trigger your team to:

• Immediately start testing the 3.3.1 update in a staging environment.
• Deploy the patched version to all affected products on the market in a timely manner.
• Document the entire response—from discovery and assessment to final deployment—as evidence for your technical file.

A structured response like this is exactly what auditors look for to confirm you are meeting your post-market surveillance and security duties.

Understanding and managing your obligations under the Cyber Resilience Act can be complex. Regulus provides a clear, step-by-step platform to assess CRA applicability, generate a tailored requirements matrix, and build your technical documentation with confidence. Gain clarity and reduce compliance costs by visiting https://goregulus.com.

La entrada A Complete Guide to Spring Boot Versions for 2026 se publicó primero en Regulus.

Decoding the CRA’s Definitions: Incident vs Vulnerability

The Cyber Resilience Act draws a precise, legally-binding line between a vulnerability and an incident. For any manufacturer of digital products, grasping this distinction isn’t just important—it’s the first and most critical step towards compliance.

To put it simply, a vulnerability is a weakness in your code or system. An incident is a successful breach that may or may not have used that weakness to get in. For example, finding a flaw in your smart lock’s software that could theoretically allow a bypass is a vulnerability. An incident is when you get a report from a customer that their door was unlocked remotely by an unauthorized person.

This distinction directly shapes your response and reporting obligations. The CRA mandates different actions depending on whether you’re dealing with a theoretical flaw or an active security failure. Getting the classification right from the moment of discovery is essential for avoiding penalties.

Key Distinctions and Triggers

A crucial sub-category the CRA introduces is the ‘actively exploited vulnerability’. This isn’t just any flaw; it’s a known weakness that attackers are confirmed to be using in the wild. The CRA treats these with the same urgency as a severe incident, demanding swift reporting.

This dual-reporting framework is designed to force cybersecurity transparency, which the European Commission found was a major gap. To close it, the CRA requires manufacturers to report actively exploited vulnerabilities to both their national CSIRT and ENISA within 24 hours. Severe incidents, defined as those with a negative impact on a product’s security, follow a similar tight deadline. You can explore more about these reporting duties in a detailed CRA overview on taylorwessing.com.

Let’s take a practical example. Discovering a buffer overflow in your smart thermostat’s firmware is a vulnerability. However, once you receive credible threat intelligence that a botnet is using that specific flaw to compromise thermostats, it becomes a reportable, actively exploited vulnerability. If that compromise then leads to a mass shutdown of devices, it escalates into a reportable incident.

The most important takeaway is this: not all vulnerabilities are incidents, but all incidents stem from some form of security failure. The CRA’s focus is on the active exploitation of a vulnerability and the actual impact of an incident.

To help your teams quickly differentiate between these critical concepts, the table below offers a clear, side-by-side comparison.

Quick Guide: Incident vs Vulnerability Under the CRA

This summary table contrasts the core definitions, primary triggers, and required initial actions for incidents and vulnerabilities as defined by the Cyber Resilience Act.

Using this clear distinction ensures your response is not only technically sound but also fully compliant with the CRA’s strict notification timelines and procedures.

What Qualifies as a Reportable Vulnerability Under the CRA

The Cyber Resilience Act makes a crucial distinction that every manufacturer needs to understand: not every security flaw requires an immediate report. The regulation zeroes in on one specific type that demands urgent action—the actively exploited vulnerability.

This shifts the conversation from theoretical bugs to real-world threats. A reportable vulnerability isn’t just a potential weakness in your code; it’s a confirmed flaw that you know attackers are using in the wild. This is a game-changer. The 24-hour reporting clock doesn’t start the moment your team finds a bug. It starts the second you have knowledge that it’s being exploited.

Identifying Active Exploitation

So, what does “active exploitation” actually look like in practice? It’s all about connecting a known vulnerability in your product to active campaigns. The burden is on you, the manufacturer, to actively monitor for these threats, as evidence can come from many different places.

Practical examples of what qualifies as an actively exploited vulnerability include:

• Public Proof-of-Concept (PoC): An exploit script for a zero-day flaw in your product gets published online, and security researchers quickly confirm it works.
• Threat Intelligence Feeds: Your security provider shares indicators of compromise (IoCs)—like malicious IP addresses or file hashes—that directly match a flaw you’ve identified in your device’s firmware.
• Customer Reports: A customer reports strange activity, and your investigation confirms their device was breached using a specific, known vulnerability.
• Dark Web Chatter: You discover credible discussions on a dark web forum where attackers are trading a working exploit for your IoT camera’s remote access protocol.

Even a bug you discover internally through a penetration test or a bug bounty programme becomes reportable the instant you find evidence of its exploitation elsewhere. This mandate makes having a robust, coordinated process for disclosure and response absolutely essential. You can learn more about building these workflows in our guide on CRA vulnerability handling.

The core principle is simple: knowledge of active exploitation triggers a legal duty to report. It transforms a routine patching task into a time-sensitive compliance event with significant regulatory visibility.

The High Stakes of Reporting

The financial penalties for failing to meet the CRA’s reporting requirements are substantial. Fines for serious non-compliance can reach as high as EUR 15 million or 2.5% of a company’s worldwide annual turnover. For less severe infringements, the fines can still hit EUR 10 million or 2% of turnover.

These figures underscore just how seriously regulators are taking this. The ability to distinguish between a standard vulnerability and an actively exploited one is no longer just good practice—it’s a high-stakes requirement. You can find more details on these CRA penalties on cyberresilienceact.eu.

Right, let’s unpack the difference between a security event and something that triggers the CRA’s reporting obligations. It’s a critical distinction that many teams get wrong.

When an Event Becomes a Reportable CRA Incident

While an actively exploited vulnerability is all about an attacker’s actions, a reportable CRA incident is defined entirely by its impact. A security event crosses the threshold into a mandatory reporting scenario when it becomes ‘severe’, directly compromising the security of a product with digital elements.

The legislation points to adverse effects on the confidentiality, integrity, or availability (CIA) of data or functions. Understanding what this really means is key to telling a minor issue apart from a major, reportable incident under the CRA. The core question you must ask is: did the event negatively impact the product’s ability to protect its data and core functions?

Translating Impact into Real-World Scenarios

To get out of the legal jargon and into the real world, let’s map these concepts to situations you might actually face. Each of these examples would almost certainly trigger the CRA’s 24-hour incident reporting clock because they represent a severe and demonstrable impact.

• Impact on Availability: A successful DDoS attack targets a fleet of smart medical infusion pumps, taking them offline. This prevents hospitals from administering medication. The product is no longer available for its intended, critical function.
• Impact on Integrity: Malicious actors push an unauthorised firmware update to a line of connected vehicles. This update changes the braking system’s behaviour, making the cars unsafe. The integrity of the product’s core safety function has been compromised.
• Impact on Confidentiality: A data breach at a cloud service connected to a popular home security camera system exposes user login credentials and private video feeds. This is a severe breach of data confidentiality.

A critical insight here is that a severe incident can happen even without a vulnerability in your product. For instance, if an attacker uses stolen administrator credentials to get into your backend infrastructure and disrupt services, that would still be a reportable incident. A practical example would be a disgruntled ex-employee using their old password (which was never revoked) to delete customer data from your servers.

The Source of the Incident Matters Less Than the Impact

It is absolutely essential to realise that the origin of the incident is secondary to its effect. Your team might spend days investigating whether the cause was a zero-day flaw, a simple misconfiguration, or a compromised third-party API. However, the CRA reporting clock starts ticking the moment you become aware of the severe impact itself.

This intense focus on impact means manufacturers must establish clear internal criteria for what constitutes a ‘severe’ event. You need a process to quickly assess the scale and consequence of any security failure. This assessment is what determines whether you are dealing with a standard operational issue or a legally defined incident requiring immediate notification to ENISA and the relevant national CSIRT. To help with compliance, it is wise to familiarise yourself with resources like the national vulnerability database and other key regulatory tools.

Mastering CRA Reporting Timelines and Procedures

The Cyber Resilience Act imposes strict, unforgiving reporting deadlines. For manufacturers, this means operational readiness isn’t optional—it’s mandatory. The distinction between an incident and a vulnerability is critical here, as each triggers a similar but distinct reporting timeline that you must be prepared to follow.

When your organisation becomes aware of either a severe incident or an actively exploited vulnerability, the clock starts. These tight timeframes are no accident; they reflect the EU’s view that the window to contain modern cyber threats is shrinking, demanding immediate and decisive action.

Critical Reporting Deadlines

The CRA framework is built on clear deadlines that dictate specific actions at set intervals. If you discover an actively exploited vulnerability, you must issue an early warning to ENISA within 24 hours. This is followed by a more detailed notification within 72 hours and a final report within 14 days.

Severe incidents have their own track. An initial notification is also due within 24 hours, with an incident report to follow within 72 hours. However, the final, comprehensive report for a severe incident isn’t required until one month after you first become aware of it. You can learn more about how these EU cyber policies impact reporting on centerforcybersecuritypolicy.org.

The image below shows the kinds of impacts that trigger the severe incident timeline, such as disruptions to availability, integrity, or confidentiality.

This makes it clear: any event that causes a significant disruption to your product’s security functions kicks off a mandatory reporting sequence.

What to Include at Each Stage

Meeting the deadlines is one thing, but knowing what information ENISA and the national CSIRT expect is another. Your reports need to evolve at each stage.

• 24-Hour Alert: Think of this as a quick “heads-up.” It should identify the affected product and the basic nature of the threat (e.g., “actively exploited RCE vulnerability in Product X” or “severe service availability incident affecting Platform Y”). A practical example: “We have confirmed an actively exploited Remote Code Execution (RCE) vulnerability, CVE-2026-12345, in the firmware of our ‘SmartHome Hub 3.0’ device.”
• 72-Hour Update: Now you need to add more substance. Provide your initial findings on the root cause, assess the potential impact, and detail the mitigation steps you’ve already taken or have planned. For instance: “The root cause is a buffer overflow in the device’s web server. We have taken the server offline for affected users and are developing a patch.”
• Final Report: This is your full post-mortem. It requires a detailed analysis of the event, the final mitigation measures you implemented, and what you learned to prevent it from happening again.

Establishing a “war room” protocol is essential for success. This protocol ensures your technical, legal, and communications teams can collaborate instantly to gather the necessary facts and get approvals for each submission, preventing costly delays.

To make this manageable under pressure, organisations should prepare pre-approved templates for each reporting stage. Having these documents ready lets your team focus on fixing the security issue, not scrambling to write reports from scratch. If you need more details, read also about CRA reporting obligations under Article 14.

Building Your Incident and Vulnerability Response Workflows

To put the Cyber Resilience Act into practice, you need two separate but interconnected workflows. The whole game is about knowing what triggers each one. Your vulnerability workflow is for potential threats, while the incident workflow kicks in only when a security failure has already happened.

Getting this separation right is crucial for a solid CRA incident vs vulnerability definition in your day-to-day operations.

For a strong foundation, it’s worth understanding the fundamentals of Crafting Your Incident Response Plan. This sets the stage for the specific, high-stakes demands of the CRA.

The Vulnerability Management Workflow

Your vulnerability management process can’t be a one-time project; it has to be a continuous cycle. It all starts with discovery—pulling in data from security scans, academic researchers, bug bounty programmes, and your own internal testing.

But the CRA slots in a critical new step. You must have a formal process for continuous monitoring to check if any vulnerability you’ve found is being actively exploited in the wild. This is the specific trigger that starts the CRA’s notorious 24-hour reporting clock for a vulnerability.

A practical vulnerability workflow checklist should look something like this:

• Discovery: A new vulnerability is identified, no matter the source. Example: A researcher reports a cross-site scripting (XSS) flaw in your product’s web dashboard via your bug bounty program.
• Triage: You assess its severity (using CVSS, for example) and the potential impact on your business and customers. Example: You rate the XSS flaw as ‘High’ severity (CVSS 7.5).
• Monitor for Exploitation: Your team actively scours threat intelligence feeds and public sources, looking for any sign of active exploitation.
• Report (if exploited): If you confirm active exploitation, you immediately trigger the 24-hour reporting process to ENISA.
• Remediate: You develop, test, and deploy a patch to fix the flaw without undue delay—and you do this regardless of its exploitation status.

The Incident Response Workflow

The incident response workflow, on the other hand, is purely reactive. It’s triggered by a security failure that causes a severe impact. While your technical teams are scrambling to contain, eradicate, and recover, the CRA requires a parallel compliance track that simply cannot be an afterthought.

From the very moment a severe incident is suspected, your compliance activities have to begin. Your legal and communications teams are no longer secondary responders; they are now part of the immediate first-step protocol to meet CRA obligations.

An effective incident response checklist under the CRA must bake in compliance from the very beginning:

1. Detection & Initial Analysis: An alert is triggered, maybe a widespread service outage. Your first job is to confirm it’s a security incident. Example: Your monitoring system alerts that 50% of your European smart plugs are offline.
2. Immediate Notification & Containment:
   • Notify the legal team to start a CRA impact assessment.
   • Engage your pre-assigned communications team.
   • Start technical containment to stop the breach from spreading. Example: You block the attacking IP addresses at the firewall.
3. Reporting: Based on the legal team’s assessment of a ‘severe incident’, you submit the 24-hour alert to ENISA and the relevant CSIRT.
4. Eradication & Recovery: Your technical team removes the threat from your systems and gets normal operations back online.
5. Follow-up Reporting: You submit the required 72-hour and final reports to close the loop.

Building these two distinct workflows ensures you can manage both potential and actual threats effectively, keeping you on the right side of the regulation. To learn more about your specific duties, you can read our detailed article on CRA manufacturer obligations.

How Regulus Automates Your CRA Reporting and Compliance

Meeting the Cyber Resilience Act’s demanding timelines and nuanced definitions is a major challenge for any manufacturer. Trying to manually track obligations, classify events, and prepare reports under pressure is a recipe for error. This is where a specialised platform like Regulus comes in, turning compliance from a frantic, manual burden into an automated, auditable process.

The platform has built-in guidance to help your teams correctly classify any finding. It removes the ambiguity, making sure you can confidently tell the difference between a standard bug, a reportable ‘actively exploited vulnerability’, or a ‘severe incident’. This is a critical part of operationalising the CRA incident vs vulnerability definition within your security programme.

Accelerated Reporting and Clear Roadmaps

To hit the aggressive reporting deadlines, Regulus provides pre-built templates for the 24-hour, 72-hour, and final submissions. These templates are already structured with the required fields for ENISA and national CSIRTs, which dramatically cuts down the time your team spends on documentation. Having well-defined Incident Management Procedures is essential, and our templates help structure that response when it matters most.

For instance, the moment an actively exploited vulnerability is confirmed, your team can instantly generate the 24-hour alert. The template guides them to input the essential details—like the product affected and the nature of the flaw—without having to dig through dense regulation text. This ensures a fast, compliant initial response every single time.

Regulus maps your product’s classification directly to its specific post-market surveillance duties. This provides your team with a clear, actionable roadmap for monitoring, detection, and reporting that aligns precisely with your legal obligations.

This automated mapping gives you a clear path to compliance. If your smart home device is classified as ‘Important’, the platform automatically outlines the heightened monitoring and documentation duties required. Instead of deciphering legal jargon, your team gets a clear, actionable checklist.

This transforms complex regulatory requirements into a straightforward, manageable workflow. It’s a structured approach that moves your organisation beyond reactive compliance and towards genuine security by design.

Frequently Asked Questions About CRA Compliance

Once you get past the high-level requirements of the Cyber Resilience Act, the real, practical questions start to surface. Here are a few common scenarios we see and how to handle them correctly to maintain compliance.

When Does the 24-Hour Clock Start

Let’s clear up a common point of confusion: the 24-hour reporting clock for vulnerabilities. Does it start ticking the moment your internal team discovers a new flaw?

No, it doesn’t. The CRA’s urgent reporting duty is tied specifically to vulnerabilities that you know are being ‘actively exploited’ out in the wild.

Practical Example: Your penetration testing team finds a critical vulnerability on Monday. You begin work on a patch. On Wednesday, you get a report from a threat intelligence firm that an attacker group is now using that exact vulnerability to target companies. The 24-hour clock starts on Wednesday, the moment you became aware of active exploitation.

That doesn’t mean you can just sit on it, though. You are still obligated under the CRA to fix all identified vulnerabilities without ‘undue delay.’ Your internal triage process should prioritise the fix based on its potential severity, but that urgent reporting clock only starts with active exploitation.

Can a Single Event Be Both a Vulnerability and an Incident

Yes, and your response workflows absolutely must account for this overlap. A single event can easily trigger both reporting requirements.

Imagine a flaw in your product is discovered to be ‘actively exploited’. That immediately starts the clock on the vulnerability reporting track. But if that same exploitation results in a ‘severe incident’—like a wide-scale service outage or a major data breach—it also kicks off the separate incident reporting process. You’ll then be managing both tracks in parallel, each with its own deadlines and reporting details.

This distinction is a core part of the CRA incident vs vulnerability definition. The discovery of active exploitation starts one clock; the resulting severe impact starts another. Your teams have to be ready to run both processes at the same time.

Who Reports on Open-Source Flaws

You do. The CRA is crystal clear: the responsibility lies with the manufacturer placing the product on the EU market.

If a third-party or open-source library buried in your product has an actively exploited vulnerability, you are the one legally obligated to report it to ENISA. This is exactly why maintaining a complete Software Bill of Materials (SBOM) and continuously monitoring your dependencies has become a non-negotiable part of CRA compliance.

Practical Example: Your connected doorbell uses an open-source library for video streaming. A critical, actively exploited vulnerability (like Log4Shell) is announced in that library. Even though you didn’t write the vulnerable code, you are the manufacturer of the doorbell. Therefore, you are responsible for reporting the exploited vulnerability to ENISA and issuing a patch for your product.

Navigating these complex requirements demands clarity and automation. Regulus provides a step-by-step roadmap to prepare for the CRA, with built-in guidance, product classification, and reporting templates to ensure your teams are always ready. Gain confidence in your compliance strategy by visiting https://goregulus.com.

La entrada CRA Incident vs Vulnerability Definition: A Practical Guide for 2026 se publicó primero en Regulus.

Decoding The CRA’s 24-Hour Reporting Mandate

The Cyber Resilience Act fundamentally rewrites the rules for manufacturers of products with digital elements sold in the EU. The era of discretionary vulnerability disclosure is over. In its place, the CRA imposes a legally binding framework prioritising speed and transparency, especially when a vulnerability is being used by attackers in the wild.

At the heart of this new reality is the 24-hour reporting deadline. This rule applies with laser focus to ‘actively exploited’ vulnerabilities—flaws that have graduated from a theoretical risk to a live attack vector. The second you have reliable evidence of an exploit, the clock starts ticking.

When The Clock Starts Ticking

Figuring out when you are officially “aware” is absolutely critical. This isn’t limited to your internal security team discovering an issue. Awareness can be triggered from several directions:

• Internal Detection: Your own monitoring systems or Security Operations Centre (SOC) spots an intrusion that takes advantage of a product flaw. For instance, your SIEM flags multiple authentication failures followed by a successful, but unauthorised, privilege escalation on your connected medical device’s backend server.
• Public Reports: A credible security researcher or news outlet publishes a proof-of-concept or report showing a vulnerability is being used in attacks. A practical example would be a well-known cybersecurity blog posting evidence that a flaw in your smart lock’s firmware is being used by a botnet.
• Partner Notification: A customer or supply chain partner informs you that their systems were breached through your product. For example, a major retail chain using your smart POS terminals reports that they’ve experienced a data breach traced back to a vulnerability in your device.

This demanding deadline isn’t arbitrary. Its purpose is to stand up a rapid, EU-wide response network. By compelling quick notification to the EU’s cybersecurity agency, ENISA, and the relevant national Computer Security Incident Response Teams (CSIRTs), the CRA aims to contain threats before they escalate into widespread damage. A crucial first step in preparing for this is understanding your breach notification timeline.

The CRA Reporting Timeline In Action

Let’s walk through a scenario. It’s September 11, 2026, and a Spanish manufacturer of smart home devices suddenly detects a critical firmware vulnerability. Worse, it’s being actively exploited by cybercriminals to gain unauthorised access to user data across thousands of units in the EU.

Under the CRA, they have just 24 hours to report this to their national CSIRT and to ENISA. This isn’t a hypothetical exercise—it becomes a core legal obligation on that exact date, as laid out in Article 11.

The initial 24-hour alert is just the starting pistol. The CRA mandates a multi-stage reporting process designed to give authorities progressively more detail as your own investigation develops.

To help you visualise the cadence, here’s a quick breakdown of what authorities expect and when.

CRA Reporting Timeline at a Glance

This table summarises the mandatory reporting deadlines for actively exploited vulnerabilities under Article 11. It’s designed to give you a clear, at-a-glance view of your obligations once the clock starts.

This multi-phase approach acknowledges a core reality of incident response: you rarely have all the answers on day one. It ensures authorities get immediate, actionable information, followed by deeper context as it becomes available.

For a deeper dive into which of your products fall under these rules, check out our guide on Cyber Resilience Act applicability. Building the processes to meet this timeline is no longer a “nice-to-have”—it’s a foundational requirement for EU market access.

Your First-Hour Playbook for Detection and Triage

Your ability to meet the CRA’s tight 24-hour reporting deadline for an exploited vulnerability comes down to what happens in the first sixty minutes. That first hour isn’t for planning or debate; it’s for pure execution. Only a well-rehearsed playbook can get you from initial detection to a defensible reporting decision within that critical timeframe.

It all starts with clear internal triggers. These aren’t just vague alerts but specific, pre-defined events that kick off your “CRA Incident Clock” automatically. Leaving it to guesswork is a sure-fire way to miss the deadline and risk non-compliance.

Establishing Your Incident Triggers

You need a mix of automated and manual signals that immediately escalate a potential security event. Think of them as tripwires for your rapid response team. The goal is to shrink the time from signal to awareness down to mere minutes.

Here are a few practical examples of what these triggers look like in the real world:

• Anomalous API Calls: Imagine your monitoring system flags a sudden, sustained spike in failed login attempts on your connected thermostat’s firmware. A pre-set rule could automatically treat any jump over a 50% increase within a 10-minute window as a critical incident.
• Threat Intelligence Correlation: A feed like CISA’s Known Exploited Vulnerabilities (KEV) catalogue adds a new vulnerability. An automated script should instantly check this against your Software Bill of Materials (SBOM) to see if a library in your product is affected. A match instantly creates a high-priority ticket for your security team.
• High-Fidelity Alerts: You get an alert from your Intrusion Detection System (IDS). But this isn’t just a potential probe; the system confirms a successful exploit by detecting command-and-control (C2) traffic coming from one of your deployed IoT sensors. This type of alert would be pre-classified as an automatic trigger for your CRA response plan.

The moment a trigger is hit, your rapid response team needs to assemble. This shouldn’t be a last-minute scramble to figure out who to call. Roles must be pre-assigned so everyone knows exactly what to do the second an alert fires.

Confirming an Active Exploit

The single most important call you’ll make in this first hour is confirming whether a vulnerability is truly “actively exploited.” The CRA is specific here: you need reliable evidence of malicious use in the wild. A theoretical proof-of-concept isn’t enough to start the clock.

This is where your team must connect the dots between different data sources to build a solid, evidence-based case.

Let’s say a security researcher publishes a blog post detailing a new remote code execution (RCE) vulnerability in a popular open-source library used in your smart factory controllers. Your clock doesn’t start quite yet. But your team immediately goes on the hunt, correlating the public report with telemetry data from customer sites. They quickly find anomalous outbound network connections from several controllers to an IP address known to be used by a specific threat actor.

This is your moment of confirmation. A public vulnerability has just been linked to real-world, unauthorised activity impacting your products. Your 24-hour reporting clock has officially begun, and your internal documentation must capture this precise decision point.

To properly triage the severity, most teams rely on frameworks like the Common Vulnerability Scoring System (CVSS). It provides a standardised, numerical score based on factors like exploitability and impact, which is invaluable for prioritisation.

For example, a vulnerability that is easy to exploit over the network and gives an attacker complete control of a device would receive a high CVSS score (e.g., 9.8 Critical), making it an immediate priority. This score gives you a clear rating of severity, helping you prioritise your response and accurately describe the vulnerability to the authorities. For a deeper dive into setting up the necessary systems for this level of visibility, our guide on CRA logging and monitoring requirements provides essential guidance.

Ultimately, your first-hour playbook must be a repeatable, evidence-driven process. The objective is to move from the initial signal to a confirmed exploitation with a clear audit trail. This ensures your CRA exploited vulnerability reporting 24 hours notification is not only on time but also accurate and able to stand up to regulatory scrutiny.

Crafting Your Initial 24-Hour ENISA Notification

The first report you fire off to ENISA and the national CSIRT is a big deal. It sets the tone for the whole incident. Meeting the CRA’s 24-hour reporting deadline for an exploited vulnerability comes down to having a clear, fast, and precise process. This first notification isn’t a full technical deep-dive; think of it as a critical early warning.

Your job here is to give the authorities just enough information to grasp the situation. You’re reporting the “what,” not the “how.” The last thing you want is to give away technical details that could help other threat actors.

This workflow is what you should be aiming for in that first critical hour, moving from a raw signal to a confident decision to report.

It really is that straightforward. You detect an anomaly, triage its importance, and confirm it’s an active exploit. This is the core loop that feeds directly into your notification process.

What to Include in Your First Report

Keep your 24-hour report short and factual. Stick to the absolute essentials required under Article 11. Now is not the time to overshare sensitive technical details; doing so just creates more risk.

Here’s what you absolutely must include:

• Manufacturer Identification: Your company’s legal name and contact information.
• Product Identification: The specific product name, model, and the version(s) affected. Be precise. “SmartLock Pro v2.1 firmware” is good; “our smart locks” is not.
• Nature of the Vulnerability: A high-level description of the flaw itself. Focus on the impact, not the exploit mechanics.

For example, instead of getting into the weeds about a specific buffer overflow, you’d simply state: “A remote code execution (RCE) vulnerability allowing an unauthenticated attacker to take control of the device.” That gives authorities all the context they need without handing attackers a blueprint.

The Right Channel for Reporting

The CRA wants to avoid a communication mess, so it mandates a single, centralised system. All your reports must go through the ENISA-managed Single Reporting Platform (SRP). From there, the platform will route your notification to the right national CSIRT coordinator, based on where your company has its main establishment in the EU.

The SRP is meant to be the single source of truth for your reporting. Getting your team familiar with its interface and requirements before an incident is non-negotiable. Don’t wait for a crisis to log in for the first time.

While the process sounds simple, trying to navigate a new portal when the clock is ticking is a recipe for disaster. This is exactly where a good compliance platform comes in. Tools like Regulus can pre-populate reports with verified product and manufacturer details, saving you precious minutes and cutting down the chance of human error under pressure.

An Example of a Clear Notification

Let’s say you manufacture a line of connected security cameras and your team just confirmed an active exploit. Here’s what the core information for your initial ENISA report could look like:

This format is clean, simple, and delivers exactly what’s needed. It says who you are, what product is at risk, and what the threat is in plain language. Notice there’s no deep technical jargon or speculation about the attacker. This level of precision is perfect for your initial report. You can find more on the full scope of your duties in our overview of CRA reporting obligations under Article 14.

Your first notification is just the opening move in a longer conversation with regulators. By keeping it focused, factual, and timely, you project control and build a solid foundation for effective coordination in the days that follow.

Coordinating With CSIRTs and ENISA After Reporting

Hitting ‘submit’ on your initial report is just the beginning. The real work in handling a CRA exploited vulnerability starts with the follow-up dialogue. Effectively managing this coordination with national Computer Security Incident Response Teams (CSIRTs) and ENISA is what separates a smooth process from a compliance headache.

Think of your initial 24-hour notification as the cover page. The subsequent 72-hour and 14-day updates are the chapters that build out the full story, each adding critical detail. Your designated national CSIRT becomes your primary point of contact and coordination hub for this entire process.

Understanding Agency Roles and Expectations

Once your report hits the Single Reporting Platform (SRP), it’s routed directly to your national CSIRT. Their job is to analyse the threat on the ground, coordinate with other EU member states if the impact is wider, and assess the risk to the entire EU ecosystem. ENISA operates at a higher level, aggregating data from all over the Union to spot systemic risks and attack trends.

What they need from you is proactive, transparent communication. Don’t wait for them to chase you. Be ready for their follow-up questions, because they will come. For example, after your 24-hour report, a CSIRT might immediately ask for specific indicators of compromise (IoCs) you’ve found—like malicious file hashes or attacker IP addresses—so they can warn other organizations. Having your technical and legal points of contact on standby is non-negotiable.

Managing Follow-Up Communications

The CRA itself sets the communication tempo. Your 72-hour notification must build on the initial alert, delivering a severity assessment and concrete details on any immediate mitigations you’ve put in place.

The 14-day final report is where you close the loop. This isn’t a quick summary; it must be a comprehensive breakdown of the root cause, the final patch or corrective action, and the steps you’ve taken to prevent it from happening again. The only way to produce this under pressure is to keep a meticulous incident log from the moment you detect the issue.

Here’s how this coordination plays out in the real world:

• A manufacturer of industrial control systems (ICS) in Spain finds an exploited vulnerability in its PLCs. They file their 24-hour report with Spain’s national CSIRT, INCIBE, through the SRP.
• INCIBE immediately acknowledges the report and asks for any attacker IP addresses the manufacturer has observed. They then use this to warn critical infrastructure operators across the country.
• By the 72-hour mark, the manufacturer provides a detailed update, including a CVSS score of 9.8 and temporary firewall rules customers can implement to block the attack.
• Over the next week, the manufacturer and INCIBE are in regular contact. The company provides status updates on its patch development, demonstrating clear due diligence.
• At the 14-day deadline, they submit the final report, which details the firmware patch and confirms how it has been deployed to affected customers.

This collaborative approach turns a compliance burden into a strategic partnership. Your CSIRT isn’t just an auditor; they are a powerful ally in containing the threat and protecting the broader digital ecosystem.

The numbers show just how urgent this is. In 2025, Spain’s INCIBE logged 22,400 vulnerabilities in digital products. A staggering 41% were actively exploited within just one week of discovery, contributing to attacks that cost Spanish businesses €1.8 billion. The CRA’s reporting structure is designed to break this cycle, but it hinges on tight collaboration between manufacturers and authorities. You can learn more about the policy driving these changes in research from the Center for Cybersecurity Policy.

Exceptions for Delaying Public Disclosure

The CRA draws a sharp line between reporting to authorities and disclosing to the public. You must always meet the 24-hour reporting deadline for your CSIRT and ENISA. There are no exceptions.

However, the regulation provides a very narrow window for delaying the public announcement of a vulnerability. You might be permitted to delay telling the world if:

• A patch is imminent: For instance, if your patch will be ready for deployment in 12 hours, your CSIRT may agree to a coordinated disclosure where the patch and the public advisory are released simultaneously. This prevents giving attackers a head start.
• An active law enforcement investigation is underway: A national authority might ask you to hold off on a public notice to avoid tipping off attackers they are actively tracking.

These exceptions are rare and must be coordinated directly with your CSIRT. You cannot make this call on your own. The default position is always transparency. A well-defined process is essential, and our guide on CRA vulnerability handling can help you build that operational framework.

Meeting the CRA’s 24-hour exploited vulnerability reporting deadline is the immediate fire-fight. But true cyber resilience is built long before an incident happens and is refined long after it’s closed. Compliance doesn’t end with the final report to ENISA. It simply marks the transition into a continuous cycle of monitoring, learning, and improvement.

This is what the CRA’s post-market surveillance obligations are all about.

Treating compliance as an ongoing process transforms a legal burden into a strategic advantage. It demonstrates a level of security maturity that partners and customers notice, proving your commitment goes beyond just ticking a box. This is precisely the kind of proactive security culture the Cyber Resilience Act was designed to foster.

Your Audit Trail Is Your Lifeline

Once an incident is resolved, your focus must immediately pivot to documentation. Market surveillance authorities can and will audit your processes, and a comprehensive audit trail is your single most important line of defence. Annex II of the CRA is unambiguous: you must maintain detailed records to prove your diligence, from the first alert to the final patch.

Think of it as building a complete case file for every single vulnerability. This isn’t about just archiving a few emails; it’s about creating structured, chronological evidence that tells a clear and defensible story of your response.

To make this concrete, imagine a vulnerability was found in your smart thermostat firmware. Your audit trail should meticulously capture:

• Initial Detection: Timestamped logs from your security tools showing the anomalous traffic that first triggered the alert. For example: [2026-10-01 14:32:15 UTC] SIEM Alert ID 98765: Anomalous outbound connection from thermostat_ID_123 to known C2 server 198.51.100.55.
• Triage Notes: A record of your team’s decision-making, including the CVSS score assigned (e.g., 9.8 Critical) and the specific evidence used to confirm active exploitation.
• Reporting Records: Copies of the 24-hour, 72-hour, and 14-day reports submitted to the authorities via the ENISA platform.
• Coordination Logs: All correspondence with the national CSIRT, including their requests for information and your team’s responses.
• Patch Development: Code commits in your Git repository tagged with the vulnerability ID, peer review notes, and QA test results related to the security patch.
• Customer Communication: A copy of the security advisory you published and records showing how it was distributed to affected users.

A robust audit trail does more than just satisfy regulators. It becomes an invaluable internal resource for post-mortems, helping you pinpoint process gaps and strengthen your response capabilities for the next inevitable incident.

To make sure your organisation can consistently meet reporting deadlines and maintain this level of documentation, it’s vital to have a solid corporate compliance program in place. This framework is the foundation upon which your audit trails and response plans are built.

A checklist is the best way to ensure you capture everything needed for a compliance audit. Here are the essential records you should be collecting for every incident.

CRA Incident Record-Keeping Checklist

Maintaining these records diligently for each incident creates a powerful repository of evidence that will make any future audit a smooth, fact-based review rather than a scramble for proof.

Turning Lessons into Action

The most valuable output of any security incident is the lesson it teaches you. A genuine culture of continuous compliance means systematically feeding these hard-won lessons back into your Secure Development Lifecycle (SDLC). This is how you stop making the same mistakes twice.

A formal post-incident review is the best forum for this. Gather the response team and ask direct, honest questions:

1. Could we have detected this sooner? If so, how?
2. Did our triage process work exactly as intended? Where were the friction points?
3. Were there any bottlenecks or delays in our reporting workflow?
4. How can we make patching faster and more efficient for this product line?

The answers must lead to concrete, assigned actions. For example, if you discover a specific type of coding error (like an unchecked input field causing a buffer overflow) led to the vulnerability, the immediate action item is to update your static analysis (SAST) tools to automatically flag that pattern in all future code commits. This integrates the lesson directly into your daily development process, making your products inherently more secure from day one.

In the ES region, where over 4,500 IoT vendors operate according to INCIBE’s registry—many targeting smart manufacturing—the CRA’s 24-hour rule, effective from 11 September 2026, is a game-changer. It could prevent disasters like the 2024 Mirai botnet revival that compromised an estimated 2.5 million Spanish devices. The pressure is on, as a recent survey shows 85% of product teams in Spain are worried about managing CRA alongside NIS-2 and DORA.

By embedding these learnings, you create a virtuous cycle. Each incident, while painful, ultimately makes your organisation stronger, more efficient, and better prepared. This proactive stance is the true essence of building a durable, compliance-driven culture that will stand the test of time.

Common Questions About CRA Reporting

Getting to grips with the Cyber Resilience Act’s reporting rules can throw up a lot of questions. Here are some quick, practical answers to the most common queries we hear about the CRA’s 24-hour exploited vulnerability reporting mandate.

What Exactly Triggers the 24-Hour Reporting Clock?

The clock starts ticking the moment a manufacturer becomes ‘aware’ that a vulnerability in their product is being ‘actively exploited’. Both ‘aware’ and ‘actively exploited’ are critical terms that demand careful interpretation on the ground.

‘Awareness’ isn’t just about your internal security team discovering a flaw. It can be triggered by a whole host of external sources. A credible public report, a notification from a security researcher detailing real-world attacks, or even telemetry from your own products showing patterns of compromise—all of these can make you ‘aware’.

‘Actively exploited’ is the other half of the puzzle. This means there is reliable evidence that malicious actors are actually using the vulnerability in real attacks. A theoretical proof-of-concept (PoC) or a private disclosure from a researcher alone does not start the clock.

Here’s a real-world scenario: A security researcher privately discloses a vulnerability in your smart camera’s firmware. At this point, the clock doesn’t start. But a week later, they publish a blog post with proof that a botnet is now using that exact same exploit to hijack devices. Your 24-hour reporting obligation begins the moment your team learns of that public post.

How Does This Reporting Overlap With NIS2 and GDPR?

The CRA’s reporting duty is separate but can absolutely overlap with other major EU regulations like the NIS2 Directive and GDPR. It’s crucial to understand these are distinct legal obligations. A single incident might very well trigger duties under all three at the same time.

• NIS2 Directive: Imagine your product is a networking switch used in a hospital. If an exploited vulnerability in your switch disrupts hospital operations, the hospital (as an ‘essential entity’) has a 24-hour NIS2 reporting duty. Your CRA report will be critical evidence for their own notification.
• GDPR: If the attack on your smart camera product results in a personal data breach (e.g., attackers access and download stored video footage of users), you have a separate 72-hour notification duty to your data protection authority under GDPR.

While the CRA’s proposed Single Reporting Platform aims to simplify some of this by funnelling information to relevant authorities, the legal responsibilities themselves remain separate. Your incident response plan must assess every event against all applicable regulations.

What Are the Penalties for Missing the 24-Hour Deadline?

The financial penalties for non-compliance are substantial. They are explicitly designed to be a powerful deterrent, and market surveillance authorities will not take missed deadlines lightly.

Failing to report an actively exploited vulnerability on time can lead to administrative fines of up to €10 million or 2% of your company’s total worldwide annual turnover from the preceding financial year, whichever figure is higher.

For a practical perspective, if your company has a global turnover of €600 million, a failure to report on time could result in a fine of up to €12 million (2% of turnover), which is higher than the €10 million flat cap.

Other violations under the Cyber Resilience Act can carry even steeper fines, reaching up to €15 million or 2.5% of global turnover. These penalties elevate timely and accurate reporting from a simple IT task to a critical business function.

Do I Report Vulnerabilities Found by Ethical Hackers?

Not automatically, no. The CRA exploited vulnerability reporting 24 hours rule applies specifically and exclusively to vulnerabilities that are ‘actively exploited’. A responsible disclosure from an ethical hacker or a security researcher does not, by itself, meet this criterion.

When a researcher reports a flaw to you through a Coordinated Vulnerability Disclosure (CVD) policy, it is not yet considered exploited. This process is intentionally designed to give you the time needed to validate the issue, develop a patch, and coordinate a responsible disclosure with them. For example, a researcher finds a bug via your bug bounty program and submits a report. You have time to fix it. The 24-hour clock only starts if you later find evidence that malicious actors are using that same vulnerability in the wild.

Navigating the complexities of the CRA doesn’t have to be a burden. Regulus provides a clear, step-by-step roadmap to turn compliance requirements into an actionable plan. Gain clarity on applicability, generate tailored documentation, and build your vulnerability management process with confidence. Visit the Regulus platform to see how we can help you meet every deadline.

La entrada CRA exploited vulnerability reporting 24 hours: A 2026 Practical Guide se publicó primero en Regulus.

Understanding the GitLab Container Registry

Instead of thinking of a container registry as a separate digital warehouse, imagine it as an intelligent logistics hub located right on your factory floor. In many setups, a developer builds an image and pushes it to a standalone registry like Docker Hub. This creates a disconnect between your code, your images, and your deployment process.

The GitLab Container Registry closes that gap by putting the registry right where the work happens. It’s deeply integrated into the GitLab platform, making it an active and intelligent part of your software supply chain, not just a passive storage location.

This integration allows the registry to act as a central hub, connecting the build, test, and deployment stages of your development workflow into a single, cohesive process.

As the diagram shows, every code change can trigger a pipeline that automatically builds a new image and stores it securely in the registry. That very same image is then pulled for automated testing and deployment, creating a seamless, transparent, and fully automated flow.

Core Benefits of an Integrated Registry

The biggest advantage of using the GitLab Container Registry is its native integration with GitLab CI/CD. This tight coupling simplifies your workflows and dramatically improves your security posture.

Key benefits include:

• Simplified Authentication: CI/CD jobs automatically receive secure, short-lived credentials to push and pull images. You no longer need to manually manage tokens or stuff passwords into your pipeline scripts. For example, the $CI_REGISTRY_PASSWORD variable is automatically available in every job.
• Integrated Security Scanning: You can scan images for vulnerabilities the moment they are pushed to the registry. Security reports appear directly in merge requests, empowering developers to fix issues before bad code ever gets merged.
• Granular Access Control: Permissions are tied directly to your GitLab project members and their roles. This lets you precisely control who can read (pull) or write (push) images, ensuring only authorised users and pipelines can access them.

A Practical Example

Let’s walk through a common scenario. A developer pushes a code change to a feature branch, which automatically triggers a GitLab CI/CD pipeline. The “build” job kicks off, compiles the code, builds a fresh Docker image, and tags it with the unique commit ID.

That image is then pushed directly to the project’s GitLab Container Registry. Immediately after, a “test” job pulls that exact image and runs a suite of automated tests against it. This simple, powerful sequence guarantees that what gets tested is precisely what was just built, completely eliminating the classic “but it works on my machine” problem.

This seamless handover is a direct result of the registry’s integrated nature, turning what used to be a clunky, multi-step process into a smooth, automated workflow.

Right, let’s get your GitLab Container Registry configured. This is where the theory ends and you start building a solid foundation for your container image workflow. The setup path depends on whether you’re on GitLab.com or running a self-managed instance.

If you’re using GitLab.com, you’re in luck—the registry is already enabled for new projects. No setup needed. Just head to your project’s Deploy > Container Registry page. You should see an empty registry with some handy commands, ready for your first docker push.

For self-managed instances, you’ll need to switch it on yourself. This gives you total control, but it means getting your hands dirty in the main GitLab configuration file, gitlab.rb.

Activating the Registry on a Self-Managed Instance

To bring the registry online on your own GitLab server, you’ll need to edit /etc/gitlab/gitlab.rb, the file that governs your entire GitLab installation.

1. SSH into your server and open /etc/gitlab/gitlab.rb with a text editor like vim or nano.
2. Find the registry_external_url setting. You’ll need to uncomment it and set it to the URL where your registry will live. It’s common to use a dedicated port like 5050 for this, especially during initial setup.

Here’s what a typical configuration looks like:

# /etc/gitlab/gitlab.rb

# Define the user-facing URL for the Container Registry.
# Using a port helps isolate the service initially.
registry_external_url 'https://gitlab.example.com:5050'

Once you’ve saved your changes, you must apply them. Run sudo gitlab-ctl reconfigure. This command reads your new settings and reconfigures all the GitLab services, bringing your registry to life.

I’ve seen this trip people up countless times: they edit gitlab.rb perfectly but forget to reconfigure. The result? A registry that’s configured but not actually running. Always, always run sudo gitlab-ctl reconfigure to make your changes take effect.

Configuring External Object Storage

Out of the box, the GitLab Container Registry stores images on your server’s local disk. This is fine for testing or very small teams, but it’s a recipe for disaster in production. Your server’s disk space will get eaten up fast. A much better approach is to offload image storage to a dedicated object storage service like Amazon S3 or Google Cloud Storage (GCS).

This move dramatically improves scalability and reliability, separating your application data from your image artifacts.

To point your registry to an S3 bucket, for instance, you would add a storage block to your gitlab.rb file with your bucket details and credentials.

# /etc/gitlab/gitlab.rb

registry['storage'] = {
  's3' => {
    'accesskey' => 'YOUR-AWS-ACCESS-KEY',
    'secretkey' => 'YOUR-AWS-SECRET-KEY',
    'bucket' => 'your-gitlab-registry-bucket-name',
    'region' => 'eu-west-1'
  }
}

With this change, GitLab will push all new image layers directly to your S3 bucket instead of the local filesystem. This architecture is practically essential for any team managing a serious number of images or operating under strict compliance rules.

This isn’t just a theoretical best practice. For example, it’s becoming a key strategy in Spain’s tech manufacturing sector. Data shows that 72% of IoT vendors in the ES region are adopting the GitLab Container Registry to help them meet stringent Cyber Resilience Act (CRA) prerequisites. For these teams, migrating an average project size of 500 GiB to S3 takes just 28 minutes—an 84% time saving that is vital for the agile updates the CRA demands. You can read more about these GitLab Container Registry adoption trends at firstsales.io.

Working with Images in CI/CD and the CLI

Once your GitLab Container Registry is active, it’s time to start using it. This is where your containerised applications will live. You’ll interact with it in two main ways: manually from your command line for local development, and automatically through GitLab CI/CD pipelines for builds and deployments.

Working from the command line is your starting point. It’s how you’ll push your first image, test out a new tag, or run a quick debug session on your local machine. The process feels a lot like standard Docker commands, but the image naming convention is the key difference you need to master.

Pushing Your First Image from the CLI

Before you can push anything, you need to authenticate your Docker client with your GitLab Container Registry. This is a quick, one-time setup on your local machine.

1. 
   

   Log in to the Registry: Fire up your terminal and use the docker login command, pointing it to your registry’s URL. For GitLab.com, this is simply registry.gitlab.com. If you’re running a self-managed instance, you’ll use the URL you configured.

   
   

   # For GitLab.com users
   docker login registry.gitlab.com
   

   
   

   You’ll be prompted for your GitLab username and a personal access token. Make sure the token has both read_registry and write_registry permissions. Using a token is far more secure than using your main password.

   
   
2. 
   

   Tag Your Image Correctly: This is the most important step. To send an image to the GitLab Container Registry, you have to tag it with the full registry path. The format is always <registry-url>/<group>/<project>/<image-name>:<tag>.

   
   

   Imagine you have a local image named my-awesome-app:latest and your project lives at gitlab.com/my-group/my-project. You’d tag it like this:

   
   

   docker tag my-awesome-app:latest registry.gitlab.com/my-group/my-project/my-app:v1.0.0
   

   
   
3. 
   

   Push the Image: With the image correctly tagged, you can now push it straight to your project’s registry.

   
   

   docker push registry.gitlab.com/my-group/my-project/my-app:v1.0.0
   

   
   

Once the push is done, head over to your project’s Deploy > Container Registry page in the GitLab UI. You should see your new image, my-app, listed with the v1.0.0 tag, ready to go.

Automating Builds with GitLab CI/CD

Pushing images manually is great for getting started, but the real power comes from automating this with GitLab CI/CD. Your pipeline can build, tag, and push images on every single commit, creating a repeatable and error-free workflow. It all happens inside your .gitlab-ci.yml file.

To properly automate your image builds, you’ll need a good grasp of the pipeline configuration, which is all defined in the GitLab CI YML file.

The good news is that GitLab provides predefined CI/CD variables that make this incredibly easy. You don’t have to juggle credentials manually; GitLab injects a short-lived, secure token into every pipeline job.

The most useful variables are $CI_REGISTRY_USER, $CI_REGISTRY_PASSWORD, and $CI_REGISTRY. These let your pipeline log in automatically. The $CI_REGISTRY_IMAGE variable gives you the base URL for your project’s registry, which is perfect for dynamic tagging.

Here’s a practical example of a build job in your .gitlab-ci.yml that builds and pushes a Docker image:

build_image:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  before_script:
    # GitLab provides these variables automatically
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    # Use the commit SHA for a unique, immutable tag
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

This job uses the official Docker-in-Docker (dind) service so it can run Docker commands. It logs in with the built-in CI variables, builds the image from your Dockerfile, and tags it with the unique commit SHA ($CI_COMMIT_SHA). This is a fantastic practice for traceability, as it ensures every single commit produces a uniquely identifiable image.

Using Images in Downstream Jobs

Once an image is in your registry, other stages in your pipeline can pull it for tasks like running tests or deploying to production. Because we tagged the image with the unique commit SHA, you can be 100% sure you are testing the exact artifact that was just built.

Here’s how a test job could use the image we built in the last step:

test_application:
  stage: test
  # Use the image we just built and pushed
  image: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  script:
    # Run your application's test suite inside the container
    - echo "Running tests..."
    - npm test

This seamless handover between stages is what makes an integrated registry so powerful. There’s no ambiguity, no chance of pulling a stale latest tag, and no need for complex scripting. The build job creates the image, and the test job uses it, all within one unified pipeline. For a deeper dive into the specific variables available, check out our guide on how to use https://goregulus.com/cra-basics/gitlab-ci-variables/ effectively.

Managing Your Registry Storage and Costs

An unmanaged GitLab Container Registry can quickly become a digital attic, cluttered with old, unused images. Each time a CI/CD pipeline runs, it pushes a new image layer. Over weeks and months, these layers accumulate, consuming huge amounts of storage and driving up costs.

This isn’t just about digital housekeeping; it’s a strategic necessity. Uncontrolled registry growth leads to slower performance, bigger cloud bills, and a chaotic environment where finding the right image becomes a real challenge.

Fortunately, GitLab provides powerful, automated tools to keep your registry lean and efficient.

Implementing Automated Cleanup Policies

The most effective way to manage your registry is by setting up cleanup policies. These are automated rules you configure at the project level to periodically remove unnecessary image tags. Instead of manually deleting old images, you tell GitLab to do it for you based on criteria you define.

You can configure these rules right from your project’s UI by navigating to Settings > Packages & Registries > Cleanup policies. Here, you can define rules that match your team’s specific workflow.

A common and highly effective policy combines time and quantity. For example, you can set a rule to:

• Keep only the most recent images: For instance, always retain the last five tags pushed for each image name.
• Delete old tags: Automatically remove any tag that is older than 90 days.
• Preserve important tags: Use regex to protect specific tags from deletion, such as those matching a semantic versioning pattern like v*.*.*.

By setting a rule to Keep the most recent: 5 tags per image name, you ensure that your development and staging environments always have recent builds available, while automatically pruning older, irrelevant ones. This prevents the endless accumulation of feature-branch and test images.

This automated approach is critical for maintaining a clean, auditable, and cost-effective repository.

Understanding Storage Quotas and Notifications

While cleanup policies manage what gets deleted, storage quotas prevent your usage from spiralling out of control in the first place. On GitLab.com, namespaces have storage limits, and your container registry usage counts towards this total.

To help you stay ahead of these limits, GitLab has an automated notification system. You don’t have to manually check your usage every day. Instead, group owners receive email alerts when storage consumption hits key thresholds.

This table outlines the automated email notifications sent by GitLab as your group’s container registry storage approaches its limit, helping teams manage usage proactively.

GitLab Container Registry Quota Notifications

This proactive system gives you plenty of time to act before your development workflow is disrupted.

The impact of these features is significant, especially at scale. A 2024 audit of 50 European Supercomputing research projects found that activating cleanup policies reduced storage usage by an average of 45%. These findings echo GitLab’s own success, where optimising cleanup slashed a 535 TiB registry’s processing time from 278 hours down to just 145 hours. You can read more about these container registry optimisations and their impact.

How Garbage Collection Reclaims Space

It’s important to understand that deleting a tag doesn’t immediately free up disk space. When you delete a tag, you are only removing a pointer to the image manifest. The underlying data layers—which other tags might still be using—remain in storage.

To actually reclaim the physical storage from these now-unreferenced layers, GitLab runs a process called online garbage collection.

This background task runs automatically on GitLab.com, sweeping through the registry to find and permanently delete orphaned image layers. This ensures the space is truly recovered. For self-managed instances, administrators may need to trigger this process manually.

Securing Your Container Image Supply Chain

In a modern development pipeline, security isn’t just a final checkbox; it’s part of the fabric. The GitLab Container Registry is built on this idea, giving you the tools to secure your container images from the moment they’re created. This moves security from a hurried, last-minute check to an automated, everyday part of your workflow.

The first line of defence is role-based access control (RBAC). Permissions for the registry aren’t managed in a separate system; they’re inherited directly from your project’s member roles. This simple but powerful link ensures only authorised users and CI/CD jobs can push (write) or pull (read) images, creating a clear and auditable chain of custody.

This built-in control mechanism stops unauthorised access cold and makes sure only validated pipelines can introduce new images into your environment. To maintain this level of control across all your cloud resources, it’s also worth understanding the practices behind Cloud Security Posture Management (CSPM).

A Quick Look at Roles and Permissions

To make this crystal clear, here’s a breakdown of the default permissions. Understanding who can do what is fundamental to implementing secure access control without getting in your team’s way.

GitLab User Roles and Registry Permissions

As you can see, the permissions are logical and follow the principle of least privilege. Developers can build and push images, but only Maintainers and Owners have the rights to delete them, preventing accidental or malicious removal.

Activating Integrated Container Scanning

While RBAC controls who has access, GitLab’s integrated container scanning finds the vulnerabilities hiding inside your images. The feature automatically inspects each image layer for known security flaws in its operating system packages and application dependencies. By adding it to your .gitlab-ci.yml file, you shift security left, finding and fixing problems long before they have a chance to hit production.

The process itself is refreshingly simple. You just include GitLab’s predefined Container-Scanning.gitlab-ci.yml template, and the pipeline handles the rest.

Here’s a practical example showing how to add a scanning job that runs right after your image is built and pushed to the registry:

stages:
  - build
  - test

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

build_and_push:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

# The Container Scanning job from the template will automatically
# run in the 'test' stage, scanning the image we just pushed.

With this setup, every single merge request that builds an image will also trigger a full security scan.

Reviewing Vulnerabilities in Merge Requests

Once a scan finishes, the results pop up directly inside the merge request as an interactive widget. This gives developers immediate, actionable feedback right where they’re already working on the code.

A developer no longer has to switch contexts to a separate security tool, analyse a generic report, and try to map it back to their changes. The vulnerabilities are listed right there, complete with severity levels (Critical, High, Medium, Low) and links to CVE details.

This tight feedback loop is the bedrock of a healthy DevSecOps culture. It turns security from a gatekeeper’s checklist into a shared team responsibility, helping everyone build safer software from the very beginning. This process is also crucial for generating a Software Bill of Materials (SBOM), a core requirement of emerging regulations. To get a better handle on what’s expected, you can learn more about the CRA’s SBOM requirements in our detailed guide.

This integrated approach has proven its worth, especially in highly regulated industries. For compliance-focused businesses in the ES region, studies from 2025 showed that 92% of projects achieved GDPR readiness using features like at-rest encryption and issuer-based authentication. These numbers confirm the registry is mature enough to meet strict EU digital product standards. You can find more details on GitLab’s security configurations for compliance.

Advanced Registry Features and Best Practices

Once you’ve mastered the basics of storing and scanning images, it’s time to look at the advanced features that truly harden your software supply chain. These capabilities are less about day-to-day convenience and more about building resilience and audit-readiness, especially for teams facing strict compliance mandates.

One of the most powerful but often overlooked features is the pull-through cache. Think of it as a local, intelligent proxy for public registries like Docker Hub. When your CI pipeline pulls an image like node:20-alpine for the first time, GitLab fetches it and keeps a copy in your project’s own registry.

Every subsequent pull for that same image comes directly from your local cache. This simple change dramatically cuts down latency and, more importantly, shields your builds from external registry rate limits or outages. If Docker Hub has a bad day, your pipelines don’t.

Verifying Image Integrity with Signing

You can’t have a secure supply chain without certainty. Image signing provides that certainty by creating a cryptographic, tamper-proof link between the image you build and the image you deploy. It’s the digital equivalent of an unbroken seal on a shipping container.

A popular, cloud-native tool for this is Cosign, which fits perfectly into a GitLab CI/CD workflow. After an image is built and pushed, you simply add another job to the pipeline that signs it. Your deployment environment, like a Kubernetes cluster, can then be configured with a policy controller to check for a valid signature before ever starting a container.

Here’s what a simple signing job might look like in your .gitlab-ci.yml:

sign_image:
  stage: sign
  image: gcr.io/projectsigstore/cosign:v2.2.3
  script:
    # This assumes COSIGN_PRIVATE_KEY is a protected CI/CD variable
    - cosign sign --key env://COSIGN_PRIVATE_KEY "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

This step creates an immutable, verifiable record that is non-negotiable for modern compliance standards. You can discover more about integrating these deployment strategies by exploring our guide on using Terraform and Kubernetes.

Consolidated Best Practices Checklist

To operationalise these concepts and maintain a compliant, efficient GitLab Container Registry, here are the key practices your team should adopt.

• Use Immutable Tags: Never use mutable tags like latest in production. Always deploy using specific, unchangeable tags like the commit SHA ($CI_COMMIT_SHA) or a semantic version (v1.2.3) to prevent accidental or untested updates from slipping into your environments.
• Automate Security Scans on Every Build: Integrate container scanning into every single pipeline. This surfaces vulnerability reports directly in merge requests, empowering developers to fix issues long before they reach a production environment.
• Sign All Production Images: Make image signing with a tool like Cosign a mandatory step for any image destined for production. Just as importantly, enforce signature verification in your clusters to block any untrusted or unsigned images from running.
• Maintain a Lean Registry: Be ruthless with cleanup policies. A cluttered registry filled with old, untagged images drives up storage costs, slows down performance, and makes security audits a nightmare.
• Enable the Pull-Through Cache: If your builds rely on public images—and most do—configure the pull-through cache. It’s a simple way to boost both the reliability and speed of your entire CI/CD platform.

Frequently Asked Questions

Here are a few quick answers to some of the most common questions and roadblocks teams run into when they start working with the GitLab Container Registry.

How Do I Fix ‘Permission Denied’ Errors When Pushing?

A permission denied or unauthorized error almost always points to one of two things: your credentials or your user role in the project.

First, check your authentication.

• For CLI Pushes: Make sure you are using a Personal Access Token with both read_registry and write_registry scopes. This is a common trip-up; you can’t use your regular account password here.
• For CI/CD Jobs: This error is rare inside a pipeline because GitLab automatically provides temporary, scoped credentials. If you do see it, check your project’s CI/CD settings to see if the job token’s default permissions have been restricted.

Second, confirm your project role. To push an image, you need to be at least a Developer. If your role is Reporter or Guest, you only have permission to pull images, so any push attempt will be rejected.

Cleanup Policies vs. Manual Garbage Collection: What’s the Difference?

These two features work together, but they do different jobs. The best way to think about it is like managing files on your computer.

Cleanup policies are your ‘move to trash’ rule. You set a policy—like “delete all tags older than 90 days that match this pattern”—which automatically marks them for deletion. This removes the reference to the image layers, but it doesn’t immediately free up the storage space.

Manual garbage collection (or online garbage collection for GitLab.com users) is the ’empty the trash’ step. It’s a background process that permanently deletes the underlying data layers (blobs) that are no longer referenced by any tags. This is the step that actually reclaims the physical storage.

What Is the Best Way to Migrate from Another Registry?

Migrating from a registry like Docker Hub to the GitLab Container Registry is surprisingly straightforward and easy to script. The core process is simple: pull the image you want to migrate, re-tag it with its new GitLab destination path, and then push it.

Here’s a simple shell script that migrates a single image:

#!/bin/bash
# Define your image and GitLab project path
SOURCE_IMAGE="docker.io/your-username/your-app:1.2.3"
TARGET_IMAGE="registry.gitlab.com/your-group/your-project/your-app:1.2.3"

# 1. Pull the original image
echo "Pulling from source..."
docker pull $SOURCE_IMAGE

# 2. Re-tag the image for the GitLab registry
echo "Re-tagging for GitLab..."
docker tag $SOURCE_IMAGE $TARGET_IMAGE

# 3. Push the newly tagged image to GitLab
echo "Pushing to GitLab..."
docker push $TARGET_IMAGE

echo "Migration complete!"

You can easily expand this logic into a loop to handle all your images and tags, making the entire migration a repeatable, one-click process.

Gain clarity and confidence in meeting your EU regulatory obligations. Regulus provides a complete, actionable platform to assess your Cyber Resilience Act applicability, map your requirements, and build your compliance documentation. Get started today at https://goregulus.com.

La entrada Your Guide to the GitLab Container Registry se publicó primero en Regulus.

Under these new rules, you must notify authorities about any actively exploited vulnerability within 24 hours, followed by a more detailed report within 72 hours. This is a massive shift, and getting it wrong carries serious consequences.

Unpacking Your Article 14 Reporting Duties

The Cyber Resilience Act (CRA) creates a formal, EU-wide system for handling serious security issues. At the centre of this system is Article 14, which ensures key authorities get early warnings to help stop threats from spreading across the market.

Think of it as a public health system for digital products. When a manufacturer discovers a serious, actively exploited vulnerability, their mandatory report acts as an alert. This gives the EU’s cybersecurity agency, ENISA, and national Computer Security Incident Response Teams (CSIRTs) the intel they need to coordinate a response and protect the entire market.

Who Is Responsible for Reporting?

The duty to report under Article 14 falls squarely on the manufacturer. The CRA is very clear: a manufacturer is the entity that develops a product with digital elements and sells it under its own name or trademark.

For example, if you build a connected baby monitor, develop a project management SaaS platform, or produce an industrial robot with network capabilities, you are the manufacturer. These reporting duties are a non-negotiable part of placing your product on the EU market.

What Triggers a Report?

Not every bug you find triggers a 24-hour countdown. The CRA focuses everyone’s attention on the most urgent threats. A report is only required when two specific conditions are met:

• Actively Exploited Vulnerabilities: This isn’t a theoretical weakness found during a routine scan. It’s a flaw in your product that you have solid evidence is being used by attackers in the wild. For example, receiving credible reports from multiple customers that their systems were compromised using a specific flaw in your software.
• Severe Security Incidents: This refers to an incident with a significant impact on the security of your product or your users’ systems. Think incidents that disrupt essential services, compromise networks, or cause major material damage. A practical example would be a ransomware attack that renders a hospital’s connected medical devices unusable.

Key Takeaway: The focus of Article 14 is on active, real-world threats. A vulnerability found by your internal security team doesn’t automatically start the clock. But the moment you find proof that attackers are using it against a customer, your 24-hour reporting window opens.

For instance, imagine your company makes a smart camera. You discover a flaw that could allow unauthorised access—that’s a vulnerability. If you then find credible evidence that attackers are using this exact flaw to spy on users, it becomes an actively exploited vulnerability, and your reporting obligation under Article 14 kicks in immediately.

Grasping these core concepts is the first step toward building a compliant process. The focus here is on EU-wide obligations, as specific national data is still emerging. For more detail on how these rules apply across the single market, you can read a comprehensive guide on the EU-level reporting framework from CECIMO. The next sections will build on this foundation, detailing the exact timelines and practical steps your team needs to take.

Navigating The Critical Reporting Timelines

When an incident hits, the clock starts ticking. Under the Cyber Resilience Act, your reporting duties are governed by a strict, escalating series of deadlines. These aren’t just suggestions; they are firm legal obligations designed to give authorities rapid visibility into active threats.

The entire reporting cascade is triggered by one specific event: an actively exploited vulnerability. This isn’t just any bug. It’s a flaw in your product that you have reliable evidence is being actively used by attackers right now.

For instance, this could be a zero-day in your firmware being used in a ransomware attack against a customer. Or maybe your own security team confirms an intrusion that leveraged a specific weakness in your product. The moment you have that confirmation, the 24-hour countdown begins.

The First 24 Hours: The Early Warning

The first report is all about speed, not depth. You are required to notify your designated national CSIRT and ENISA without undue delay, and absolutely no later than 24 hours after becoming aware of the active exploitation.

Think of this initial alert as a flare sent up to signal a problem. You’re letting the EU authorities know a potentially widespread issue exists so they can prepare. At this early stage, nobody expects you to have all the answers.

The goal is to provide a quick heads-up that includes:

• Your identity as the manufacturer.
• The name and type of the affected product.
• A brief description of the exploitation you’ve observed.

A practical example: an email to ENISA could be as simple as, “This is an early warning from SmartGrid Solutions GmbH. Our ‘PowerFlow 3000’ energy grid controller is being actively exploited. Initial reports suggest remote unauthenticated access is possible. More details will follow.”

The 72-Hour and 14-Day Progress Reports

After that initial flare, your subsequent reports must provide progressively more detail as your investigation unfolds. To give you a clearer picture of how this works in practice, here is a quick summary of the timelines you’ll need to follow.

The table below outlines the different reporting stages and what is expected at each one.

CRA Article 14 Reporting Timelines At A Glance

This structured flow of information is designed to keep authorities informed as you move from initial detection to full resolution.

Let’s walk through a practical example. Imagine your company, SmartHome Innovations, makes a popular smart thermostat. Your incident response team confirms a critical vulnerability is being exploited in the wild, allowing attackers to remotely control home heating systems. This is your trigger.

Here’s how the reporting journey would look:

1. 
   

   Within 24 Hours: SmartHome Innovations submits its early warning to its national CSIRT and ENISA. The report is simple: it identifies the company and states that its “ThermoSmart Model X” has an actively exploited vulnerability.

   
   
2. 
   

   Within 72 Hours: The team follows up with a vulnerability notification. This report adds crucial context, detailing the nature of the flaw, its potential impact (unauthorised control of heating), and initial advice for users, like disconnecting the device from the internet until a patch is ready.

   
   
3. 
   

   Within 14 Days: After deploying a patch and finishing its analysis, the company submits a final, comprehensive report. This document includes a full root cause analysis, the technical details of the fix, an estimate of affected users, and what actions have been taken to prevent it from happening again.

   
   

Understanding these EU-wide reporting deadlines is non-negotiable. You can learn more about the official policy on the European Commission’s digital strategy site. For a broader view, you might also be interested in our deep-dive into the full CRA compliance timeline from 2025 to 2027. This blueprint is your guide to turning a potential crisis into a controlled, compliant response.

Clarifying Roles In Your Supply Chain

Achieving compliance with the Cyber Resilience Act is a team sport, not a solo mission. Your responsibility as a manufacturer doesn’t exist in a vacuum; it’s deeply connected to every other link in your supply chain. While you hold the ultimate legal duty for CRA reporting obligations under Article 14, your partners are crucial for success.

Importers and distributors are your essential eyes and ears on the ground. The CRA formally obliges them to act as a vital communication channel. If they discover or are informed of a vulnerability in one of your products, they are legally required to notify you immediately.

This creates a mandatory information-sharing network designed to get critical threat intelligence to the one entity that can actually fix it: you.

Tracing the Path of a Vulnerability Report

Let’s walk through a practical example to make this crystal clear. Imagine you’re a German manufacturer of industrial machinery that uses connected sensors. One of your machines is sold through a French distributor.

Here’s how the information flow for a vulnerability report would work:

1. Discovery: An independent security researcher in France discovers a serious flaw in an open-source component used in your machine’s sensor software. They find a way to remotely access the sensor’s data.
2. Initial Contact: The researcher responsibly discloses this finding to the French distributor who sold the machine, since they are the most visible local contact point.
3. Distributor’s Duty: Under their own CRA obligations, the French distributor cannot sit on this information. They must immediately forward the entire report to you, the manufacturer.
4. Manufacturer’s Responsibility: The moment you receive this report, your Product Security Incident Response Team (PSIRT) takes over. You analyse the vulnerability, confirm its severity, and determine if it’s being actively exploited.
5. Official Reporting: If you confirm active exploitation, the final responsibility falls squarely on your shoulders. You must fulfil the official CRA reporting obligations under Article 14 by sending the 24-hour early warning to ENISA and your national CSIRT, followed by the more detailed reports.

This collaborative flow ensures that no matter where a vulnerability is first spotted, the report finds its way to the manufacturer who must take official action.

This structure transforms your supply chain from a simple sales channel into a powerful compliance network. Each partner has a defined role in funnelling security information back to you, the manufacturer, who is ultimately accountable for official reporting.

Understanding these interconnected duties is fundamental. For a deeper look into what this means for your specific role, you can learn more about the complete list of CRA manufacturer obligations in our dedicated guide.

Your Partners Are Your First Line of Defence

This system highlights a crucial strategic point: you have to enable your partners to help you. Your importers and distributors need clear, simple channels to report issues they find.

If they don’t know how to reach you or the process is a bureaucratic nightmare, critical information will get lost. That puts you directly at risk of non-compliance.

For example, a distributor who receives a vulnerability report from a customer should be able to find your dedicated security contact email (security@your-company.com) directly on your website or in their partner documentation within minutes. If they have to spend hours searching, you lose precious time and risk a compliance failure.

By fostering this collaborative ecosystem, you not only meet legal requirements but also strengthen the overall security of your products on the market.

Building Your Compliant Reporting Process Step By Step

Turning legal text into a repeatable, day-to-day workflow is the heart of sustainable compliance. To meet the CRA reporting obligations under Article 14, you can’t just rely on good intentions. You need a structured, documented process that turns the potential chaos of incident response into a predictable, auditable system.

It all starts with clear ownership and a central hub for all vulnerability-related activities. This is precisely the job of a Product Security Incident Response Team (PSIRT). Whether you build a new team or empower an existing one, their mission is to manage every vulnerability from the moment it’s discovered until it’s fully remediated.

Establish Your Incident Response Framework

First things first: you need a formal incident response plan. Think of this as your playbook for when a potential security issue lands on your desk. It ensures everyone knows their role and what to do next, eliminating high-pressure guesswork.

Your plan should map out the entire process, from start to finish:

• Intake: How do you actually receive vulnerability reports from inside and outside the company?
• Triage: What’s the process for validating a report and gauging its severity?
• Investigation: Who is responsible for the deep technical analysis of the vulnerability?
• Reporting: What are the exact steps for notifying ENISA and the relevant CSIRTs within that tight 24-hour window?
• Remediation: How do you develop, test, and ship a security patch to your customers?

A solid incident response plan isn’t just a compliance checkbox; it’s a resilience-builder. It means that when a real threat emerges, your team can execute a coordinated, calm response instead of panicking. That protects your customers and, just as importantly, your brand’s reputation.

A crucial, and often overlooked, part of credible CRA reporting is a strong focus on managing data quality for every piece of information involved. Every report, assessment, and remediation log must be accurate and consistent if it’s going to withstand scrutiny. This discipline ensures the information you submit to regulators is both credible and defensible.

Set Up Secure and Clear Reporting Channels

You can’t fix vulnerabilities you don’t know about. That’s why making it incredibly easy for security researchers, partners, and even customers to report issues is non-negotiable. This means setting up dedicated, secure channels that are simple to find and use.

For instance, a common best practice is to establish a well-publicised point of contact. This usually includes:

1. A Dedicated Email Address: A simple, memorable address like security@yourcompany.com is the industry standard. This inbox needs to be constantly monitored by your PSIRT.
2. A Web Form: A structured form on your website can guide reporters to provide the essential information right away, like the affected product, version, and a technical description of the flaw.

This infographic shows how information flows from researchers and distributors to you, the manufacturer. It really highlights why those clear intake channels are so important.

As you can see, you are the central point for processing vulnerability information before it triggers an official CRA reporting obligation under Article 14.

Integrate and Automate Your Workflow

Once a report comes in, it must enter a documented workflow. Let’s be honest: tracking vulnerabilities in spreadsheets is a recipe for disaster, especially when you’re up against tight deadlines. Integrating your reporting channels with an internal ticketing system like Jira or ServiceNow is a total game-changer.

This integration instantly turns a simple email into a trackable, auditable record. For example, you can create an automation rule where any email sent to security@yourcompany.com automatically generates a new high-priority ticket in your PSIRT’s Jira project. This immediately assigns the issue, starts the clock on your internal SLAs, and establishes a single source of truth for the entire incident.

This isn’t just about making your response more efficient; it’s about building a crucial evidence trail. You’ll need this documentation to prove your due diligence, a topic we cover in more detail in our guide on creating CRA technical documentation: https://goregulus.com/cra-documentation/technical-documentation/

Don’t forget, these processes need to be ready soon. The reporting rules kick in on September 11, 2026, with full CRA implementation required by December 11, 2027.

Mastering Vulnerability Documentation and Management

Solid documentation isn’t a bureaucratic chore. It’s your best defence during a market surveillance audit and a crucial tool for meeting the tight deadlines of the CRA’s reporting obligations under Article 14. Good records turn the frantic 24-hour reporting window from a mad dash into a manageable, well-documented process.

Without a robust documentation system, proving your due diligence is nearly impossible. When auditors ask how you handled a specific vulnerability, a vague “we think we fixed it” won’t cut it. You need a complete, timestamped audit trail that shows exactly what happened, when it happened, and why you made the decisions you did.

Structuring Your Technical Documentation for Audits

The CRA is specific about what your technical documentation needs to contain, laying it all out in Annex VII. A critical piece is a detailed account of your vulnerability handling procedures. This isn’t just a brief mention; it must be a thorough explanation of your end-to-end process.

As you build out your reporting process, it’s essential to follow established document management best practices. This ensures your records are consistent, accessible, and ready for an audit. Your technical file must explicitly include:

• A Published Vulnerability Disclosure Policy (VDP): This is your public-facing document that tells security researchers how to report vulnerabilities to you securely. It builds trust and creates a clear intake channel.
• Internal Vulnerability Handling Procedures: This is the detailed playbook for your PSIRT, covering everything from the initial triage of a report to the final deployment of a patch.
• The Software Bill of Materials (SBOM): This is a complete inventory of every single component in your product, including all the open-source libraries. An SBOM is non-negotiable for quickly figuring out which products are affected when a new component vulnerability is discovered.

To help you get organised, here is a checklist of the essential documentation you’ll need to have in place to satisfy the CRA’s requirements under Article 14.

Essential Documentation For Article 14 Compliance

Having these documents defined, maintained, and accessible is the key to turning a reactive, chaotic process into a structured and defensible compliance strategy.

Maintaining an Internal Vulnerability Database

At the very heart of your documentation strategy must be an internal vulnerability database. This is your single source of truth for every security issue ever reported or discovered in your products. For any IoT vendor or software manufacturer, this isn’t just a nice-to-have; it’s the bedrock of effective product security lifecycle management.

This database—whether it’s a dedicated platform or a well-configured Jira project—needs to track each vulnerability’s entire journey from start to finish.

Key Insight: Your vulnerability database tells the story of your security efforts. It shows regulators exactly how you identify, assess, and resolve threats, providing concrete proof that you are meeting your CRA reporting obligations under Article 14.

Let’s walk through a practical example. A security researcher reports a flaw in your smart lock’s firmware. Here’s how that vulnerability would move through your database:

• Initial Entry: The report is logged with a unique ID, a timestamp, and the reporter’s details. Its status is immediately set to “New.”
• Triage & Assessment: Your PSIRT gets to work and validates the report. They assign it a CVSS (Common Vulnerability Scoring System) score to quantify its severity. A flaw allowing a remote attacker to unlock the door would likely get a 9.8 (Critical).
• Remediation Plan: The ticket is assigned to the right engineering team. They outline a plan to fix the bug and estimate a timeline for developing, testing, and releasing a patch.
• Resolution: The patched firmware is released. The database entry is updated to “Resolved,” with direct links to the new firmware version and the security advisory you sent to customers.

This detailed, step-by-step record is precisely what makes the 24-hour reporting requirement achievable. When you learn an issue is being actively exploited, you aren’t starting from zero. You simply pull up the existing record, which already contains most of the information you need for your initial notification to ENISA. For a deeper dive into the whole process, our guide on CRA vulnerability handling breaks it down even further. By treating documentation as a strategic asset, you build both resilience and confidence in your compliance.

Your Top Questions About Article 14 Answered

Even after you get a handle on the rules, the practical side of the Cyber Resilience Act can throw up some tricky questions. The CRA reporting obligations under Article 14, in particular, create new pressures and responsibilities. It’s no surprise that managers and engineers are worried about how this plays out in the real world.

Let’s tackle some of the most common questions we hear, breaking down the nuances to help you build confidence in your compliance plan.

What If a Vulnerability Is Discovered But Not Yet Exploited?

This is one of the most important distinctions you’ll need to make, and getting it right is fundamental. The 24-hour reporting clock under Article 14 does not start ticking the moment you find a new bug. The CRA is crystal clear on this: the urgent reporting obligation is triggered only for an actively exploited vulnerability.

This means you need credible evidence that attackers are actually using the flaw against systems in the wild. A theoretical weakness found by your internal security team or a bug reported by a researcher doesn’t automatically trigger a report to ENISA.

Key Insight: The threshold for official reporting is active exploitation, not just discovery. Until you have credible evidence of exploitation, your responsibility is to focus on your internal assessment, triage, and patching process.

For instance, let’s say your QA team uncovers a serious SQL injection flaw in your cloud-connected industrial controller during routine testing. It’s a severe vulnerability, but as far as you know, it’s not being exploited.

At this point, your duties are to:

• Assess the Risk: Use a framework like the Common Vulnerability Scoring System (CVSS) to figure out its severity. A flaw like this would almost certainly get a Critical score.
• Prioritise a Fix: Your engineering team needs to start working on a patch straight away.
• Monitor for Exploitation: Your security team should be actively hunting for any signs that this vulnerability is being used by attackers.

Your own vulnerability management process takes priority here. It’s only if you later find evidence of active exploitation—like logs showing an attacker using that exact SQL injection to breach a customer’s network—that your CRA reporting obligations under Article 14 would kick in.

Does Reporting to ENISA Mean a Flaw Becomes Public Knowledge?

This is a huge concern for manufacturers. The fear is that reporting a vulnerability will immediately spark negative press, customer panic, and a hit to your reputation. Fortunately, the CRA was designed with confidentiality measures to prevent exactly that.

When you send a report to ENISA and the national CSIRTs, it isn’t broadcast to the world. The information is handled within a trusted network of cybersecurity authorities. Their primary goal is to protect the single market, not to name and shame manufacturers.

The entire process is built around the principles of Coordinated Vulnerability Disclosure (CVD). In simple terms, this means the authorities work with you to manage how and when information is released.

Let’s walk through a practical example. Imagine you manufacture a point-of-sale (POS) terminal and you report an actively exploited vulnerability that could leak transaction data.

• The initial report you send to ENISA is confidential.
• ENISA and the CSIRTs use this information to assess the risk across the entire market. They might, for example, quietly warn financial institutions to monitor for suspicious activity without ever naming your product.
• This buys you a critical window to develop and roll out a security patch.
• The vulnerability is typically made public only after a fix is available and you’re ready to inform your customers, often through a joint advisory.

This collaborative model protects the market from the immediate threat while giving you the time to fix the problem responsibly. It prevents a premature disclosure that would only help attackers.

Who Is Responsible for Reporting Flaws in Open-Source Software?

The use of open-source software (OSS) is everywhere, but it’s a common source of confusion when it comes to accountability. The CRA is unambiguous here: the ultimate responsibility for the security of the final product lies with the manufacturer.

If your product uses an open-source component with a vulnerability, you are responsible for it as if it were your own code. You can’t just point the finger at the open-source project and consider your job done.

This is where having a complete Software Bill of Materials (SBOM) becomes an absolute must. When a vulnerability like Log4Shell hits the headlines, your SBOM should allow you to instantly see if your products are affected.

Here are the practical steps you have to take:

1. Track and Monitor: Continuously watch all OSS components in your products for newly disclosed vulnerabilities.
2. Report Upstream: If you discover a brand-new flaw in an OSS component, you have a duty to report it to the project’s maintainers so they can fix it for the entire community.
3. Manage and Mitigate: You must assess how the vulnerability impacts your specific product. If it’s being actively exploited, you have to fulfil your own CRA reporting obligations under Article 14.
4. Patch Your Product: You are responsible for integrating the fixed OSS component into your product and shipping an update to your customers.

For example, if your smart TV uses a vulnerable open-source media library and attackers are actively exploiting it, it is you—the TV manufacturer—who must submit the 24-hour report to ENISA. You also have to release a firmware update with the patched library. Simply waiting for the OSS project to act is not an option.

Navigating the complexities of the Cyber Resilience Act can be daunting, but you don’t have to do it alone. Regulus provides a unified software platform that simplifies every step of the CRA compliance process. From applicability assessments and requirements mapping to documentation templates and vulnerability management guidance, Regulus turns regulatory hurdles into a clear, actionable plan. Gain clarity and confidence on your path to EU market readiness by exploring our solution at https://goregulus.com.

La entrada A Guide to CRA Reporting Obligations Article 14 se publicó primero en Regulus.

What Is a CRA Compliance Evidence Pack

The Cyber Resilience Act requires that any company placing products on the EU market must be able to demonstrate end-to-end security. Your CRA compliance evidence pack is how you do it. This isn’t just a single document; it’s a living dossier that tells the entire story of your product’s security journey.

This collection of proof shows you’ve woven security into every stage of the product lifecycle, from initial design concepts right through to post-market support and vulnerability management. When an auditor from a market surveillance authority comes knocking, this dossier is your first and most important line of defence.

Core Components of the Evidence Pack

A solid evidence pack is far more than a few ticked boxes. It’s an organised body of tangible proof. While the exact contents will differ from one product to the next, every pack should be built on a few core pillars.

• Cybersecurity Risk Assessment: This is your foundation. It’s where you document all identified threats, analyse their potential impact, and detail the mitigation strategies you put in place. For a smart lock, a threat might be a brute-force attack on the entry PIN. The mitigation strategy documented here would be implementing an account lockout mechanism after three failed attempts.
• Secure Design & Development Evidence: This includes all the documentation proving that security was a non-negotiable part of your development process from day one. This could be meeting minutes from a design review where security features were mandated or a link to a secure coding standard in your internal wiki that developers must follow.
• Software Bill of Materials (SBOM): An essential inventory of every software component, including open-source and third-party libraries, that is absolutely critical for effective vulnerability management.
• Vulnerability Handling Records: This section must demonstrate a clear, repeatable process for receiving, evaluating, and fixing vulnerabilities discovered after your product hits the market.
• Conformity Assessment Documentation: This covers your test reports, internal audit results, or any certificates from notified bodies that verify compliance with CRA requirements.

A common mistake is to treat the evidence pack as a one-and-done project. The CRA demands it to be a “living” file, continuously updated throughout the product’s entire support period to reflect new patches, newly found vulnerabilities, and any design changes.

Getting these materials organised is a major challenge in itself, which is why a proper file structure is a critical first step. For more on this, you might be interested in our detailed guide on the CRA technical file structure.

Gathering Your Essential Documents and Artifacts

Putting together your CRA compliance evidence pack is where the rubber meets the road. It’s not about ticking boxes; it’s about building a coherent, auditable story that proves your product’s security from the ground up. Think of it as assembling a legal case file—every document, log, and report is a piece of evidence.

Your goal is to have everything organised and traceable, ready to withstand the scrutiny of market surveillance authorities. A messy collection of files will get you failed just as quickly as a missing risk assessment.

The Non-Negotiable Items for Your Technical File

Your technical file is the heart of the evidence pack. It holds the foundational artefacts that prove you’ve done your due diligence right from the start of the product’s life. Without these, your compliance claims are just that—claims, not verifiable facts.

Two documents are absolutely critical and non-negotiable: your cybersecurity risk assessment and the Software Bill of Materials (SBOM).

• Cybersecurity Risk Assessment: This is your starting point. For a smart baby monitor, a documented threat would be unauthorised access to the video stream. The assessment must then detail the mitigation, such as end-to-end encryption and a mandatory strong password policy for user accounts.
• Software Bill of Materials (SBOM): You’ll need a complete, machine-readable inventory of every single software component. For example, your SBOM for a smart TV would list its operating system (e.g., Linux kernel 5.15.6), the video streaming library (FFmpeg 4.4), and even the small library used for parsing JSON data (cJSON 1.7.15).

Efficiently compiling these records is a huge part of the challenge. A practical guide to extract data from documents can be a lifesaver here, especially when dealing with complex component lists.

What Detailed Test Reports Should Include

Your test reports are the proof that your security measures actually work as designed. Vague, high-level summaries won’t cut it. To be credible, your reports need to connect the dots with granular detail, linking your security claims to real-world verification.

Take a smart thermostat, for example. A report that just says “encryption tested” is useless. A compliant report would include:

• The specific penetration testing tools used (like Wireshark or Nmap).
• Logs that show both successful and failed attempts to intercept data traffic.
• Confirmation that only strong, current encryption protocols such as TLS 1.3 are enabled.
• Hard evidence that weaker, outdated protocols (like SSLv3 or TLS 1.0) are actively disabled. For example, a screenshot or log output from a tool like nmap --script ssl-enum-ciphers -p 443 <device-ip> showing the rejection of weak ciphers.

Remember, the point of a test report is to give an auditor a clear, undeniable trail from a stated security requirement (e.g., “all data in transit must be encrypted”) to the objective evidence proving it’s been implemented effectively.

In the ES region, evidence packs are foundational for proving compliance across all 27 EU states. Regulation (EU) 2024/2847 requires a technical file with product descriptions, risk assessments, test results, and vulnerability handling records, all retained for 10 years post-market. Our data from 2025 audits in the ES region showed that a staggering 85% of IoT devices contained third-party open-source components requiring a detailed SBOM, which dramatically increases the evidence-gathering workload.

Internal Audits and Self-Assessment Evidence

For products in the default risk class, the CRA allows for self-assessment. But don’t mistake “self-assessment” for an easy way out. You still need to produce robust internal audit evidence showing your conformity assessment was objective and thorough.

This means creating an “internal audit” file that essentially simulates what an external auditor would demand to see.

Key Evidence for Self-Assessment:

1. Conformity Checklist: A detailed checklist that maps every single applicable requirement from Annex I of the CRA to the specific evidence you’ve gathered to prove it.
2. Review Records: Documentation of internal review meetings, noting who attended, what was found, and what actions were taken to fix any identified gaps. For example, minutes from a review stating, “Gap found in session timeout policy. Action: JIRA-5432 assigned to dev team to implement 15-minute inactivity logout.”
3. Signed Declaration: A formal, signed statement from a responsible party in your organisation, confirming that the product meets all requirements based on the compiled evidence.

Going back to our smart thermostat, this would involve internally verifying that security-by-default principles were followed, like forcing a password change on first use. Your evidence would be a test script and a screenshot showing the mandatory password prompt in action.

Our guide on CRA technical documentation offers more practical insights into structuring these crucial files. This methodical approach ensures you have every piece of the puzzle ready to satisfy authorities and prove your due diligence.

Once you’ve gathered all your documents, the real work begins. A CRA compliance evidence pack isn’t just a folder stuffed with files; it’s a carefully constructed argument that proves your compliance. The next step is to map every single piece of evidence to the specific legal requirements of the Cyber Resilience Act.

Think of it this way: you need to create a clear, logical trail for an auditor. When they pick up a requirement from the CRA, they should be able to follow that trail directly to the document—or documents—that prove you’ve met it. Without this mapping, your evidence pack is just a disorganised collection of files that won’t convince any market surveillance authority.

This process transforms your documentation from a simple checklist into a compelling, auditable narrative.

As you can see, compliance is a dynamic process where artifacts like risk assessments, SBOMs, and test reports all inform and validate one another. It’s not about static documents.

Building Your Compliance Matrix

The most effective way to manage this is with a compliance matrix. In my experience, a detailed spreadsheet is the perfect tool for this, though some teams use dedicated compliance software. This matrix will become the central index for your entire evidence pack.

Your matrix should, at a minimum, include columns for:

• CRA Requirement: The specific article or point from Annex I (Essential Cybersecurity Requirements) or Annex II (Vulnerability Handling).
• Requirement Description: A short, plain-English summary of what the obligation actually means for your product.
• Evidence Artefact: The exact filename of the document or record that proves compliance (e.g., “Cybersecurity Risk Assessment v1.2.pdf”).
• Location/Link: A direct link or clear file path to where the evidence is stored. This is non-negotiable for audit readiness.
• Notes: Any extra context an auditor might need, like a specific page number, section heading, or table within a larger document. For example: See Section 4.2, Table 3 for port scan results.

Don’t treat this matrix as just an administrative chore. This process is effectively your first internal audit. It forces you to critically review your evidence, spot the gaps, and see where your documentation is weak or missing entirely.

Mapping Evidence to Annex I Security Requirements

Annex I of the CRA details the essential security requirements products must meet by design. Your mapping needs to show precisely how your development practices and technical controls fulfil these obligations.

Let’s take a common example: the requirement for a secure-by-default configuration. Your matrix would need to connect this to several different pieces of evidence to build a strong case.

Practical Example: Secure-by-Default Configuration

• CRA Requirement: Annex I, Section 1(a) – “products shall be made available on the market with a secure by default configuration.”
• Evidence Artefact 1: “Internal Secure Configuration Guide v2.0″—This shows you have a defined standard.
• Evidence Artefact 2: “Penetration Test Report – Q3 2026″—Point to the specific section that verifies non-essential ports are closed by default.
• Evidence Artefact 3: A screenshot from your product’s setup screen that forces the user to change the default password on first use.

Here, each piece of evidence reinforces the others, creating a much more robust and verifiable claim than a single document ever could.

Linking Artefacts to Annex II Vulnerability Handling

Annex II is all about your process. It focuses on how your organisation handles vulnerabilities after the product is on the market. You’re not just proving the product was secure at a single point in time, but that you have a robust, ongoing process for keeping it secure.

For instance, Annex II requires manufacturers to have procedures for regular security testing.

Practical Example: Regular Security Testing

• CRA Requirement: Annex II, Point 2 – “The manufacturer shall have procedures in place to regularly test and verify the security of the product.”
• Evidence Artefact 1: Your internal policy document, like “Quarterly Security Testing & Review Process.”
• Evidence Artefact 2: A log or report from your automated tooling showing a record of scheduled vulnerability scans over the last 12 months.
• Evidence Artefact 3: A firmware update log showing that an update (e.g., FW v1.4.2) was released to patch a vulnerability discovered during a scheduled test.

This combination is powerful because it shows an auditor the complete cycle: you have a policy, you execute on it (the scans), and you take action on the findings (the firmware update). It proves your process actually works in the real world. This kind of structured mapping is the absolute backbone of a successful CRA compliance evidence pack.

Mastering Vulnerability and Update Records

Under the Cyber Resilience Act, your entire vulnerability response process is going under the microscope. The regulation demands impeccable record-keeping and rapid, structured reporting. This is exactly where your CRA compliance evidence pack becomes an active operational tool, not just some static file you pull out for an audit.

Let’s walk through a real-world scenario. Imagine an actively exploited, critical vulnerability is discovered in an open-source library. It turns out your flagship IoT camera uses this library. The clock starts ticking immediately.

The 24-Hour ENISA Notification Window

Your first, most urgent priority is the 24-hour initial notification to ENISA. The evidence for this report has to be assembled fast, but it must be accurate. You don’t need all the answers yet, but you do need to prove you have a process to find them.

At this stage, you need to capture a few key pieces of evidence:

• Initial Discovery Logs: A timestamped alert from your dependency scanning tool (e.g., Snyk, Dependabot) flagging a new critical CVE in a library used by your product.
• Internal Triage Communications: A screenshot of the Slack channel or a copy of the Jira ticket (VULN-1234) created by your PSIRT (Product Security Incident Response Team) to begin the investigation, including initial comments and assignments.
• Preliminary Technical Analysis: An engineer’s notes confirming the vulnerable library is present in the production firmware. For example: “Confirmed lib_xyz.so version 1.2.3 is present in firmware build #5678, which is vulnerable to CVE-2027-XXXX.”

This initial evidence set is your proof of a responsible first response. It shows you’ve identified a potential threat and have already kicked off a structured investigation.

The goal of the 24-hour report isn’t to present a complete solution. It’s to inform authorities that a potentially serious, actively exploited vulnerability exists in your product and that you are actively managing it. Your evidence pack must capture the start of this process with precision.

The 72-Hour Follow-Up and Final Report

As your investigation deepens and your remediation plan takes shape, the next reporting phases demand more substantial evidence. Your evidence pack needs to grow to include detailed records of your response activities.

The CRA imposes a strict reporting timeline for actively exploited vulnerabilities. The table below summarises the key deadlines you’ll need to meet.

| CRA Vulnerability Reporting Deadlines |
| :— | :— | :— |
| Event | Deadline | Required Action and Evidence |
| Initial Alert | Within 24 hours of awareness | Submit an early warning to ENISA. Evidence includes discovery logs, internal triage records, and preliminary analysis notes. |
| Main Notification | Within 72 hours of awareness | Provide a more detailed report covering severity, affected products, and initial mitigation advice. Evidence includes CVSS scoring and draft user guidance. |
| Final Report | Within 14 days of patch availability | Submit a final report with details on the fix. Evidence should include patch commits, QA test results, and the published security advisory. |

Meeting these deadlines is non-negotiable, especially with fines for non-compliance reaching up to €15 million or 2.5% of global turnover.

For the 72-hour report, your evidence should now include:

• Severity Assessment: A completed CVSS scoring worksheet resulting in a score of 9.8 (Critical), with the vector string documented (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
• Mitigation Guidance: A draft of the security advisory email to users advising them to temporarily disable a specific feature until a patch is available.
• Remediation Plan: Internal documents that outline your team’s plan to develop, test, and release a security patch, such as a project plan in Confluence or a detailed epic in Jira.

The final report is your opportunity to close the loop. A huge part of this is mastering vulnerability remediation to ensure every weakness is fully addressed. Your evidence here must be comprehensive, including patch development commits, quality assurance test results, and the final security advisory published to your users.

For a deeper dive into these processes, check out our guide on https://goregulus.com/cra-requirements/cra-vulnerability-handling/.

Documenting Security Updates and Support

The CRA’s focus isn’t just on individual incidents; it extends to your entire update process. You must be able to prove you have a mature, repeatable system for delivering security updates throughout the product’s defined support period.

Your evidence pack should contain a complete, running log of all security updates. For every single update, you need to document the release date, the vulnerabilities it addresses (with their CVE identifiers), and a direct link to the published release notes. For example, an entry in this log could read: “Firmware v2.5.1, released 2027-10-15. Fixes CVE-2027-1234 and CVE-2027-5678. Release notes: [link].” This log is the definitive proof of your commitment to ongoing product security and a true cornerstone of your CRA compliance evidence pack.

Your CRA Compliance Roadmap for 2026–2027

With the Cyber Resilience Act’s deadlines approaching, just knowing the rules isn’t enough. Your organisation needs a concrete, strategic plan to turn that knowledge into action. Breaking the compliance journey down into manageable phases makes the whole project feel less daunting and helps ensure your CRA compliance evidence pack is ready when it needs to be.

This roadmap lays out a phased approach, helping you prioritise tasks and allocate resources effectively as we head toward the key enforcement dates in 2026 and 2027.

Phase 1: Foundational Work (Now to Mid-2026)

This initial phase is all about discovery and planning. If you rush into implementation without a solid foundation, you’re just setting yourself up for wasted effort and critical gaps in your evidence. The main goal here is to figure out exactly where you stand and what needs to be done.

First, conduct a thorough applicability assessment. Not every product will fall under the CRA, so confirming which of your offerings are actually in scope is the only logical place to start. A purely analogue device, for instance, has no digital elements, but a smart toaster with a Wi-Fi connection is clearly in scope.

Once you know which products are affected, it’s time for product classification. You have to determine if your product is in the default class or a more critical category, as defined in Annex III of the CRA. For example, a network router or a firewall would likely fall into a critical class, requiring third-party assessment. A connected coffeemaker would be in the default class, allowing for self-assessment. This decision has huge implications for your budget and timeline.

This is the perfect time to run a comprehensive gap analysis. Compare your current security practices, documentation processes, and vulnerability handling workflows against the specific requirements of the CRA. The output should be a clear report detailing what you have versus what you need.

Phase 2: Implementation and Assembly (Mid-2026 to Early 2027)

With your foundational analysis complete, you can shift from planning to doing. This phase is all about building the core components of your compliance programme and starting to assemble the tangible evidence. A critical deadline to keep an eye on is September 2026, when the mandatory vulnerability reporting obligations kick in.

Your absolute top priority should be to establish and operationalise your vulnerability reporting workflow. This includes setting up your coordinated disclosure policy and making sure your team is ready to meet the 24-hour ENISA notification window for actively exploited vulnerabilities.

• Assemble Your Evidence Pack: Begin creating the central repository for your CRA compliance evidence pack. This is when you start gathering all the documents identified during your gap analysis, like existing risk assessments and design documents.
• Generate Initial SBOMs: Start creating Software Bills of Materials (SBOMs) for your in-scope products. This process can be surprisingly time-consuming, so starting early is the only way to identify all dependencies accurately.
• Refine Internal Processes: Based on your gap analysis, start refining your secure development lifecycle (SDL) and other internal processes to align them with CRA standards.

For example, a manufacturer of a connected security camera would use this phase to deploy a tool for automated SBOM generation and integrate it into their CI/CD pipeline. They would also run drills to simulate an ENISA reporting event, ensuring their team can gather the required information and submit it well within the 24-hour timeframe.

Phase 3: Finalisation and Audit Readiness (Mid-2027 Onwards)

The final stretch is about pulling everything together and getting ready for the full enforcement date in December 2027. This phase focuses on finalising all documentation, validating your work through audits, and making the official declarations required for market access.

Your technical documentation has to be complete and polished. This means finalising all test reports, ensuring your risk assessments are up-to-date, and verifying that your evidence matrix correctly maps every single CRA requirement to its corresponding proof.

Key Actions for the Final Phase:

1. Complete All Technical Documentation: Ensure every required artefact for your evidence pack is finalised, reviewed, and stored in your central repository.
2. Conduct Audits: Perform a thorough internal audit against your compliance matrix. For critical products, this is when you would schedule the assessment with your chosen notified body.
3. Prepare for CE Marking: Once you are confident in your compliance, you can draft and sign the EU Declaration of Conformity and prepare to affix the CE mark to your products. For instance, you will generate a PDF of the declaration, have it digitally signed by the CEO, and store it in the evidence pack.

This phased approach provides a structured path to compliance and helps prevent last-minute chaos. For more details on key dates, you can read our guide on the CRA deadlines for 2025–2027. By methodically working through these stages, you can build a robust compliance posture and a complete evidence pack with confidence.

Frequently Asked Questions About the CRA Evidence Pack

Even with a solid plan, a few practical questions always pop up when it’s time to actually build a CRA compliance evidence pack. We get these all the time from manufacturers and developers working through the new requirements.

Let’s clear up some of the most common points of confusion around documentation scope, third-party components, and ongoing maintenance. Getting these right will help you avoid common pitfalls and keep your compliance project on track.

What Is the Difference Between Technical Documentation and the Evidence Pack?

This is a frequent source of confusion, but the distinction is simple. Think of the “technical documentation” as the legal checklist of required content laid out in the CRA, especially in Annex VII. It’s the official “what” you need to have.

The CRA compliance evidence pack is the real-world assembly of all that content. It’s the organised, living collection of your actual documents, records, and artefacts—your SBOMs, risk assessments, test reports, and so on. It’s the tangible “how” you prove you meet the legal requirements.

In short, the evidence pack is the practical dossier you’ll present when an auditor asks to see your technical documentation. It’s the proof behind the promise.

For instance, Annex VII requires a “cybersecurity risk assessment.” Your evidence pack is where you’ll find the actual file, like Product-X-Risk-Assessment-v2.1.pdf, that satisfies this obligation.

Do I Need an Evidence Pack for a Product Already on the Market?

Yes, but with an important distinction. The CRA’s main requirements apply to products placed on the EU market after the December 2027 enforcement date. If your product was on the market before then and doesn’t undergo a “substantial modification,” it’s generally exempt from most obligations.

There’s a critical exception, though. The vulnerability and incident reporting duties under Article 14 kick in much earlier, on September 11, 2026. These rules apply to all in-scope products, including your legacy ones.

So, even for existing products, you’ll need processes and documentation ready to meet these reporting obligations. And if you make a substantial modification to an older product after the 2027 deadline, it’s treated as a new product and will need a full evidence pack.

A substantial modification isn’t just a minor bug fix. A practical example would be releasing a firmware update for a smart speaker that adds a new voice-activated payment feature. This changes its risk profile significantly and would require a full re-evaluation and a complete evidence pack.

How Granular Does My Software Bill of Materials (SBOM) Need to Be?

Your SBOM must be comprehensive, accurate, and machine-readable. A vague or incomplete SBOM is useless for vulnerability management and will not pass an audit. The goal is a complete inventory that enables fast, effective tracking of vulnerabilities across your entire supply chain.

At a minimum, your SBOM has to include:

• All Components: Every single piece of software must be listed. This includes your own proprietary code, all open-source libraries, and any commercial third-party software.
• Transitive Dependencies: It’s not enough to list the libraries you use directly. You must also identify the dependencies of those libraries. For example, if your product uses libcurl, your SBOM must also list its dependencies like zlib and OpenSSL.
• Component Details: For every component, you need the supplier name, component name, the exact version number, and a unique identifier like a PURL (Package URL).

Practical Example:
Simply listing openssl in your SBOM is not enough. A compliant entry is specific and machine-readable, like this: pkg:conan/openssl@3.0.12. This format gives automated scanners the exact name and version needed to do their job. This level of detail is non-negotiable for building a compliant CRA compliance evidence pack.

Navigating the complexities of the Cyber Resilience Act can be challenging, but you don’t have to do it alone. Regulus provides a software platform designed to guide you through every step, from applicability assessments to generating your technical documentation templates. Gain clarity, reduce compliance costs, and confidently place your products on the EU market by visiting our website.

La entrada How to Build a CRA Compliance Evidence Pack se publicó primero en Regulus.

Decoding the Official CRA Implementation Timeline

Now that the European Commission’s Cyber Resilience Act is in force, the first job for any manufacturer, software developer, or IoT vendor is to get to grips with the implementation timeline. These aren’t just dates on a calendar; they are hard milestones that will determine whether your products can be sold in the EU. If you fail to get ready, you risk being shut out of one of the world’s biggest markets.

The good news is that the timeline is designed to give you a window to adapt. It’s not a sudden cliff edge but a progressive rollout of obligations, allowing you to build a solid compliance framework without having to tear up your existing product development and operational workflows.

Key Dates and Their Impact

The period between now and late 2027 is your preparation window. The European Commission has laid out the CRA implementation timeline to give manufacturers and IoT vendors a reasonable runway before full enforcement. The most important deadlines are packed into 2026 and 2027, leading up to the full application of the Act on 11 December 2027. This 36-month grace period from its entry into force gives your organisation the adjustment time it needs to run applicability checks, map requirements, and build out your technical files.

The timeline below cuts through the noise and shows the two milestones that should be anchoring your roadmap right now: vulnerability reporting and full enforcement.

It’s pretty clear that while full enforcement seems a way off in late 2027, your first compliance actions around vulnerability management need to be locked in much sooner.

Key CRA Compliance Milestones 2026-2027

The phased timeline sets clear expectations for manufacturers. This table summarises the critical deadlines you need to factor into your internal project plans between now and 2027.

These dates aren’t suggestions—they are firm deadlines. Your roadmap must show a credible plan for meeting each one.

Turning Deadlines into Action

The real work is translating these legal dates into practical business actions. For instance, the mandatory vulnerability reporting requirement means your security and product teams need a defined process for receiving, triaging, and reporting security issues to the right authorities well before the deadline hits. A practical example would be a company that manufactures smart locks. Before June 2026, they must have a public-facing security contact point, an internal system to assess bug reports (e.g., using a CVSS framework), and a clear protocol for notifying ENISA within 24 hours if a severe vulnerability is actively being exploited.

The CRA’s phased rollout is a strategic opportunity. Use this period to methodically align your engineering, security, and legal teams, turning compliance from a burdensome cost centre into a competitive advantage built on trust and security.

As you build out your CRA implementation plan, it’s also smart to look at how it intersects with other EU regulations. You’ll often find overlaps with data protection, and a practical AI GDPR compliance guide can provide useful context for making sure your product ticks all the necessary legal boxes.

By mapping these dates to your internal project plans, you can build a manageable path forward. For a more detailed plan, check out our guide on how to build a complete Cyber Resilience Act compliance roadmap. This proactive approach ensures you’re not scrambling to meet deadlines but are instead building a foundation for sustained compliance.

Does the CRA Apply to Your Product Portfolio?

Before your teams spend a single euro on compliance, the first move is to figure out if the Cyber Resilience Act even touches your products. The European Commission’s guidance all comes back to one core concept: “products with digital elements” or PDEs. It’s a deliberately broad term, but a quick, systematic check will tell you where you stand.

A PDE is any software or hardware product—and its remote data processing solutions—that connects directly or indirectly to another device or network. This definition casts a wide net, catching far more than just obvious smart devices. It’s time to move past assumptions and take a hard look at your entire portfolio.

Defining Products with Digital Elements

To make sense of the EU’s guidance, you need to focus on how your products handle data. The key is the “data connection” requirement. This is what separates a simple electrical kettle from a smart kettle that exchanges digitally encoded information with a network or app.

Let’s ground this in some real-world scenarios:

• Smart Thermostat: This is the textbook case. It’s a piece of hardware running firmware that connects to a Wi-Fi network. It takes commands from a mobile app and sends data to a cloud server. Unambiguously a PDE.
• Connected Industrial Sensor: A sensor on a factory floor that monitors temperature and sends that data over a local network to an industrial control system (ICS) is also a PDE. Both the hardware and the software enabling that connection are in scope.
• Commercial Software Library: Here’s where it gets less obvious. If you sell a software development kit (SDK) for processing images that developers integrate into their commercial mobile apps, your SDK is a PDE. Because it’s intended for integration into connected products, it falls under the CRA.

The CRA’s reach isn’t just about finished goods. It extends to the very components and software that make them work. If your product is built to be integrated into another product with digital connectivity, it almost certainly falls within the scope.

This means scrutinising not just what your product does, but what it enables other products to do. For a deeper analysis of the edge cases, our detailed guide on Cyber Resilience Act applicability offers more specific examples.

Navigating Common Grey Areas

The official guidance also helps clear up some common points of confusion, especially around software and older products. Getting these distinctions right is critical for scoping your compliance project accurately from day one.

One of the most debated topics is free and open-source software (FOSS). The CRA is quite clear here: if FOSS is supplied on a non-commercial basis, it’s generally out of scope. For example, a developer maintaining a small open-source logging library in their free time is not covered. However, the moment a company integrates that same open-source component into a commercial product they sell, they, as the manufacturer, become responsible for its security and CRA compliance.

Another frequent question is about legacy products. The rule seems simple: products placed on the EU market before 11 December 2027 are exempt. But there’s a massive catch—the “substantial modification” clause.

So, what counts as a substantial modification?

• Not a Substantial Modification: Releasing a routine security patch to fix a known vulnerability in a smart TV. This is just maintenance.
• A Substantial Modification: Pushing a major software update to that same smart TV that adds new streaming service apps and voice assistant integration. This introduces new functionalities and potential threat vectors, changing the product’s original risk profile.

If a legacy product gets a “substantial modification” after the deadline, it’s instantly treated as a new product. That means it must fully comply with the CRA. This forces engineering and product teams to meticulously document every change and assess its security impact, otherwise you could accidentally trigger a full-blown and expensive compliance obligation.

How to Classify Your Product’s Risk Level

Once you’ve confirmed the Cyber Resilience Act applies to your products, the next job is classifying their risk level. This isn’t just a box-ticking exercise; this decision shapes your entire conformity assessment journey, its complexity, and ultimately, its cost. The CRA implementation guidance from the European Commission lays out three main categories, and getting this classification right is absolutely fundamental.

Get it wrong, and you’re looking at two expensive mistakes. Under-classify, and you create a massive compliance gap, risking market withdrawal and serious penalties. Over-classify, and you saddle your team with unnecessary costs and administrative burdens, like paying for a Notified Body assessment when a self-assessment would have been perfectly fine.

The Default Risk Category

The vast majority of products with digital elements will land in the default category. This is the baseline for products whose failure isn’t expected to cause significant systemic disruption or widespread harm. For these products, the conformity assessment path is the most straightforward.

Think of your typical consumer smart home device—a connected coffee machine, smart lighting, or a smart toy. While a security bug is certainly an issue that needs fixing, it’s unlikely to bring down critical infrastructure or endanger public safety. A bug in a smart speaker might allow someone to play music without permission, which is inconvenient but not catastrophic.

For these default products, manufacturers can perform a self-assessment. This means you internally verify and document that your product meets all the essential requirements in Annex I of the CRA. You get to skip the cost and overhead of involving an external third-party certification body.

Critical Products Class I and Class II

This is where the real complexity starts. The European Commission, in Annex III of the CRA, provides a specific list of product categories that are automatically deemed “critical” and sorted into Class I or Class II. The decision comes down to the product’s core function and its potential impact if it were ever compromised.

A key takeaway from the official guidance is that classification hinges on the product’s “core functionality,” not the risk level of its individual components. A default-risk product that contains a critical component is still treated as a default-risk product.

Class I Critical Products are those performing functions important to cybersecurity, but they aren’t at the very highest level of criticality. For these, your compliance path gets more involved. We have a complete guide on how to conduct a CRA risk assessment that breaks down the specific steps needed here.

Here are a few examples of products that usually fall under Class I:

• Network Equipment: This covers products like routers, modems, and network switches that are central to network management and security.
• Operating Systems: General-purpose operating systems for desktops and servers are in this class because of their central role in any computing environment.
• Password Managers: Any software designed specifically for storing and managing credentials is also considered a Class I critical product.

For these products, you have a choice. You can either follow a harmonised standard and perform a self-assessment, or you must go through a third-party conformity assessment carried out by a Notified Body.

The Highest Risk Level: Class II

Class II Critical Products represent the highest risk category, period. These are products where a failure could lead to severe consequences, hitting critical infrastructure, public safety, or causing major economic disruption.

For instance, an Industrial Control System (ICS) managing a power grid or a railway switching system is a clear-cut Class II product. A compromise there could have immediate, dangerous real-world effects. Likewise, the core hardware security modules (HSMs) used to protect financial transactions or network-connected robots used in surgery also fall into this top tier.

For Class II, there is no option for self-assessment. Mandatory third-party conformity assessment by a Notified Body is the only route. This is a rigorous audit where an independent, government-appointed organisation scrutinises your product and processes to certify they meet the CRA’s strictest requirements. It provides the highest level of assurance but also demands the most significant investment in both time and resources.

Translating CRA Requirements Into Engineering Tasks

The biggest hurdle for most organisations isn’t understanding the Cyber Resilience Act’s legal text; it’s turning it into actual engineering work. This is where the theory stops and the real work begins. We’ll map the essential security requirements from Annex I of the CRA directly onto the development and operational workflows your teams use every day.

Think of this as a practical translator. It takes the high-level legal obligations and turns them into a task-level roadmap. Your product security, engineering, and DevOps teams get a clear set of tickets they can drop right into their backlog and start executing. After all, the European Commission provides the framework, but your technical teams are the ones who have to build it.

From Secure by Default to Developer Checklists

“Secure by default” is a core principle of the CRA, but it’s far too abstract for a developer to act on. You can’t just assign a ticket that says “make it secure.” The real goal is to break this principle down into a concrete checklist that becomes a non-negotiable part of your development process.

Let’s take a connected camera manufacturer as a real-world example. “Secure by default” doesn’t mean much, but these specific engineering tasks do:

• Disable All Non-Essential Ports: When the device comes out of the box, a network scan should only show ports that are absolutely essential for its main function. For instance, only port 443 for HTTPS communication should be open. Any development, testing, or management ports like Telnet (port 23) or FTP (port 21) must be completely disabled in the production firmware.
• Enforce Strong Initial Passwords: The camera can’t ship with default credentials like “admin/admin.” It must force the user to create a unique, complex password (e.g., minimum 12 characters, including upper/lower case, numbers, and symbols) during the initial setup. No exceptions.
• Implement Brute-Force Protection: If someone tries to log in and fails five consecutive times, the device’s login interface has to temporarily lock out that IP address for at least five minutes.

When you break it down like this, you create verifiable tasks. They can be assigned, tracked, and, most importantly, tested. This also generates the exact evidence you’ll need for your technical file later on.

Mapping Vulnerability Handling to Operational Workflows

Another huge part of the CRA is vulnerability handling. The regulation demands a structured process for receiving, fixing, and reporting security flaws. For your teams, this means building an operational workflow that is both robust and repeatable.

A requirement for a ‘vulnerability disclosure policy’ isn’t just about writing a document—it’s about defining a live process. You need a dedicated security contact, a clear system for triaging incoming reports, and established communication channels.

So, how does an obligation to “manage vulnerabilities” look in practice? It becomes a series of well-defined operational steps:

1. Establish a Public Security Contact: Create a simple, easy-to-find security@yourcompany.com email address and a /security webpage. This is where security researchers know exactly where to send their findings. This is your front door.
2. Develop an Internal Triage System: When a report arrives, it should automatically create a ticket in a project management tool (like Jira or Azure DevOps) and assign it to a security engineer for initial validation within one business day.
3. Define Remediation Timelines: Set internal service-level agreements (SLAs) for fixing vulnerabilities based on severity. For a smart thermostat manufacturer, a critical vulnerability allowing remote takeover might demand a patch within 14 days, while a low-risk UI bug can be slated for the next quarterly release cycle.
4. Structure the Coordinated Disclosure Process: Once a fix is ready, you need a documented plan. This covers how you notify the original researcher, publish a security advisory with a CVE identifier, and push the update out to customers. This process must be consistent every single time.

For a much deeper look into setting up these processes, our guide on building a CRA secure development lifecycle offers more detailed steps and context.

These workflows aren’t just best practices; they are mandatory requirements under the CRA and will be scrutinised during an audit. Failing to get this right can lead to major compliance failures, even if your product is otherwise secure. This methodical approach is how you turn legal language into engineering reality.

Building Your Technical File and Vulnerability Management Process

The Cyber Resilience Act boils down to two concrete outputs that will become your proof of compliance: a comprehensive Technical File and a systematic vulnerability management process. Think of the Technical File as your product’s compliance biography—a single source of truth that demonstrates how you’ve met every single requirement. Your vulnerability management process, on the other hand, is the living, breathing system that keeps the product secure long after it ships.

These two elements are precisely what market surveillance authorities will ask for during an audit. Without them, even a technically flawless product will fail its CRA assessment. Getting them right isn’t about ticking boxes; it’s about creating a bulletproof, auditable trail that proves you’ve done your due diligence.

Structuring Your CRA Technical File

Annex II of the CRA spells out the mandatory structure for your Technical File. This isn’t a marketing brochure; it’s a detailed, evidence-based dossier. Your entire goal here is to make it incredibly easy for an auditor to connect each legal requirement to a specific piece of evidence in your file.

A practical way to organise this is to create a master document that indexes all the required components. Here’s a blueprint for its structure:

• General Product Description: The product’s name (e.g., “SmartHome Hub Model X1”), version (e.g., Firmware v2.1.3), intended use, and a clear, concise description of its core functionalities.
• Cybersecurity Risk Assessment: The full report detailing how you identified threats (e.g., “Man-in-the-middle attacks on local network”), assessed risks, and chose your mitigation measures (“Implement TLS 1.3 for all communications”).
• List of Applied Standards: A detailed list of every harmonised standard (e.g., “ETSI EN 303 645”), common specification, or other technical solution you used to meet Annex I requirements.
• Software Bill of Materials (SBOM): A complete and accurate inventory of all third-party and open-source components (e.g., openssl-3.0.2, mosquitto-2.0.14) baked into your product, generated in a standard format like SPDX or CycloneDX.
• Source Code or Documentation: For critical products, you may need to provide a Notified Body with access to source code or extensive technical documentation for review.
• EU Declaration of Conformity: A copy of the formal declaration you sign, attesting to the product’s compliance.

This structure provides a clear, logical narrative for auditors, showing them exactly how your product was designed, developed, and tested with security at its core. To ensure robust cybersecurity and the kind of vulnerability management the CRA requires, it is crucial to understand and implement the latest in API Security Best Practices, as APIs are often a primary attack vector.

Building a Compliant Vulnerability Workflow

Beyond just the documentation, the CRA mandates a robust, active process for handling vulnerabilities. This is much more than just patching bugs as they pop up. It’s about having a documented, repeatable, and timely workflow for every single security report you receive. This process must cover everything from the initial intake to reporting the issue to the EU’s cybersecurity agency, ENISA.

Let’s walk through a tangible scenario. Imagine you’re a manufacturer of a smart home hub, and a security researcher drops a vulnerability report into your inbox.

Your documented workflow should kick in immediately:

• Receipt and Triage: The report lands at your public security@ address. An internal ticket is automatically created and assigned to the product security team. Within 24 hours, the team validates whether the vulnerability is genuine and exploitable.
• Severity Assessment: Using a framework like the Common Vulnerability Scoring System (CVSS), the team classifies the bug’s severity. They quickly determine it’s a critical remote code execution flaw, giving it a score of 9.8.
• ENISA Reporting: Because the vulnerability is being actively exploited in the wild, you must notify ENISA within 24 hours of becoming aware of it. You’ll use ENISA’s designated portal to submit an initial report.
• Remediation and Patching: The engineering team gets to work on a patch. For a critical flaw like this, your internal SLA should mandate that a fix is developed and tested within a short timeframe, say 7 days.
• Coordinated Disclosure: Once the patch is ready, you coordinate with the original researcher. You agree on a public disclosure date, publish a clear security advisory on your website, and push the firmware update automatically to all connected hubs.

This entire workflow—from the first email to the final update—must be documented. Timestamps, key decisions, and every communication create the auditable evidence that proves you are meeting your post-market surveillance obligations under the CRA.

The European Commission is still releasing guidance to clarify these obligations. For instance, on 3 March 2026, it unveiled draft guidance to help manufacturers—especially small and medium-sized enterprises—understand their responsibilities. This guidance addresses how to handle legacy products and even allows for cost-saving measures like grouped testing for similar product families, which is a significant relief for teams with limited resources. You can discover more insights about these draft guidelines on Hunton.com. This ongoing support from the commission is vital for navigating the practicalities of CRA implementation.

Of all the questions we see from product teams digging into the Cyber Resilience Act, a few pop up again and again. It’s understandable—the official guidance from the European Commission can be dense, and getting clear answers on these recurring pain points is key to building a compliance plan you can trust.

This section tackles the most frequent queries head-on, giving you practical answers to cut through the complexity and avoid common missteps.

What Happens to Products Already on the Market?

One of the most pressing questions is about legacy products. What happens if your product was already on the EU market before the full application date of 11 December 2027?

The short answer is that these products generally are not subject to the CRA’s requirements. But there’s a huge catch you need to be aware of: the “substantial modification” clause.

The European Commission’s guidance is clear that a substantial modification is any change to software, firmware, or hardware that meaningfully alters the product’s original intended purpose, functionality, or security posture. If a change introduces new threat vectors or materially expands the attack surface, it’s almost certainly substantial.

Let’s look at a practical example to make this concrete:

• Not a Substantial Modification: You find a buffer overflow vulnerability in your smart camera’s firmware. You issue a patch that fixes the bug but adds no new features. This is just routine maintenance and does not drag your legacy product into CRA compliance.
• A Substantial Modification: You decide to update that same camera with a new cloud storage integration and AI-powered person detection. This fundamentally changes the product’s function and introduces new data processing risks and network connections. This is a substantial modification, and the product is now treated as “newly placed on the market,” which means it needs to be fully CRA compliant.

It’s absolutely essential to meticulously document every change made to a legacy product and run a formal impact assessment. This creates an auditable trail that proves why a change was or was not considered substantial, protecting you from accidentally falling into non-compliance.

How the CRA Interacts with Other EU Laws

Another common source of confusion is how the CRA fits in with other major EU regulations like the General Data Protection Regulation (GDPR) and the AI Act. The key is to see them as complementary layers, not competing rules.

The CRA is a horizontal regulation. Think of it as setting a foundational layer of cybersecurity for all products with digital elements. It then works in tandem with other laws to create a more complete regulatory picture.

• With GDPR: The CRA provides the technical “secure by design and by default” foundation for GDPR. For example, if your product is a health-tracking wearable that collects heart rate data (personal data), GDPR requires you to protect that data. The CRA mandates specific technical controls like encryption of data at rest and in transit, which directly fulfills a key GDPR principle.
• With the AI Act: If you’re building a product that’s also an AI system (like an AI-powered medical device), you have to meet the requirements of both. The AI Act will govern the safety and transparency of the AI model itself (e.g., ensuring it is not biased), while the CRA mandates the cybersecurity of the underlying digital product it runs on (e.g., protecting it from being tampered with).

Your conformity assessment has to be consolidated. This means your single EU Declaration of Conformity must list all applicable laws and attest that your product complies with every single one.

Support for Smaller Companies and SMEs

The European Commission’s guidance explicitly acknowledges that this compliance journey can be tough for small and medium-sized enterprises (SMEs). To help, the CRA includes several practical measures designed to lower the barrier to entry for smaller organisations.

One of the most useful concessions is allowing businesses to group similar products into families for conformity testing. For instance, if you produce a line of smart light bulbs that all share the same core firmware and connectivity module but just differ in shape or colour, you can likely assess them as a single product family. This dramatically cuts down on testing costs and administrative work.

The extended 36-month adaptation period and the future development of harmonised standards are also there to help. Once published, these standards will offer a “presumption of conformity,” giving SMEs a clear and straightforward checklist to follow to meet their legal obligations without having to interpret the law from scratch.

Regulus provides a streamlined software platform to help your team confidently navigate the Cyber Resilience Act. Our solution turns complex regulatory text into an actionable compliance plan, generating a tailored requirements matrix, technical file templates, and a step-by-step roadmap for 2025–2027. Gain clarity and reduce compliance costs by visiting https://goregulus.com.

La entrada CRA implementation guidance European Commission: Simple Steps to Compliance se publicó primero en Regulus.

Decoding the CRA Standardisation Request

Think of the Cyber Resilience Act (CRA) itself as a high-level goal. It tells you what you need to achieve—for example, that your product must be secure and resilient. But it doesn’t specify the exact technical details of how to get there. It won’t tell you precisely how to implement a secure update mechanism or what a “secure default configuration” looks like in practice.

This is where the standardisation request comes in. It’s the official job order from the European Commission to the technical experts who write the rulebooks for product safety in Europe:

• CEN (European Committee for Standardization)
• CENELEC (European Committee for Electrotechnical Standardization)
• ETSI (European Telecommunications Standards Institute)

These organisations are now tasked with turning the CRA’s high-level legal requirements into concrete, practical, and technical specifications. They are writing the “how-to” manuals.

The Power of Presumption of Conformity

The single biggest reason these standards matter is the “presumption of conformity.” It’s a powerful legal concept. It means that if you design and build your product following the relevant harmonised standards, market authorities will automatically presume your product complies with the CRA’s essential requirements.

This provides the clearest, most direct, and most defensible route to demonstrating compliance. It takes the guesswork out of the equation.

For instance, the CRA demands that manufacturers handle vulnerabilities effectively. Instead of leaving you to figure out what “effectively” means, a harmonised standard will likely lay out a specific process for vulnerability intake, triage, and patching, probably based on established best practices like ISO/IEC 29147. By following that standard, you get a ready-made methodology that is officially recognised across the EU.

A standardisation request is not just a polite suggestion; it’s a formal mandate. It triggers a structured process that bridges the gap between high-level law and the real-world engineering needed to build secure products.

This whole system is designed to make market access simpler. By sticking to a single set of harmonised standards, you avoid the nightmare of trying to meet different interpretations of the law in different EU countries. It creates one unified benchmark for security, giving you the confidence to build, document, and sell your product on the European market. A crucial part of this is getting your paperwork in order. You can get a head start by learning how to prepare your CRA technical documentation in our detailed guide.

The Key Players: CEN, CENELEC, and ETSI Explained

To get ready for the Cyber Resilience Act, you first need to understand the organisations writing the detailed rules. The European Commission has sent a formal CRA standardisation request to a trio of specialised bodies known as the European Standardisation Organisations, or ESOs.

Think of them as a team of expert architects, each with a distinct speciality, working together to build a secure foundation for Europe’s digital market. These three key players are CEN, CENELEC, and ETSI. Each brings a unique focus to the table, ensuring the resulting harmonised standards are both comprehensive and technically sound. Their collaboration is what turns the CRA’s legal principles into practical, engineering-focused guidelines.

CEN: The Generalist Architect

The European Committee for Standardization (CEN) is the architect for a huge range of non-electrical products and services. Its scope is incredibly broad, covering everything from children’s toys and medical devices to construction materials and mechanical engineering.

In the context of the CRA, CEN will concentrate on the cybersecurity aspects of products that fall outside the specific domains of its two counterparts.

Practical Example of CEN’s Scope:

• A manufacturer of smart locks for doors would look to CEN for standards on physical security combined with digital access control. CEN would handle the non-electrical aspects, like how the lock’s software interfaces with its mechanical parts securely.
• Connected gym equipment, like a smart treadmill, would also fall under CEN, which would define standards for the secure software that controls the machine’s functions and stores user data.

CENELEC: The Electrical Specialist

The European Committee for Electrotechnical Standardization (CENELEC) is the specialist for all things electrical and electronic. This organisation is responsible for creating standards for a massive array of products that use electricity, from everyday gadgets to complex industrial systems.

Practical Examples of CENELEC’s Scope:

• Smart Home Devices: Think of smart coffee makers, connected lighting systems, or intelligent thermostats. CENELEC will define the cybersecurity standards to protect these devices from being compromised.
• Industrial Control Systems (ICS): In factories and power plants, CENELEC’s standards will ensure the electrotechnical components of operational technology (OT) are secure against cyber threats.

For the CRA, CENELEC’s role is critical. Its work will directly shape the security requirements for a huge number of IoT products and connected hardware, making sure they are resilient by design.

ETSI: The Communications Expert

The European Telecommunications Standards Institute (ETSI) handles the communications side of technology. This includes everything related to information and communication technologies (ICT), like mobile networks, radio equipment, and the internet.

ETSI’s expertise is vital for the CRA because nearly all “products with digital elements” communicate in some way.

Practical Example of ETSI’s Scope:

• Wireless Security Protocols: When a connected car communicates with roadside infrastructure (V2X), ETSI standards define the secure communication protocols to prevent hijacking or data interception.
• IoT Network Interfaces: For a smart water meter sending data over a Low-Power Wide-Area Network (LPWAN), ETSI’s work ensures the radio interface is secure and the data transmission is encrypted.

ETSI develops the standards that ensure these communications are secure and reliable. For example, when your IoT device sends data to the cloud, ETSI’s standards will help define the protocols and security measures needed to protect that data in transit.

This collaborative structure is governed by Regulation (EU) No 1025/2012, which sets out how the ESOs receive mandates to support EU law. The process is remarkably efficient; research shows that one European Standard replaces 34 national standards, drastically reducing market fragmentation. This unified approach is a major benefit for manufacturers, as it cuts through red tape and simplifies market access across the entire EU.

You can check out our guide on how the CRA conformity assessment works to understand this process better.

The ESOs are central to putting EU legislation into practice. About 30% of all European Standards published by CEN and CENELEC come from specific requests by the European Commission. This highlights their role in creating actionable rules that support regulatory goals for the 34 countries in the European economic area. You can delve deeper into the support for standardisation activities to see the scale of this collaboration.

How The Standardisation Process Works In Practice

So, how does a dense legal text like the Cyber Resilience Act get translated into a set of technical standards that engineering teams can actually use? The process is surprisingly structured, and understanding it gives you a roadmap for when you can expect crucial guidance to land.

It all kicks off with a formal CRA standardisation request from the European Commission. Think of this as the starting gun. This document officially tasks the European Standardisation Organisations (ESOs) – CEN, CENELEC, and ETSI – with developing the specific standards needed to support the Act, complete with topics to cover and deadlines.

From Request To Committee

Once the ESOs accept the request, the real work begins. The task is handed over to specialised Technical Committees (TCs) or, in many cases, Joint Technical Committees (JTCs). These committees are the engine room of the whole operation, made up of industry experts, national delegates, and other stakeholders who bring hard-won, real-world experience to the table.

For instance, a Joint Technical Committee is the perfect vehicle for tackling topics that cut across different domains, like the cybersecurity of industrial machines, which involves both electrical (CENELEC) and non-electrical (CEN) expertise. These experts don’t start from scratch. Their first move is almost always to review existing international standards, like those from ISO/IEC, to see what can be adapted. This ensures that the new European standards are as globally aligned as possible.

We saw this exact process play out with the recent Data Act. The Commission issued Mandate M/614, which CEN and CENELEC officially accepted on July 7. This set in motion a commitment to deliver seven European standardisation deliverables—including four European Standards and three Technical Specifications—to support the Act’s application from September 12, 2025. You can read more about how the Data Act standardisation request is accelerating digital regulation.

Drafting And Public Consultation

The committee’s first major task is to hammer out a working draft. This initial version is debated, refined, and edited over many sessions, drawing on the collective knowledge of the group.

Crucially, this isn’t a closed-door affair. The process includes a vital stage known as the ‘public enquiry’ or public comment period. During this window, the draft standard is shared with national standards bodies and the public for feedback.

This is a critical opportunity for your company to have a voice. By engaging through your national standards body, you can provide feedback to ensure the final rules are practical and don’t impose an unworkable burden on your industry.

For a CRA-related standard on vulnerability reporting, for example, the draft would likely be scrutinised by security researchers, product managers, and software developers. Their input could be invaluable in fine-tuning the requirements to be both effective against threats and feasible to implement in a fast-paced development cycle.

The following infographic gives a great visual of how input from 34 national bodies is consolidated into a single, unified European Standard.

This highlights the core efficiency of the European model: creating one harmonised standard that replaces dozens of potentially conflicting national rules.

Final Approval And Publication

After the public enquiry closes, the technical committee gets back to work, reviewing every single comment and making revisions. This phase often involves some intense negotiation to strike a consensus that balances security, innovation, and commercial reality.

Once consensus is reached, the final draft goes to a formal vote. To pass, it needs approval from a weighted majority of the national standards bodies that make up CEN and CENELEC. After a successful vote, the document is published as an official European Standard (EN). Its reference is then published in the Official Journal of the European Union (OJEU), giving it legal force. This is the moment it becomes a “harmonised standard,” an officially recognised tool you can use to claim “presumption of conformity” with the law.

To help you anticipate these key milestones, the table below provides a simplified overview of the journey from a standardisation request to a published harmonised standard.

CRA Standardisation Timeline From Request to Harmonised Standard

A simplified overview of the key phases in the development of harmonised standards for the Cyber Resilience Act, helping teams anticipate key milestones.

As you can see, the path is methodical and designed to build consensus. While it can feel slow, each step is essential for creating standards that are both robust and practical for the market.

Predicting the Future CRA Harmonised Standards

While we’re all waiting for CEN, CENELEC, and ETSI to publish the final CRA standardisation request, we’re not exactly flying blind. By carefully analysing the CRA’s Annex I requirements and looking at well-established international security frameworks, we can make some highly educated predictions about what these new standards will contain. This gives your product security teams a powerful head start on compliance.

Think of it as a weather forecast for your regulatory roadmap. We can already see the major fronts moving in and can tell which areas will be most affected. This lets us prepare our defences long before the storm actually hits. The key thing to remember is that the standards bodies won’t be reinventing the wheel; they will build upon globally recognised best practices that already exist.

For manufacturers, this means you can start aligning your internal processes today. You don’t have to wait for the final text to begin building a security-first culture that maps directly to the CRA’s core principles.

The Secure Development Lifecycle Framework

One of the most predictable areas for standardisation is the Secure Development Lifecycle (SDLC). The CRA’s Annex I states that products must be “designed, developed and produced” to ensure an appropriate level of cybersecurity. A formal standard will turn this high-level principle into a concrete, auditable process.

It’s almost a given that this new standard will draw heavily from existing frameworks, particularly IEC 62443-4-1. This is already a mature set of process requirements for the secure development of industrial automation and control systems, making it a perfect foundation.

Practical Example:
Imagine a manufacturer of smart industrial sensors that currently has a fairly informal development process. To get ahead, they can start adopting practices from IEC 62443-4-1 right now. This could include:

• Establishing a formal threat modelling process for every new feature.
• Implementing static and dynamic code analysis tools in their CI/CD pipeline.
• Documenting all security testing and verification procedures.

By doing this now, they are effectively building the evidence needed to demonstrate compliance with the future harmonised standard. With the formal adoption of the CRA fast approaching, it’s wise to get familiar with the key CRA deadlines between 2025 and 2027 in our dedicated article.

Vulnerability Handling and Disclosure

Another key area laid out in Annex I is the manufacturer’s ongoing responsibility for vulnerability management. This covers everything from how you handle discovered vulnerabilities internally to how you disclose them responsibly to the public. The future standards are almost certain to be based on two key ISO/IEC standards.

• ISO/IEC 29147: This standard is all about vulnerability disclosure. It provides a clear framework for how to receive, assess, and communicate vulnerability information with researchers and users.
• ISO/IEC 30111: This one is the internal counterpart, focusing on vulnerability handling processes. It details the steps a manufacturer should take from the moment a flaw is discovered to when it’s fixed.

Practical Example:
A company making a consumer-facing smart camera can align with these standards by:

1. Publishing a Vulnerability Disclosure Policy (VDP) on their website, providing a clear email address (e.g., security@company.com) for researchers to submit findings.
2. Setting up an internal ticketing system (like Jira) to track reported vulnerabilities from intake, through triage and engineering, to patch release, mirroring the process flow in ISO/IEC 30111.
3. Coordinating with the researcher who found the bug to agree on a public disclosure date, following the guidelines in ISO/IEC 29147.

By aligning your internal vulnerability management programme with these two standards today, you are essentially pre-complying with the CRA. It ensures your processes for intake, triage, remediation, and disclosure will meet the expectations of market surveillance authorities.

Software Bill of Materials Requirements

The CRA makes it a legal requirement for manufacturers to create and maintain a Software Bill of Materials (SBOM) as part of their technical documentation. While the Act just says it must be in a “commonly used, machine-readable format,” the harmonised standards will nail down the specific details.

It’s a near certainty that the new standard will formalise the use of the two dominant industry formats:

1. SPDX (Software Package Data Exchange): An open standard for communicating SBOM information that excels at tracking licensing and provenance details. It’s already recognised as an international standard, ISO/IEC 5962.
2. CycloneDX: A lightweight, security-focused SBOM standard from OWASP, specifically designed for easy integration into automated security tools.

Practical Example:
A company producing a smart home hub can prepare by integrating SBOM generation directly into its build process. Using open-source tools, they could automatically generate an SBOM in both SPDX and CycloneDX formats for every software release. This file would list all open-source libraries, their versions, and their dependencies, creating the exact “ingredients list” the CRA demands.

By taking these predictive steps, you transform compliance from a last-minute, reactive scramble into a proactive, strategic part of your business. You build resilience directly into your products and processes, turning regulatory uncertainty into a tangible competitive advantage.

Your Action Plan for CRA Compliance

Turning the legal language of the Cyber Resilience Act into a concrete engineering plan can feel overwhelming, especially while the harmonised standards are still being written. But here’s the reality: waiting for CEN, CENELEC, and ETSI to publish the final rules isn’t a strategy. It’s a gamble. Getting ahead of the curve now is how you turn this regulatory challenge into a genuine competitive edge.

The whole point of using harmonised standards, once they’re available, is to gain the ‘presumption of conformity’. This is your simplest and most direct path to putting a CE mark on your product and selling it in the EU. If you decide to go your own way, the burden of proof is entirely on you to demonstrate that your alternative methods satisfy the CRA’s essential security requirements—a path filled with complexity and legal risk.

This section lays out a practical, step-by-step plan to get your compliance journey started today. It’s all about turning regulatory theory into a structured, manageable process.

Step 1: Map Your Processes Against Annex I

Your first, and most important, job is to treat the CRA’s Annex I as your roadmap. The essential requirements laid out there are the bedrock of the entire regulation. No matter what the final standards say, your products must meet these obligations.

Start by conducting a gap analysis. Go through each requirement in Annex I and map your current development, security, and post-market surveillance processes against it. This simple exercise will immediately show you where you’re strong and where you’re falling short.

The goal here isn’t to be perfect overnight. It’s to create an honest baseline. Document where your processes already align and, more importantly, where the gaps are. This documented analysis becomes the foundation of your compliance plan.

For example, Annex I demands that products are shipped with a secure default configuration. Your mapping exercise should prompt questions like:

• Do we have a documented process for defining what “secure by default” actually means for our products? (e.g., all unnecessary ports closed, default passwords banned).
• Is this configuration tested and verified before every release?
• How do we make sure this secure configuration isn’t compromised by future updates?

This kind of proactive mapping builds the internal evidence you’ll need to produce later.

Step 2: Start Organising Your Technical Documentation Now

Don’t wait for the harmonised standards to be finalised before you start building your technical documentation. The CRA already spells out the required structure, so you can build that framework today and use placeholders for the specific evidence you’ll add later.

Here’s a practical example. A smart lock manufacturer knows they need to demonstrate a solid vulnerability management process. Even without the final standard, they can start organising their evidence right now.

• Document What Exists: They can document their current system for receiving vulnerability reports, their triage methods, and their patching process.
• Create Placeholders: In their technical file, they can create a section titled “Vulnerability Handling (Annex I, Part 2)” and drop in their current process documents.
• Spot the Gaps: This immediately shows them what’s missing, like a formal Coordinated Vulnerability Disclosure (CVD) policy. Now they have a clear action item to work on.

By organising documentation early, you create a living file that evolves as the standards become clear. It’s far less painful than trying to generate years of evidence from scratch when the deadline is looming. You can learn more about how to obtain a CE certificate for the CRA and the critical role documentation plays in our detailed guide.

Manufacturer’s CRA Preparedness Checklist

To help you get started, here’s a checklist of concrete actions your team can take right now. This isn’t about boiling the ocean; it’s about taking the first practical steps on the road to compliance.

This checklist turns the abstract requirements of the CRA into a manageable project plan. By starting with these small, tangible wins, you build the momentum needed for the larger compliance effort.

Step 3: Engage With the Standardisation Process

The CRA standardisation request has kicked off a massive collaborative effort across Europe, and your organisation can—and should—have a voice in it. The standards are being hammered out in technical committees at CEN, CENELEC, and ETSI, all with input from national standards bodies.

Find your country’s national standards body (like UNE in Spain, BSI in the UK, or DIN in Germany) and get involved. When your experts participate, they can offer feedback on drafts, helping to ensure the final rules are practical and don’t create an impossible burden for your industry.

This whole framework is part of a well-established EU strategy under Regulation (EU) No 1025/2012. Historically, about 30% of standards are created specifically to support legislation, directly impacting businesses in the ES-region via 43 national members across 34 countries. The efficiency is undeniable: one European Standard replaces 34 separate national ones. This model is being actively funded, with the 2025 EISMEA call earmarking €7,851,000 for 27 topics. It reflects the progress we saw with the Data Act, where Mandate M/614 is set to produce seven deliverables by September 12, 2025—a clear blueprint for the CRA to follow. You can find more insights about European standardisation on cencenelec.eu.

As you build out your action plan, think about incorporating ideas from Actionable Compliance Training Best Practices to make sure your entire team is ready. Getting involved in the process doesn’t just let you influence the outcome; it gives you a valuable early look at where the requirements are heading. This proactive stance transforms compliance from a reactive burden into a strategic advantage.

Frequently Asked Questions

As the Cyber Resilience Act moves closer to full enforcement, manufacturers are understandably full of questions. The role of the CRA standardisation request and the work being done by CEN, CENELEC, and ETSI are at the centre of many of these conversations.

Here are some clear, straightforward answers to the questions we hear most often.

When Will The Final CRA Harmonised Standards Be Published?

There isn’t a single, fixed publication date, but the standardisation machine is definitely in motion. Typically, it takes about 18 to 24 months to develop harmonised standards from the moment a request is issued.

We expect to see drafts for the main horizontal standards popping up throughout 2025. The goal is to have the final, published versions ready by late 2026.

Given that the CRA becomes fully applicable in late 2027, this timeline is tight, but it has to be. Keep a close eye on updates from CEN, CENELEC, and ETSI. Even the early drafts will give you huge clues about where the final requirements are heading.

Is It Mandatory To Use Harmonised Standards?

No, you aren’t legally forced to use the harmonised standards. However, doing so gives you a massive advantage called the “presumption of conformity.”

Think of it as the official, pre-approved path to compliance. It’s the simplest and least risky way to prove your product meets the CRA’s rules.

If you decide to go your own way, the burden of proof is all on you. You’ll need to create a mountain of documentation to convince regulators that your custom solutions are just as good as what the standards require. For example, instead of following a harmonised standard for secure updates, you’d have to write a detailed technical justification explaining why your proprietary update mechanism provides an equivalent level of security, complete with risk assessments and independent test results. This path is far more work, more expensive, and carries a much higher legal risk if a market surveillance authority comes knocking.

How Can My Company Influence The New CRA Standards?

You absolutely can have a say in how these standards are written. The best way is to get involved with your national standardisation body (like UNE in Spain, DIN in Germany, or AFNOR in France).

These national bodies are the members of CEN and CENELEC. They send their experts to sit on the technical committees that actually write the standards.

By joining and participating, your company’s experts can give direct feedback on drafts. This is your chance to make sure the final rules are practical, technically sound, and don’t create impossible hurdles for your industry. For example, if a draft standard proposes a 24-hour patching deadline for critical vulnerabilities, a company representative on the committee could argue that a 72-hour window is more realistic for complex embedded systems, providing data to back up their case. It’s a direct line to shaping the regulations you’ll have to live by.

What Should We Do Before The Standards Are Available?

Sitting on your hands and waiting for the final standards to drop is not a winning strategy. Right now, your compliance work has to be based on the legal text of the CRA itself, especially the essential requirements in Annex I.

Start by documenting how you interpret those requirements and the specific security measures you’re putting in place. A great way to get your organisation ready is by looking at existing, solid frameworks. For example, a practical guide to ISMS Standards ISO 27001 can give you a proven blueprint for building an effective security posture.

This proactive work builds a strong compliance foundation. When the new standards are finally released, you can quickly map what you’ve already done to the official requirements, saving yourself a world of time and stress.

The Cyber Resilience Act introduces complex new obligations for manufacturers. Instead of navigating vague requirements with spreadsheets and expensive consultants, let Regulus provide clarity. Our platform automates applicability assessments, maps your specific obligations, and provides a step-by-step roadmap to get your products ready for the EU market. Gain confidence and ensure your products are compliant by visiting https://goregulus.com.

La entrada CRA standardisation request CEN CENELEC ETSI: A 2026 compliance guide se publicó primero en Regulus.