Does Shipping a Progressive Web App Instead of a Native App Let You Skip the CRA?
A reader wrote in with a sharp observation. They are building an app with cross-platform web technologies. Were it to be packaged and downloaded through an app store, it would fall squarely under the Cyber Resilience Act: conformity assessment, CE marking and the full set of manufacturer obligations. Deployed instead as a progressive web app (PWA) in the browser, the same codebase, with the same backend, APIs, data flows and attack surface, drops out of the CRA entirely. Their conclusion was blunt: the CRA quietly rewards web-only deployment and penalises installable software, regardless of real risk.
It is a fair point, and the technical reading is correct. There is a little more worth adding.
The line is real, and deliberate
The CRA regulates products, things placed on the market, not services consumed over the network. The Commission's own guidance draws the line with worked examples: a desktop application built with web technologies but packaged for local installation executes on the user's device and is a product with digital elements; a web application accessed only through a browser is not. A website that merely presents information is not a product either. So the same source code can land on either side of the boundary depending on how it reaches the user.
The reason the service side looks empty is that it is covered elsewhere. The EU's service-side cybersecurity regime is NIS2 (Directive (EU) 2022/2555), not the CRA. The two were designed to complement each other: products under the CRA, services under NIS2. Personal data sits under the GDPR in either case.
The honest gap
There is a real gap, though. NIS2 is gated by size and sector. It applies to medium and large organisations (broadly, 50 or more staff, or over €10 million in turnover) in its covered sectors, which do include many digital providers, but it generally leaves micro and small entities out. So a lean, independent developer shipping a browser-only PWA can fall below NIS2's thresholds and outside the CRA's product scope at the same time. The GDPR still applies to any personal data, but the product-grade cybersecurity obligations largely do not. The asymmetry the reader describes is real for small operators.
Why 'ship a PWA' is not a clean exemption
For most teams, though, the browser route is less of an escape hatch than it looks.
- You may still be in scope elsewhere. NIS2 captures medium and large providers, and the GDPR captures personal data regardless of size. The regulatory surface shrinks; it does not vanish.
- The line can move under you. The moment you also offer an installable build, that build is a product with digital elements. And where a web service becomes the remote data processing that an installed product needs to function, it is pulled back into the CRA as part of that product.
- The risk does not change with the label. The attack surface the reader described is, by their own account, identical. Enterprise customers, insurers and procurement teams increasingly ask for the same assurances, an SBOM, a vulnerability-handling process, a security contact, whether you ship a binary or a URL.
- The boundary is under review. The Commission has acknowledged the product-versus-service question in its guidance, and the CRA carries review clauses. A distinction that is gamed at scale is exactly the kind of thing a future revision revisits.
The practical takeaway
Choose native or web for product reasons, not to dodge a regime. If you place installable software on the EU market, plan for the CRA early: the Fast Check confirms scope in two minutes and the macierz zgodności turns the obligations into a checklist. If you stay web-only, you carry fewer CRA duties, but check NIS2 and the GDPR, and do not assume the security work disappears. In practice it is much the same work either way; the CRA just writes it down.
Thanks to the reader who raised this. If you have spotted an edge case in how the CRA applies, the contact form is open.