Defectiveness: The Safety a Person Is Entitled to Expect

Article 7 states the test: a product is defective when it does not provide the safety that a person is entitled to expect, or that is required under Union or national law.

Two words carry the weight. Safety, not quality. And a person, not this person.

Safety means the regime is not a warranty. Software that crashes, loses work, corrupts a document, or fails to do what the brochure promised is not defective merely by being bad. It becomes defective when it fails to be safe. A contract claim handles the rest.

A person means the standard is objective. The court asks what the public at large is entitled to expect of a product of this kind, not what this claimant happened to assume. A user who expected a consumer drone to be crash-proof gets no help from that expectation being unreasonable.

The second limb matters too. Where Union or national law requires a level of safety, falling short of it is defectiveness by definition.

Article 7 then lists the circumstances a court takes into account. Several would have been recognisable in 1985.

The presentation of the product, including its labelling, design, technical features, composition and packaging, and the instructions for its assembly, installation, use and maintenance. Documentation is not adjacent to the product; it is part of what is assessed. A safe device with instructions that induce unsafe configuration can be defective.

The reasonably foreseeable use of the product, including misuse that is not unreasonable in the circumstances. The standard is not the manual's intended use. If users predictably do something else, the product must be safe when they do.

The specific needs of the group of users for whom the product is intended. A product aimed at children, patients, or people with limited technical knowledge is measured against what those users are entitled to expect, not against a sophisticated operator.

Three further circumstances exist because the old Directive could not accommodate products that change after they are sold.

The effect on the product of its ability to continue to learn or acquire new features after it is placed on the market or put into service. A model that adapts in deployment does not have one fixed behaviour to assess, and the Directive says so rather than pretending otherwise.

The reasonably foreseeable effect on the product of other products that can be expected to be used together with it, including by means of inter-connection. A component that is safe alone but unsafe in a predictable integration is assessed in that integration.

The moment in time when the product was placed on the market or put into service, or, where the manufacturer retains control thereafter, the moment when the product left the manufacturer's control.

That last clause is the quiet one. For continuously updated software, the assessment point moves with your control rather than freezing at first release.

Among the circumstances, Article 7 names relevant product safety requirements, including safety-relevant cybersecurity requirements.

This is the sentence that connects civil liability to the Cyber Resilience Act, and it does real work. A vulnerability is no longer only a compliance matter to be settled with a regulator. Where it bears on safety, it is a circumstance in deciding whether the product was defective, and a defective product means compensation to whoever was harmed.

Read alongside Article 10, the effect sharpens. Where a claimant demonstrates that the product does not comply with mandatory safety requirements laid down in Union or national law that are intended to protect against the risk of the damage suffered, defectiveness is presumed. The burden then sits with the manufacturer to displace it.

So an unpatched flaw that Annex I of the CRA required you to handle is not merely an administrative failure. It is a presumption of defectiveness handed to a civil claimant.

Article 7 also lists any recall of the product, or any other relevant intervention relating to product safety by a competent authority or by an economic operator.

Both halves matter. An authority's intervention counts, which means a market surveillance measure under the Cyber Resilience Act, ordering corrective action or restricting availability, becomes a circumstance in a later civil claim. So does a voluntary step by the manufacturer itself.

That creates a genuine tension worth naming rather than hiding. Recalling a product promptly is the responsible act, reduces harm, and is what safety regulation is designed to produce. It also produces a documented fact that a claimant will point to.

The Directive addresses the incentive problem only partly, through the rule in the next step about later improvements. A recall is not an admission of defectiveness, and a court weighs it among all the circumstances. But the honest position is that acting on safety creates a record, and the alternative creates a worse one.

Article 7 closes with a protective rule: a product shall not be considered defective for the sole reason that a better product, including an update or an upgrade, has already been or is subsequently placed on the market or put into service.

Without it the regime would punish improvement. Every security patch would be an argument that the previous version was unsafe, and every new model would indict the old one. Manufacturers would face a standing incentive to ship less.

Read the qualifier carefully. For the sole reason. The existence of a fix does not by itself establish defectiveness. It does not immunise the earlier version if other circumstances show it was unsafe, and a fix released alongside an advisory describing exploitation is evidence of something beyond mere improvement.

The rule is best understood as protecting the act of improving, not as protecting whatever was there before. Shipping a patch is safe to do. Having needed it is a separate question.

The circumstances in Article 7 are not a checklist producing a score. They are inputs a court weighs to answer one question: was the safety of this product what a person is entitled to expect?

The diagram groups them by what they describe. What you shipped covers presentation, design, instructions and the needs of the intended users. How it is used covers reasonably foreseeable use and misuse that is not unreasonable. What it became covers the ability to learn, interconnection with other products, and the moment control was retained or lost. What the law required covers safety and cybersecurity requirements. What happened after covers recalls and interventions.

All five feed the single question, and one strong circumstance can carry it. A product that breaches a mandatory safety requirement is unlikely to be saved by good documentation.

Off to the side sits the better-product rule, which removes one input from the weighing rather than adding to it.

The relationship between regulatory compliance and defectiveness is asymmetric, and getting it wrong in either direction is expensive.

Compliance does not establish safety. A product can carry a CE marking, hold a valid declaration of conformity, satisfy every harmonised standard applied, and still be found defective, because the test is what a person is entitled to expect rather than what a standard specifies. Standards set a floor, and courts are not bound by it.

Non-compliance, however, is close to decisive. It is an express circumstance under Article 7, and under Article 10 it triggers a presumption of defectiveness where the requirement breached was intended to protect against the risk of the damage suffered.

So the two regimes are not symmetric halves. Passing the public-law test buys you evidence, not immunity. Failing it hands the claimant a presumption.

The practical implication is that a compliance programme is a floor for liability exposure, never a ceiling.

A smart lock ships in 2027. Two years later an attacker exploits a flaw in its firmware to open doors, and a resident is injured during a burglary.

Run the circumstances. Presentation: the packaging advertised the lock as secure, raising what a person is entitled to expect. Intended users: consumers, not security professionals. Foreseeable use: mounted on a front door with the default configuration, exactly as the instructions describe.

Interconnection: the lock is opened by a phone application over a home network, a configuration the manufacturer expected.

Safety-relevant cybersecurity requirements: the flaw was reachable by an unauthenticated remote request, and Annex I of the Cyber Resilience Act required protection against unauthorised access. If the claimant demonstrates that non-compliance, defectiveness is presumed.

Preventive purpose: a lock exists to prevent exactly this. Its failure to fulfil that purpose is an express circumstance.

A patch released after the incident does not, on its own, prove defectiveness. Very little else here points the other way.

The final circumstance deserves separating out, because it lands squarely on an entire software category.

Article 7 provides that, in the case of a product whose very purpose is to prevent damage, any failure of the product to fulfil that purpose is a circumstance in assessing defectiveness.

That reaches alarms, smoke detectors, brakes and airbags. It also reaches endpoint protection software, intrusion detection systems, backup and recovery tools, content filters, fraud detection systems and access control products. Their entire function is prevention, so failing to prevent is not incidental underperformance. It is the failure the circumstance describes.

The qualification is that this is a circumstance, not a guarantee obligation. No security product stops everything, and a court weighs the failure against what a person is entitled to expect of such a product, which is not perfection.

But vendors in this category should notice that the gap between their marketing claims and their technical limits is now a legally relevant quantity.