The Cyber Resilience Act (Regulation (EU) 2024/2847) — a working guide

This page is a working overview of the EU Cyber Resilience Act — what the Regulation is, whom and what it covers, and what it requires in practice. It runs in fifteen short sections: orientation first (what it is, the key dates, scope, roles, open source), then the substance (classification, obligations, support periods, modifications, remote data processing, reporting), and finally how the CRA sits with neighbouring law, what non-compliance costs, what to do now, and the questions clients ask most. The navigation at the top jumps straight to any section.

Every section runs in the same order: the plain English meaning first, then a worked example, then the legal detail with the article references. Where the law reliably catches people out, there is a third block.

Citations appear inline like this: Art. 13(2) for the Regulation, Guidance §4.3 for the Commission's guidance of 27 July 2026 (C(2026) 5252, Annex).

01 / Orientation

WHATIT IS

The Regulation lays down horizontal cybersecurity requirements for products with digital elements placed on the EU market, covering both the moment of placing on the market and the product lifecycle Guidance §1.1, point 1. It is built on the New Legislative Framework, so the concepts of placing on the market, making available, substantial modification, conformity assessment modules and CE marking carry the meaning they have across EU product law, as set out in the Commission's Blue Guide.

Market surveillance sits with national authorities under Regulation (EU) 2019/1020 Art. 52. In Germany that role falls to the BSI: the designation has been notified to the Commission, and the implementing statute is currently before the Bundestag. The Commission and ENISA support application Guidance §1.1, point 3.

What the 27 July 2026 guidance adds

Nothing in the obligations or the dates changed. The guidance answers the questions the Commission was asked most, with particular attention to microenterprises and SMEs, as required by Art. 26. The practically significant clarifications are on standalone software, free and open-source software, substantial modification, support periods, remote data processing, and the point at which a manufacturer is deemed to have become aware of a vulnerability.

02 / The clock

KEYDATES

03 / Does it apply

SCOPE

A product with digital elements is a software or hardware product together with its remote data processing solutions, including software or hardware components placed on the market separately Art. 3(1). It falls in scope where its intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network Art. 2(1).

The data connection test

Scope is anchored in the capacity to exchange digital information, not in the presence of electronics. Switching an output on and off is not a data connection unless those states are deliberately encoded as information by a sender and can be decoded as information by a receiver. Where signals only trigger or power a function, there is no data connection and the product is outside Art. 2(1) Guidance §2.5.

Standalone software: when is it placed on the market

Software is not subject to physical production limits, so the guidance treats the manufacturer as having placed multiple copies of the same product on the market at the same moment: when the manufacturing phase is complete and the software is first supplied for distribution or use in the course of a commercial activity Art. 3(21)–(22) Guidance §2.1, points 13–14. Later downloads of that version are making available, not new placings.

Two consequences are easy to miss. Variants that differ in components, configuration or enabled functionality, such as builds for different operating systems or bundles with different feature sets, are not copies of the same product. They are distinct products Guidance §2.1, point 14. And iterations that qualify as substantial modifications are newly placed on the market, which resets the analysis Guidance §4.4, point 116.

Software you run versus software you reach

For software to be a product with digital elements, it must be supplied to the user and executed on, or as part of, an electronic information system on the user's side Guidance §2.2, point 20.

Source code

Software means the part of an electronic information system consisting of computer code Art. 3(4), and that covers machine code and source code alike. Whether a given supply amounts to placing on the market is a separate question. Publishing free and open-source code in a public repository, sharing unfinished code for testing or review, and sample code in tutorials are generally not placings Guidance §2.3, point 23. Licensing source code to a customer as a product is Guidance example 7. Unfinished software such as alpha or beta versions may be made available, but only for the limited period required for testing and with a visible indication that it does not yet comply with this Regulation Art. 4(3) Recital 37.

Hardware plus software

Where a hardware product is designed to work with specific software from the same manufacturer in order to perform its functions, the two together constitute one product, even if the software arrives through a different channel later Guidance §2.4. A network printer and its drivers are one product. A fitness wearable and the app needed to display and configure it are one product.

Spare parts and legacy designs

Spare parts intended to replace identical components, manufactured to the same specifications, are excluded Art. 2(6). The guidance narrows this: the repair or maintenance purpose must be apparent from the supply context, for example by identifying the product or product family in the order, or by supplying through after-sales channels. Technical capability to serve as a replacement is not enough Guidance §4.2, point 97. Identity is judged on functional role and security-relevant characteristics, so a replacement with a different cryptographic implementation or secure boot mechanism is not identical and becomes a product in its own right.

Products designed before the CRA applies but placed on the market after 11 December 2027 do not need to be redesigned. The manufacturer runs a current risk assessment under Art. 13(2) and demonstrates that existing measures address the identified risks. Historical design and test documentation does not have to be recreated. Conformity assessment, the EU declaration of conformity and CE marking still apply Guidance §2.7.

Out of scope

Sector regimes take precedence for medical devices and in vitro diagnostics Art. 2(2)(a)–(b), vehicles covered by Regulation (EU) 2019/2144 Art. 2(2)(c), civil aviation products certified under Regulation (EU) 2018/1139 Art. 2(3), and marine equipment Art. 2(4). Most L-category vehicles under Regulation (EU) No 168/2013 were excluded separately, by delegated act — see section 12 for the carve-out that matters. Products developed exclusively for national security or defence purposes, or specifically designed to process classified information, are also excluded Art. 2(7). Non-commercial supply is outside the concept of placing on the market altogether.

04 / Roles

WHOIS WHO

05 / Open source

FREE ANDOPEN SOURCE

FOSS under the CRA has two cumulative conditions: a licence granting the full set of rights to access, use, modify and redistribute freely, and source code that is openly shared, meaning publicly available rather than provided to paying customers or a restricted group Art. 3(48) Guidance §3, points 44–46.

The two questions

1. Is the project under your responsibility?Responsibility lies with those who publish it and exercise primary control over development, releases and distribution decisions. Contributors are not caught, and commit access alone does not create responsibility Guidance §3.1.
2. Do you supply it in the course of a commercial activity?If yes, it is placed on the market and you are its manufacturer. If no, and you are a legal person providing sustained support to a project intended for commercial activities, you are its steward. If no and you are a natural person, the CRA does not apply Guidance §3.2.

What counts as monetisation

Steward obligations scale with the support given

All stewards need a cybersecurity policy and must cooperate with market surveillance authorities Art. 24(1)–(2). Beyond that, the reporting duties of Art. 14 apply according to what the steward actually does Art. 24(3): non-technical support such as branding, governance or events brings no reporting duty, though the steward should pass information to maintainers; hosting the underlying IT infrastructure brings severe incident reporting for that infrastructure; contributing engineering resources brings reporting of actively exploited vulnerabilities Guidance §3.3.1, points 80–82.

06 / Classification

HOWYOU PROVE IT

The technical descriptions of the important and critical categories are set out in Commission Implementing Regulation (EU) 2025/2392. FOSS that qualifies as an important product of class I or II and is placed on the market may use the default internal control procedure — on one condition: the technical documentation must be made available to the public when the product is placed on the market Art. 32(5).

Core functionality

A product may have only one core functionality for classification purposes, and it must be identified in the technical documentation Guidance §6.1, point 144. Additional functions do not change the classification. Neither does integrating an important or critical product as a component: a smartphone that runs an operating system does not thereby have the core functionality of an operating system Art. 7(1) Guidance example 58.

Where a product substantially exceeds or falls substantially short of a category, it is outside it. SOAR software generally exceeds SIEM because incident response is core to its capabilities. A log collection and visualisation tool generally falls short of SIEM because it does not correlate data or produce actionable security insights Guidance examples 59 and 60. The assessment is objective and technical. Marketing language that does not reflect the actual characteristics does not control it, and misrepresenting core functionality to escape a stricter regime is not available Guidance §6.1, point 143.

Harmonised standards and presumption of conformity

Applying a harmonised standard whose reference has been published in the Official Journal gives a presumption of conformity for the essential requirements the standard covers Art. 27(1). The same applies to common specifications Art. 27(5) and to certificates under a European cybersecurity certification scheme where specified by delegated act Art. 27(8)–(9).

Two limits matter in practice. The presumption reaches only as far as the standard reaches, so ancillary functionality outside the standard's scope carries no presumption and the manufacturer must document the additional measures it took Guidance §6.3. And the standards are not there yet: work under standardisation request M/606 is ongoing and, until references are cited in the Official Journal, conformity has to be demonstrated directly against Annex I.

Support for smaller manufacturers

Microenterprises and small enterprises may provide all elements of the Annex VII technical documentation in a simplified format, which the Commission is to specify by implementing act Art. 33(5). Member States are directed to organise awareness-raising and training, run dedicated communication channels for advice, and support testing and conformity assessment activities Art. 33(1), and may establish cyber resilience regulatory sandboxes: controlled environments for testing innovative products against the Regulation before placing them on the market, with access for start-ups expressly facilitated Art. 33(2).

07 / Obligations

WHAT YOUMUST DO

Annex I, Part I: product requirements

The chapeau requires design, development and production ensuring an appropriate level of cybersecurity based on the risks. The specific requirements apply on the basis of the risk assessment, so not all of them apply to every product:

• Made available without known exploitable vulnerabilities
• Secure by default configuration, with the ability to reset to that state
• Vulnerabilities addressable through security updates, including automatic updates with an opt-out where applicable
• Protection from unauthorised access through appropriate control mechanisms, and reporting of possible unauthorised access
• Confidentiality of data at rest and in transit, using state-of-the-art encryption where relevant
• Integrity of data, commands, configuration and program, with detection of unauthorised modification
• Data minimisation: only data adequate, relevant and limited to what is necessary
• Availability of essential and basic functions, including resilience against denial of service
• Minimising the product's own negative effect on the availability of other devices and networks
• Limiting attack surfaces, including external interfaces
• Reducing the impact of incidents through exploitation mitigation techniques
• Recording and monitoring of security-relevant internal activity, with an opt-out
• Secure and easy permanent deletion of all data and settings, and secure transfer where applicable

The chapeau requirement is a catch-all. Where the other requirements already treat every identified risk, it is satisfied. Where the risk assessment surfaces risks they do not cover, further product-level measures are needed Guidance §7.2, point 166.

Annex I, Part II: vulnerability handling

• Identify and document vulnerabilities and components, including an SBOM Art. 3(39) in a commonly used machine-readable format covering at least the top-level dependencies
• Address and remediate vulnerabilities without delay, providing security updates separately from functionality updates where technically feasible
• Apply effective and regular tests and reviews
• Publicly disclose information about fixed vulnerabilities once an update is available
• Maintain and enforce a coordinated vulnerability disclosure policy
• Facilitate information sharing about potential vulnerabilities, including a contact address
• Provide mechanisms to distribute updates securely, with automatic updates and user notification where applicable
• Disseminate patches without delay and, unless otherwise agreed for tailor-made products, free of charge with advisory messages

"Regular tests" does not mean repeating an unchanged campaign at fixed intervals. It means regularly reviewing whether new threats or newly discovered vulnerabilities require the test set to change, and executing accordingly. Where the review finds nothing new, no additional tests need to be devised Guidance §9.2.3.

Risk assessment and due diligence: two separate duties

Two practical reliefs. You may restrict the intended purpose, for instance to trusted environments, and inform users accordingly, provided the restriction is real and documented Guidance example 66. And where variants share architecture, security-relevant design, intended purpose and risk profile, one risk assessment, one set of technical documentation, one conformity assessment and one declaration of conformity can cover the family, as long as the declaration identifies the variants Guidance §7.4.

Paperwork that has to exist

• Technical documentation, drawn up before placing on the market and kept up to date Art. 31, content per Annex VII
• EU declaration of conformity Art. 28, content per Annex V
• CE marking Art. 30
• Information and instructions to users, including the support period end date Art. 13(18)–(19), content per Annex II
• A single point of contact for vulnerability reports, and a coordinated vulnerability disclosure policy

Who owns what

CRA programmes stall on ownership rather than on interpretation. The evidence below is what an authority, a customer's procurement team or an acquirer will ask to see. The third column is the allocation that works in most organisations, and the point of naming it is that no single function can produce this file alone.

08 / Support period

HOW LONGYOU OWE IT

The support period is the period during which the manufacturer must ensure that vulnerabilities in the product are handled effectively Art. 3(20). It reflects the expected use time and is set against the criteria in Art. 13(8): reasonable user expectations, the nature of the product including its intended purpose, and relevant Union law on product lifetimes. Additional criteria include support periods offered by comparable products, availability of the operating environment, the support periods of third-party components providing core functions, and guidance from the CRA administrative cooperation group.

It must be at least five years, unless the product is expected to be in use for less, in which case it matches the expected use time. Products reasonably expected to be in use for longer than five years should have longer support periods. Five years is a safeguard, not a default Guidance §5, point 126.

The end date, at least month and year, must be stated at the time of purchase, and where technically feasible the product must notify users when the period expires Art. 13(19).

"Additional costs" is read practically. It does not cover the ordinary effort of applying updates: personnel time, routine testing, configuration adjustments, or upgrading underlying dependencies to deal with end-of-life components. It does cover mandatory new hardware, infrastructure replacement, or fundamental changes to the operating environment Guidance §5, point 130. Where support for earlier versions is discontinued, users who have not upgraded should be informed if that is technically feasible.

09 / Change control

SUBSTANTIALMODIFICATION

A substantial modification is a change after placing on the market that affects compliance with the essential requirements in Annex I Part I, or that changes the intended purpose for which the product was assessed Art. 3(30). A product is substantially modified where a change alters the level of cybersecurity risk and that altered or additional risk was not considered in the manufacturer's risk assessment Recital 39.

Four questions for a software update

The guidance offers a non-exhaustive test. Does the update Guidance §4.3, point 110:

1. Introduce new threat vectors, such as additional interfaces, communication channels, execution environments or external dependencies?
2. Enable new attack scenarios?
3. Change the likelihood of scenarios already identified, by lowering the effort to exploit them, increasing exposure to untrusted actors, or weakening safeguards?
4. Change their potential impact, including the scope of affected data or functions, the severity of consequences, or the ability to detect, contain or recover?

Four times no, with the assumptions and mitigations in the risk assessment still valid, points away from a substantial modification.

What follows

A substantially modified product made available on the market is a new product, and making it available is a new placing on the market. This holds whether the original manufacturer or someone else made the change Guidance §4.4, point 116.

Proportionality applies to the consequences. Where the modification does not negatively affect the cybersecurity of the product as a whole, the modifier's duties under Arts. 13 and 14 are limited to the modified part, and the original manufacturer's duties continue for the rest Art. 22. Where it does affect the product as a whole, the modifier takes on the full set for the whole product. The original manufacturer may reuse existing documentation and tests for unaffected aspects, and a notified body should focus on the modified parts Guidance §4.4.2.

Legacy products are covered too: substantially modifying a product placed on the market before 11 December 2027, then placing it on the market, makes you its manufacturer Art. 69(2). But that does not by itself require bringing the entire legacy product into full compliance, unless the modification affects the cybersecurity of the product as a whole.

Refurbishment, maintenance and repair do not by themselves amount to substantial modification. Replacing a defective part with a better-performing one is not a substantial modification unless it affects compliance with the essential requirements or changes the intended purpose covered by the risk assessment Recital 42 Guidance §4.1. A major change made by a third-party cloud provider is not a substantial modification of your product either, since it is outside your responsibility, but it should trigger a review of your risk assessment Guidance §8.2, point 208.

10 / Back end

REMOTE DATAPROCESSING

Remote data processing means data processing at a distance for which the software is designed and developed by the manufacturer, or under its responsibility, and the absence of which would prevent the product from performing one of its functions Art. 3(2). Only the software elements are captured, not the underlying hardware Guidance §8, point 180.

Three questions

1. Is any part of the processing at a distance?Typically outside the user's environment. On-premises servers of the manufacturer and private cloud qualify just as much as public cloud, and edge processing close to the device counts. If no, it is not remote data processing, though relevant risks still enter the risk assessment.
2. Would its absence prevent the product from performing one of its functions?Not limited to core functionality or intended purpose. Sending commands, synchronising files, onboarding, configuration, automated update distribution and identity and access management all qualify. Telemetry analysed purely for statistics or future product development does not. If no, treat it as an external dependency and mitigate through product-level controls.
3. Was the software designed and developed by you or under your responsibility?Tailor-made for you, built by or on behalf of you to your designs and specifications. Licensing an existing product a provider offers to its customers generally is not. If no, treat it as a third-party component: assess the integration risks, mitigate at product level, and exercise due diligence.

Three yes answers means the software is a remote data processing solution, part of the product, and inside the risk assessment, the essential requirements, the conformity assessment and the lifecycle duties. Who operates it is not decisive: design and development are what count Guidance §8.1.3, point 196.

Where you rely on third-party remote services, evidence you can reuse in your own assessment includes compliance evidence under Commission Implementing Regulation (EU) 2024/2690 for NIS2, evidence under DORA, statements or certificates under a European cybersecurity certification scheme, and ISO/IEC 27001:2022 or ISO/IEC 27017:2015 conformity Guidance §8.2, point 207. Security guarantees in service level agreements, including on vulnerability handling and notification of changes, are the practical instrument.

11 / Live from 11 Sep 2026

REPORTING

Manufacturers must notify actively exploited vulnerabilities Art. 3(42) and severe incidents having an impact on the security of the product Art. 3(44) Art. 14(5), simultaneously to the coordinating CSIRT and ENISA Art. 14(1) and (3). Applies from 11 September 2026, to all in-scope products including those placed on the market earlier, and it continues after the support period ends Art. 69(3).

When does the clock start

Awareness arises when, after an immediate initial assessment of a suspicious event or a third-party report, you have a reasonable degree of certainty that a vulnerability in your product is being actively exploited, or that a severe incident has occurred and compromised your product's security Guidance §9.1, point 213. The guidance deliberately aligns this with the NIS2 implementing regulation and with the EDPB's Guidelines 9/2022 on personal data breach notification, so a single internal triage process can serve all three regimes. The emphasis is on prompt initial assessment, not on delaying certainty.

Informing users

After becoming aware, manufacturers must inform impacted users and, where appropriate, all users Art. 14(8). This is risk-based. It does not mean indiscriminate publication, and for products used in sensitive or essential environments, publishing technical detail early can itself increase risk. Broader disclosure becomes appropriate once the vulnerability has been addressed, and Annex I Part II requires public disclosure of fixed vulnerabilities once a security update is available Guidance §9.1, points 220–221. Where a manufacturer fails to inform users in time, the CSIRT that received the notification may do so.

Upstream reporting

Report vulnerabilities in the component version you integrate to the person or entity maintaining it, following their disclosure policy and channels Art. 13(6). No duty where you can confirm the maintainer already knows, where the component is unmaintained, or where you no longer rely on that maintainer. Check public vulnerability databases, advisories and issue trackers first to avoid duplicate reports. Fixes should be shared in a machine-readable, verifiable form, and for FOSS components under a licence compatible with the component's own Guidance §9.2.1. You are not required to get your fix accepted, and you are not required to accept theirs.

12 / Neighbouring law

HOW ITFITS

13 / Enforcement

WHAT ITCOSTS

Two derogations are worth knowing Art. 64(10): administrative fines do not apply to open-source software stewards for any infringement, and micro and small enterprises are not fined for missing the early warning deadlines in Art. 14(2)(a) and Art. 14(4)(a). The steward carve-out removes the fine, not the obligation. A drafting quirk for the attentive: the derogation textually refers to paragraphs 3 to 9, while the fine ceiling for Article 14 breaches sits in paragraph 2 — the carve-outs are generally read in line with their evident purpose, as reaching those fines.

Fines are set by national market surveillance authorities taking account of the nature, gravity and duration of the infringement, prior infringements, and the size and market share of the operator. In Germany that will be the BSI: the designation has been notified to the Commission, and the implementing statute is currently before the Bundestag.

14 / Sequencing

WHAT TODO NOW

Now: reporting is live

Make sure you can report today

1. Decide who reports. Name the accountable role, the deputy, and the out-of-hours path. The 24-hour clock does not pause for holidays.
2. Write the awareness trigger down. Define what "reasonable degree of certainty" means in your triage, and align it with your NIS2 and GDPR breach procedures so one intake feeds all three.
3. Identify your reporting channels. ENISA's single reporting platform has been operational since 11 September 2026, initially for mandatory Art. 14 notifications only; voluntary Art. 15 notifications follow later. Confirm the coordinating CSIRT for your Member State and make sure you can use the platform, because the 24-hour clock will not wait for it.
4. Inventory in-scope products already on the market, including legacy ones. Reporting applies to them even though vulnerability handling does not.
5. Draft the user notification templates and decide who signs them off.
6. Set up monitoring for exploitation signals: CISA KEV, the EU vulnerability database, vendor advisories, your own telemetry.

Through 2026 and 2027

7. Classify every product: default, important class I, important class II, or critical. Record the core functionality determination and the reasoning.
8. Draw the product boundary, including remote data processing solutions. Run the three questions per back-end component and document the answers.
9. Run the risk assessments. Group product families where architecture, security-relevant design, intended purpose and risk profile genuinely coincide.
10. Set support periods per product and check they are defensible against expected use time. Get them into the sales channel, the packaging and the contracts.
11. Build the SBOM pipeline and the coordinated vulnerability disclosure policy. Publish a contact address.
12. Fix supplier contracts: component security specifications, vulnerability notification, support period alignment, change notification from cloud providers, service level agreement security terms.
13. Define your substantial modification gate. A release checklist against the four questions, with the decision recorded, is the cheapest evidence you will ever produce.
14. Book notified body capacity early if you have class II or critical products. Capacity will be scarce in 2027.

Before 11 December 2027

15. Complete conformity assessment, technical documentation per Annex VII, EU declaration of conformity per Annex V, CE marking, and user information per Annex II.
16. Check whether existing RED or Machinery Regulation certificates cover part of your evidence, and plan for their CRA usability ending on 11 June 2028.

15 / Questions

WHATCLIENTS ASK

Does the CRA apply to our SaaS?

Not to the browser-delivered service itself. A web application accessed only through a browser is not a product with digital elements, and neither is a website that merely presents information Guidance §2.2. Three things change that answer: shipping any locally installed component, such as a desktop client, mobile app, agent or browser extension; server-side software you built that the product needs to perform a function, which becomes a remote data processing solution and part of the product; and NIS2, which regulates the cloud service in parallel and is unaffected by the CRA analysis.

We only use open source. Are we exempt?

There is no blanket exemption, and the question splits three ways. If you publish and control a project without monetising it, you are outside the Regulation as a natural person, or a steward under Art. 24 as a legal person. If you contribute to a project you do not control, the CRA does not apply to you. If you integrate FOSS into a product you sell, you are the manufacturer of that product, with due diligence on the components Art. 13(5) and upstream reporting duties Art. 13(6). The component's own status does not change because you used it.

Does every update create a new product?

No. Only a change that affects compliance with Annex I Part I, or that changes the assessed intended purpose Art. 3(30). Security updates generally do not, even substantial ones. What matters is the risk delta against your existing risk assessment, and the cheapest way to be able to prove it later is a short recorded assessment at each release.

Can we just declare five years of support?

Only if five years genuinely matches the expected use time. Five years is a floor for products used that long or longer, and products reasonably expected to be in use longer should get longer Art. 13(8), Recital 60. The number has to be defensible against user expectations, the nature of the product, comparable products on the market, and the support periods of the third-party components providing core functions. It also has to appear at the point of purchase.

Our product was designed years ago. Do we have to redesign it?

Generally no. Run a current risk assessment and show that the existing design already addresses the identified risks. You do not have to recreate historical design or test documentation, and you do not have to add security features that the risk assessment does not call for Guidance §2.7. You do have to complete conformity assessment, draw up the declaration of conformity, affix CE marking, and run vulnerability handling.

We are a supplier, not a manufacturer. What do our customers need from us?

Whatever their own compliance depends on. Expect contractual demands for component security specifications, an SBOM, vulnerability notification within defined windows, support period alignment with their product, notification of changes to hosted services, and the evidence they need for their due diligence under Art. 13(5). Suppliers who can hand this over as a package will be selected over those who cannot, well before any authority gets involved.

How does this sit with NIS2, DORA, the AI Act and the GDPR?

The CRA regulates the product and the economic operators around it. The others regulate entities, services, operational resilience, AI systems or personal data processing. The same architecture and the same incident can engage several of them at once with different triggers, scopes and deadlines. Build one intake and one control map, then preserve each regime's own clock. Aligning the CRA awareness test with the NIS2 implementing regulation and the EDPB's breach guidance, as the Commission's guidance does, is the practical starting point.

What happens if we are late?

Administrative fines run to EUR 15 000 000 or 2.5% of worldwide annual turnover for the essential requirements and the manufacturer obligations Art. 64(2). The larger commercial exposure is usually elsewhere: market surveillance authorities can require corrective action, restrict availability, or order withdrawal and recall, and customers will start asking for CRA evidence in procurement long before enforcement begins.