Regulatory Sandboxes in the MDR/IVDR Proposal: Why They Exist — and Why They Do Not Assure Safety

As a parent and previous cat owner, the only thing I ever found in a sandbox was cat poop.

It is a crude analogy. It also captures an uncomfortable truth about how the term regulatory sandbox is now being used in the context of medical devices, IVDs and software-driven health technologies.

The intent in the proposal is not irrational. The MDR and IVDR amendments introduce sandboxes to support highly innovative technologies where existing regulatory requirements may not map cleanly to early development stages. The stated purpose is to allow development, testing and supervised use in a controlled environment where full application of the framework would significantly delay or impede access, particularly for technologies addressing unmet medical needs.

As a regulatory learning mechanism, that intent is understandable.

Where the logic breaks

The problem starts when a sandbox is implicitly associated with quality assurance, validation or conformity assessment.

It has nothing to do with any of them.

Quality and safety are engineered properties of a system. They are established through requirements definition, architecture, hazard analysis, risk control implementation, verification, validation and lifecycle evidence. None of these activities are owned, defined or executed by competent authorities. Regulators assess evidence. They do not create it.

There is a worrying drift in some regulatory circles towards a development partner posture rather than a safeguarding role. History shows that this tendency usually corrects itself after major patient harm. That is not a learning cycle anyone should welcome.

Validation is being misused

Validation is objective evidence that the final designed product meets defined user needs and intended use in its real deployment context.

User needs are not defined by regulators. Intended use is not negotiated in a sandbox. Deployment context is not explored under derogation.

If these foundations are not established before exposure, the activity is experimentation. It is not validation.

The proposal itself is careful here. The sandbox provisions do not claim to perform validation. They do not claim to satisfy Annex I. They do not describe sandbox activity as conformity assessment. They refer to development, testing and supervised use. They stop there.

That precision matters.

Absence of harm proves very little

A product that does not cause observable harm during a sandbox tells us little about its safety once deployed at scale. Different users. Different workflows. Different environments. Different data conditions. Predictable and non-predictable use. Predictable and non-predictable failure modes.

Safety-critical failures are often rare, emergent, delayed or context dependent. They are not reliably revealed through short, constrained exposure.

If a sandbox has technical value, it is in exposing assumptions, weaknesses and unknowns. Those should feed directly back into safety risk management, engineering design, performance and robustness. They should not be treated as validation outcomes.

The liability paradox

The proposal states that manufacturers retain liability for harm arising from sandbox activity. That statement is formally correct. It is also incomplete.

Liability is shaped by context.

A sandbox explicitly recognises uncertainty. It justifies derogation from standard requirements. It places real-world use under regulatory supervision. This creates a documented framework of accepted uncertainty. That framework is approved by a competent authority and visible at EU level.

Liability assessments turn on foreseeability, reasonableness and the safety expectations a patient is entitled to hold. Sandbox participation inevitably alters that frame. Harm occurring during or after sandbox activity will be assessed in the context of regulatory awareness, accepted uncertainty and supervised exposure.

Liability is not removed. It is reshaped.

This creates a structural incentive problem. Manufacturers may emphasise novelty and regulatory misfit to gain sandbox inclusion, not only to support development but to soften future liability exposure by embedding uncertainty within a regulator-endorsed narrative.

This does not require bad faith. It follows directly from how liability is assessed in practice.

Unlike clinical investigations or compassionate use frameworks, the sandbox sits between development and deployment. It lacks the same clarity around consent, evidentiary purpose and legal separation from market access.

National and EU sandboxes introduce variability

The proposal introduces both national and EU-level sandboxes.

The EU-level construct is comparatively constrained and framed around regulatory learning. The national sandbox model gives Member States significant discretion. This includes temporary derogation from core regulatory requirements under a sandbox plan.

That creates real risk: jurisdictional variability, technical misalignment, regulatory capture, and evidence generated under one authority’s supervision later meeting resistance from another authority or a notified body.

“We did it in a sandbox” is not a technical argument. It will still be treated as one.

Why this adds regulatory effort

The uncomfortable question remains: why is this needed at all?

We already have established mechanisms. Clinical development plans. Early scientific advice. Innovative pathway tools. Controlled usability studies. Simulated use environments. Disciplined design and development under ISO 13485, ISO 14971, IEC 62304 and related standards.

These mechanisms generate robust evidence without implying regulatory endorsement or relaxing assurance discipline.

If the objective is safe adoption of novel technologies, a cleaner solution would be national or regional centres for controlled product evaluation and adoption. Simulated clinical environments. Structured integration sites. Post-market learning hubs embedded into normal design and development processes.

Responsibility stays where it belongs: with the manufacturer, supported by engineering and clinical expertise, not regulatory derogation.

What a sandbox can realistically do

A sandbox can support regulatory learning. It can highlight where existing rules struggle. It can expose assumptions that must be engineered out before conformity assessment. It can inform future guidance or legislation.

It does not assure safety. It does not establish validation. It does not replace disciplined quality systems. It is not a clinical investigation mechanism.

The real risk

The risk is not the existence of sandboxes.

The risk is confusing supervised experimentation with assurance. The risk is confusing regulatory comfort with engineering confidence.

Sandboxes are fine for children and cats.

Safety-critical products require safety by design, performance by design, interoperability by design, and safety-risk and quality management systems that remain active throughout the product lifecycle.

Engineering first. Assurance first. Everything else is observation to inform the next stage of development.