[{"data":1,"prerenderedAt":227},["ShallowReactive",2],{"seo-verification":3,"blog-cra-2027-what-the-cyber-resilience-act-changes-for-your-agency-ma-en":6,"promo-bar-likely":226},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-cra-2027-what-the-cyber-resilience-act-changes-for-your-agency-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":155,"ctaBody":156,"ctaButton":157,"ctaUrl":158,"relatedPosts":159},267,"cra-2027-what-the-cyber-resilience-act-changes-for-your-agency",{"fr":12,"en":10,"ar":13,"es":14},"cra-cyber-resilience-act-hebergement-2027","cra-2027-ما-يغيره-قانون-المرونة-الإلكترونية-لوكالتك","cra-2027-cyber-resilience-act-agencias","CRA 2027: What the Cyber Resilience Act Changes for Your Agency","The CRA already requires reporting of exploited flaws and fully applies on 11 December 2027: obligations, penalties and a plan for your agency.",18,3,false,"2026-08-15T00:00:00+00:00","2026-11-09T20:55:13+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},10,"Compliance & Regulation","conformite","bg-amber-500\u002F10 text-amber-400",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fcra-cyber-resilience-act-hebergement-2027-poster.svg","The Cyber Resilience Act (CRA) — Regulation (EU) 2024\u002F2847, published in the Official Journal of the European Union on 20 November 2024 and in force since 10 December 2024 — imposes, for the first time, binding cybersecurity obligations on **manufacturers of products with digital elements** placed on the European market. For a web agency building applications, plugins, extensions or firmware, the clock is already running: since **11 September 2026**, every actively exploited vulnerability must be reported within 24 hours. On **11 December 2027** all requirements apply, and non-compliance exposes you to fines of up to €15 million or 2.5% of worldwide annual turnover.",[34,38,50,53,56,59,84,87,115,119,122,149,152],{"type":35,"title":36,"body":37},"h2","What is the Cyber Resilience Act?","The CRA (Regulation (EU) 2024\u002F2847) is a horizontal regulation covering **all products with digital elements** made available on the EU market whose intended use includes a direct or indirect connection to a device or network: physical products (routers, IP cameras, connected thermostats) as well as pure software (mobile apps, plugins, libraries, operating systems). It is the first European regulation that applies to **code security** across a product's entire lifecycle.\n\nIt is not a directive that each Member State transposes its own way: it is a **regulation**, directly and uniformly applicable in all 27 Member States. It applies from **11 December 2027**, with two earlier steps: the rules on conformity assessment bodies (Chapter IV) since **11 June 2026**, and the reporting obligation of Article 14 since **11 September 2026**.\n\n**Three product tiers, three levels of assessment:**\n- **Default products**: the vast majority of software and connected devices. The manufacturer demonstrates conformity through **internal control** (module A, self-assessment).\n- **Important products (Annex III)**, in two classes. **Class I**: identity management systems, browsers, password managers, anti-malware software, VPN products, SIEM, boot managers, operating systems, routers and switches, among others. Self-assessment remains possible only if the manufacturer fully applies a harmonised standard, a common specification or a certification scheme; otherwise a notified body is involved. **Class II**: hypervisors and container runtime systems, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors and microcontrollers. A notified body (EU-type examination or full quality assurance) or a European certification is mandatory.\n- **Critical products (Annex IV)**: hardware devices with security boxes, smart meter gateways, smartcards and secure elements. They fall under a European cybersecurity certification scheme where one is required, otherwise under the Class II procedures.",{"type":39,"title":40,"items":41},"ul","What the CRA concretely requires",[42,43,44,45,46,47,48,49],"**Security by design**: cybersecurity risks are assessed and documented from the design phase, not handled as post-launch patches.","**Secure by default configuration**: the product ships in a safe state, with no default credentials left in place and a way to reset it to its original state. For a tailor-made product, the manufacturer and its business customer may agree on a different configuration.","**No known exploitable vulnerability** when placed on the market: dependencies are up to date, audited and fixable through security updates.","**Vulnerability handling throughout the support period**, at least five years unless the expected use time is shorter: fixes released without delay and free of charge, separately from new features where possible, and every security update kept available for at least ten years.","**Software bill of materials (SBOM)** for **all** products, in a commonly used machine-readable format, covering at least top-level dependencies. It belongs in the technical documentation; the regulation does not require you to publish it.","**Coordinated vulnerability disclosure policy**, with a contact address for third-party reports, and user information about fixed vulnerabilities.","**Reporting** of every actively exploited vulnerability and every severe incident, through the single reporting platform, within **24 hours** (early warning) and then **72 hours** (notification), since **11 September 2026**.","**CE marking**: from 11 December 2027, covered products bear the CE marking under the CRA, together with an EU declaration of conformity.",{"type":35,"title":51,"body":52},"Is your agency affected?","The CRA applies if you **make a product available on the EU market** in the course of a commercial activity — which covers far more than direct sales:\n\n- **You publish commercial software** (mobile app, installable software, desktop application) distributed to European businesses or consumers: yes, you are the manufacturer.\n- **You distribute plugins or extensions** on marketplaces (WordPress.org, Shopify App Store, Chrome\u002FFirefox extensions) and monetise them: yes.\n- **You build, on commission, a product your client will place on the market under its own brand**: your client is the manufacturer. It must exercise due diligence on the third-party components it integrates (Article 13(5)), so it will ask you for guarantees: SBOM, fixes, disclosure policy. If you sell a software component yourself as a separate product, that component is a product under the CRA and you are its manufacturer.\n- **You integrate open source libraries**: you remain responsible for the security of the whole. When you find a flaw in a component, you must report it to its maintainer and remediate it in your product.\n- **You run a SaaS or a website**: the CRA covers an online service only when it is the **remote data processing solution** of a product (for example the cloud application that controls a connected device). A standalone website or SaaS falls under NIS2 and the GDPR instead.\n- **You do R&D, undistributed prototypes or pure consulting**: outside the CRA's direct scope.\n\n**Free and open source software that its manufacturer does not monetise** is not considered supplied in the course of a commercial activity and falls outside the scope. Foundations and entities that provide sustained support to an open source project intended for commercial use come under a lighter regime, that of **open-source software stewards** (Article 24), whose reporting obligations only apply from 11 December 2027. Be careful: as soon as your agency monetises an open source plugin it publishes, the analysis changes and has to be settled case by case.",{"type":35,"title":54,"body":55},"Penalties and their logic","Article 64 of the CRA sets three ceilings for administrative fines, whichever amount is higher:\n\n1. **Non-compliance with the essential requirements of Annex I and the obligations of Articles 13 and 14** (secure design, vulnerability handling, **reporting**): up to **€15,000,000** or **2.5% of worldwide annual turnover**.\n2. **Non-compliance with the other operator obligations** (importers, distributors, authorised representatives, CE marking, declaration of conformity, assessment procedures): up to **€10,000,000** or **2%**.\n3. **Incorrect, incomplete or misleading information** supplied to notified bodies or market surveillance authorities: up to **€5,000,000** or **1%**.\n\nA late or missing report therefore falls into the highest tier, not the second one. Two exceptions apply: **micro and small enterprises** are not fined solely for missing the 24-hour early-warning deadline, and **open-source software stewards** are not subject to fines.\n\nPenalties are imposed by the **market surveillance authorities** that each Member State designates, taking into account the nature and duration of the infringement as well as the size of the company. National CSIRTs and ENISA receive the reports. The framework resembles the GDPR: the authority adjusts the penalty, but an established non-compliance is enough to make it possible.",{"type":35,"title":57,"body":58},"Reporting an exploited vulnerability: what has applied since 11 September 2026","Article 14 is the CRA's first operational obligation, and it also covers products **already on the market** before 11 December 2027 (Article 69(3)). As soon as you become aware of an **actively exploited** vulnerability in one of your products, you notify it simultaneously to the **coordinating CSIRT** of the Member State of your main establishment and to **ENISA**, through the **single reporting platform** set up by ENISA and operational since 11 September 2026. One submission is enough: the CSIRT then forwards it to the CSIRTs of the other countries where the product is distributed.\n\nReporting happens in three stages:\n\n- **Early warning within 24 hours**, indicating where possible the Member States where the product is distributed. It goes out even if no fix exists yet.\n- **Notification within 72 hours**: general information on the product, the nature of the exploit and the vulnerability, corrective measures already taken and measures users can apply, and how sensitive the information is.\n- **Final report no later than 14 days after a fix is made available**: description and severity of the vulnerability, information on the malicious actor where relevant, details of the security update.\n\nA **severe incident** affecting the security of the product follows the same 24 h \u002F 72 h pattern, with a final report within one month of the notification. The CSIRT may also request an intermediate report. In every case, you inform the affected users and the measures they can take, where appropriate in a structured, machine-readable format.\n\nTo put this into practice, the European Commission published guidance on applying the CRA on **27 July 2026**, and it maintains a page dedicated to the reporting obligations. Read both before drafting your own templates.",{"type":60,"title":61,"steps":62},"steps","Preparing your agency before December 2027",[63,66,69,72,75,78,81],{"title":64,"body":65},"Step 1 — Map your products and their classification","Inventory every product you place on the EU market (applications, plugins, components sold to third parties) and, separately, those you build for clients who market them. For each one, determine:\n- Default product, important product of Class I or II, or critical product?\n- Who is the manufacturer under the CRA: you or your client?\n- Distribution model: direct sale, marketplace, monetised open source or not?\n- Expected use time, which sets your support period (at least five years in most cases).\n\nThe classification determines the assessment procedure: internal control or notified body.",{"title":67,"body":68},"Step 2 — Generate and maintain an SBOM","The SBOM (Software Bill of Materials) lists the product's software components: third-party libraries, direct and transitive dependencies, versions and licences. The CRA requires it for **all** products, at least for top-level dependencies, in a machine-readable format such as SPDX or CycloneDX. Generate it on every build rather than once a year.\n\n```bash\n# Syft — generates a CycloneDX or SPDX SBOM from a directory or an image\ncurl -sSfL https:\u002F\u002Fget.anchore.io\u002Fsyft | sudo sh -s -- -b \u002Fusr\u002Flocal\u002Fbin\nsyft dir:\u002Fpath\u002Fto\u002Fyour\u002Fproject -o cyclonedx-json > sbom.json\n\n# Trivy — looks for known vulnerabilities from the SBOM\ntrivy sbom sbom.json\n\n# cdxgen — SBOM for Node.js, Python, PHP, Go projects\ncdxgen -t php -o sbom-php.json \u002Fpath\u002Fto\u002Fproject\n```",{"title":70,"body":71},"Step 3 — Set up vulnerability handling","The CRA requires an active process throughout the support period. In practice:\n\n1. **CVE monitoring**: alerts on your dependencies (GitHub Dependabot, npm audit, Composer audit, Trivy in CI\u002FCD), complemented by the NVD and CERT-EU feeds and by the security advisories of the vendors you integrate.\n2. **Coordinated disclosure policy**: publish a `security.txt` file at the root of `yourdomain.com` and a `SECURITY.md` in each repository, with a contact address and a committed handling time.\n3. **Fix process**: define an internal SLA (for example: CVSS ≥ 9 vulnerability → fix within 7 days) and ship security fixes separately from new features where possible.\n4. **User information**: with every fix, an advisory describes the fixed flaw, its severity and the affected versions.",{"title":73,"body":74},"Step 4 — Organise the reporting chain and prepare templates","The 24-hour deadline leaves no time to discover the procedure. Decide who qualifies a vulnerability as \"actively exploited\", who approves the submission, who drafts it and who files it on the single reporting platform, with a deputy for each role.\n\nPrepare one template per stage in advance: early warning (product, versions, countries of distribution, first findings), 72-hour notification (nature of the exploit, mitigations for users) and final report (severity, cause, fix). Have them reviewed by your legal counsel, then test the chain with a dry run.",{"title":76,"body":77},"Step 5 — Document compliance","The technical documentation includes:\n- The description of the product and its security architecture.\n- The cybersecurity risk assessment (threat modelling).\n- The security measures implemented and the tests performed.\n- The vulnerability handling and disclosure policy.\n- The SBOM.\n- The secure-use instructions and the length of the support period.\n\nIt is kept, together with the EU declaration of conformity, for **at least ten years** after the product is placed on the market, or for the whole support period if that is longer.",{"title":79,"body":80},"Step 6 — Review contracts and delivered documentation","For each client, put in writing who is the manufacturer under the CRA and who handles what during the support period: dependency monitoring, fix deadlines, SBOM hand-over, involvement in reporting. A maintenance contract that is silent on these points leaves your client alone with Article 14, and leaves you exposed to its claims.\n\nThe delivered documentation must include a secure configuration guide, the reporting procedure for users and the end date of the support period.",{"title":82,"body":83},"Step 7 — Assess whether you need a third-party audit","For **Class II** products and for **Class I** products assessed without fully applying a harmonised standard, a notified body is mandatory. The rules on notifying these bodies have applied since 11 June 2026: identify early the ones that cover your category, because their capacity will be in demand as 2027 approaches.\n\nFor **default** products, self-assessment is enough, provided you keep a complete technical file. A voluntary audit can strengthen your commercial credibility with large corporate clients, who will demand proof of CRA compliance before signing.",{"type":35,"title":85,"body":86},"The impact on your hosting infrastructure","The CRA does not target hosting services as such: a cloud service that is not designed under the responsibility of a product's manufacturer falls outside its scope, and hosting comes under NIS2 (see \u003Ca href=\"\u002Fen\u002Fblog\u002Fnis2-what-the-directive-requires-from-your-hosted-clients\">what NIS2 requires from your hosted clients\u003C\u002Fa>). The two texts add up without merging: authorities, deadlines and scopes differ, and a measure taken for one does not automatically count for the other. Your infrastructure is still involved in your CRA compliance on four points:\n\n**1. The components you run are part of the product.** If your application ships PostgreSQL, Redis or Nginx in its image, these components belong to the attack surface you document in the SBOM and monitor for CVEs.\n\n**2. The CI\u002FCD pipeline carries the checks.** Your GitHub Actions, GitLab CI or other workflows systematically run dependency scans (npm audit, Composer audit, Trivy) and block a deployment when a critical vulnerability remains unresolved.\n\n**3. Detecting an exploit requires monitoring.** The 24-hour deadline starts when you become aware of the exploitation: without alerts on abnormal behaviour and on CVEs in production components, you find out too late. A tool such as \u003Ca href=\"\u002Fen\u002Fblog\u002Fsecuring-your-vps-with-crowdsec\">CrowdSec\u003C\u002Fa> on your servers helps.\n\n**4. Incident handling requires traceability.** Your logs must be detailed enough and kept long enough to establish when and how a flaw was exploited: that is what goes into the 72-hour notifications and the final report. A server where you hold root access and choose your own logging and detection tools makes this collection far easier than a closed shared environment.",{"type":88,"title":89,"headers":90,"rows":96},"comparison","CRA vs NIS2 vs GDPR — the three key regulations",[91,92,93,94,95],"Text","Scope","Who is targeted","Date of application","Maximum fine",[97,103,109],[98,99,100,101,102],"**CRA** (Regulation 2024\u002F2847)","Products with digital elements placed on the EU market","Manufacturers, importers and distributors of software and hardware products","11 Sept 2026 (reporting) \u002F 11 Dec 2027 (all requirements)","€15M or 2.5% of worldwide turnover",[104,105,106,107,108],"**NIS2** (Directive 2022\u002F2555)","Entities in the 18 sectors of Annexes I and II (energy, health, digital infrastructure, cloud, hosting…)","Essential and important entities, including cloud, data centre, CDN, DNS and managed service providers","18 October 2024, through national transposition laws","At least €10M or 2% (essential), €7M or 1.4% (important)",[110,111,112,113,114],"**GDPR** (Regulation 2016\u002F679)","Processing of personal data of people in the EU","Any controller or processor","25 May 2018","€20M or 4% of worldwide turnover",{"type":116,"title":117,"body":118},"tip","Free SBOM tools to add to your CI\u002FCD","Generating the SBOM automatically on every build is the most cost-effective way to prepare for the CRA: it feeds both the technical documentation and vulnerability monitoring. Three open source tools to add now:\n\n**Syft** (Anchore) — generates SBOMs in SPDX and CycloneDX formats from a directory or a Docker image:\n```bash\n# Install\ncurl -sSfL https:\u002F\u002Fget.anchore.io\u002Fsyft | sudo sh -s -- -b \u002Fusr\u002Flocal\u002Fbin\n# Generate the SBOM of the current repository\nsyft dir:. -o cyclonedx-json > sbom.json\n```\n\n**Trivy** (Aqua Security) — produces a CycloneDX SBOM of a Docker image, then scans it for vulnerabilities:\n```bash\ntrivy image --format cyclonedx --output sbom.cdx.json my-app:latest\ntrivy sbom sbom.cdx.json\n```\n\n**cdxgen** (CycloneDX project) — specialised for Node.js, Python, PHP, Go, Java and Ruby projects:\n```bash\nnpx @cyclonedx\u002Fcdxgen -t php -o sbom-php.json \u002Fmy-project\n```\n\nArchive the SBOM with the artefact of every released version: when a flaw surfaces, it tells you within minutes which versions of which product are affected.",{"type":35,"title":120,"body":121},"Timeline of obligations — the first step is already behind us","The CRA applies in stages. Two intermediate deadlines come before 11 December 2027, and the heaviest one for a technical team, reporting, has been running since 11 September 2026.\n\n**The mistake to avoid**: assuming nothing is urgent before 2027. If a vulnerability in your product is exploited today and you do not report it on time, you are already in breach — including for a product placed on the market before the other requirements apply.",{"type":88,"title":123,"headers":124,"rows":128},"CRA deadlines",[125,126,127],"Deadline","What applies","What you need to have",[129,133,137,141,145],[130,131,132],"**10 Dec 2024**","Entry into force of the regulation","A first map of your products",[134,135,136],"**11 June 2026**","Rules on conformity assessment bodies (Chapter IV)","The relevant notified bodies identified, for important products",[138,139,140],"**11 Sept 2026**","Reporting of actively exploited vulnerabilities and severe incidents (Article 14), including for products already on the market","A working, tested reporting chain",[142,143,144],"**11 Dec 2027**","Full application: essential requirements, conformity assessment, CE marking","Technical file, SBOM, EU declaration of conformity",[146,147,148],"**10 years after placing on the market**, or end of the support period if later","Retention of the technical documentation and the declaration of conformity","Dated archiving, per product version",{"type":35,"title":150,"body":151},"ServOrbit and your CRA compliance","We provide VPS and hosting services that form the infrastructure your products run on. Our role in your CRA compliance is indirect but concrete:\n\n- **Environment isolation**: our VPS let you deploy separate environments per client and per criticality, limiting the blast radius of a compromise.\n- **Backups**: the on-demand snapshots included in our plans give you a documentable restore point after an incident, useful information for your reports. For a complete policy, combine them with \u003Ca href=\"\u002Fen\u002Fblog\u002Fautomate-your-vps-backups-with-restic\">off-site Restic backups\u003C\u002Fa>.\n- **Log access**: you have full access to your VPS and configure logging at application level, which incident traceability depends on.\n- **Data location**: our VPS are hosted in data centres in Europe, which helps you document where your infrastructure is located in your compliance file.",{"type":35,"title":153,"body":154},"Next steps","Reporting has been mandatory since 11 September 2026, and full compliance is expected on 11 December 2027. That is short for an agency that has never formalised its security practices.\n\n**Within 30 days:**\n1. Map your products on the EU market, identify their classification and who their manufacturer is.\n2. Appoint the people in charge of reporting, prepare the templates and get familiar with the single reporting platform.\n3. Check that your repositories have a `SECURITY.md` and your site a `security.txt`, and install Syft or Trivy in your CI\u002FCD pipeline.\n\n**Within 6 months:**\n4. Generate an SBOM for each product and each released version.\n5. Formalise your vulnerability handling process (owner, SLA, user information) and update your maintenance contracts.\n6. For important products: contact a notified body to schedule the assessment.\n\n**Before 11 December 2027:**\n7. Finalise the technical file, the EU declaration of conformity and the CE marking for every covered product.","Documentable Hosting for Your CRA Compliance","Your products need a documentable infrastructure that gives you full access to your logs. Our VPS plans give you complete control over your stack — and the audit trail your CRA file needs.","See our agency plans","\u002Fsolutions\u002Fagences",[160,177,202],{"id":161,"slug":162,"slugs":163,"title":167,"excerpt":168,"readTime":169,"views":170,"isPinned":19,"noindex":19,"publishedAt":171,"updatedAt":172,"category":173,"categories":174,"featuredImage":29,"bgImage":30,"posterImage":176,"relatedSolution":29},211,"nis2-what-the-directive-requires-from-your-hosted-clients",{"fr":164,"en":162,"ar":165,"es":166},"nis2-hebergement-obligations-clients-2026","nis2-ما-تفرضه-التوجيهات-على-عملائكم-المستضافين","nis2-obligaciones-hosting-clientes-2026","NIS2: what the directive requires from your hosted clients","NIS2: who is in scope, the ten measures of Article 21, the 24-hour and 72-hour deadlines, and what your clients will require from their hosting.",16,0,"2026-08-02T00:00:00+00:00","2026-11-09T20:55:14+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[175],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fnis2-hebergement-obligations-clients-2026-poster.svg",{"id":178,"slug":179,"slugs":180,"title":184,"excerpt":185,"readTime":186,"views":187,"isPinned":19,"noindex":19,"publishedAt":188,"updatedAt":189,"category":190,"categories":196,"featuredImage":29,"bgImage":30,"posterImage":198,"relatedSolution":199},108,"securing-your-vps-with-crowdsec",{"fr":181,"en":179,"ar":182,"es":183},"securiser-vps-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","proteger-vps-con-crowdsec","Securing your VPS with CrowdSec","Deploy CrowdSec on your VPS to block attacks thanks to behavioral detection and a shared community blocklist.",4,2,"2026-03-04T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":191,"name":192,"slug":193,"color":194,"icon":195},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[197],{"id":191,"name":192,"slug":193,"color":194,"icon":195},"\u002Fblog\u002Fcovers\u002Fsecuriser-vps-crowdsec-poster.svg",{"categorySlug":200,"appSlug":201},"cybersecurity-bastion","crowdsec",{"id":203,"slug":204,"slugs":205,"title":209,"excerpt":210,"readTime":211,"views":212,"isPinned":19,"noindex":19,"publishedAt":213,"updatedAt":214,"category":215,"categories":221,"featuredImage":29,"bgImage":30,"posterImage":223,"relatedSolution":224},160,"how-to-self-host-infisical-on-a-vps",{"fr":206,"en":204,"ar":207,"es":208},"self-host-infisical-vps","كيفية-استضافة-infisical-ذاتيا-على-خادم-vps","como-autoalojar-infisical-en-un-vps","How to Self-Host Infisical on a VPS","Deploy Infisical on your VPS in under 20 min: RBAC, automatic rotation, GitHub Actions and GitLab CI integration, plus Redis and TLS troubleshooting.",9,1,"2026-07-02T00:00:00+00:00","2026-10-16T01:57:38+00:00",{"id":216,"name":217,"slug":218,"color":219,"icon":220},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[222],{"id":216,"name":217,"slug":218,"color":219,"icon":220},"\u002Fblog\u002Fcovers\u002Fself-host-infisical-vps-poster.svg",{"categorySlug":200,"appSlug":225},"infisical",true,1794270383180]