10 CRA Rules That Can Get Your Product Pulled From the EU Market

A market surveillance authority can order your product off the shelf, including the units already sitting in a customer's factory or living room. The Cyber Resilience Act carries administrative fines as well, and those are the numbers that end up in board decks. For most manufacturers, a year of lost EU revenue on a flagship SKU costs more than the fine.

September 11, 2026 brings vulnerability and incident reporting into force, and it applies to everything already on the market. December 11, 2027 brings everything else.

Something else has changed since most CRA coverage was written. On July 27, 2026, the Commission approved its Article 26 guidance, document reference C(2026) 5252, roughly 80 pages working through the questions manufacturers ask most. The guidance is not binding, and only the Court of Justice can authoritatively interpret the regulation, but market surveillance authorities and notified bodies will read it, and it settles several questions teams had been answering with their own assumptions.

Which CRA requirements decide market access

The CRA requirements that carry a market-access consequence fall into four groups: the Annex I essential requirements covering product properties and vulnerability handling, the Article 13 manufacturer obligations, the Article 14 reporting obligations, and the conformity assessment, documentation, and CE marking duties in Articles 28 through 32.

A gap in any of them can end in withdrawal rather than in a line item. These are the ten that come up most, in the order teams tend to meet them.

1. You cannot ship a product with a known exploitable vulnerability

Annex I, Part I requires products to be placed on the market with no known exploitable vulnerabilities. Read the word "known" carefully. It covers anything already published and cataloged: a CVE disclosed years ago, sitting in a third-party library, in firmware you shipped last month. Finite State researchers found CVE-2002-1819 in a home security camera on sale in 2026, which is what "known" looks like once it reaches a real product.

This sits in the top penalty tier alongside the Article 13 and 14 manufacturer obligations, and it is the requirement teams fail most often. The failure is almost always an inventory problem. Most manufacturers cannot produce an accurate, current list of what is inside a shipped binary, and you cannot assert the absence of a known vulnerability in a component you never knew you were shipping.

Rule three is the one holding up the rest of this list.

2. Secure by design and secure by default are two separate obligations

Both are mandatory, and teams routinely satisfy one while assuming it covers the other.

Secure by design means security shaped the architecture from the start rather than being added during hardening sprints before launch. Secure by default means the product is in a secure state the moment your customer powers it on, before they change a single setting. Annex I sets out what that looks like in practice:

• Eliminate universal default credentials. No shared passwords across a product line, no documented factory logins that survive deployment.
• Minimize the attack surface. Unnecessary ports, services, and interfaces off in the shipping configuration, rather than documented as optional.
• Protect data at rest and in transit. Encryption applied by default rather than available as a configuration option.
• Support a reset to the original secure state. The product must be restorable to the secure configuration it shipped with.

The test is uncomfortable and simple. If your product is only secure after a well-informed administrator hardens it, you have met the design requirement and failed the default one. Our guide to security by design under the CRA covers where this diverges from the voluntary US frameworks most teams calibrated against.

3. Without an accurate SBOM, every other rule is an assertion you cannot evidence

Annex I, Part II requires manufacturers to identify and document the components in a product, including through a software bill of materials in a commonly used machine-readable format, covering at least top-level dependencies.

Top-level dependencies are where the obligation starts, and a useful SBOM goes deeper. The regulation does not mandate a specific format, and both CycloneDX and SPDX are recognized, so the practical decision is to pick one and stay consistent across your portfolio. You also have to keep it current for the entire support period, which makes the SBOM a living artifact tied to your release process rather than a document produced once for an auditor.

The dependency runs in one direction, and it is absolute. You cannot report on, patch, or prioritize a vulnerable component you never recorded. The harder problem underneath it is that a supplier's manifest and the shipped build are not the same artifact: manifest-based inventories miss roughly one component in six, according to Black Duck's own research. Reading the compiled firmware rather than the manifest is how manufacturers reconcile the bill of materials on paper with the software running on the device, and our CRA SBOM and technical documentation guide walks through what regulators expect to see.

4. Declare a support period, then fund it

Article 13(8) requires you to determine a support period reflecting how long the product is reasonably expected to be in use. The expectation is at least five years unless the product's genuine lifetime is shorter.

The July 2026 guidance sharpened this in three ways worth knowing:

• Five years is a floor. A product reasonably expected to remain in service for a decade should carry a support period closer to a decade, and defaulting every SKU to five years is not a compliance strategy.
• State the end date at purchase. At minimum, the month and year, communicated clearly at the point of sale, with notification to users when it expires where technically feasible.
• A substantial modification does not reset the clock. The period gets reassessed against the same criteria rather than automatically extended.

Security updates during that window are free of charge, rather than a maintenance tier or a support contract. That reshapes the product roadmap rather than the security program, because every SKU you launch now carries a multi-year funded obligation. Finance needs it in the model before launch.

5. A patch you cannot deliver protects nobody

Annex I requires security updates to be distributed automatically by default, with a clear and easy-to-use mechanism for users to opt out. Where technically feasible, security fixes should be separable from functional updates, so a customer never has to accept an interface redesign they did not ask for in order to receive a patch they urgently need.

The engineering implications are the substance here. Automatic delivery means signed updates, verification before installation, and a rollback path when something goes wrong in the field. A patch you can build but cannot reliably deliver to deployed devices will not satisfy a market surveillance authority reviewing your vulnerability handling process, and it does nothing for the customer holding the device.

Worth noting from the July guidance: a security update is generally not a substantial modification. Its purpose is to reduce risk, so a fix that does not change the product's intended purpose or introduce new risk does not by itself trigger a fresh conformity assessment. Teams that were delaying patches out of conformity anxiety can stop.

6. The clock is 24 hours, 72 hours, and 14 days

This is the rule with a live deadline on it. From September 11, 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents through the CRA single reporting platform, which routes a submission to the CSIRT in your Member State of main establishment and to ENISA at the same time:

The clock starts when you become aware, not when engineering confirms it, legal signs off, or the disclosure committee next meets. Twenty-four hours is not enough time to design a process, assign an owner, and get an executive to approve a regulatory filing for the first time.

If your organization cannot name the person who makes that call today, that is the gap to close this quarter. Our breakdown of the Article 14 reporting deadline covers what a functioning process looks like, and because the obligation covers products already on the market, the scope is your entire shipped portfolio rather than your current release.

7. Researchers need an obvious place to send bad news

Annex I, Part II requires a coordinated vulnerability disclosure policy, a contact address for reports, and a documented process for handling them. In practice: when an external researcher finds a flaw in your product, there is an obvious, published place to send it, and a defined path for what happens after it arrives.

At a lot of manufacturers, that report currently lands in a general sales inbox and dies there over a weekend. Under the CRA, that is a compliance gap, and it is one a regulator can identify from outside your company in about ninety seconds. You also have to share information about fixed vulnerabilities publicly, so downstream integrators and operators can act on it.

The bar here is low, which is exactly why failing it reads so badly in an enforcement file.

8. To a market surveillance authority, your documentation is your security

Article 31 and Annex VII require cybersecurity technical documentation. Article 28 requires an EU Declaration of Conformity. Articles 29 and 30 govern CE marking.

Engineers tend to treat this tier as administrative overhead, and that instinct is expensive. An authority evaluating your product does not observe your secure development practices. It reads your technical file: the risk assessment, the design decisions, the vulnerability handling procedures, the test evidence. If you cannot evidence a control, you did not implement it, as far as the assessment is concerned.

Retention runs for at least ten years after the product is placed on the market, or the length of the support period, whichever is longer. Only 13% of the organizations ENISA surveyed felt confident they could produce the technical documentation the CRA asks for, and a missing or incorrect Declaration of Conformity sits in its own penalty tier, separate from the essential requirements.

9. Confirm your product class before you self-assess

Not every manufacturer gets to grade its own work. Most products fall into the default category and can self-assess. Above that sit important products in Annex III (Class I and Class II) and critical products in Annex IV, with technical definitions set out in Commission Implementing Regulation (EU) 2025/2392.

The distinctions carry real commercial weight:

• Class I covers 19 categories including identity management systems, password managers, VPNs, operating systems, routers, modems, switches, and browsers. Self-assessment stays available only where harmonized standards, common specifications, or a certification scheme fully cover the applicable essential requirements.
• Class II covers four categories: hypervisors and container runtime systems, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers. A notified body is always involved, and self-assessment is unavailable.
• Critical products in Annex IV, such as hardware devices with security boxes, smart meter gateways, and smartcards or similar devices including secure elements, can require a European cybersecurity certification scheme.

Here is the trap. If you classify into the default bucket when your product belongs to an important class, your conformity assessment is not weak. It is invalid, and so is the CE marking that rests on it.

The July 2026 guidance both sharpens and softens this. The test is the product's core functionality, the main features without which it would not serve its intended purpose. Ancillary functions do not escalate the class, and integrating an important or critical component does not make the whole product important: a smartphone that embeds an operating system is not itself an "operating system." For the purposes of choosing a conformity route, a product is treated as having a single core functionality, identified in its technical documentation. Our guide to CRA conformity assessments covers the routes in detail.

Whichever way it lands, have the classification reviewed by someone whose incentive is not to reach the word "default."

10. Someone else's code is still your liability

Article 13 requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source software. When you ship someone else's library inside your product, its vulnerabilities become your regulatory exposure. "Our supplier provided that binary" is not a defense, and neither is "that component is maintained upstream."

The open-source picture is better than the early panic suggested, and the July guidance set out the detail. Free and open-source software developed and supplied outside a commercial activity is largely outside scope, and individual contributors submitting patches generally carry no CRA obligation. The guidance also defines a proportionate set of duties for open-source software stewards, and confirms under Article 32(5) that important products placed on the market as free and open-source software may follow the lighter default-category conformity procedures.

None of that transfers to you. The moment you pull that library into a product you sell, you are engaged in commercial activity, and you own the downstream obligation. The maintainer's exemption is not your exemption, and the due diligence expectation runs to components you did not write and cannot patch yourself.

What enforcement actually looks like

Nobody wakes up banned. Enforcement typically starts with an information request, moves to an evaluation of the product, and then to an order to take corrective action within a set period. Most manufacturers who fail get a chance to fix it.

The CRA does not promise you that sequence. Under Article 54, a market surveillance authority that finds non-compliance can require corrective action, withdrawal, or recall within a period it sets, and can move to provisional measures restricting or prohibiting availability if the operator does not act. The penalty structure runs to three tiers rather than the two most summaries mention:

In each tier, the authority applies whichever figure is higher, the fixed amount or the percentage.

Your conformity route also depends on standards that do not exist yet. The two core horizontal standards, covering secure development and vulnerability handling, were due under standardization request M/606 by August 30, 2026, with vertical product standards by October 30, 2026. In early July 2026, the Commission published a draft amendment to M/606 pushing both back by about two months. Delivery is not the same as availability: no CRA harmonized standard has been cited in the Official Journal yet, so the Article 27 presumption of conformity is not available to anyone today. Track that cadence, because it determines when the self-assessment route actually opens for Class I products.

Three artifacts, one product, this week

Pick one product. Then try to produce three things:

1. An accurate SBOM reflecting what ships in the current firmware build
2. Your declared support period, with an end date you could print on a datasheet
3. The name of the person who owns the 24-hour reporting decision

If any of those takes more than a day to answer, you have found your gap while there is still time to fix it. If all three take more than a day, the gap is structural, and September 11 is not the deadline you should be worried about.

Answering those three questions across a portfolio is a different problem from answering them for one product, and it is where manual CRA programs come apart. Finite State reads the compiled firmware to produce a software inventory a manufacturer can stand behind, ranks what is left by what an attacker could reach in the shipped build, and keeps the decisions and the evidence behind them in one record as the product changes. Our CRA Managed Services team runs that work as a program for manufacturers who would rather not staff it. If you are still sizing the problem, our post on the five CRA compliance mistakes we see most often is the shorter version of this list.

When a customer or a regulator asks you to show how you decided a vulnerability did not apply to your product, how long does that take, and where does the answer come from? Bring us something you already shipped, and we will walk that answer through your own firmware. Talk to our team about a CRA plan →

Frequently asked questions

When does the EU Cyber Resilience Act take effect?

The CRA entered into force on December 10, 2024. Vulnerability and incident reporting obligations under Article 14 apply from September 11, 2026, and cover products already placed on the EU market before that date. The remaining obligations, including conformity assessment and CE marking, apply in full from December 11, 2027.

What happens if you fail to meet the CRA requirements?

A market surveillance authority can require corrective action and, where that does not happen, restrict, withdraw, or recall the product. Administrative fines run in three tiers under Article 64, reaching €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaches of the Annex I essential requirements or the Article 13 and 14 obligations.

Does the CRA apply to companies outside the EU?

Yes. The CRA applies to products with digital elements placed on the EU market regardless of where the manufacturer is headquartered. A US or Asian manufacturer selling into the EU carries the same obligations as an EU-based one, and typically needs an authorized representative established in the Union.

Is open-source software exempt from the CRA?

Free and open-source software developed and supplied outside a commercial activity is largely outside scope, and individual contributors generally carry no obligation. Open-source software stewards carry a lighter, proportionate set of duties. That exemption does not transfer to manufacturers: integrating an open-source component into a product you sell commercially makes its vulnerabilities your responsibility under the due diligence requirement.

Does the CRA require a specific SBOM format?

No. Annex I requires a software bill of materials in a commonly used machine-readable format covering at least top-level dependencies. CycloneDX and SPDX are both recognized. Choose one and apply it consistently, and keep the SBOM current across the product's support period rather than generating it once for conformity assessment.