Under the Cyber Resilience Act (CRA), the powers of market surveillance authorities are getting a serious upgrade. They are being given a full toolkit to investigate, restrict, and penalise non-compliant digital products.
These new “digital watchdogs” can demand your technical documentation, order product recalls, and hit you with multi-million euro fines to enforce cybersecurity standards across the EU.
Understanding the New Digital Watchdogs
The Cyber Resilience Act isn’t just more paperwork. It kicks off a new era for digital product safety, enforced by powerful national regulators known as Market Surveillance Authorities (MSAs). These bodies are the engine room of the CRA’s enforcement strategy, responsible for making sure every product with digital elements sold in the EU is secure.
Think of an MSA as a new breed of digital safety inspector for the European Union. They now have the authority to proactively examine any product—from a smart thermostat to industrial control software—for potential security weaknesses, even if no incident has been reported. A practical example could be France’s ANSSI deciding to test the security of all connected baby monitors available on the French market to check for unauthorized access vulnerabilities.
The MSA’s Core Mandate
At its heart, an MSA’s mission is to shield the single market from insecure products. Their job is to check that manufacturers, importers, and distributors are meeting their obligations all the way through a product’s lifecycle.
This breaks down into three key activities:
- Verifying Compliance: Checking that products carry the correct CE marking and are backed by a complete and accurate EU Declaration of Conformity. For example, an MSA could purchase a popular smart lock from an online store and first check if the CE mark is present on the product and its packaging, and then request the Declaration of Conformity from the importer.
- Investigating Risks: Proactively testing products and demanding technical files to find vulnerabilities before they can be exploited. For instance, an authority could perform penetration testing on a new connected car’s infotainment system to see if it can be hacked to control critical functions.
- Enforcing Rules: Taking corrective actions against non-compliant products to get them off the market and protect consumers. A real-world scenario would be an MSA ordering a manufacturer to stop selling a line of smart TVs after discovering they transmit user data without encryption.
To truly grasp the scope of an MSA’s authority, you need to understand the principles of statutory interpretation, as these govern how their mandates are defined and ultimately put into practice.
An MSA’s power isn’t just reactive. They are empowered to conduct “sweeps” of specific product categories, such as IoT home devices or connected toys, to gauge the overall security level of the market and root out bad actors.
For instance, the Spanish National Cybersecurity Institute (INCIBE) could decide to investigate all smart plugs sold in Spain. They would have the power to request technical documentation, including risk assessments and vulnerability handling processes, from every single manufacturer.
If a manufacturer can’t produce this evidence, or if their product is found to be insecure, INCIBE can order an immediate sales ban. You can get more insight into what regulators expect by reading the European Commission’s CRA implementation guidance.
MSA Investigations: Information and Access Rights
Market Surveillance Authorities (MSAs) are armed with serious investigative powers to check for Cyber Resilience Act (CRA) compliance, and they aren’t just waiting for a problem to be reported. These authorities can proactively demand access to your company’s most sensitive technical data to make sure your products are secure from the ground up.
This proactive approach marks a fundamental shift. Instead of only reacting to incidents, MSAs are now empowered to run planned and unplanned audits to verify that your products conform to the regulation. This is a core part of the CRA market surveillance authorities powers, designed to catch security flaws before they can be widely exploited.
The Scope of Information Requests
When an MSA opens an investigation, its right to access information is incredibly broad. This is far from a simple box-ticking exercise; authorities have the power to dig deep into your product’s architecture and your company’s internal security processes.
They can demand a whole range of documents and data, including:
- Technical Documentation: Required under Annex VII of the CRA, this is the master file for your product’s compliance journey. It needs to contain everything from the product’s intended use and design to the results of your cybersecurity risk assessment.
- Software Bill of Materials (SBOM): An MSA will want to see a full inventory of all software components, covering everything from open-source libraries to commercial third-party code. This helps them assess your supply chain security and see how you handle vulnerabilities in your dependencies.
- Security Assessments and Test Reports: This includes solid proof from penetration tests, vulnerability scans, and secure code reviews. You must be able to show that you’ve actively looked for weaknesses in your product.
- Vulnerability Handling Processes: Authorities will carefully examine your internal procedures for finding, evaluating, and fixing vulnerabilities after your product is on the market.
In exceptional and fully justified cases, the CRA market surveillance authorities powers even extend to requesting access to your product’s source code. This is seen as a last resort, usually reserved for high-risk products when all other documentation isn’t enough to confirm compliance.
A Practical Example of an MSA Request
Imagine your company builds a popular line of connected thermostats sold across the EU. One morning, you get a formal information request from Spain’s National Cybersecurity Institute (INCIBE), the region’s designated MSA. The notice says they’re running a compliance check on smart home devices.
The request demands that within 10 business days, you provide the complete technical documentation for your main thermostat model. This includes the full SBOM, records of all security updates from the last 24 months, and a detailed report on how you fixed three specific Common Vulnerabilities and Exposures (CVEs) found in an open-source library used in your firmware.
This scenario shows you the level of detail and tight deadlines you could be up against. Failing to provide this information accurately and on time would be a direct breach of the CRA, leading to immediate corrective measures and possible fines.
Remote and Physical Product Access
Beyond asking for documents, the CRA market surveillance authorities powers give them the right to directly inspect and test your products. This can happen in a couple of ways.
First, an authority can carry out remote inspections. They might use network tools to check your product for open ports, weak encryption, or other security flaws that can be spotted from the outside. For instance, an MSA could use a tool like Shodan to scan for internet-connected devices from a specific manufacturer and test if they are using default, easily guessable passwords.
Second, they have the right to request or buy a product sample for physical evaluation. This lets them perform detailed laboratory testing, including reverse engineering and forensic analysis, to find hidden vulnerabilities that remote scanning would miss. If they uncover a serious risk, they can order you to take immediate action. A practical example is Germany’s BSI purchasing a connected doorbell, taking it to their lab, and using hardware-level attacks to extract its encryption keys.
These broad access rights are backed by real enforcement. You can discover more insights about the Cyber Resilience Act’s rollout on taylorwessing.com. This just goes to show how critical it is for manufacturers to have their documentation organised and ready for scrutiny at a moment’s notice.
The Consequences of Non-Compliance: Corrective Actions and Fines
Failing to meet your obligations under the Cyber Resilience Act isn’t a minor administrative slip-up. It’s an invitation for serious penalties that can directly threaten your market access and your bottom line. When a Market Surveillance Authority (MSA) identifies a non-compliant product, it has a powerful set of tools designed to remove that risk from the EU single market—swiftly and decisively.
Understanding these enforcement actions is central to grasping the full scope of CRA market surveillance authorities’ powers. The consequences aren’t just financial; they can stop your sales cold, inflict lasting damage on your brand, and force you into complex and costly logistical operations.
Product Withdrawal vs. Recall: A Critical Distinction
When an MSA finds a non-compliant product, its first priority is to contain the risk. The two main tools for this are product withdrawals and recalls, and it’s vital you understand the difference.
- Product Withdrawal: This is the first line of defence. An MSA can order you to stop the product from being made further available on the market. This action hits the supply chain, forcing distributors and retailers to pull your product from their physical and online shelves. For example, if a new model of a smart fridge is found to have a security flaw, the MSA can order all electronics stores and online retailers in the EU to immediately stop selling it.
- Product Recall: This is a much more drastic step, reserved for products that pose a significant cybersecurity risk and are already in the hands of end-users. A recall requires you to retrieve the product from customers—a far more complicated and expensive undertaking. For example, if a popular fitness tracker is found to have a vulnerability that leaks personal health data, the MSA could order the manufacturer to contact all registered users and arrange for the product to be returned for a fix or replacement.
Picture this: your company makes a popular IoT security camera. An MSA discovers a critical vulnerability that allows unauthorised remote access. They would first order a withdrawal to halt all new sales. If the vulnerability can’t be patched remotely and poses a severe risk, they would escalate to a recall, forcing you to contact every customer and arrange for their cameras to be returned.
Beyond these measures, MSAs can also mandate specific corrective actions. They could force you to issue a critical security patch by a strict deadline or require you to publish public disclosures about the vulnerability to ensure all users are aware of the risks.
The Staggering Financial Penalties
The CRA doesn’t just rely on corrective actions; it backs them up with some of the most significant financial penalties seen in product regulation, echoing the structure of the GDPR. The fines are deliberately designed to make non-compliance a far more expensive gamble than investing in security from the outset.
The regulation uses a tiered system for fines, based on the severity of the infringement. These penalties are calculated as either a maximum fixed sum or a percentage of your company’s total worldwide annual turnover from the preceding financial year—whichever is higher.
This approach gives MSAs the flexibility to penalise organisations proportionally. For a detailed breakdown of the violations that can trigger these sanctions, our guide on CRA penalties and enforcement actions offers more clarity.
CRA Enforcement Actions and Penalties at a Glance
The table below outlines the potential enforcement actions and the staggering financial penalties that an MSA can impose for non-compliance with the Cyber Resilience Act.
| Violation Type | Potential Corrective Action | Maximum Penalty (Whichever Is Higher) |
|---|---|---|
| Violating essential cybersecurity requirements or core reporting obligations | Product recall, withdrawal, or sales ban | €15 million or 2.5% of global turnover |
| Failing to meet other CRA obligations (e.g., documentation, vulnerability handling) | Corrective action orders, public warnings | €10 million or 2% of global turnover |
| Providing incorrect, incomplete, or misleading information | Information request orders, administrative fines | €5 million or 1% of global turnover |
As the table shows, the penalties are structured to ensure that failing to invest in cybersecurity is simply not a viable business strategy. A practical example for the highest tier could be a software vendor that fails to patch a known, actively exploited vulnerability in their enterprise software, leading to a major data breach for their customers. The MSA could impose a fine of up to 2.5% of their global turnover for this severe negligence.
These are not just theoretical numbers. The powers of market surveillance authorities are already being put to use. As you can see from recent legal analyses of EU authority actions, this case highlights the very real financial stakes of getting CRA compliance wrong.
Navigating Cross-Border Enforcement in the EU
If you sell a non-compliant digital product in one EU country, you’ve just created a cybersecurity risk for all 27 member states. The EU’s single market is only as strong as its weakest link, which is precisely why the Cyber Resilience Act (CRA) builds powerful tools for cross-border cooperation and uniform enforcement.
This framework is designed to dismantle national silos and stop non-compliant manufacturers from hopping between countries to find a safe haven. For any business with a pan-European strategy, understanding these cooperative CRA market surveillance authorities powers is essential. It proves that compliance must be solid across the entire EU, not just in one or two key markets.
The Principle of Mutual Assistance
At the heart of the CRA's cross-border muscle is the principle of mutual assistance. This is a legal mechanism that allows a Market Surveillance Authority (MSA) in one country to formally request that an MSA in another country take action. It ensures enforcement can follow a non-compliant product, no matter where the manufacturer is based or where the product was first sold.
Think of it as a law enforcement pact for product security. If a product poses a risk anywhere in the EU, authorities can work together to pull it from the market everywhere.
An MSA can ask its counterpart to run inspections, demand your technical documentation, or even impose corrective measures like a product withdrawal on its behalf. This closes the loophole where a manufacturer might ignore an order from an authority in a country where it has no office or staff.
For example, imagine a software company in Ireland sells a new project management tool across the EU. If Germany’s MSA (the BSI) finds a critical vulnerability, its power doesn't stop at the German border. It can formally ask Ireland's MSA to investigate the company directly and, if needed, enforce a sales ban that applies across the entire market.
Intelligence Sharing and Coordinated Actions
For mutual assistance to work in practice, MSAs need to share intelligence. The CRA leans on established information-sharing networks to make sure an alert raised in one country is immediately visible to all others, triggering swift, coordinated responses.
The key platforms and groups making this happen include:
- EU Safety Gate (formerly RAPEX): A rapid alert system for dangerous non-food products. An alert about a non-compliant smart thermostat or a vulnerable software component gets circulated to all national authorities almost instantly. A practical example: if the Dutch MSA finds that a popular brand of connected light bulbs can be easily hijacked to join a botnet, they would issue a Safety Gate alert, and within hours, authorities in Poland, Italy, and Sweden could begin their own investigations or order retailers to stop sales.
- ADCO Groups (Administrative Cooperation Groups): These are expert groups where MSAs coordinate their market surveillance work for specific laws, including the CRA. They plan joint inspection projects and work to apply the rules consistently. For instance, the CRA ADCO might organize a "joint action" where multiple MSAs simultaneously test the security of mobile banking apps offered in their respective countries.
The data proves how cross-border cooperation multiplies the reach of CRA market surveillance authorities powers. For a closer look at the legal text, you can explore the European Cyber Resilience Act's legal text.
This integrated enforcement model sends a clear message: geography offers no protection from scrutiny. A flaw found by one authority quickly becomes a problem for you across the entire European Union.
Preparing Your Defence Against Enforcement
Knowing about MSA powers is one thing, but actively preparing for scrutiny is how you protect your business and maintain market access. A strong defensive posture isn't about scrambling to react when an inspector calls; it's about making readiness a part of your daily operations.
The best approach turns these complex regulatory duties into a manageable, repeatable plan. A solid defence is a continuous cycle built on three core activities: comprehensive documentation, vigilant monitoring, and a rapid response capability. Think of it as having your evidence organised and your team ready to act long before you're ever questioned.
This process flow shows how these core activities fit together in a strong CRA defensive strategy.
As the visual shows, this isn't a one-off project. It's a cycle that ensures you're always prepared for an inspection from market surveillance authorities.
Step 1: Establish Watertight Technical Documentation
Your technical documentation, as required by Annex VII of the CRA, is the absolute cornerstone of your defence. It's the first thing an MSA will demand to verify your product’s compliance. If that file is incomplete, disorganised, or out of date, your defence can crumble before it even begins.
A robust technical file isn't just a document dump. It must clearly contain:
- A Detailed Product Description: This should cover the product’s intended purpose, its complete architecture, and all software and firmware versions.
- The Cybersecurity Risk Assessment: This is your proof that you have methodically identified, evaluated, and mitigated potential security risks.
- A Complete Software Bill of Materials (SBOM): A full inventory of every single software component, from your own code to open-source libraries and third-party dependencies.
- Vulnerability Handling Processes: Clear, documented procedures that explain exactly how you discover, assess, and fix vulnerabilities after the product is on the market.
Using a dedicated compliance platform can make this far more manageable. For instance, a platform can help you generate a tailored requirements matrix and provide ready-to-use templates for Annex VII. This helps you systematically structure all the necessary evidence into an audit-ready CRA compliance evidence pack that you can present to an MSA on demand.
Step 2: Implement a Robust Post-Market Surveillance Process
Your duties don't stop once a product ships. The CRA mandates a continuous post-market surveillance process to monitor for new and emerging vulnerabilities. A weak or non-existent surveillance process is a huge red flag for MSAs, signalling that you aren't taking your ongoing security obligations seriously.
A practical workflow here should include:
- Systematic Monitoring: Actively and continuously scan vulnerability databases (like the NVD), security feeds, and other intelligence sources for threats that could affect your product’s components. For example, if your product uses the OpenSSL library, your process should include daily checks for any new vulnerabilities reported for that library.
- Triage and Assessment: When a potential vulnerability is identified, you need a process to promptly assess its severity (e.g., using CVSS scores) and actual impact on your product.
- Clear Reporting Channels: Define an internal process for escalating significant vulnerabilities to the right teams for immediate remediation.
- Coordinated Disclosure: Establish a clear workflow for handling the mandatory 24-hour reporting of actively exploited vulnerabilities to ENISA and the relevant national CSIRT.
Step 3: Define Your Response and Disclosure Workflow
When an MSA launches an investigation or a critical vulnerability is discovered, a chaotic, ad-hoc response can be just as damaging as the issue itself. A predefined workflow ensures you can respond with confidence and control, not panic.
This means assembling a dedicated response team well in advance, with representatives from legal, engineering, and compliance. Everyone should know their role. A practical example of a role would be the 'Legal Liaison', who is the sole point of contact for communicating with the MSA to avoid conflicting statements from different parts of the company.
It can also be useful to understand the legal mechanics for challenging an MSA's claims early in the process. For example, knowing the principles behind mastering the motion to dismiss can provide a solid framework for contesting unfounded allegations from a legal standpoint.
By turning these three defensive pillars into routine business operations, you transform CRA compliance from a daunting regulatory burden into a structured, manageable process that safeguards your access to the entire EU market.
Use this checklist to assess your organisation's readiness for an MSA inspection and overall CRA compliance. It's a simple way to see where you stand and what gaps need closing.
Your CRA Compliance Readiness Checklist
| Compliance Area | Key Action Item | Status (Not Started / In Progress / Complete) |
|---|---|---|
| Technical Documentation | Is your Annex VII technical file complete, up-to-date, and audit-ready? | |
| Risk Assessment | Have you conducted and documented a thorough cybersecurity risk assessment? | |
| SBOM | Do you maintain a complete and accurate SBOM for every product version? | |
| Post-Market Surveillance | Do you have a documented process for monitoring new vulnerabilities? | |
| Vulnerability Handling | Is there a clear internal process for triaging and remediating vulnerabilities? | |
| 24-Hour Reporting | Is your team prepared to report actively exploited vulnerabilities to ENISA within 24 hours? | |
| Response Team | Have you formally designated a response team with clear roles (legal, tech, compliance)? | |
| Disclosure Workflow | Is your process for disclosing vulnerabilities to customers and authorities defined and tested? |
Once you have this foundation in place, you're not just compliant—you're resilient. You've built a system that not only meets regulatory demands but also makes your products fundamentally more secure.
How to Respond to an MSA Information Request
Receiving an official notice from a Market Surveillance Authority (MSA) can be unsettling, but your response sets the tone for the entire interaction. An information request isn’t an accusation; it’s a standard procedure under the CRA market surveillance authorities powers to verify compliance. A calm, organised and professional reply can make all the difference.
Think of it as an open-book exam where you’ve already done the homework. With your documentation in order and a clear plan, you can navigate the process confidently, demonstrating cooperation while protecting your organisation’s interests.
Your Step-by-Step Response Playbook
When an information request lands, the last thing you want is a panicked scramble. Instead, follow a structured process to ensure your response is timely, accurate and complete. A methodical approach shows the MSA that you are organised and take your compliance duties seriously.
-
Assemble Your Response Team: Immediately bring together your designated point people. This team should include representatives from legal, engineering (product security), and compliance. Each person has a critical role—legal to review the request’s scope, engineering to gather the technical data, and compliance to oversee the entire submission.
-
Verify the Request's Legitimacy: Before you do anything else, confirm the request is from a genuine MSA and falls within its legal mandate. For example, check that the email comes from an official government domain (like
@bsi.bund.defor Germany's BSI) and cross-reference the contact person on the MSA's official website. This crucial first step stops you from accidentally sharing sensitive information with unauthorised parties. -
Analyse and Clarify the Scope: Read the request carefully with your team. Pinpoint exactly which documents, data, and time periods are required. If any part of the request is ambiguous, it is perfectly acceptable—and often wise—to contact the MSA for clarification. A practical example: if the request asks for "all security test reports" but your product is five years old, you could ask, "Can you clarify if you require reports for all historical versions or just for versions released in the last 24 months?" A precise understanding prevents you from providing either too little or too much information.
-
Gather the Required Documents: This is where your proactive documentation efforts pay off. Pull the specific evidence from your technical file, such as the Software Bill of Materials (SBOM), risk assessments, vulnerability handling records and test reports. Ensure every piece of evidence directly addresses the MSA's query.
A well-organised company can pull a complete evidence pack in hours. A disorganised one might spend weeks searching through disconnected files and emails. That difference in response time and quality sends a powerful message to the authority about your company’s maturity.
A Tale of Two Responses
Consider two companies that both make smart lighting systems. Company A receives an MSA request and, using its compliance platform, generates a complete, audit-ready report with all requested documentation in under two days. Their response is prompt, professional and precise.
Company B, however, relies on spreadsheets and shared drives. The request triggers a frantic search for documents. Their final submission is late, incomplete and contains outdated information, immediately raising red flags for the MSA and inviting deeper scrutiny. For more details on what authorities expect, you can learn about the specific CRA reporting obligations under Article 14.
Answering Your Top Questions About CRA Enforcement
When it comes to the Cyber Resilience Act, the enforcement powers of national regulators are a major point of concern for many manufacturers. Let's tackle some of the most common questions we hear about what CRA market surveillance authorities can actually do.
Can an MSA Really Demand Access to Our Source Code?
Yes, they can. However, this is a power of last resort, not a routine check.
Article 41 of the CRA gives a Market Surveillance Authority (MSA) the right to request your source code, but only when it is considered strictly necessary to confirm whether a product is compliant. This is typically reserved for high-risk products where a critical vulnerability is suspected and reviewing the technical documentation isn't enough to get a clear picture.
Imagine a widely-used industrial controller is found to have a flaw that could take down critical infrastructure. If standard inspection methods fail to clarify the risk, an MSA might then demand to see the source code. This underscores how vital it is to maintain well-organised and documented codebases, just in case.
What If We Disagree with a Recall Decision?
You have the right to challenge it. Before an MSA can force a restrictive measure like a product recall, you are entitled to be heard and to present your own evidence to make your case.
If the authority still moves forward with the decision, both the CRA and national laws give you a path to challenge it in court. Be warned, though: this route is almost always expensive and time-consuming.
A practical example might be a smart home hub manufacturer that receives a recall order. They could challenge it by providing independent test reports showing that the vulnerability in question has already been patched via an over-the-air update for 99.8% of active devices, arguing that a full recall is disproportionate to the residual risk. The takeaway is clear: proactive compliance and rock-solid documentation are your best, and most cost-effective, lines of defence.
Do These Powers Only Apply to Hardware?
No. The CRA’s scope is extremely broad and covers all "products with digital elements." This is a crucial point to understand. It includes:
- Hardware with embedded software, like IoT devices and smart appliances. (e.g., a connected coffee machine)
- Standalone software, including mobile apps, desktop programs, and operating systems. (e.g., a photo editing software or a password manager)
- Firmware that controls how a piece of hardware operates. (e.g., the software running on a network router)
Whether you develop software, manufacture devices, or import them, if your product has a digital component and you sell it in the EU, you are subject to these enforcement powers.
Are Importers Held to the Same Standard?
While the manufacturer holds primary responsibility for a product’s conformity, importers and distributors have their own distinct and critical obligations. They are required to verify that the manufacturer has done their job, make sure the product carries the CE marking, and cooperate fully with MSAs during any investigation.
An MSA can take action against any economic operator in the supply chain. If an importer brings a non-compliant product into the EU market, they can be held directly accountable and face fines or orders to withdraw the product. For instance, if a European importer distributes a non-compliant drone from a non-EU manufacturer, the MSA can fine the importer and order them to manage the product withdrawal from all retailers, even though they didn't create the product.
Navigating CRA compliance can be complex, but Regulus provides the clarity and tools you need. Our platform helps you assess applicability, generate tailored requirement matrices, and build audit-ready technical documentation to confidently meet your obligations. Prepare for the CRA with Regulus.
