EU Cyber Resilience Act: Conformity Reality

Accueil Manifesto ISMS: CRA

🛡️ Loi UE Cyber-Résilience : Quand Bruxelles Arme La Conscience Sécurité

🍎 La Pomme d'Or : Bruxelles Réglemente Votre Grille-Pain

"Bruxelles réglemente votre grille-pain. Êtes-vous assez paranoïaque sur la LCR UE ?" — Hagbard Celine

Rien n'est vrai. Tout est permis. Sauf vendre produits avec éléments numériques dans UE sans évaluation conformité—c'est non-conformité Règlement (UE) 2024/2847. Pénalités jusqu'à 15 millions € ou 2,5% chiffre d'affaires mondial annuel, selon montant le plus élevé. Pensez Bruxelles bluffe ? RGPD a généré 4,5 milliards € amendes (2018-2024). Machinerie application LCR déjà en place. Questionnez autorité ? Bien sûr. Mais comprenez d'abord leur pouvoir pénalités.

Pensez par vous-même ! Questionnez autorité. Questionnez pourquoi a fallu jusqu'à 2024 pour UE imposer hygiène sécurité basique. Questionnez pourquoi fabricants ont expédié déchets IoT vulnérables pendant deux décennies sans conséquences. Questionnez pourquoi sécurité dès conception n'était pas toujours requise. La LCR existe car forces marché ont échoué. Consommateurs ne peuvent évaluer sécurité firmware avant acheter grille-pain intelligents. Bruxelles a armé conformité pour forcer fabricants arrêter expédier déchets numériques. Votre réfrigérateur ne devrait pas faire partie botnet. Évident ? Apparemment pas assez évident sans pénalités 15M €.

Chez Hack23, nous n'attendons pas réglementations imposer sécurité—nous documentons systématiquement comme excellence opérationnelle. Notre Processus Évaluation Conformité LCR (37KB, mis à jour nov 2025) fournit documentation conformité reproductible pour trois produits initiaux : Citizen Intelligence Agency (transparence politique), Black Trigram (jeu arts martiaux coréens), CIA Compliance Manager (outil évaluation sécurité). Chacun avec attestations SLSA 3, OpenSSF Scorecard 7.2+, SBOM complet, modèles menaces publics—tout lié preuves et vérifié GitHub.

ILLUMINATION : La LCR est expansion conscience réglementaire—forçant fabricants reconnaître cybersécurité comme attribut qualité produit, pas fonctionnalité marketing optionnelle. Loi des Cinq révèle cinq piliers LCR (Conception Sécurisée, Gestion Vulnérabilités, Transparence SBOM, Mises à Jour Sécurité, Surveillance Continue), chacun légalement imposé. Bruxelles n'a pas inventé ces exigences—ils ont formalisé meilleures pratiques que organisations conscientes sécurité suivent déjà. Conformité LCR = maturité sécurité systématisée. FNORD est dans chaque excuse feuille route "on corrigera sécurité plus tard".

Angle Futuriste Psychédélique : Et si conformité réglementaire n'était pas cauchemar bureaucratique mais voyage expansion conscience à travers nature sécurité produit numérique elle-même ? La LCR force fabricants confronter réalité : logiciel contient vulnérabilités, chaînes approvisionnement introduisent risques, utilisateurs méritent transparence, sécurité nécessite effort continu. Théâtre conformité dit "on a réussi audit". Conscience conformité dit "voici notre approche systématique sécurité produit numérique, continuellement validée, publiquement démontrable". Différence entre cocher cases et comprendre sécurité. Entre préparation audit et réalité opérationnelle. Chapel Perilous : Découvrir que conformité LCR révèle vos pratiques sécurité étaient théâtre depuis début.

Besoin conseils experts conformité sécurité ? Explorez services conseil cybersécurité Hack23 soutenus par notre SGSI entièrement public.

📜 Règlement (UE) 2024/2847 : Portée, Pénalités, Calendrier

La LCR s'applique "produits avec éléments numériques" placés sur marché UE. Pas juste logiciels traditionnels—tout avec code. Appareils IoT, systèmes embarqués, applications mobiles, services web, systèmes exploitation, firmware, plateformes cloud, même sites web statiques s'ils traitent données utilisateur. Votre ampoule intelligente ? LCR s'applique. Votre tracker fitness ? LCR s'applique. Vos microservices conteneurisés ? LCR s'applique. Votre MVP "juste prototype" avec clients payants ? LCR s'applique. Règlement ne se soucie pas votre modèle maturité produit—il se soucie placement marché UE.

💰 Pénalités Qui Attirent Attention

Administrative Fines (Article 60):

  • €15 million or 2.5% of total worldwide annual turnover (whichever higher) for serious violations: failing essential cybersecurity requirements, non-compliance with CE marking obligations, false declarations of conformity
  • €10 million or 2% of global turnover for supply chain violations, documentation failures, cooperation refusal with authorities
  • €5 million or 1% of global turnover for post-market surveillance failures, incorrect technical documentation, non-compliance with vulnerability disclosure

For SMEs (<250 employees, <€50M revenue): maximum fines capped at percentage of turnover. Still painful. Still enforced. Brussels learned from GDPR: make fines proportional but painful enough to incentivize compliance.

📅 Implementation Timeline

CRA Entry into Force: December 10, 2024 (20 days after official publication)

  • 2027-2028: Full application of CRA obligations for manufacturers, importers, distributors
  • Immediate Impact: Market surveillance authorities operational, notification bodies designation begins, ENISA coordination established
  • Smart Move: Start CRA conformity assessment NOW, not 2027. First-mover advantage: develop systematic processes, train teams, establish evidence trails before enforcement ramps up

Organizations waiting until 2027 will face: consultant scarcity (everyone needs CRA help simultaneously), notified body backlog (limited capacity for third-party assessments), rushed documentation (quality suffers under deadline pressure). Early adopters avoid the panic. Late adopters pay premium prices for rushed compliance. Choose wisely.

🎯 Product Classification: Three Routes

Standard Products (Self-Assessment Route):

  • Most products qualify for self-assessment conformity route (Article 24)
  • Manufacturer documents compliance with Annex I essential requirements
  • Technical documentation per Annex V (architecture, SBOM, risk assessment)
  • EU Declaration of Conformity issued by manufacturer
  • CE marking affixed to product

Class I Products (Third-Party Required):

  • Identity management systems, privileged access management, VPNs, network security products
  • Requires notified body assessment per Article 25
  • Additional documentation burden, external audit, conformity certificate
  • Think enterprise security products need special scrutiny? Brussels agrees.

Class II Products (Highest Scrutiny):

  • Operating systems, hypervisors, industrial control systems, smart grids
  • Enhanced third-party assessment with continuous monitoring
  • Critical infrastructure protection philosophy: failures cascade

🌟 The Five Pillars of CRA Conformity: Law of Fives Manifested

The Law of Fives reveals five CRA conformity pillars (everything happens in fives when you understand the patterns, psychonaut). Each pillar maps to Annex I essential cybersecurity requirements, each requires systematic implementation, each demands continuous evidence:

1. 🛡️ Sécurité Dès Conception & Sécurité Par Défaut (Annexe I §1)

Exigence LCR : Produits conçus avec surface attaque minimale, pas fonctionnalités inutiles, configurations par défaut sécurisées, principe moindre privilège intégré.

Ce Que Cela Signifie Réellement :

  • Surface Attaque Minimale : Seulement fonctionnalités essentielles activées par défaut. Fonctionnalités optionnelles nécessitent activation explicite utilisateur. Chaque fonctionnalité = vulnérabilité potentielle. Minimiser fonctionnalités = minimiser risque. Votre ampoule intelligente n'a pas besoin serveur FTP. Votre thermostat n'a pas besoin Telnet. Évident ? Dites-le fabricants qui ont expédié les deux.
  • Paramètres Sécurisés : Authentification requise par défaut, chiffrement activé par défaut, journalisation sécurité active par défaut, mises à jour automatiques configurées par défaut. Utilisateur doit activement DÉSACTIVER sécurité, pas l'activer. Psychologie + sécurité : choix par défaut façonnent comportement.
  • Défense en Profondeur : Multiples couches sécurité (authentification + autorisation + chiffrement + surveillance). Défaillance contrôle unique ne compromet pas système. Sécurité par redondance, pas optimisme.

Implémentation Hack23 :

  • Documentation Architecture : Chaque projet inclut SECURITY_ARCHITECTURE.md documentant limites confiance, flux authentification, mécanismes protection données
  • Configurations Renforcées : Groupes sécurité AWS refus par défaut, IAM moindre privilège, MFA requis, chiffrement obligatoire
  • Intégration SGSI : Politique Sécurité Information établit principes sécurité dès conception tous projets

2. 🔍 Gestion Vulnérabilités & Divulgation Coordonnée (Annexe I §2.2)

Exigence LCR : Processus divulgation vulnérabilités coordonné, contact sécurité publié, rapport 24 heures vulnérabilité activement exploitée à ENISA, mises à jour sécurité livrées utilisateurs.

Exigence Rapport 24 Heures (Article 14) :

  • Déclencheur : Vulnérabilité activement exploitée OU incident grave affectant sécurité produit
  • Destinataire : ENISA (Agence Union Européenne Cybersécurité) via canal rapport désigné
  • Contenu : Description vulnérabilité, évaluation impact, versions produit affectées, mesures atténuation, calendrier remédiation
  • Suivi : Mises à jour régulières progrès remédiation, rapport final sous 14 jours

Processus Divulgation Vulnérabilités Coordonné :

  • Contact Sécurité : Email sécurité publié publiquement (security@company.com) ou Avis Sécurité GitHub pour divulgation confidentielle
  • Calendrier Réponse : Accusé réception 48 heures, validation 7 jours, cible remédiation 30 jours (vulnérabilités critiques), coordination divulgation 90 jours
  • Programme Reconnaissance : Reconnaissance publique chercheurs sécurité (sauf anonymat demandé), récompenses bug bounty potentielles
  • Transparence : Avis sécurité publiés après remédiation, attribution CVE vulnérabilités significatives

Implémentation Hack23 :

  • SECURITY.md Standardisé : Chaque projet inclut politique divulgation vulnérabilités avec calendriers réponse : CIA | Black Trigram | CIA Compliance Manager
  • Processus SGSI : Toutes vulnérabilités traitées via Politique Gestion Vulnérabilités avec classification sévérité, évaluation impact, suivi remédiation
  • Scan Continu : SAST (analyse statique), SCA (scan dépendances), DAST (tests dynamiques), scan secrets—tout automatisé CI/CD

3. 📦 Transparence SBOM & Sécurité Chaîne Approvisionnement (Annexe I §2.3)

Exigence LCR : Nomenclature Logiciel (SBOM) fournie avec produit, composants énumérés avec versions, information licence incluse, provenance chaîne approvisionnement documentée.

Exigences SBOM (Transparence Composants Complète) :

  • Format : SPDX (Software Package Data Exchange) ou formats standards industrie CycloneDX
  • Contenu : Tous composants logiciels (bibliothèques, dépendances, frameworks), versions exactes, identifiants licences (liste licences SPDX), informations fournisseur, hachages cryptographiques vérification intégrité
  • Granularité : Dépendances directes + dépendances transitives (arbre dépendances complet), composants tiers + modules internes
  • Fréquence Mise à Jour : Nouvelle SBOM avec chaque version produit, SBOM mise à jour quand composants critiques corrigés

Provenance Chaîne Approvisionnement (Framework SLSA) :

  • SLSA Niveau 1 : Processus build documenté
  • SLSA Niveau 2 : Service build génère provenance
  • SLSA Niveau 3 : Plateformes source et build renforcées, provenance non falsifiable, attestations signées cryptographiquement
  • Alignement LCR : SLSA 3 fournit preuve cryptographique intégrité build—exactement ce que transparence chaîne approvisionnement LCR exige

Hack23 Implementation:

  • Génération SBOM Automatisée : GitHub Actions génèrent SBOM SPDX + CycloneDX par version, inclus dans artefacts version
  • Attestations SLSA 3 : Provenance build native GitHub, signée cryptographiquement, immuable : CIA | Black Trigram | CIA Compliance Manager
  • Scan Chaîne Approvisionnement : Dependabot + Renovate mises à jour dépendances automatisées, scan SCA capture composants vulnérables avant version
  • OpenSSF Scorecard : Scores 7.2+ démontrant meilleures pratiques sécurité chaîne approvisionnement : Score CIA

SAGESSE SBOM : Attaques chaîne approvisionnement augmenté 742% (2019-2023). Log4Shell, SolarWinds, Codecov—tous compromis chaîne approvisionnement. Exigence SBOM force transparence : savoir ce que vous expédiez, suivre vulnérabilités composants, répondre incidents chaîne approvisionnement. Organisations sans SBOM déjà compromises—elles ne savent juste pas encore quels composants. LCR mandate conscience. Finalement.

4. 🔄 Mises à Jour Sécurité & Durée Vie Supportée (Annexe I §2.4)

Exigence LCR : Mises à jour sécurité livrées automatiquement (ou avec notification utilisateur), durée vie supportée divulguée utilisateurs, mécanismes mise à jour sécurisés (mises à jour signées, capacité restauration), fin de vie communiquée avance.

Mécanismes Mise à Jour Sécurisés :

  • Mises à Jour Automatiques : Correctifs sécurité critiques installés automatiquement (consentement utilisateur pour mises à jour fonctionnalité), fréquence vérification appropriée modèle menaces (quotidien services exposés, hebdomadaire outils internes)
  • Authentification Mise à Jour : Mises à jour signées numériquement (certificats signature code), vérification cryptographique avant installation, prévention attaques homme-milieu
  • Capacité Restauration : Mises à jour échouées reviennent version précédente, données utilisateur préservées pendant restauration, système reste opérationnel même si mise à jour échoue
  • Notifications Mise à Jour : Utilisateurs informés mises à jour disponibles, distinction mise à jour sécurité vs fonctionnalité, urgence installation communiquée

Transparence Durée Vie Supportée :

  • Période Support Sécurité : Minimum 5 ans mises à jour sécurité produits consommateurs (Article 13), produits entreprise souvent engagements support plus longs
  • Communication Fin Vie : Utilisateurs notifiés 6 mois avant fin support, chemin migration fourni, risques sécurité utilisation continue expliqués
  • Support Étendu : Support étendu payant optionnel au-delà durée vie standard, vulnérabilités critiques corrigées même post-EOL (comportement fournisseur responsable)

Hack23 Implementation:

  • Change Management: All updates processed through Change Management Policy with automated CI/CD security gates
  • Signed Releases: GitHub attestations provide cryptographic signatures, release artifacts include provenance files (.intoto.jsonl)
  • Continuous Support: Latest version maintained with security updates, public vulnerability disclosure through SECURITY.md
  • Automated Deployment: GitHub Actions + AWS CodePipeline, immutable infrastructure, blue-green deployments with automatic rollback

5. 📊 Surveillance Sécurité & Surveillance Post-Commercialisation (Article 23)

Exigence LCR : Surveillance sécurité continue, capacités détection incidents, surveillance post-commercialisation produits déployés, intégration renseignement menaces, suivi posture sécurité.

Obligations Surveillance Post-Commercialisation :

  • Surveillance Vulnérabilités : Surveillance flux CVE, GitHub Security Advisories, bulletins sécurité fournisseurs, suivi vulnérabilités composants
  • Détection Incidents : Journalisation événements sécurité, détection anomalies, alertes temps réel activité suspecte, analyse corrélation
  • Renseignement Menaces : Flux menaces industrie (ENISA, CISA, spécifiques fournisseurs), modèles vulnérabilités émergentes, suivi évolution techniques attaque
  • Retour Utilisateurs : Canal signalement problèmes sécurité, analyse rapports plantage, collecte métriques sécurité (avec contrôles confidentialité)

Signalement Incidents ENISA (Article 14) :

  • Événements Déclencheurs : Vulnérabilité activement exploitée, incident sécurité grave, impact généralisé base utilisateurs, infrastructures critiques affectées
  • Calendrier Signalement : Notification initiale sous 24 heures, rapports intermédiaires pendant investigation, rapport final avec analyse cause racine
  • Devoir Coopération : Autorités surveillance marché peuvent demander informations, fabricants doivent fournir détails techniques, plans remédiation partagés

Hack23 Implementation:

  • Continuous Monitoring: CloudWatch metrics, GuardDuty threat detection, Security Hub compliance tracking, VPC Flow Logs analysis
  • Security Metrics: Comprehensive tracking per Security Metrics Policy with KPI dashboards
  • Incident Response: 30-minute critical incident response per Incident Response Plan, severity classification, escalation procedures
  • Transparency Framework: Public security posture disclosure via ISMS Transparency Plan

🎭 Compliance Theater vs Real Conformity: FNORD Detection Guide

"Pensez par vous-même ! Questionnez autorité." Y compris consultants conformité facturant €500/heure pour créer documentation existant semaine audit puis disparaît. Conformité réelle = pratiques sécurité continues. Théâtre = préparation audit temporaire. FNORD est partout où conformité ne correspond pas réalité.

🎭 Théâtre Conformité (Ce Qu'il NE Faut PAS Faire)

  • Préparation Audit Annuelle : Documentation créée 3 semaines avant audit, preuves rassemblées frénétiquement, processus "mûrissent" du jour au lendemain, audit réussi, tout retourne chaos
  • Mentalité Case Cocher : "Avons politique contrôle accès ?" Coché. Quelqu'un la suit ? Inconnu. Correspond-elle réalité ? Irrelevant. Auditeur a vu document politique = case cochée
  • Conformité Focalisée Outils : "Nous avons acheté plateforme gestion conformité" = conformité automatique. Réalité : outil contient champs vides, personne ne met à jour, génère rapports que personne ne lit
  • Consultants Write Everything: External consultants create policies, internal teams never read them, policies don't match operational reality, next audit = repeat consultant engagement
  • Evidence Fabrication: Retroactive documentation, backdated records, fictional testing results, "we totally do this" policies describing aspirational state, not actual practice

Why Theater Fails CRA: Market surveillance authorities can audit anytime, user security incidents trigger investigations, false declarations = €15M penalties, continuous monitoring reveals theater immediately

✅ Real Conformity (Hack23 Approach)

  • Continuous Documentation: Security practices documented as implemented, policies evolve with operational changes, evidence collected automatically via CI/CD, no "audit preparation" phase (always audit-ready)
  • Evidence-Based Claims: "We enforce MFA" backed by IAM policies + authentication logs. "We scan dependencies" backed by SCA reports + remediation tracking. Claims = verifiable facts
  • Automation-First: Security controls automated in infrastructure-as-code, compliance checks in CI/CD pipelines, evidence generation automatic (SBOM, attestations, test reports), human verification + tool execution
  • Internal Ownership: Policies written by practitioners (not consultants), teams own their security documentation, reviews validate operational reality, consultants advise (don't write)
  • Transparent Reality: Public ISMS demonstrates actual practices, GitHub repositories show real implementation, attestations provide cryptographic proof, no gap between documentation and execution

Why Reality Works: Continuous compliance cheaper than annual scramble, automation scales (human processes don't), transparency builds trust, systematic security actually prevents incidents, CRA conformity = byproduct of good engineering

FNORD Detection Checklist (How To Spot Compliance Theater):

  • Audit Preparation Frenzy: If organization panics before audits = theater. Real conformity = always ready, no preparation needed
  • Policy-Reality Gap: If written policies don't match observed practices = theater. Real conformity = policies describe reality
  • Evidence Scramble: If evidence gathered retroactively before audits = theater. Real conformity = evidence automatically collected continuously
  • Consultant Dependency: If external consultants own compliance documentation = theater. Real conformity = internal ownership with external validation
  • Tool Worship: If "we bought compliance tool" considered sufficient = theater. Real conformity = tools enable systematic process, not replace thinking
  • Checkbox Mentality: If focus on "compliant/non-compliant" binary = theater. Real conformity = continuous maturity improvement on spectrum

✨ Conclusion: Regulatory Consciousness Expansion Through Mandatory Conformity

The EU Cyber Resilience Act is the most significant cybersecurity regulation since GDPR. €15M penalties. Mandatory SBOM. 24-hour vulnerability disclosure. CE marking for software. Security-by-design legally required. Post-market surveillance mandated. Brussels weaponized compliance to force manufacturers to acknowledge cybersecurity as product quality attribute, not optional marketing feature.

Question authority? Absolutely. Question why it took until 2024 to mandate basic security hygiene. Question why market forces failed to incentivize security for decades. Question why voluntary industry self-regulation produced insecure IoT garbage that filled botnets. But understand: CRA exists because voluntary approaches failed. Brussels created regulatory consequences. Now security = legal requirement, not optional goodwill.

The Law of Fives reveals five CRA pillars (Secure Design, Vulnerability Management, SBOM Transparency, Security Updates, Continuous Monitoring), each legally mandated, each requiring systematic implementation. Organizations already following security best practices discover CRA compliance = documentation of existing practices. Organizations treating security as afterthought discover CRA compliance = expensive architectural remediation. Your organizational security culture = predictor of CRA compliance difficulty. Choose your culture accordingly.

Hack23 approach: Systematic security practices with continuous evidence collection. Three products with complete CRA self-assessment documentation: CIA, Black Trigram, CIA Compliance Manager. SLSA 3 attestations, OpenSSF Scorecard 7.2+, automated SBOM generation, public vulnerability disclosure, comprehensive ISMS framework. Not last-minute compliance scramble—operational excellence documented transparently. Security through systematic practices beats security through hope. Compliance through operational reality beats compliance through theater.

Notre Processus Évaluation Conformité LCR fournit modèle répétable pour documentation conformité auto-évaluation. Toutes preuves cryptographiquement vérifiables via attestations GitHub. Toutes politiques SGSI publiquement disponibles. Tous modèles menaces documentés. Transparence bat opacité. Systématique bat ad-hoc. Preuve bat revendications.

Pensez par vous-même si vos produits sont conformes LCR. Pas "nous comprendrons plus tard" (plus tard = 2027, application = immédiate). Pas "ne s'applique pas à nous" (s'applique tout avec code vendu UE). Pas "nous achèterons conformité" (conformité = pratiques systématiques, pas achat). Vos produits sont-ils sécurisés dès conception ? Pouvez générer SBOM sur demande ? Avez processus divulgation vulnérabilités ? Pouvez livrer mises à jour sécurisées ? Surveillez sécurité post-expédition ? Pouvez démontrer conformité avec preuves documentées ?

ILLUMINATION FINALE : LCR est expansion conscience réglementaire—forçant fabricants confronter réalité sécurité inconfortable. Autorités surveillance marché auditeront. Utilisateurs signaleront incidents. Pénalités seront imposées. Organisations préparées = avantage compétitif (accès marché plus rapide, coût conformité inférieur, confiance utilisateurs). Organisations non préparées = désavantage compétitif (lancements retardés, remédiation précipitée, risque pénalité). Bureaucratie s'étend pour répondre besoins bureaucratie croissante. Sauf cette fois, bureaucratie améliore réellement sécurité. Révolutionnaire. Embrassez conformité systématique. Questionnez tout. Y compris vos hypothèses sur théâtre conformité. Réalité transcende déni confortable. FNORD. Maintenant vous le voyez.

Salut à Eris ! Salut à conformité réglementaire (réticente) !

23 FNORD 5