sota.io
2026-05-06·12 min read·sota.io team

EU GPSR for SaaS Developers: When Your App Becomes Part of a "Product" (2026)

Since December 13, 2024, the EU General Product Safety Regulation (GPSR, Regulation (EU) 2023/988) has replaced the old General Product Safety Directive of 2001. For most SaaS developers, that sounds like a hardware story — the kind that affects companies making toasters, electric scooters, and children's toys.

It is not only a hardware story.

GPSR introduced a critical expansion: products with digital elements — including connected apps, embedded software, and cloud services that are integral to a physical product's function — fall within scope. If your backend controls a smart lock, your mobile app monitors a medical device, or your platform manages industrial IoT sensors, the GPSR's safety obligations may apply to your software team directly.

This guide explains what GPSR requires, how to determine whether your SaaS is in scope, and what the obligations mean for development, deployment, and incident response.

What GPSR Is — And What Changed from the Old Directive

The old General Product Safety Directive (GPSD, 2001/95/EC) was written before smart devices existed. It assumed products were static physical objects sold once. The GPSR rewrites that assumption.

GPSR Regulation (EU) 2023/988 entered into force January 12, 2023, and became directly applicable on December 13, 2024. As an EU Regulation (not a Directive), it does not require national transposition — it applies uniformly across all 27 member states from that date.

Key changes from the old GPSD:

The definition of "product" in Art.3(1) reads:

"'product' means any item, whether interconnected with other items or not, supplied or made available, whether for consideration or not, including in the context of providing a service, and including through online means..."

Recital 20 makes the software connection explicit:

"Products which have a digital component, such as software, can be considered as products and fall within the scope of this Regulation insofar as they are embedded in or linked to a physical product..."

The Three-Part GPSR Applicability Test for SaaS

Before assessing obligations, you need to determine whether your software is in GPSR scope at all. Apply this three-part test:

Part 1: Is There a Physical Product in the Chain?

GPSR covers physical products that contain, communicate with, or depend on your software. Examples that trigger this test:

If your SaaS only processes data in the abstract — no connection to a physical device that a consumer or worker interacts with physically — GPSR likely does not apply.

Part 2: Is Your Software Integral to Product Function or Safety?

GPSR does not capture incidental software connections. The relevant question under Art.2(1) and Recital 20 is whether your software:

A cloud dashboard that reads data from a temperature sensor for analytics is borderline. A cloud service that controls HVAC systems based on occupancy data, where a malfunction could cause overheating, is clearly within scope.

Part 3: Do You Place the Product on the Market or Make It Available?

Art.3(9) defines "making available on the market" as any supply of a product for distribution, consumption, or use in the EU. If you:

— you are likely an "economic operator" within GPSR's meaning.

If all three parts are yes: proceed to the obligations assessment below.

Article 6: What Makes a Product "Safe" Under GPSR

Art.6(1) defines the general safety requirement: products may only be placed on the market if they are safe.

Art.6(2) lists the criteria for assessing safety, and three are directly relevant to software:

Art.6(3) explicitly states that products meeting harmonised standards (or, where none exist, European or international standards) are presumed safe. For connected products, the relevant standards are ETSI EN 303 645 (consumer IoT cybersecurity) and IEC 62443 (industrial automation security).

This creates the practical compliance path: align with ETSI EN 303 645 to trigger the presumption of conformity, rather than attempting a standalone safety case.

OTA Updates: The GPSR Risk Most SaaS Teams Overlook

The most significant GPSR obligation for SaaS developers is Article 9(8), which addresses product changes during the product lifecycle:

"Manufacturers shall ensure that procedures are in place so that series production remains in conformity with the requirements of this Regulation. Changes in the design or characteristics of a product and changes in the harmonised standards by reference to which a product is declared safe shall be adequately taken into account."

In plain English: every OTA (Over-The-Air) software update that could affect product safety must be assessed before deployment.

This has direct consequences for continuous deployment pipelines in connected product contexts:

What counts as a safety-relevant update:

What GPSR requires before deployment:

  1. Document the change and its potential safety implications
  2. Assess whether the updated product still meets Art.6(1) safety requirements
  3. Update technical documentation to reflect the new software version
  4. If the update introduces a significant change, assess whether conformity assessment procedures need to be re-run

For most SaaS teams using weekly or daily deployment cycles, this requires a safety gate in the CI/CD pipeline — an explicit step that classifies each release as safety-relevant or not, and routes safety-relevant releases through an approval workflow.

Article 10: Safety Communication Obligations

Art.10 requires manufacturers to provide users with accessible safety information. For connected products, this means your app or platform interface must:

Practically, this means:

Article 20: Mandatory Safety Notifications to the Safety Gate Portal

This is the GPSR obligation with the most direct enforcement consequence.

Art.20(1) requires economic operators (manufacturers, importers, distributors) to immediately notify the Safety Gate portal if they become aware that a product they have placed on the market:

The Safety Gate portal (replacing RAPEX) is operated by the European Commission. Notifications are public. They trigger market surveillance authority investigations and can lead to mandatory recalls.

For SaaS developers, Art.20 is triggered when:

The "immediately" requirement is strict. Unlike the 72-hour NIS2 incident notification window or GDPR's 72-hour breach notification, GPSR's Art.20 notification trigger is discovery-based without a specified delay window. Market surveillance authorities have interpreted "immediately" as within hours for high-severity risks, not days.

NIS2 Intersection: Cybersecurity Is Now Product Safety

Here is where GPSR becomes particularly complex for B2B connected product developers.

GPSR Recital 27 states:

"Products with digital elements are increasingly exposed to cyber-attacks... Cybersecurity risks affect product safety. Therefore, products with digital elements should be safe from cybersecurity risks."

This means a cybersecurity vulnerability in your SaaS that could allow an attacker to cause physical harm via a connected device is simultaneously:

A single incident can trigger three parallel regulatory notification obligations with different recipients, timelines, and content requirements. This is the "triple incident report" problem that arises specifically in connected product contexts.

The practical implication: your incident response procedure for connected product security incidents must have a regulatory triage step that determines which notifications are required within the first 24 hours.

Article 5: The Traceability Requirements

Art.5 requires economic operators to maintain information about the product supply chain for 10 years after the last product is placed on the market. For connected products with a software component:

This creates a data retention obligation that sits uncomfortably against GDPR's data minimization principle. The EU Data Protection Board's guidance on GPSR/GDPR interaction (as of early 2026) treats the GPSR traceability obligation as a legitimate legal basis under GDPR Art.6(1)(c) — legal obligation — for retaining deployment records for 10 years. However, the records must be strictly limited to what traceability requires (device IDs, software versions, deployment timestamps) rather than full operational telemetry.

CLOUD Act Exposure in the Connected Product Safety Chain

Where your software runs matters for GPSR.

If your connected product backend runs on US-based cloud infrastructure (AWS, Azure, GCP in US regions), US CLOUD Act jurisdiction allows US authorities to compel production of data stored or accessible on those servers — including:

In product liability cases involving physical harm from a connected product, the discovery exposure from US-jurisdiction data access is significant. A competitor, plaintiff's attorney, or regulator in the EU may receive GPSR-compliant documentation, while a US litigation discovery process might access the same data through a different legal pathway.

Running your connected product backend on EU-sovereign infrastructure (hosted on servers with no US-parent jurisdiction, no US sub-processors in the data path) eliminates CLOUD Act exposure from the product safety evidence chain. This is not a hypothetical risk mitigation — product liability cases involving connected vehicles, medical devices, and industrial systems routinely involve cross-jurisdictional discovery disputes.

Who Bears GPSR Liability: Manufacturer, Importer, or Distributor?

GPSR's liability structure is relevant when your SaaS is part of a B2B supply chain.

If you build the entire connected product (hardware + software + cloud backend): you are the manufacturer. Full Art.6–10, Art.20 obligations apply to you.

If you provide the software platform to a hardware OEM: the OEM is typically the manufacturer. However, Art.3(14) defines "manufacturer" to include any person who:

"substantially modifies a product already placed on the market in a way that could affect compliance with this Regulation."

A software update that substantially changes safety-relevant functionality could reclassify a software provider as a "manufacturer" for that update, regardless of the original hardware manufacturer's responsibilities.

If you are a marketplace or platform: Arts. 22–35 impose specific obligations on online platforms — including obligations to cooperate with market surveillance authorities and remove unsafe product listings.

In practice, when negotiating B2B contracts with hardware manufacturers who will bundle your software:

GPSR Compliance Checklist for SaaS Teams

Use this to assess your current exposure and identify gaps:

Scoping:

Safety Assessment:

OTA Update Process:

Incident Response:

Traceability:

User Communication:

Enforcement: Market Surveillance Authorities and Penalties

GPSR enforcement is handled by national market surveillance authorities (MSAs) in each member state — the same authorities that enforce CRA and ESPR. They have wide powers under Art.31: right to inspect, test, and demand information from any economic operator.

Art.44 empowers member states to set penalties. While GPSR does not prescribe EU-wide maximum fines (unlike GDPR's 4% global turnover), member state implementations are introducing significant penalties:

The Safety Gate notification obligation (Art.20) is considered high-priority for enforcement. Authorities treat late or missing Safety Gate notifications as evidence of bad faith — it often triggers enhanced scrutiny of the entire product safety management system.

What GPSR Means for Your Infrastructure Decision

The intersection of GPSR's 10-year traceability requirement, Art.20's immediate notification obligation, and NIS2's 24-hour incident reporting window creates a demanding compliance environment for connected product SaaS teams.

The infrastructure implications are concrete:

Deployment logging must be immutable: Safety authorities may request proof that a specific software version was deployed before a reported incident — and may challenge logs that could have been modified.

Incident timelines must be reconstructable: A Safety Gate notification requires a precise account of when the hazard was discovered, what versions were affected, and what remediation was deployed. This requires timestamped, tamper-evident deployment and incident records.

Cross-border data access must be controlled: If your safety-critical records are stored on US-based infrastructure, CLOUD Act requests can expose them in ways that may conflict with EU GDPR obligations and product liability litigation strategies.

EU-sovereign infrastructure addresses each of these requirements structurally — not through legal opinions about US law, but by placing data outside US jurisdiction entirely. For connected product teams serving the EU market, this is increasingly a baseline compliance requirement rather than an optional enhancement.

GPSR has been in force since December 13, 2024. If you build software that controls, monitors, or enables physical products in the EU market, the regulation's safety assessment, notification, and traceability obligations apply to your engineering and deployment processes — not just to your hardware partners.

Learn more about EU-sovereign infrastructure for connected product compliance at sota.io