What is the Cyber Resilience Act?
The CRA (Regulation (EU) 2024/2847) is a horizontal regulation covering all products with digital elements placed on the EU market — whether physical (routers, IP cameras, connected thermostats) or purely software (mobile apps, plugins, libraries, operating systems). It is the first European regulation that applies to code security throughout a product's lifecycle.
It is not a directive transposed differently by each Member State: it is a regulation, directly and uniformly applicable in all 27 EU Member States. The full application date is December 11, 2027 — but the first critical obligation, reporting actively exploited vulnerabilities (to ENISA), applies from September 11, 2026.
What the CRA Concretely Requires
- Security by design: security risks must be addressed from the design phase, not as post-launch patches.
- No known exploitable vulnerabilities at market placement: dependencies must be up-to-date and audited.
- Vulnerability management throughout the lifecycle (minimum 5 years): publish security updates, distribute them for free, inform users.
- Incident reporting: an actively exploited vulnerability must be notified to ENISA within 24 hours (early warning) and 72 hours (full report), from September 11, 2026.
- Technical documentation: secure usage instructions, a vulnerability disclosure policy, and for Class 1/2 products, a SBOM (Software Bill of Materials).
- CE marking: from 2027, covered products must bear the CRA CE marking.
Is Your Agency Affected?
The CRA applies if you make a product available on the EU market — covering much more than direct sales:
- Commercial applications (SaaS, mobile app, boxed software) distributed to European businesses or individuals: yes.
- Plugins or extensions on marketplaces (WordPress.org, Shopify App Store, Chrome/Firefox extensions): yes.
- Custom/white-label development where your client sells the product: your client is the manufacturer, but you are a component supplier — and the CRA imposes obligations on suppliers of components integrated into covered products.
- Open source software distributed without a commercial model (no commercial support, no warranty): explicitly exempt — but this exemption may not apply if you provide paid support or integration services.
Penalties and Their Logic
The CRA introduces a three-tier sanction regime:
1. Violation of essential requirements (secure design, vulnerability management): up to €15,000,000 or 2.5% of worldwide annual turnover.
2. Violation of reporting obligations: up to €10,000,000 or 2% of worldwide turnover.
3. Providing inaccurate or misleading information: up to €5,000,000 or 1% of worldwide turnover.
Preparing Your Agency Before December 2027
Step 1 — Map your products and their classification
Inventory all products you place on the EU market. For each: Default class, Class 1, or Class 2? B2B or B2C? Direct sale, marketplace, or open source + support?
Step 2 — Generate and maintain a SBOM
# Syft — SBOM generation (SPDX or CycloneDX format) curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin synth packages /path/to/project -o cyclonedx-json > sbom.json # Trivy — vulnerability audit from SBOM trivy sbom sbom.jsonStep 3 — Establish a vulnerability management process
1. Monitor CVEs for your dependencies (GitHub Dependabot, npm audit, Composer audit, Trivy in CI/CD).
2. Publish asecurity.txtandSECURITY.mdin each repository.
3. Define an internal SLA (e.g. CVSS ≥ 9 → fix within 7 days).
4. From September 11, 2026: report actively exploited vulnerabilities to ENISA within 24h then 72h.Step 4 — Document compliance
Technical dossier must include: product and security architecture description, cybersecurity risk analysis, security measures implemented and tests performed, vulnerability management policy, SBOM (mandatory for Class 1/2), secure usage instructions. Keep for 10 years after market placement.
Step 5 — Document CE Marking and Maintain the Technical File
From December 2027, covered products must bear CE marking. Create a technical file containing:
- Product description and intended use
- Security risk analysis
- Generated SBOM
- Vulnerability disclosure policy
- Evidence of conformity assessmentThis file must be maintained for 10 years after market placement — until December 2035 at the latest for products released around the regulation's start date.
Impact on Your Hosting Infrastructure
The CRA targets products with digital elements — software and hardware with network connectivity. For a web agency, this translates concretely into:
Third-party dependencies: if you integrate libraries or CMS plugins into products delivered to clients, these components must come with a Software Bill of Materials (SBOM). Tools: [Syft](https://github.com/anchore/syft), [Trivy](https://github.com/aquasecurity/trivy), [cdxgen](https://github.com/CycloneDX/cdxgen).
Security update time: the CRA requires patches for exploited vulnerabilities to be deployed without undue delay. In practice, define an update procedure documented in your SLA, with response times.
VPS and dedicated hosting: hosted hardware is not directly covered (it is a service, not a product with digital elements), but the software you deploy on it falls under the CRA if you commercialize it.
CRA vs NIS2 vs GDPR — The Three Key EU Regulations
Scroll the table
| Regulation | Scope | Who is targeted | Application date | Max penalty |
|---|---|---|---|---|
| **CRA** (2024/2847) | Products with digital elements placed on EU market | Manufacturers, importers, distributors of software/hardware products | Dec 11, 2027 (security) / Sep 11, 2026 (reporting) | €15M or 2.5% turnover |
| **NIS2** (2022/2555) | Essential and important services (cloud, hosting, energy, finance, health…) | Essential and important operators, cloud/CDN/DNS providers | October 2024 (transposition) | €10M or 2% turnover |
| **GDPR** (2016/679) | Processing personal data of EU residents | Any data controller or processor | May 2018 | €20M or 4% turnover |
Free SBOM Tools to Add to Your CI/CD
Automatic SBOM generation at each build is the most cost-effective CRA preparation measure. Three open-source tools:
Syft — generates SBOM in SPDX 2.3 or CycloneDX 1.5 format.
Trivy — scans vulnerabilities from a CycloneDX SBOM or Docker image.
cdxgen — specialized for Node.js, Python, PHP, Go, Java, Ruby projects:
npx @cyclonedx/cdxgen -t php /my-project -o sbom-php.jsonCompliance Timeline — Don't Miss the First Two Deadlines
| Deadline | Obligation |
|---|---|
| Dec 10, 2024 | Regulation enters into force |
| Sep 11, 2026 | Obligation to report actively exploited vulnerabilities to ENISA (24h/72h) |
| Dec 11, 2027 | Full application: all essential requirements, CE marking, documentation |
The mistake to avoid: treating September 11, 2026 as minor. If a vulnerability in your product is actively exploited after that date and you did not report it to ENISA within the deadlines, you are already in violation — more than a year before the CRA's full application.
Technical file retention: the CRA requires keeping the technical dossier for 10 years after product market placement — meaning until December 2035 for the first products placed under the CRA in the start of the transition period.
ServOrbit and Your CRA Compliance
As a host, ServOrbit plays a complementary role in your CRA compliance:
Managed and secured infrastructure: our VPS servers run on hardened Debian 12 (updated kernel, automatic security patches). Your applications run on a certified base.
Automated backups: an exploited vulnerability requires incident response. Having daily backups reduces the risk window.
Dedicated technical support: our team can assist you in setting up monitoring (SigNoz, Beszel) and automated vulnerability scanning for your deployments.
CRA compliance is not a one-time effort: it requires a maintainable DevSecOps chain.
Next Steps to Get Ready Before December 2027
The CRA comes into force in December 2027 — 18 months from now. Three concrete actions to implement now:
1. Map your exposure: list products with digital elements that you develop or commercialize. A SaaS delivered to clients is likely covered.
2. Set up an SBOM pipeline: integrate Syft or Trivy into your CI/CD to generate a for each release. Free and non-intrusive.
3. Document your vulnerability management process: create an internal procedure (detection → triage → patch → client notification). This documentation will be requested by auditors.
For regulated architectures, consider [CRA self-assessment checklists](https://www.enisa.europa.eu/publications/enisa-report-cyber-resilience-act) from ENISA.
