What does the EU Cyber Resilience Act mean for your data platform?

The Cyber Resilience Act (CRA) has real, concrete implications for any organization running a data platform in the EU or selling software into the EU market. It imposes mandatory cybersecurity requirements on products with digital elements, including the data infrastructure tools that power modern analytics, streaming, and machine learning workloads. If your platform includes components that process, store, or transmit data, the CRA almost certainly applies to some part of it. Below, we work through the most common questions data teams are asking right now, and at the end we cover how the Stackable Data Platform (SDP) is built to support these requirements.

Which data platform components fall under the CRA?

Any software component that connects to a network and is made available on the EU market falls within the CRA’s scope. For a typical data platform, this means stream processing engines, query engines, orchestration tools, storage backends, and the operators or controllers that manage them, essentially the full stack.

More specifically, components like Apache Kafka® (event streaming), Apache Spark™ (batch and stream processing), and Trino (distributed query) all qualify as „products with digital elements“ under the CRA’s definition. So do the Kubernetes operators that configure and manage them. The regulation distinguishes between default and important products, with stricter conformity assessment required for components that handle sensitive data or form critical infrastructure. Data platforms in financial services, healthcare, or public sector environments are especially likely to fall into the higher-risk categories.

What the CRA does not do is exempt software that is distributed as open source and then integrated into a commercial offering. If you package, distribute, or monetize a component, you take on obligations as a manufacturer or importer, regardless of the underlying license.

What security requirements does the CRA impose on software vendors?

The CRA requires software vendors to design products with security by default, maintain vulnerability management processes throughout the product lifecycle, and provide timely security updates. Vendors must also report actively exploited vulnerabilities to the relevant national authority within 24 hours of becoming aware of them.

In practical terms, vendors must:

Minimize the attack surface and apply the principle of least privilege by default
Protect the confidentiality, integrity, and availability of data the product processes
Provide security updates for the expected product lifetime, or at minimum five years
Disclose known vulnerabilities through a coordinated disclosure process
Produce and maintain a software bill of materials (SBOM) for each product
Notify the European Union Agency for Cybersecurity (ENISA) of actively exploited vulnerabilities within 24 hours

These are not aspirational guidelines. Non-compliance can result in market withdrawal orders and fines of up to 15 million euros or 2.5% of global annual turnover, whichever is higher. For data platform vendors, security can no longer be treated as a post-release concern, it has to be built into the development and release process from the start.

How does the CRA affect open-source data software?

Open-source software is not automatically exempt from the CRA, but the regulation does draw a meaningful distinction. Software developed and distributed purely as a non-commercial open-source project, where no commercial support or services are offered, falls outside the regulation’s scope. The moment a company monetizes that software, the obligations attach.

This matters enormously for the open-source data ecosystem. Apache Kafka®, Trino, Apache Spark™, and similar projects are developed by communities and foundations. The projects themselves are not subject to the CRA. But any vendor that packages these tools into a product, offers managed hosting, or sells support contracts around them becomes a „manufacturer“ under the CRA and must meet its requirements.

For data engineering teams, the practical implication is that you need to understand which layer of your stack carries CRA obligations. If you are running community builds directly, the obligation may sit with you as the deploying organization. If you are using a commercial distribution or managed service, the vendor carries the manufacturer obligations, but you still need to verify their compliance posture as part of your own supply chain due diligence.

The open-source community has responded by developing shared tooling around software supply chain security, including standardized SBOM formats and vulnerability disclosure frameworks, which reduces the compliance burden for everyone building on top of these projects.

What is a software bill of materials and why does the CRA require it?

A software bill of materials (SBOM) is a structured, machine-readable inventory of all components, libraries, and dependencies that make up a piece of software. The CRA requires vendors to produce and maintain one because it is the foundation of any credible vulnerability management process, you cannot patch what you cannot identify.

For a data platform, an SBOM might list hundreds of components: the JVM version, specific versions of Apache libraries, compression codecs, authentication libraries, Kubernetes client dependencies, and more. When a new Common Vulnerabilities and Exposures (CVE) is published, an SBOM lets you immediately determine whether any of your deployed components are affected, without manually auditing every container image.

The CRA does not mandate a specific SBOM format, but the industry has converged on two standards: SPDX (Software Package Data Exchange, maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). Both are supported by major build toolchains and container registries. Alongside SBOMs, the Common Security Advisory Framework (CSAF) and Vulnerability Exploitability eXchange (VEX) formats are increasingly used to communicate whether a known vulnerability in a dependency is actually exploitable in a given product configuration, an important nuance for complex data stacks with many transitive dependencies.

How does the CRA interact with GDPR and NIS-2 for data platforms?

The Cyber Resilience Act, the General Data Protection Regulation (GDPR), and the NIS-2 Directive address overlapping concerns but from different angles. Together, they create a layered compliance framework that data platforms operating in the EU must work within.

GDPR focuses on the lawful processing of personal data and the rights of data subjects. It requires appropriate technical and organizational security measures, but does not specify what those measures look like at the software component level. The CRA fills that gap by defining baseline security properties that products must have before they reach the market.

The NIS-2 Directive targets operators of essential and important entities, organizations in sectors like energy, finance, healthcare, and digital infrastructure, and requires them to manage cybersecurity risks in their supply chains. If your organization is in scope for NIS-2, you are already required to assess the security of the software you use. CRA compliance by your vendors directly supports your NIS-2 obligations, because a CRA-compliant product comes with documented security properties, an SBOM, and a known vulnerability disclosure process.

In practice, data sovereignty and compliance go hand in hand here. Keeping data on infrastructure you control, rather than delegating it to a third-party cloud service where the supply chain is opaque, makes it significantly easier to demonstrate compliance across all three frameworks.

When does the EU Cyber Resilience Act come into force?

The CRA entered into force in December 2024, following its publication in the Official Journal of the European Union. But the obligations do not all apply immediately. The regulation uses a phased implementation timeline that gives manufacturers and market participants time to adapt.

The key dates, as we understand them from the published regulation, are:

September 2026: Reporting obligations for actively exploited vulnerabilities and incidents apply from this date
December 2027: The full set of product security requirements and conformity assessment obligations become enforceable

This means that in 2026, the most immediate obligation for software vendors is establishing a functioning vulnerability disclosure and incident reporting process. The broader engineering and product changes required to meet the security-by-design requirements have until the end of 2027, but given the scope of work involved, particularly around SBOM generation, supply chain traceability, and default security configurations, organizations that have not started planning are already behind.

How can Kubernetes-native platforms simplify CRA compliance?

Kubernetes-native platforms simplify CRA compliance because they treat infrastructure configuration as code, making the entire software supply chain traceable, reproducible, and auditable. Every component version, configuration parameter, and dependency is declared explicitly, which is exactly the kind of transparency the CRA’s SBOM and vulnerability management requirements demand.

When data applications are managed by Kubernetes operators, several compliance-relevant properties emerge naturally from the architecture:

Traceable deployments: Every version of every operator and managed application is declared in a manifest, creating an auditable record of what is running and when it was deployed
Automated updates: Operators can apply security patches to managed applications in a controlled, repeatable way, reducing the window between a CVE disclosure and a remediated deployment
Consistent security defaults: Operators enforce security configurations, TLS, authentication, authorization policies, at deployment time, reducing the risk of misconfiguration
Portable compliance posture: Because the configuration is cloud-agnostic, the same security baseline applies whether you are running on-premises, in a private cloud, or in a hybrid environment

The infrastructure-as-code approach also supports the supply chain security requirements of frameworks like Supply-chain Levels for Software Artifacts (SLSA, pronounced „salsa“), which is increasingly referenced alongside CRA compliance discussions. When your build and deployment pipeline is fully declarative, producing a verified SBOM and maintaining a chain of custody from source to running workload becomes a tractable engineering problem rather than a manual audit exercise.

How Stackable supports CRA compliance for data platforms

Stackable built the SDP with supply chain transparency as a core design principle, not as a compliance afterthought. Here is what that looks like in practice:

Fully traceable software supply chain: Every container image in the SDP is built from source with a verifiable build pipeline. SBOMs are generated for all components, and Stackable operates as a CVE Numbering Authority (CNA), meaning we can issue and track CVEs for the software we maintain.
Security by default: The Stackable Operators for Apache Kafka®, Trino, Apache Spark™, and other components enforce TLS, authentication, and authorization configurations out of the box, aligning with the CRA’s security-by-design requirements.
Open source and auditable: Because the SDP is 100% open source, every line of code is available for inspection. There are no proprietary black boxes in the stack, which makes third-party security audits and supply chain assessments straightforward.
Data sovereignty: The SDP runs on your infrastructure, on-premises, in your cloud account, or in a hybrid setup, so you retain control over where your data lives and who has access to it, supporting both GDPR and NIS-2 obligations alongside CRA requirements.
No vendor lock-in: The cloud-agnostic, Kubernetes-native architecture means your compliance posture is not tied to a single provider’s security model or disclosure timeline.

If you are working through what CRA compliance means for your specific data platform setup, we are happy to talk through the architecture. Get in touch with the Stackable team to start the conversation, or explore a live demo to see how the SDP handles security configuration in practice.