Conformité au Règlement sur la cyber-résilience
The EU Cyber Resilience Act sets binding cybersecurity requirements for products with digital elements. Learn how ImmuniWeb supports its secure-by-design and vulnerability-handling obligations.
Conformité au Règlement sur la cyber-résilience
What Is the EU Cyber Resilience Act?
The CRA is the first horizontal EU regulation on product cybersecurity. It applies to 'products with digital elements' - software and hardware, and their remote data processing solutions - placed on the EU market, regardless of where the manufacturer is based.
Les fabricants doivent satisfaire aux exigences essentielles de cybersécurité énoncées à l’annexe I, procéder à une évaluation de la conformité, apposer le marquage CE, fournir une liste de composants logiciels (SBOM) lisible par machine, mettre en œuvre la divulgation coordonnée des vulnérabilités et fournir des mises à jour de sécurité pendant toute la période de maintenance.
See how ImmuniWeb supports CRA secure-by-design and vulnerability handling- testing your products with digital elements for exploitable vulnerabilities. Request a demoor run a free Community Edition test.
Who Must Comply with EU CRA?
The CRA applies to:
- Manufacturers of products with digital elements (software and hardware) placed on the EU market.
- Importers and distributors placing such products on the EU market.
- Non-EU manufacturers whose products reach the EU market (extraterritorial reach).
Les logiciels et composants web/mobiles concernés doivent être développés de manière sécurisée et testés pour détecter les vulnérabilités.
Key CRA Requirements for Application Security
The Annex I essential requirements drive application-security work:
- No known exploitable vulnerabilities: products must be placed on the market without known exploitable vulnerabilities.
- Secure by design:design, develop and produce products to ensure an appropriate level of cybersecurity.
- Vulnerability handling: identify and document vulnerabilities, address them without delay, and perform regular tests and reviews of product security.
- Security updates & reporting:provide security updates over the support period; report actively exploited vulnerabilities and severe incidents (from 11 September 2026).
CRA Security Requirements in Depth
No Known Exploitable Vulnerabilities & Secure by Design
Products with digital elements must be placed on the market free of known exploitable vulnerabilities and engineered to be secure by design. Penetration testing and vulnerability scanning of the software and its web and mobile components identify the exploitable issues that must be removed before release.
Vulnerability Handling and Regular Testing
L'Annexe I impose aux fabricants d'identifier et de documenter les vulnérabilités, ainsi que d'effectuer régulièrement des tests et des revues de la sécurité des produits. Le scanning continu et les tests d'intrusion périodiques — avec un suivi des corrections — opérationnalisent cette exigence tout au long de la période de support.
Risques courants des applications Web et mobiles à remédier
The vulnerabilities the CRA expects you to remove from products map closely to the OWASP Top 10 for web and mobile components:
- Broken Access Control — users reaching data or actions they should not.
- Échecs cryptographiques — chiffrement faible ou absent exposant des données sensibles.
- Injection — Injection SQL, de commande ou autre via des entrées non validées.
- Insecure Design — contrôles de sécurité manquants par conception, pas seulement à cause d'un bug.
- Mauvaise configuration de sécurité — configuration par défaut, incomplète ou non sécurisée.
- Composants vulnérables et obsolètes — bibliothèques et frameworks non patchés.
- Identification & Authentication Failures — weak login, session or credential handling.
- Échecs d'intégrité des logiciels et des données — mises à jour non fiables, pipelines CI/CD non sécurisés.
- Échecs de la journalisation et de la surveillance de la sécurité — attaques non détectées.
- Server-Side Request Forgery (SSRF) — the server tricked into making malicious requests.
For mobile apps, the OWASP Mobile Top 10 is the equivalent reference (insecure data storage, insecure communication, weak cryptography, and so on). Reliably finding these issues requires testing the running application, not just a documentation review.
How to Approach CRA Compliance with ImmuniWeb
- Inventory products & components. Map internet-facing products, apps and APIs with ImmuniWeb Discovery.
- Test for exploitable vulnerabilities with On-Demand and Neuron before release.
- Test mobile components with MobileSuite and Neuron Mobile.
- Handle vulnerabilities with regular scanning and tracked remediation.
- Secure development with Continuous in CI/CD across the support period.
- Re-test after updates and on a recurring basis.
How ImmuniWeb Helps You Achieve EU CRA Compliance
ImmuniWeb supports the CRA's secure-by-design and vulnerability-handling requirements with testing that produces conformity-ready evidence.
| Exigence | Ce que cela nécessite | Produits ImmuniWeb |
|---|---|---|
| No known exploitable vulnerabilities | Éliminer les vulnérabilités exploitables avant la publication. | On-Demand, Neuron |
| Vulnerability handling | Identify, document and regularly test product security. | Neuron, On-Demand, Discovery |
| Secure development / support period | Secure the SDLC; test across the support period. | Continuous, MobileSuite |
ImmuniWeb On-Demand and MobileSuite deliver web and mobile penetration testing; Neuron and Neuron Mobile provide automated scanning; Continuous embeds testing into CI/CD; and Discovery maps the attack surface of your products and components - together producing evidence for CRA conformity.
EU CRA vs International Frameworks
Si vous respectez déjà des normes internationales, les mêmes tests ImmuniWeb les couvrent toutes:
| Framework | Perspective sécurité des applications | Comment ImmuniWeb s'aligne |
|---|---|---|
| EU CRA | Secure-by-design + vulnerability handling for products | Tests d’intrusion Web/mobile + scans + ASM |
| EU NIS 2 | Organisational risk-management measures | Les mêmes tests couvrent les deux |
| Loi européenne sur l’IA | Cybersecurity of high-risk AI | Securing apps and components around AI |
| ISO/IEC 27001 | Annexe A: contrôles techniques | Tests comme preuve de contrôle |
Tests d'intrusion vs scans de sécurité
Les deux sont nécessaires. Le scan automatisé (DAST) offre une couverture large et fréquente et est idéal pour les tests continus dans le CI/CD ; le penetration testing manuel trouve les vulnérabilités de logique métier et complexes que les scanners manquent et produit la profondeur attendue par les auditeurs et les régulateurs. Combinez le scanning continu avec du penetration testing manuel périodique, et re-testez après des changements significatifs.
Liste de contrôle de conformité (Sécurité des applications)
- Products with digital elements and their components inventoried
- Products tested and free of known exploitable vulnerabilities
- Pratiques de conception sécurisée documentées
- Vulnerability handling process with regular testing in place
- Security updates provided across the support period
- Reporting workflow ready for the 11 September 2026 obligations
- Preuves de conformité et SBOM maintenues
Why EU CRA Compliance Matters
After 11 December 2027, products that fail CRA conformity cannot legally be placed on the EU market, and non-compliance can attract fines of up to EUR 15 million or 2.5% of global annual turnover. From 11 September 2026, manufacturers must already report actively exploited vulnerabilities and severe incidents on tight deadlines.
Because exploitable vulnerabilities in software and its web and mobile components are exactly what the CRA targets, demonstrable testing is one of the most direct ways to meet the essential requirements and protect EU market access.