CRA Manufacturer Cessation Obligations Explained

The Cyber Resilience Act (CRA) explicitly addresses what happens when a manufacturer stops operating while products with digital elements are already on the market. Article 13(23) requires a manufacturer that ceases operations and, as a result, cannot comply with the Regulation to inform the relevant market-surveillance authorities before the cessation takes effect and, by any means available and to the extent possible, users of the affected products about the impending cessation.

This is a notification obligation, not a mechanism that transfers all remaining manufacturer duties to another company. The CRA separately gives importers and distributors notification duties when they become aware that a manufacturer has ceased operations and can no longer comply. For product teams, the practical task is therefore to prepare a controlled cessation process that identifies affected products, authorities, users, support commitments, supply-chain contacts and the evidence needed to explain what happened.

The CRA's main obligations, including Article 13(23), apply from 11 December 2027. Reporting obligations under Article 14 have applied since 11 September 2026. A cessation plan should distinguish those legal dates from internal business-continuity planning and should not assume that closing a legal entity automatically resolves product-security responsibilities that arose while products were on the market.

Start with the trigger in Article 13(23)

Article 13(23) contains two linked conditions: the manufacturer ceases its operations and, as a result, is not able to comply with the CRA. When that trigger is met, the manufacturer must act before the cessation takes effect.

The required recipients are:

the relevant market-surveillance authorities; and
users of the relevant products with digital elements already placed on the market, by any means available and to the extent possible.

The wording matters. The CRA does not say that every corporate restructuring, acquisition or product-line discontinuation automatically triggers Article 13(23). The provision is tied to cessation of the manufacturer's operations that results in inability to comply with the Regulation.

That makes the legal-entity and operational facts important. A team evaluating a planned closure should record which manufacturer entity placed each product on the market, which CRA obligations remain relevant, and whether another organisational arrangement actually preserves the manufacturer's ability to perform them.

Do not confuse company closure with end of support

A manufacturer ceasing operations is different from a product reaching its declared support-period end date.

Under Article 13, manufacturers determine a support period for each product with digital elements and have obligations during that period, including vulnerability handling and security updates. The end of that planned support period is part of the normal product lifecycle. Article 13(23), by contrast, deals with a manufacturer that stops operating and consequently cannot comply with the Regulation.

A product may therefore still be within its announced support period when the manufacturer plans to cease operations. The cessation notice should make that distinction clear to users. Avoid language that silently rewrites an earlier support commitment or suggests that the CRA defines cessation as an ordinary support-period expiry.

A useful product register should show, for every affected product or family:

manufacturer legal entity;
product, model and variant identifiers;
dates the product was placed on the market;
declared support-period end date;
supported software or firmware branches;
current security-update channel;
vulnerability-reporting contact;
user communication channels; and
importer, distributor and authorised-representative contacts where applicable.

This gives the cessation team a concrete scope instead of relying on a generic list of products once operational knowledge has already started to disappear.

Identify the relevant market-surveillance authorities early

Article 13(23) requires notification of the relevant market-surveillance authorities before cessation takes effect. That means authority identification belongs in the preparation phase, not in the final days of a closure.

For manufacturers operating across several EU markets, the relevant authority picture can depend on where products were placed on the market and how national market surveillance is organised. The CRA establishes an EU framework, while national authorities perform market-surveillance functions.

For an Austrian manufacturer, start from the competent Austrian CRA implementation and market-surveillance information, then map other Member States where the affected products were placed on the market. Keep the legal assessment separate from the operational contact list: the team should know both why an authority is considered relevant and how to reach it.

The notice package should be reviewed before submission. At minimum, it should make the manufacturer, affected product scope, expected cessation date and practical consequence understandable. If the manufacturer will no longer be able to provide a particular support or security function, state the factual limitation rather than using vague language such as "services may change."

Build a user-notification plan around reachable channels

The CRA requires the manufacturer to inform users by any means available and to the extent possible. The Regulation does not prescribe one universal communication channel for every product.

The appropriate method depends on what user relationships and technical channels actually exist. Possible channels can include:

registered-customer email;
product account notifications;
in-product or application notices;
manufacturer support portals;
security advisory pages;
distributor or reseller communication channels;
device-management interfaces used by organisational customers; and
public website notices where direct contact data is incomplete.

The objective is not to collect new personal data merely for cessation. It is to make a reasonable, documented use of available channels to reach users of affected products.

For each channel, record the intended audience, delivery date, message version and evidence of publication or dispatch. If some user population cannot reasonably be contacted, record the limitation and the alternative public channel used. That creates a defensible record of what "to the extent possible" meant in the actual product context.

Tell users what changes operationally

A legally accurate notice can still be operationally useless if it only announces that the company is closing. Users need enough product-specific information to understand the security consequences.

Depending on the product and facts, useful information can include:

the date operations are expected to cease;
which products or versions are affected;
whether the product is still within its previously announced support period;
whether security updates will continue until a stated date;
whether vulnerability-reporting channels will remain available;
whether cloud, activation, identity or update services will stop;
where final security advisories or product documentation will remain accessible; and
what users should do if a security-relevant service becomes unavailable.

Do not promise continuity that has not been secured. Equally, do not imply that users must immediately discard a product unless that conclusion follows from the actual security situation and applicable requirements.

The notice should distinguish confirmed facts from recommendations. If a successor, acquirer or service provider will take over a function, describe only the arrangement that has actually been established and identify the scope precisely.

Importers have their own cessation-notification duty

Article 19(8) addresses the downstream case. When an importer becomes aware that the manufacturer of a product with digital elements has ceased operations and, as a result, cannot comply with the CRA, the importer must inform the relevant market-surveillance authorities and, by any means available and to the extent possible, users of the products placed on the market.

This is important for non-EU manufacturers selling into the Union through importers. A manufacturer's cessation process should therefore include importer contacts and should not assume that one manufacturer notice automatically completes every downstream operator's duty.

Operationally, provide importers with a stable factual package they can use to identify affected products and communicate accurately. That can include product identifiers, cessation date, support status, known user-facing consequences and the manufacturer's public notice.

The CRA does not state in Article 19(8) that the importer automatically inherits all manufacturer support and vulnerability-handling obligations merely because the manufacturer has ceased operations. Avoid turning a notification duty into an unsupported transfer-of-obligations claim.

Distributors also need an escalation path

Article 20(6) applies a related rule to distributors. Where a distributor becomes aware, on the basis of information in its possession, that the manufacturer has ceased operations and therefore cannot comply with the CRA, the distributor must inform the relevant market-surveillance authorities without undue delay and, by any means available and to the extent possible, users of the products placed on the market.

Manufacturers should therefore include distributors in the cessation communication map. A distributor that learns about the closure through customers or public news should not have to reconstruct product scope and security consequences from scratch.

A controlled handover package can reduce ambiguity by giving distributors:

the legal manufacturer identity;
affected product identifiers;
the confirmed cessation date;
a factual statement of support and service impact;
a user-notice reference;
authority-notification contacts where appropriate; and
a point of contact that remains valid during the wind-down period.

This does not replace the distributor's own assessment of its CRA duties. It makes the underlying facts available before organisational knowledge disappears.

Preserve evidence before systems and accounts are decommissioned

Cessation creates a predictable evidence risk: the same shutdown that ends business operations can also remove access to the records needed to explain product-security decisions, support history and notifications.

Before decommissioning internal systems, identify the records that need controlled retention. Depending on the product, these can include:

EU declarations of conformity and technical documentation;
cybersecurity risk assessments;
support-period determinations;
released SBOM and component records;
vulnerability decisions and security advisories;
security-update history;
authority correspondence;
user-notification content and delivery evidence;
importer and distributor communications; and
records showing which product versions were affected by the cessation.

Retention decisions must follow the applicable CRA requirements and other legal obligations. The cessation project should not simply export every internal system. Define which records are necessary, who will retain them, how integrity and access will be protected, and who can respond if an authority request arrives after normal operations have wound down.

Treat security infrastructure as part of the cessation scope

Products with digital elements often depend on infrastructure that is easy to overlook during a corporate shutdown: update servers, certificate services, vulnerability-reporting mailboxes, DNS, cloud APIs, package repositories, device registries or authentication services.

Inventory those dependencies before terminating contracts or credentials. For each one, decide whether it will:

continue for a defined period;
be transferred under a documented arrangement;
be replaced by a static or reduced service; or
stop at cessation.

Then assess the security consequence for affected products. Turning off an update endpoint, revoking a signing service, expiring a domain or removing an identity dependency can change product behaviour even when the product binary itself does not change.

Do not keep sensitive infrastructure alive indefinitely without ownership. Continuity without accountable operators can create a different security risk. The goal is a deliberate, documented transition rather than an accidental failure caused by billing, credential or domain expiry.

Run a cessation-readiness review before the final date

A practical review should confirm that legal notification, user communication, product-security operations and evidence retention agree on the same product scope and dates.

Use a checklist such as:

Is the Article 13(23) trigger analysis documented?
Are all affected manufacturer entities and products identified?
Are relevant market-surveillance authorities mapped?
Is the authority notice approved and scheduled before cessation takes effect?
Are available user communication channels identified?
Do user notices accurately describe support and service consequences?
Have importers and distributors received the facts they need for their own duties?
Are vulnerability-reporting and security-advisory channels handled explicitly?
Are update, cloud, identity, certificate and domain dependencies accounted for?
Is required product-security evidence retained with an accountable owner?
Is there a contact path for authority requests during the wind-down?
Is evidence retained showing what was notified, when and through which channel?

The review should have named owners and a closure condition. A spreadsheet marked "done" is weak evidence if the underlying notice, delivery record or retained technical package cannot later be produced.

Keep the cessation record tied to exact product context

A cessation event can affect several products differently. One product may already be out of support, another may still receive updates, and a third may depend on a cloud service that ends with the manufacturer.

That makes product-level traceability more useful than a single corporate closure record. Keep the cessation decision, notices, support status, retained evidence and infrastructure consequences connected to the relevant product, variant or release.

AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. For a cessation workflow, that model can help organise the evidence showing which products were affected, what was communicated and which lifecycle facts supported the decision, while legal determinations and the actual notifications remain the customer's responsibility.

Key takeaway

CRA Article 13(23) requires a manufacturer that ceases operations and consequently cannot comply with the Regulation to notify relevant market-surveillance authorities before cessation takes effect and, by available means and to the extent possible, users of affected products already placed on the market. Articles 19(8) and 20(6) create related notification duties for importers and distributors when they become aware that the manufacturer has ceased operations and cannot comply.

Treat this as a product-lifecycle exit process, not merely a corporate announcement. Identify affected products and authorities early, communicate concrete security consequences to reachable users, coordinate with downstream economic operators, preserve necessary evidence before systems disappear, and explicitly plan the shutdown or transfer of security-critical infrastructure.

Official sources

Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
Cyberresilienz-Verordnung – Cyber Resilience Act (CRA) — Austrian Federal Chancellery