Software Configuration and Product Liability

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Configuration can be part of the alleged unsafe mechanism

Software configuration can affect product safety without changing the executable code. Limits, permissions, feature flags, calibration and regional settings can determine how a program responds. Under Directive (EU) 2024/2853, the investigation still concerns the safety the product should provide, covered damage and causation. An unusual setting is not automatically a defect, and a configurable product is not automatically free of responsibility for unsafe behaviour.

The software product liability framework explains the common legal conditions. Configuration analysis asks what values were actually applied, who selected or authorised them, how they affected the product and whether the resulting use was reasonably foreseeable. This is more precise than labelling the event user error or software failure before examining the relationship between code, settings and instructions.

Establish the applied state, not just the defaults

A settings screen can show a default value while a local override, management policy or remote service applies another. Export the effective configuration where available and preserve its origin and time. Record environment variables, relevant policy values and feature flags as appropriate to the product. Avoid including unrelated personal or confidential information merely because an export facility collects it.

Document how the setting was read and whether the act of inspection could change it. A reset, reinstall or troubleshooting wizard may replace the values that matter. If only a later configuration survives, identify that limitation explicitly. It can support a hypothesis but should not silently stand in for the state operating at the moment of the alleged damage.

Identify who could select or change the setting

Separate factory defaults, installer decisions, manufacturer-authorised remote changes and user choices. Keep approvals and relevant access records. Article 4 defines manufacturer control through specified actions, authorisation or consent and the ability to supply updates or upgrades. Control is therefore a legal relationship to assess, not simply a count of people with administrator credentials.

A user-selectable value also requires examination of product presentation and foreseeable use under Article 7. Consider the range permitted by the interface, warnings, safeguards and intended users. A documented technical limit can be relevant without automatically deciding every safety question. Likewise, the absence of a warning does not by itself establish the causal effect of the chosen value.

Follow units, ranges and dependencies

Configuration failures can arise when one component interprets a number differently from another. A temperature limit might use a different unit, an empty value might activate a fallback or an inherited permission might enable an unintended function. Describe the actual path from stored setting to program behaviour and physical or data consequence. Avoid assuming a displayed anomaly proves the internal calculation used that value.

Compare configuration with supported hardware, operating system and dependency versions. A parameter valid for one revision may not be valid for another. Preserve schemas, migration records and validation rules associated with the affected release. If configuration changed format between versions, test the migration on a controlled copy and record the limits of the reconstruction.

Distinguish design questions from deployment mistakes

An investigator may need to ask whether a dangerous value should have been selectable, whether the instructions explained it and whether a protection should have prevented the consequence. Those are different from asking who entered the value. A safe design may tolerate predictable mistakes, while a product can also be used in ways unrelated to its reasonably foreseeable operation. Facts and the Article 7 circumstances must guide that assessment.

For dependency interactions, a default selected by another package can matter as much as a visible user setting. Record which component supplied the value and whether the finished-product manufacturer approved the integration. A supplier's internal description of a setting as advanced does not determine its safety significance or the actual expectations created by the product's presentation.

Build a chronology that can be tested

Record the last known safe state, changes before the event, the incident itself and later troubleshooting. Use timestamps with their clock source and time zone. A configuration audit can show that a value changed but may not show when a running process loaded it. Some programs apply settings immediately; others require restart. Establish which behaviour applies to the affected release.

Link changes to deployment and runtime evidence where possible. A configuration file created before an incident may never have been activated. A database revision may have applied only to a subset of devices. State these distinctions rather than presenting a stored value as universal operational fact. A carefully bounded chronology helps test whether the proposed mechanism fits the observed timing.

Separate configuration restoration from proof of defect

A product working after a reset can indicate that state mattered, but the reset may have changed several variables. It might remove corrupted data, update software or alter connections as well as settings. Record the complete intervention before treating the result as proof that one parameter caused the original harm. Controlled comparison can be useful, provided it avoids unsafe operation and identifies remaining differences.

The later availability of a safer default does not alone prove earlier defectiveness under Article 7(3). Examine the reason for the change, test evidence and relevance to the incident. If the alleged harm falls outside Article 6, a successful technical explanation does not itself create a covered damage claim, although other legal routes may remain relevant.

Preserve focused evidence and unresolved questions

Useful records include the applied configuration, its provenance, change approvals, access history and test results tied to the release. Article 9 allows relevant court-controlled disclosure under conditions and confidentiality safeguards. It does not justify gathering every credential, account record or unrelated setting. Explain which specific values are needed and how they bear on the alleged unsafe behaviour.

Article 10's starting proof requirements remain defectiveness, damage and causation, subject to its specified rebuttable presumptions. If historical configuration cannot be recovered, identify what external evidence could narrow the possibilities and what remains uncertain. A reliable report separates observed values, reconstructed values and assumptions. That distinction makes configuration evidence useful without presenting the existence of a setting as a completed liability analysis.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Incident-time software identity and configuration
Relevant safety assumptions and test evidence
Supply, integration and control chronology

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.