The European Union’s Cyber Resilience Act (CRA) is an upcoming regulatory hurdle that spans beyond the scope of citizens within Europe. The CRA is a significant shift in how software and hardware are built for the European market. The CRA mandates that any Product with Digital Elements (PDE) – this can be anything from mobile apps to industrial routers - must essentially be secure by design and by default throughout its entire lifecycle. Hardware and software products with digital elements will bear a CE marking to prove compliance.
While product security and compliance teams are the traditional owners of these requirements, the actual implementation often falls into the gap between policy and production. This is where platform engineering becomes the hero of the story.
Important dates for CRA compliance:
- Entered into force (EIF): The CRA law entered into force on December 10th 2024, under the document titled Regulation (EU) 2024/2847. This is the precise date the law and contracts become legally binding and effective. It marks the transition from a signed agreement to an active, enforceable instrument, following other specific criteria and ratification.
- Mandatory: Some requirements apply starting September 11th 2026. This document is designed to focus primarily on the reporting obligations coming into force this year. Manufacturers, which we’ll discuss later on, are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements.
- Fully-enforced: All requirements and obligations to be enforced by December 11th 2027 after which all products with digital elements (including software and remote data processing) must comply. The entire timeline of events can be followed on the implementation page for CRA.
Understanding the role of manufacturer vs. steward
You’ll hear both of these roles being discussed in the industry, so whether you’re a business selling services in Europe, or are contributing to an open source project that’s now part of the global software supply chain, it’s important to understand the differences between each role.
The manufacturer is essentially any person or company selling a PDE inside the EU. They must ensure compliance, conformance assessments, vulnerability management, incident reporting, and free security updates. Manufacturers of products with digital elements must adhere to strict post-market requirements for at least five years. For the context of platform engineering teams, you are all manufacturers of software PDEs.
OSS stewards on the other hand can loosely be thought of as any legal person, other than a manufacturer, that provides sustained, non-commercial support for Free & Open Source Software (FOSS) PDEs. Unlike manufacturers, they don’t actually sell services into the region, but they are a crucial part of the software supply chain. They have to comply with fewer obligations, but must crucially handle vulnerabilities and incidents in more or less the same way, such as reporting on critical flaws in code, reporting through SBOMs etc.
Platform engineering teams can help the broader organization
At its core, the CRA requires manufacturers to ensure their products meet essential cybersecurity requirements before they hit the market. While Security and Compliance teams define the what, Platform Engineering builds the how. By embedding these requirements into the Internal Development Platforms (IDPs), we can ensure compliance is a byproduct of the developer workflow, not a blocker to it.
Key obligations include:
- Automated classification and conformance checks: The CRA categorizes PDEs into default, important, and critical classes, each requiring different levels of assessment. In the Platform approach, we can automate this classification at the repository level via metadata in your catalog-info.yaml or through automated discovery tools. By integrating automated policy-as-code using tools like OPA or Kyverno, the platform can enforce different deployment gates based on a service’s risk class. This ensures that critical services, for example, automatically trigger external conformance checks before reaching production.
- Standardizing secure-by-default via IaC: The phrase secure-by-default is now a legal requirement. Section 3.1.3(a) states that software must ship with the most secure settings out of the box. While this might sound arbitrary and up to interpretation, there’s a lot that platform teams already do today to meet these controls. Unlike the world where devs were freely able to bring-your-own tools and cloud configs, platform teams can provide pre-configured, hardened IaC modules. Instead of devs configuring their own S3 buckets or AuthN/AuthZ layers, they consume platform-provided modules that disable public access, enforce TLS 1.3, and prohibit weak default credentials by design. This ultimately shifts the operational burden of configurations from the developer to the Golden Path template itself, ensuring every new microservice inherits a compliant security posture.
- Automated documentation through SBOM: The CRA (under Section 3.2.1) requires comprehensive technical documentation, including a machine-readable Software bill of materials (SBOM) and supply-chain risk assessments. Platform teams can bake SBOM generation (using standards like CycloneDX or SPDX) directly into the CI/CD pipeline. Every build creates a snapshot of the software stack, including transitive dependencies and their provenance. Using either open-source format allows an org to centralize these artifacts within an IDP. The platform now aids as a single source of truth for compliance teams. When a new vulnerability is announced, the platform can instantly query all active SBOMs to identify affected services across the entire fleet.
- Rapid vulnerability management and incident reporting: With a 24-hour window to report actively exploited vulnerabilities, manual spreadsheets are a liability. The CRA demands that your releases ship without known exploitable flaws and that patching processes are robust. Again, platform teams can implement automated vulnerability scanning at the build, registry, and runtime levels. By sourcing dependencies from internal, vetted mirrors (with verified provenance) from a managed platform like Cloudsmith, we can prevent poisoned packages from entering the ecosystem. We, as platform engineers, can automate the remediation path by providing self-service tools that notify developers of required updates and, in some cases, automatically open Pull Requests to bump vulnerable versions. This infrastructure ensures the entire development organization can meet our end of the strict 24–72 hour reporting and patching windows required by EU authorities.
How platform engineers hold the secret weapon
We want Devs, SREs and Platform Engineering teams to think of compliance not as a boring mandatory checklist activity that was added to make your daily activities more complicated. Instead, we need to treat compliance as a mandatory approach to enforce provenance and repeatability in the IDPs we are all focused on getting devs to adopt. Platform engineers have the unique opportunity to transform CRA compliance from yet another government regulation, red-tape, manual burden into a frictionless Golden Path that gets the proper buy-in from teams throughout the organisation.
- Hardening the golden path: Instead of asking every developer to learn the nuances of Annex I of the CRA, platform engineers can bake those requirements into the IDP. By providing Golden Paths, you ensure that every new service is compliant from git init. For example, this could be a standard template for a new microservice that automatically includes a hardened base image, pre-configured logging for incident reporting, and mandatory authentication headers.
- Automating the SBOM and dependency chain: The CRA’s requirement for a machine-readable SBOM could be a massive operational lift. According to a recent study by Cloudsmith, 25% of organizations are struggling to get visibility across their existing stacks with SBOMs. Platform engineering teams have the ability to automate this process by integrating tools like Syft or Trivy directly into the CI/CD pipeline processes. The result here is that every time a developer pushes code, an updated SBOM is generated and stored as an artifact, making the audit trail automatic rather than a painful, manual task. Work with your relevant security and compliance teams to understand the minimum elements required for meeting CRA inside those SBOMs.
- Self-service compliance via templates: By providing self-service templates, you empower developers to move fast without breaking compliance. Within the self-service templates platform teams can address the secure-by-default infrastructure requirements. By using IaC modules like Terraform you can enforce secure credential management practices by default. These self-service templates are also precisely the right place to enforce automated scanning for all developers. We recommend building security gates into the platform that prevent the deployment of any container with critical CVEs that are known to be exploited in the wild, directly supporting the CRA’s vulnerability management mandates. You become the controller who can securely source known-to-be-safe software dependencies, libraries and container images from a central artifact repository like Cloudsmith, with the correct SBOM provenance in place, rather than insecurely sourcing these software packages from the public internet.
- Incident response and telemetry: The CRA’s 24-hour reporting window is incredibly tight. Platform engineers can aid this by building standardized observability and alerting suites to aid security and compliance. If a platform can automatically flag an actively exploited pattern (like a sudden spike in 401 errors combined with known exploit signatures), the compliance team can meet their reporting deadlines with ease.
Platform engineers are the MVP in a collaborative future
Don’t get me wrong, I’m not advocating for platform engineering to take over the existing roles of Security or Legal, but it should be clear from this blog post that platform engineers have the unique position to operationalize these policies. When compliance is invisible, such as being embedded into the tools developers are already using, the organization in question doesn’t just meet the regulation more easily, but it also builds a more resilient product - something we all want to see as manufacturers and as consumers.
