When a manufacturer discovers that a product with digital elements, or the manufacturer's relevant processes, does not conform to the Cyber Resilience Act (CRA) essential cybersecurity requirements, recall is not automatically the first response. Article 13(21) requires the manufacturer to act immediately once those obligations apply: take the corrective measures needed to bring the product or processes into conformity, or withdraw or recall the product as appropriate.
That distinction matters operationally. A correctable software defect may be handled through a verified security update and associated process corrections. Stock that should no longer move through the supply chain may need withdrawal. Products already with end users may require recall where correction is not sufficient or appropriate. The decision should be tied to the actual non-conformity, affected scope, cybersecurity risk and distribution state.
The CRA's main manufacturer obligations apply from 11 December 2027. The separate Article 14 reporting obligations for actively exploited vulnerabilities and severe incidents apply earlier, from 11 September 2026. Corrective-measure planning should therefore distinguish the future Article 13 conformity duty from reporting obligations that can already be triggered earlier.
The core manufacturer duty is broader than “fix the bug”
Article 13(21) applies from placing a product on the market and throughout its support period. It covers a manufacturer that knows or has reason to believe that either the product, or the processes put in place by the manufacturer, is not in conformity with the essential cybersecurity requirements in Annex I.
The required response is immediate corrective action. The regulation gives three outcomes: bring the product or processes into conformity, withdraw the product, or recall it as appropriate.
This trigger is not limited to a newly discovered exploitable vulnerability. A non-conformity can also arise from the way vulnerability handling, security updates or another Annex I process is implemented. Start by identifying the exact requirement that is not being met rather than assuming every case is simply a patch-management problem.
“Correct”, “withdraw” and “recall” are different actions
The CRA incorporates the market-surveillance definitions of recall and withdrawal from Regulation (EU) 2019/1020.
- Bring into conformity means correcting the product or the manufacturer's processes so the relevant requirement is met. Depending on the case, this may involve a security update, configuration change, revised process, additional verification, corrected documentation, or a combination of measures.
- Withdrawal is a measure aimed at preventing a product already in the supply chain from being made available on the market.
- Recall is a measure aimed at achieving the return of a product that has already been made available to the end user.
For downloadable software and remotely updateable products, implementation can be less intuitive than for connected hardware, but the legal distinction still matters. Removing an installer from a distribution channel, stopping further supply, remotely correcting an installed release and seeking return of an already supplied product are not interchangeable actions.
Record both the market action and the technical remediation. “Patch released” does not by itself show whether affected stock remained distributable, whether users already had the product, or whether withdrawal or recall was considered.
Start by defining the non-conformity precisely
Before choosing a market action, establish what is actually wrong and what evidence supports that conclusion.
A useful initial record should identify:
- the affected CRA requirement or Annex I control;
- the product, variant, release or process concerned;
- the evidence showing why the current state is non-conforming;
- when the manufacturer first knew or had reason to believe the non-conformity existed;
- whether the issue affects a product characteristic, a lifecycle process, or both; and
- the initial cybersecurity-risk assessment.
Preserve the chronology when understanding changes. If investigation first identifies three affected releases and later testing expands the scope to six, retain both decisions and the evidence that changed the scope.
An internal awareness timestamp is useful even though Article 13(21) does not set a fixed number of hours. It shows when corrective action started and separates initial containment from later remediation and closure.
Determine the affected market scope before choosing the action
Corrective action becomes unreliable when teams know the technical defect but not where the affected product sits in its lifecycle.
Map at least:
- affected product families, variants and releases;
- serial, batch or other identifiers where relevant;
- units or releases not yet placed on the market;
- products still within the distribution chain;
- products already made available to end users;
- Member States in which affected products have been made available, where known; and
- third-party dependencies that materially affect remediation.
This scope distinguishes a release correction, a supply-chain withdrawal and a potential recall. The same technical defect can need different handling if one affected release has not shipped, another is held by distributors, and a third is already installed by end users.
For software, keep release and distribution channels explicit. A fixed build in a repository does not correct users who remain on an affected version, and delisting one download does not necessarily address packages mirrored through other authorised channels.
Use a decision framework, not an automatic recall rule
The CRA uses the phrase “as appropriate”; it does not provide a formula saying that every non-conformity above a particular severity score requires recall.
A practical engineering decision should consider the unmet requirement, cybersecurity risk, exploitability and exposure where relevant, whether a reliable correction can be deployed, the distribution state, whether users can apply the correction through a supported mechanism, and whether interim mitigation meaningfully reduces risk.
This is an engineering and evidence framework, not a substitute for legal analysis of a specific case. The control is that the selected action follows from recorded facts and risk reasoning rather than convenience.
If the product can be brought into conformity through a controlled correction, verify the corrected state. If it cannot, or if continued market availability would leave the non-conformity unresolved, withdrawal or recall may become the appropriate path.
Corrective action needs verification and release evidence
A corrective measure is not complete when a code change is merged or a patch package is built.
For a technical correction, retain evidence connecting the original non-conformity, remediation decision, engineering or process change, security and regression verification, exact corrected release or process revision, approval, distribution, and confirmation that the defined affected scope was addressed.
Where the correction changes the product or supporting documentation, reassess the cybersecurity risk analysis and technical documentation that the change affects. Article 13 also requires procedures for series-produced products to remain in conformity and requires relevant development, production, design and conformity-reference changes to be taken into account.
The objective is not to regenerate every compliance artifact after every defect. Update the evidence that is actually affected and preserve why the corrected state is considered conforming.
Withdrawal controls the supply chain; recall reaches end users
A withdrawal can require stopping shipment or release, blocking affected identifiers in fulfilment systems, instructing importers and distributors not to make affected stock available, segregating or reworking units, and controlling software distribution channels under the manufacturer's responsibility.
Importers and distributors have their own CRA duties when they know or have reason to believe a product is non-conforming. Corrective instructions should therefore identify the affected products and required disposition precisely enough that supply-chain actors do not have to infer scope.
Recall is different because the product has already reached the end user. The manufacturer may need evidence of the affected user population, the action users should take, available correction mechanisms, completion status where technically possible, and residual risk for products that cannot be reached or corrected.
Do not label a normal update campaign a “recall” merely for emphasis. Equally, do not assume that publishing an update means recall can never be required. The decision depends on the specific non-conformity and effectiveness of the available corrective measure.
Market surveillance can impose a corrective timeline
Article 54 establishes an enforcement path for products presenting a significant cybersecurity risk. If a national market surveillance authority evaluates a product and finds non-compliance, it must require appropriate corrective action to bring the product into compliance, withdraw it, or recall it within a reasonable period commensurate with the nature of the risk.
The scope can become Union-wide. The economic operator must ensure appropriate corrective action for all affected products it has made available throughout the Union. If adequate action is not taken within the required period, the authority can move to provisional measures restricting further availability, withdrawal or recall.
The European Commission describes the CRA as an ex-post enforcement model: manufacturers place products on the market under their responsibility, while Member States perform market surveillance and can request corrective or restrictive measures from economic operators across the supply chain. The Austrian Federal Chancellery likewise describes lifecycle manufacturer duties and the national market-surveillance structure being established for CRA implementation.
Formal non-compliance has its own escalation route
Not every enforcement issue begins with a vulnerability or Annex I technical failure. Article 58 addresses formal non-compliance, including missing or improperly affixed CE marking, a missing or incorrect EU declaration of conformity, a missing notified-body number where applicable, or unavailable or incomplete technical documentation.
The market surveillance authority must require the manufacturer to end the non-compliance. If it persists, the Member State must take appropriate measures to restrict or prohibit market availability or ensure that the product is recalled or withdrawn.
This is a reason to keep technical remediation and compliance-document remediation in the same corrective-action model. Secure code does not remove a formal conformity defect.
Do not merge corrective action with Article 14 reporting
Corrective measures and regulatory reporting can overlap, but they are not the same workflow.
From 11 September 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents through the CRA reporting process. Those triggers can arise before a final corrective measure is available. Conversely, a non-conformity requiring Article 13 corrective action after the main obligations apply will not automatically be an Article 14 reportable event.
Keep the non-conformity record, reporting-trigger assessment, any Article 14 notification timeline, corrective-action decision, remediation and verification, withdrawal or recall decision, and closure evidence connected but distinct. This avoids treating “reported”, “patched” and “conformity restored” as synonyms.
Build a corrective-action evidence package
A practical record should let a reviewer reconstruct the decision without relying on the memory of the people who handled it. Retain, as applicable:
- the exact non-conformity and requirement;
- the awareness record and source evidence;
- affected products, variants, releases and distribution state;
- cybersecurity-risk assessment;
- the rationale for correction, withdrawal, recall or a combination;
- containment, remediation and verification evidence;
- the corrected release or product disposition;
- supply-chain and user communications;
- authority correspondence and imposed timelines; and
- the closure decision showing the defined scope was addressed.
The evidence does not have to live in one document. What matters is traceability between the records and the exact product or lifecycle context they describe.
Make corrective measures part of lifecycle governance
Corrective-action work crosses security, engineering, release management, compliance, support and supply-chain functions. Define in advance who can declare a potential non-conformity, stop a release or further market availability, approve a corrected state, coordinate economic operators and users, assess separate Article 14 reporting, communicate with authorities, and close the case.
Preserve revisions as the case evolves. If the affected scope expands, a withdrawal becomes a recall, or an authority changes the required timeline, the earlier decision and reason for change should remain visible.
Keeping requirements, affected-product scope, remediation decisions and verification evidence aligned is the kind of lifecycle traceability problem that becomes difficult when records are spread across unrelated tools. AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. AA-sec does not determine CRA conformity or decide whether correction, withdrawal or recall is legally required.
Key takeaway
A CRA non-conformity should trigger a controlled decision, not an automatic “recall everything” response. Once Article 13(21) applies, manufacturers that know or have reason to believe that a product or relevant process does not conform to Annex I must act immediately to restore conformity or withdraw or recall the product as appropriate.
The defensible workflow is to identify the exact requirement, define the affected market scope, assess the cybersecurity risk, choose and execute the proportionate corrective measure, verify the corrected state, and retain the evidence linking every step. If market surveillance later becomes involved, that evidence should show not only what changed, but why the selected action addressed the full affected scope.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Regulation (EU) 2019/1020 on market surveillance and compliance of products — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- Cyber Resilience Act - Member States — European Commission
- Fragen und Antworten zur Cyberresilienz-Verordnung — Austrian Federal Chancellery