sota.io
2026-04-09·8 min read·sota.io team

EU Cyber Resilience Act 2027: Open-Source PaaS Developer Checklist

The EU Cyber Resilience Act — Regulation (EU) 2024/2847 — is not only a hardware regulation. It applies to every software component placed on the EU market, including open-source libraries, APIs, and web applications distributed commercially. If you host an open-source project on a PaaS and receive any commercial benefit from it — subscriptions, sponsorships, support contracts, or integration into a commercial product — the CRA applies to you.

The enforcement timeline has two dates that matter for developers:

September 2026 is five months away. Most open-source developers have done nothing. This checklist covers what you actually need to do.

Who Does CRA Apply To?

The CRA includes a carve-out for non-commercial open-source software (Recital 18). If your project is:

…then the CRA does not directly apply to you as a manufacturer. You are outside the scope.

But the carve-out has sharp edges. You lose non-commercial status if:

If any of those apply, you are either a manufacturer (full CRA obligations) or an Open-Source Software Steward (lighter obligations, but real ones).

The Open-Source Software Steward Category

CRA Art. 3(14) defines a new legal category: the Open-Source Software Steward. This covers organizations and individuals that "provide support on a sustained basis for the development of products with digital elements qualifying as free and open-source software that are intended for commercial use."

In practice, this means: a person or legal entity that regularly maintains an open-source project that other companies integrate into commercial products.

Open-Source Software Steward obligations are a subset of manufacturer obligations, but they are real:

ObligationApplies from
Security policy (Art. 14a)December 2027
Vulnerability handling and coordination (Art. 14a)December 2027
Cooperation with market surveillance authoritiesDecember 2027
Vulnerability disclosure to ENISA (Art. 14)September 2026

The September 2026 deadline is the one most developers will be caught unprepared for.

September 2026: Vulnerability Disclosure (Art. 14/15)

Starting 11 September 2026, if your product has an actively exploited vulnerability, you must:

  1. Within 24 hours: Notify ENISA of the vulnerability (early warning)
  2. Within 72 hours: Submit an updated notification with an initial assessment (severity, CVSSv3/v4 score, affected versions, mitigation status)
  3. Within 14 days: Submit a final notification (root cause, fix, disclosure timeline)

ENISA will operate a single notification portal. Member states' CSIRTs (BSI in Germany, ANSSI in France, NCSC in Netherlands) receive copies automatically.

For a solo developer or small team, this is a real process to build. The checklist item is not "comply with Art. 14" in the abstract — it is having a concrete pipeline that can produce a notification document within 24 hours of discovering an exploited vulnerability.

The 8-Item CRA Checklist for OSS Developers on PaaS

1. Determine Your CRA Status

Question: Is your project non-commercial, an OSS Steward, or a manufacturer?

Run through this decision tree:

Document your decision. This documentation is required if market surveillance authorities ask.

2. Establish a Security Policy (Art. 14a)

Required for OSS Stewards by December 2027. The policy must cover:

A SECURITY.md file in your repository is not sufficient by itself — you need a documented process that you actually follow. The policy must be publicly available.

3. Create and Maintain an SBOM

The CRA requires a Software Bill of Materials — a machine-readable inventory of all components, libraries, and dependencies your software includes. Formats accepted:

For a PaaS-hosted project, this means documenting not just your code dependencies but your runtime environment. If you use Node.js 20 on Ubuntu 22.04, your SBOM should reflect that. Tools:

# Node.js
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Python
pip install cyclonedx-bom && cyclonedx-py -o sbom.json

# Go
go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod app -output sbom.json

The SBOM must be kept current. It should be regenerated on every release and stored somewhere retrievable — not just buried in a CI artifact.

4. Build a 24-Hour Vulnerability Notification Pipeline

This is the September 2026 deliverable. You need a process that, when you discover an actively exploited vulnerability, produces an ENISA notification document within 24 hours.

The notification must include:

Build a template now:

# CRA Vulnerability Notification — [Product Name] [Date]

**Early Warning (24h)**
- Product: [name] v[affected versions]
- CVE: [CVE-XXXX-XXXXX or PROVISIONAL]
- Type: [e.g., Remote Code Execution, Authentication Bypass]
- Active exploitation: YES/NO
- Mitigation available: YES/NO — [describe]
- ENISA submission: [portal URL once live]

You do not need to notify ENISA of every vulnerability you fix — only those being actively exploited in the wild.

5. Document Your Supply Chain

CRA Art. 13(5) requires manufacturers (and by extension, OSS Stewards at higher risk levels) to document their software supply chain. For a PaaS-hosted project, this means:

The PaaS jurisdiction matters here. If your build and runtime environment is on US infrastructure, the CLOUD Act gives US authorities the right to compel access to your data — including source code in memory, logs, and environment variables — without notifying you. This is a supply chain documentation item: your EU customers evaluating CRA compliance will ask where your infrastructure is incorporated.

6. Verify Your PaaS Provider's CRA Position

Your PaaS provider is part of your supply chain. Under CRA, if you use a third-party service that processes or handles your software's data, you should verify:

ProviderIncorporationCRA Jurisdiction Risk
RenderDelaware, USCLOUD Act applies — US authorities can compel access
RailwayDelaware, USCLOUD Act applies
Fly.ioDelaware, USCLOUD Act applies
Heroku (Salesforce)Delaware, USCLOUD Act applies
sota.ioEUEU jurisdiction, no CLOUD Act
Clever CloudFranceEU jurisdiction, no CLOUD Act
ScalingoFranceEU jurisdiction, no CLOUD Act

For CRA supply-chain documentation, an EU-incorporated PaaS removes one line item from your compliance evidence.

7. Assign a Security Contact

The CRA requires that users of your product can reach you for security issues. This means:

For OSS projects, this is often the SECURITY.md file plus a dedicated email. The key requirement is that it is reachable and responds — not just present.

8. Plan for December 2027 — Conformity Assessment

Full CRA compliance by December 2027 requires a conformity assessment for products in higher-risk categories (Annex III Class I and Class II). For most standard web applications and libraries:

For Class I products (development tools, OS, virtual private networks, browsers, password managers, firewalls), a third-party audit may be required. Check Annex III — if your software appears in the product categories listed there, plan for external assessment.

What This Looks Like in Practice

For a solo developer maintaining an open-source library used in commercial software:

Now (April 2026):

By September 2026:

By December 2027:

The work is not technically complex. It is process work — documentation, templates, and contacts. The risk is not knowing you need to do it until September 2026 arrives.

How PaaS Infrastructure Affects CRA Compliance Evidence

When your software is hosted on a PaaS, the provider is part of your CRA supply chain documentation. EU market surveillance authorities can ask for evidence of your supply chain during a conformity assessment. The question they will ask: "Is your infrastructure subject to third-party access obligations incompatible with EU law?"

CLOUD Act compliance with a US subpoena requires the provider to hand over data without notifying you. If that data includes your running application code, environment variables, or logs, it represents a control gap in your supply chain documentation.

EU-incorporated infrastructure removes this documentation burden. sota.io deploys on EU-jurisdiction servers with no CLOUD Act exposure — a single line in your supply chain documentation, not a risk item.

The Formal Verification Question

If you want to go beyond process compliance and build proof-level security evidence, formal verification tools are available for OSS projects:

This is a different level of effort than the checklist above — and it is covered in the companion post EU Cyber Resilience Act 2027: Why Formal Verification Is the Right Tool. For most OSS developers, the process checklist is the right starting point.

See Also