Public previewRAGSuite is open-source, self-hosted and EU-ready — and we build it in the open.See it live

Platform Platform overviewSee it in actionAI SearchAI AssistantAI Connectors & MCPIntegrationsQuality LoopAdministration & SecurityMobile app
Solutions IT & Platform teamsCompliance & Data ProtectionDevelopersAgencies & Partners
Sovereignty
References
Pricing
Resources Trust CenterEU AI ActSecurity & disclosureFree toolsOpen source & open coreDocumentation ↗API reference ↗GitHub ↗ReferencesBlogChangelog
Company AboutPartnersContact
Search See it live Book a demo
Compliance

The Cyber Resilience Act and your AI platform

Self-hosted software is in scope of the EU Cyber Resilience Act; cloud-only AI tools generally aren't. Why that's an advantage — and how RAGSuite is built to it.

COMPLIANCE SBOM · signed releasessecure by design ragsuite.de
Jürgen Pietschmann
Jürgen Pietschmann AI Consultant
Published25 June 2026 Read4 min Compliance

Most conversations about AI and EU regulation start with the AI Act or GDPR. There’s a third one that quietly matters more for how your software is built: the Cyber Resilience Act (CRA) — Europe’s product-security law for software. And it lands differently depending on one choice: whether you run the software yourself, or rent it from a cloud.

What the CRA is

The CRA — Regulation (EU) 2024/2847 — sets mandatory cybersecurity requirements for products with digital elements placed on the EU market, across their whole lifecycle. It works like CE-marking product law: manufacturers assess conformity, keep technical documentation, affix a CE mark, and handle vulnerabilities on a defined clock. It entered into force in December 2024 and phases in.

Cyber Resilience Act — phased application EU Cyber Resilience Act timelineDec 2024in forceSep 2026reporting dutiesDec 2027main obligations
Reporting duties for actively exploited vulnerabilities and severe incidents begin 11 September 2026; the main obligations apply from 11 December 2027.

Self-hosted is in scope. Cloud-only generally isn’t.

Here is the part most teams miss. Software offered purely as a cloud service is generally not a “product placed on the market” under the CRA — those providers fall under NIS2 instead, not product-security law. Software you deploy yourself is a product with digital elements, and it is in scope.

That sounds like a burden. For a sovereignty-minded buyer it’s the opposite. It means self-hosted software is held to a published European security bar — and a cloud-only AI tool is not even subject to it. You can’t inherit a standard a vendor never had to meet.

The open-source myth

“We’re open source, so the CRA doesn’t apply” is the most common mistake. Truly free and open-source software that its own maker doesn’t monetise is generally exempt, and foundations that steward such software get a lighter, fine-free regime. But the test is monetisation, not licence. RAGSuite’s core is Apache-2.0 and fully inspectable — yet because NITSAN sells a commercial edition, NITSAN is the manufacturer and carries the full obligations. We’d rather meet the bar than argue our way around it.

What “built to it” actually means

The CRA’s essential requirements split into product properties (secure-by-design, no known exploitable vulnerabilities at release, secure defaults) and vulnerability handling (an SBOM, timely free security updates, coordinated disclosure, a published security contact). Concretely, that’s what RAGSuite ships toward:

≥ 5 years
Security-update support period per major version
24 / 72 h
Early-warning & notification clock for exploited vulnerabilities (from Sep 2026)

Signed, version-pinned releases (verify before you run). A CycloneDX software bill of materials on every release. A coordinated vulnerability disclosure policy with a published security.txt. Hardened, local-by-default configuration that doesn’t phone home. None of these are adjectives — they’re things a security review can check.

The honest qualifier

RAGSuite is being engineered to the CRA’s essential requirements ahead of the 11 December 2027 obligations. We describe ourselves as CRA-aligned — not “CRA-compliant” or “CRA-certified.” Those words require a completed conformity assessment, an EU Declaration of Conformity, and harmonised standards that don’t yet exist. When they do, we’ll say so precisely.

See RAGSuite & the Cyber Resilience Act for the full posture, and our security disclosure policy to report a vulnerability. This is general information, not legal advice.

Frequently asked questions

Is RAGSuite CRA-compliant?

We're CRA-aligned — engineered to the CRA's essential requirements, on a documented path to full conformity. Nobody can truthfully be 'CRA-compliant' yet: the main obligations don't apply until 11 December 2027 and the harmonised standards aren't final.

Does the CRA apply to open-source software?

Free and open-source software that its maker does not monetise is generally exempt. But when a company places a commercial product on the market — as NITSAN does with RAGSuite — it is the manufacturer and carries the full obligations, Apache-2.0 core or not.

Does the CRA add cost or work for us as the deployer?

No. The obligations sit with the manufacturer, not the deployer. You get the security work — signed releases, an SBOM, a disclosure process — without inheriting the paperwork. This is general information, not legal advice.

Sources & further reading

  1. European Commission — Cyber Resilience Act — scope, timeline and obligations
  2. European Commission — CRA and open source — the open-source steward / manufacturer line
  3. BSI — Cyber Resilience Act — German market-surveillance context
  4. RAGSuite — Cyber Resilience Act — our posture and the controls

← All posts