Cybersecurity Resilience Act vs PSTI Act : différences clés, conformité et sanctions

Le Cyber Resilience Act de l'Union européenne, le CRA, marque un tournant dans la manière dont les produits numériques sont conçus, maintenus et mis sur le marché. Il place la cybersécurité au cœur de la conception des produits, de la première ligne de code à la dernière mise à jour.

Alors que la loi britannique sur la sécurité des produits et les infrastructures de télécommunications, PSTI, poursuit un objectif similaire au niveau national, le CRA établit un cadre plus large et plus strict pour quiconque propose des produits numériques dans l'ensemble de l'UE.

Comprendre la différence entre les deux actes, et savoir quand ils s'appliquent, est essentiel pour les entreprises opérant à l'international, en particulier celles des secteurs qui dépendent de produits numériques ou de services connectés.

CRA vs PSTI Act : une comparaison côte à côte 

Aspect	UK PSTI Act	EU CRA
Juridiction et portée	S'applique uniquement au Royaume-Uni. Cible les fabricants non britanniques vendant des appareils IoT ou intelligents au Royaume-Uni.	S'applique à l'ensemble des 27 États membres de l'UE. Couvre les fabricants de l'UE et hors UE proposant des produits avec des éléments numériques dans l'UE.
Produits concernés	Produits grand public « connectables » : appareils IoT ou intelligents se connectant à Internet ou à un réseau domestique.	Tous les produits comportant des éléments numériques : matériel ou logiciel pouvant se connecter à un appareil ou à un réseau. Comprend à la fois les systèmes grand public et industriels.
Exigences de sécurité clés	Trois obligations fondamentales : aucun mot de passe par défaut, un moyen de signaler les vulnérabilités et la transparence sur les périodes de mise à jour.	Sécurité sur l'ensemble du cycle de vie : principes de sécurité dès la conception et par défaut, évaluation des risques, gestion des vulnérabilités, divulgation obligatoire et correctifs en temps utile.
Processus de conformité	Auto-déclaration via une Déclaration de conformité. Aucun test par un tiers requis.	Les évaluations de conformité varient selon le risque. Les produits critiques peuvent nécessiter une certification indépendante avant leur entrée sur le marché de l'UE.
Autorité de contrôle	Bureau britannique pour la sécurité et les normes des produits (OPSS).	Autorités nationales de surveillance du marché dans chaque État membre de l'UE.
Pénalités	Jusqu'à 10 millions de livres sterling ou 4 % du chiffre d'affaires mondial (le montant le plus élevé étant retenu) et des amendes journalières pouvant atteindre 20 000 livres sterling.	Jusqu'à 10 millions de livres sterling ou 4 % du chiffre d'affaires mondial (le montant le plus élevé étant retenu) et des amendes journalières pouvant atteindre 20 000 livres sterling. Jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial pour les violations graves ; paliers inférieurs à 10 M€/2 % et 5 M€/1 %.
Calendrier	En vigueur en avril 2024 (période de transition terminée).	Entrée en vigueur en décembre 2024. Conformité obligatoire d'ici décembre 2027.

Quand les entreprises britanniques doivent-elles se conformer au Cyber Resilience Act ? 

Bien que le Royaume-Uni ne fasse plus partie de l'UE, le Cyber Resilience Act s'applique aux entreprises britanniques qui vendent, distribuent ou fournissent des produits comportant des éléments numériques à des clients de l'UE.

Si votre organisation développe ou vend des logiciels, des appareils connectés ou des systèmes numériques mis sur le marché de l'UE, directement ou via des distributeurs, vous relevez du champ d'application du CRA.

En d'autres termes, si vous proposez vos services en dehors du Royaume-Uni, et que ces services ou produits sont disponibles dans les pays de l'UE, vous devez vous conformer au Cyber Resilience Act.

Le CRA est officiellement entré en vigueur en décembre 2024, avec une période de transition de trois ans. D'ici décembre 2027, toutes les entreprises concernées devront démontrer leur conformité, tandis que les exigences de signalement des vulnérabilités s'appliqueront déjà d'ici fin 2026.

Pour les entreprises britanniques, cela signifie planifier :

• Identifiez tous les produits numériques proposés sur les marchés de l'UE.

• Intégrer les pratiques de sécurité dès la conception tout au long du cycle de développement.

• Documenter les mesures de cybersécurité et les plans de réponse aux incidents.

• Préparez-vous aux évaluations de conformité, en particulier si vos produits relèvent de catégories critiques.

Ne pas agir rapidement pourrait signifier être bloqué pour la vente sur le marché de l'UE ou faire face à des pénalités importantes une fois l'application commencée.

Quand le Cyber Resilience Act ne s'applique-t-il pas ?

Il existe quelques cas où le CRA ne s'applique pas :

• Pas d'accès au marché de l'UE : Si vos produits ou logiciels ne sont pas mis à disposition dans l'UE, les obligations du CRA ne s'appliquent pas.

• Secteurs déjà réglementés : Les dispositifs médicaux, les systèmes automobiles et les produits de l'aviation civile sont exemptés, car ils sont régis par des règles de cybersécurité dédiées dans le cadre des réglementations européennes existantes.

• Logiciel open source non commercial : Les projets open source développés ou distribués en dehors d'une activité commerciale sont exclus. Toutefois, une fois intégrés dans un produit commercial, le CRA s'applique.
• Modèles de services purs : Les produits cloud ou SaaS sans « produit » physique ou numérique mis sur le marché peuvent relever d'autres législations (par exemple la directive NIS2) plutôt que du CRA.

Sanctions en cas de non-conformité 

Les cadres britannique et européen introduisent tous deux des sanctions strictes en cas de non-conformité.

En vertu de la loi PSTI : 

• Amendes jusqu'à10 millions £ ou 4 % du chiffre d'affaires annuel mondial, selon le montant le plus élevé.

• Pénalités journalières jusqu'à£20,000 pour non-conformité continue.

• Rappel potentiel ou avis d'arrêt pour des produits déjà sur le marché.

Dans le cadre du Cyber Resilience Act : 

• Jusqu'à15 millions € ou 2,5 % du chiffre d'affaires mondial pour les infractions graves.

• 10 millions € ou 2 % pour des violations mineures.

• 5 millions € ou 1 % pour fausses déclarations ou informations trompeuses fournies aux autorités.

• Les régulateurs nationaux peuvent ordonner le retrait du marché ou le rappel de produits non conformes.

Au-delà des sanctions financières, la non-conformité risque de nuire à la réputation, d'entraîner la perte de clients et l'exclusion de l'un des plus grands marchés numériques mondiaux.

À quoi ressemble une conformité pratique ? 

Considérez la préparation au CRA comme une discipline produit plutôt qu'un exercice administratif.

Start by defining security requirements from the outset and recording the threats you are designing against. Maintain a software bill of materials, SBOM, for each release so you can trace third-party code and respond quickly when a component becomes vulnerable. Ensure your update process uses signed packages, prevents rollback to known-weak versions and supports staged rollouts with telemetry so you can monitor health and reverse safely if needed. 

Make your vulnerability disclosure policy public and run a coordinated process internally to triage, fix and communicate issues. Provide clear information to users about security features, support periods and update behaviour. Keep a concise technical file for each product that brings all this evidence together: requirements and threat model, SBOMs, test outcomes, update policy, disclosure records and incident logs. It will save time—and cost—when you face a conformity review. 

Les fournisseurs font partie de votre produit.

Contracts should set expectations for patch timelines by severity, notification windows, proof of conformity and cooperation during incidents. Align your CI/CD pipelines to generate and store the artefacts you will need: SBOMs, signatures, test results and release notes. Measure progress with a handful of leading indicators such as time to patch critical issues, SBOM coverage across products and releases, the share of suppliers under CRA-aligned clauses, and the proportion of releases that pass security gates. 

Qui porte l'obligation ?

The manufacturer bears primary responsibility under the Cyber Resilience Act. If the manufacturer is outside the EU, an EU-based authorised representative and importers share duties to ensure compliance and keep documentation available. Distributors must check that conformity markings and user information, including the declared security support period — are present. Contracts should allocate these tasks clearly, including who maintains the technical file and who submits regulatory reports. 

Classes de produits et parcours d'évaluation

La plupart des logiciels grand public et de nombreux produits connectés suivront une voie d'évaluation interne, à condition que vous puissiez démontrer des pratiques de sécurité dès la conception, un mécanisme de mise à jour durable et des informations utilisateur claires.

Products with higher potential impact, because they control sensitive processes, are widely deployed or create a significant attack surface, may need independent evaluation. The triggers are predictable: safety implications, systemic dependency, a serious vulnerability history or links to critical infrastructure. Plan for the strictest product in your portfolio and your entire programme will benefit. 

Surveillance post-commercialisation

La conformité au CRA se poursuit après la mise sur le marché. 

Track vulnerabilities and incidents affecting your product, assess severity, and publish updates within the declared support window. Keep an auditable log of findings, triage decisions, advisories and the dates you informed users and authorities. Tie this cadence to your regular release train rather than treating it as an ad-hoc task.  

Signalement des vulnérabilités dans le cadre du CRA

Le CRA introduit une notification à délai contraint des vulnérabilités activement exploitées ou graves et des incidents significatifs.

The manufacturer, or the authorised representative in Europe, will need to notify the designated authority through the EU portal within short windows. This is separate from your public disclosure to customers and from community reporting through your VDP. Assign roles, prepare templates and rehearse the process so you can act in days, not weeks. 

Ce que vos utilisateurs devraient voir

ach product should include a concise security notice that states the security support period, explains how updates are delivered and verified, points to the vulnerability reporting route, and notes any necessary secure configuration by the user. Host this online and reference it in packaging, app store listings and admin consoles.  

Cas particuliers des logiciels et services

Mobile and desktop apps distributed to EU users are typically treated as products with digital elements, so they fall within scope. Embedded SDKs inherit scope when they ship as part of a product. Community open-source remains exempt until it enters a commercial build; at that point, you must track it in the SBOM and maintain updates. If you reach EU users through a marketplace or an EU-based reseller, that counts as placement on the EU market. 

Secteurs qui devraient prioriser la préparation au CRA

Commerce de détail

Retail runs on connected tech: POS terminals, handhelds, kiosks, in-store Wi-Fi, smart shelving, beacons and a stack of mobile and web apps. These are “products with digital elements” or depend on them, which brings CRA obligations into the procurement and operations flow. 

Où les lacunes apparaissent généralement

• Parcs d'appareils non gérés en magasin: configurations par défaut faibles, correctifs incohérents, durcissement ad hoc.
  Prolifération des fournisseurs: plusieurs fournisseurs de POS, d'applications et de paiements avec une maturité de sécurité inégale.

• Chemins de mise à jour fragiles: déploiements de correctifs sans plans de restauration, inventaire limité de composants logiciels.

Ce qu'il faut prioriser ce trimestre

• Référentiel des actifs et nomenclature logicielle (SBOM) pour les technologies en magasin et les applications clients.

• Mécanisme de mise à jour sécurisé pour les points de vente, les bornes interactives et les applications mobiles, avec des mises à jour signées et des déploiements progressifs.

• Politique de divulgation des vulnérabilités (VDP) and intake workflow; publish the security support period for customer apps and connected devices. 

• Avenants au contrat pour le CRA avec les principaux fournisseurs : délais de divulgation, SLA de correctifs, preuves des évaluations de conformité.

MTTR des correctifs pour les appareils en magasin ; % d'actifs couverts par un SBOM ; % de fournisseurs sous clauses alignées sur le CRA ; % d'applications avec contrôles d'intégrité des mises à jour intégrées.

Les KPI qui comptent

Si vous avez besoin d'aide pour la conformité et pour vous assurer d'être bien préparé au CRA, consultez notre vente au détail offre.

Avec notre accompagnement, vous bénéficiez d'évaluations de sécurité approfondies qui évaluent votre préparation non seulement au CRA, mais aussi aux cyberattaques et aux violations de sécurité.

Biens de consommation 

Les fabricants d'objets connectés portables, de jouets, d'appareils électroménagers, d'appareils de divertissement et d'accessoires livrent les produits mêmes que cible le CRA. Les attentes incluent la sécurité dès la conception, des paramètres sécurisés par défaut, la gestion des vulnérabilités et des mises à jour prises en charge tout au long de la durée de vie attendue du produit. Si vous vendez également au Royaume-Uni, les obligations PSTI s'appliquent en parallèle.

Où les lacunes apparaissent généralement

• Identifiants par défaut ou équivalents dans les micrologiciels et les applications compagnon.

• Aucune période de support de sécurité déclarée ou une politique de fin de vie peu claire.

• Canaux de mise à jour OTA sans contrôles d'intégrité ni épinglage de version.

• Code tiers (SDK, OSS) à la provenance inconnue et sans traçabilité SBOM.

Ce qu'il faut prioriser ce trimestre

• Modélisation des menaces et exigences de sécurité lors de la définition du produit ; bloquer les versions qui ne disposent pas d'un VDP, d'un SBOM et d'un pipeline de mise à jour signé.

• Référentiels de durcissement: supprimer les mots de passe par défaut, verrouiller les interfaces de débogage, appliquer le principe du moindre privilège, chiffrer les données en transit et au repos.

• OTA sécurisé: paquets signés, anti-retour arrière, récupération à sécurité intégrée, télémétrie pour l'état des mises à jour.

• Politique de support et de fin de vie: publier les calendriers de support de sécurité par modèle et localiser les communications clients selon la langue.

Les KPI qui comptent

% de modèles avec OTA signé ; % de composants avec SBOM et validation des licences ; MTTR des vulnérabilités par gravité ; % de versions franchissant le jalon de modélisation des menaces.

Hôtellerie

Les hôtels et les établissements s'appuient sur des applications destinées aux clients, des systèmes de gestion immobilière, des serrures intelligentes et des contrôles de chambre, la vidéosurveillance, l'automatisation des bâtiments et les paiements. Nombre d'entre eux sont en réseau et gérables à distance, ce qui accroît leur exposition.

Où les lacunes apparaissent généralement

• IoT dans les espaces clients (serrures, thermostats, téléviseurs) fonctionnant avec les paramètres par défaut du fabricant ou un micrologiciel obsolète.

• Intégrations tierces entre les moteurs de réservation, les PMS, l'accès sans clé et les processeurs de paiement sans tests de sécurité de bout en bout.

• Télémétrie d'incidents limitée depuis les appareils de la salle, ce qui ralentit la détection et la réponse.

Ce qu'il faut prioriser ce trimestre

• Zonage et confiance zéro pour les appareils destinés aux clients : isolez les réseaux, limitez le trafic est-ouest, faites tourner les identifiants à grande échelle.

• Profilage de conformité des fournisseurs: exiger des preuves alignées sur le CRA pour les fournisseurs de smart-room et de PMS ; inclure un SLA de correctifs et une divulgation coordonnée dans les contrats.

• Images de référence et playbooks de flotte pour les appareils de salle avec des mises à jour planifiées, des contrôles de santé et un retour arrière rapide.

• Communications en cas de violation: notifications prédéfinies pour les invités concernant les mises à jour de sécurité et la gestion des incidents.

Les KPI qui comptent

% d'appareils de chambre connectée sur la base de référence actuelle ; délai de correction des vulnérabilités critiques ; % de fournisseurs disposant de preuves de conformité validées ; temps moyen de détection des incidents sur l'ensemble des réseaux clients.

Travel 

Airlines, airports and travel platforms operate high-volume, high-availability systems: booking and loyalty apps, kiosks, baggage and sensor networks, crew devices and partner APIs. Many components are “products with digital elements” placed on EU markets. 

Où les lacunes apparaissent généralement

• Connectivité API et partenaires avec une authentification et une limitation de débit inégales.

• Parcs de bornes interactives et en libre-service avec des niveaux de firmware hétérogènes et des protections physiques faibles.

• Modules hérités dans les applications clients et les plateformes de fidélisation sans visibilité sur la SBOM.

Ce qu'il faut prioriser ce trimestre

• Référentiels de sécurité des API: authentification forte, requêtes signées, validation de schéma, limitation comportementale et découverte automatisée.

• Durcissement et mises à jour des bornes interactives: démarrage sécurisé, attestation de l'appareil, verrouillage des ports, journalisation des altérations et fenêtres de correctifs par étapes.

• Assurance de la chaîne d'approvisionnement: Obligations de SBOM pour tous les SDK, conditions de divulgation coordonnée et fuzzing en pré-production pour les flux utilisateurs critiques.

• Procédure de déclaration d'incidents aligné sur les obligations du CRA, avec des rôles clairs pour les équipes produit, sécurité et juridique.

Les KPI qui comptent

% d'API critiques avec tests de contrat et application du schéma ; taux de conformité des bornes ; % de SDK tiers avec SBOM et veille sur les vulnérabilités ; MTTR des vulnérabilités dans les applications mobiles.

Exemples de feuilles de route de démarrage rapide 

Utilisez-les comme encarts dans vos plans internes ou comme annexes à l'article.

Commerce de détail et hôtellerie

Semaines 1 à 4 : recensement des actifs + analyse SBOM ; durcissement des images de référence POS/kiosque ; publication d'un VDP.

Semaines 5 à 9 : canaux de mise à jour signés ; zonage réseau pour l'IoT invité/magasin ; avenants aux contrats fournisseurs.

Semaine 10–14 : exercice d'incident ; dossier de preuves pour deux sites phares ; tableau de bord d'indicateurs au niveau du conseil d'administration.

Biens de consommation

Semaines 1 à 4 : modèle de menace + exigences de sécurité au jalon produit ; suppression des identifiants par défaut ; signature OTA.

Semaines 5 à 9 : Automatisation du SBOM dans l'intégration continue ; politique de fin de vie et de support ; page de sécurité destinée aux clients pour chaque modèle.

Semaine 10–14 : playbook de divulgation coordonnée ; dossier de preuves de conformité ; audit à blanc.

Travel

Semaines 1 à 4 : Inventaire des API et classification des risques ; base de durcissement des bornes interactives ; SBOM de l'application mobile.

Semaines 5 à 9 : des tests de contrat et une application stricte des schémas sur les API critiques ; un démarrage sécurisé et une attestation sur les bornes interactives.

Semaine 10–14 : exercice de déclaration d'incidents ; examens d'assurance des fournisseurs ; compilation du dossier technique.

Gérer cela comme un programme 

Give CRA readiness clear ownership. Product leaders should be accountable for the technical file and user disclosures; security engineering for threat modelling, update integrity and SBOM automation; compliance for evidence and liaison; legal and procurement for supplier obligations; and incident teams for regulatory reporting. Report a small set of programme-level metrics to leadership so progress is visible, and trade-offs are explicit. 

Indicateurs clés du programme : 

• Correctif MTTR par gravité

• Couverture SBOM par produit et par version

• % fournisseurs en vertu des clauses du CRA, avec les preuves fournies

• % versions franchir les étapes de sécurité (modèle de menace, SBOM, mise à jour signée, VDP présent)

• % appareils au sein d'une base durcie

Aperçu RACI :

• Product owner : responsable de l'exhaustivité du dossier technique et des informations destinées aux utilisateurs

• Ingénierie de sécurité : responsable de la modélisation des menaces, de l'automatisation du SBOM, de la signature des mises à jour

• Responsable de la conformité : responsable des preuves de conformité, liaison pour l'évaluation

• Juridique/approvisionnement : responsable des clauses fournisseurs et de leur application

• Équipe CERT/IR : responsable de la déclaration des vulnérabilités/incidents et des avis

Calendrier de référence 

Stand up your disclosure channel, supplier obligations and SBOM automation now, and compile a first complete technical file this quarter. Prepare for time-bound vulnerability reporting from late 2026. By December 2027, ensure every product placed on the EU market has demonstrable secure-by-design controls, an operational signed-update mechanism, a published support period and a complete technical file. 

Le Cyber Resilience Act s'applique-t-il au SaaS ?

expand_more

Oui, si votre service inclut des logiciels distribués (clients desktop/mobile) ou des dispositifs connectés mis sur le marché de l'UE. Les services purement hébergés, sans élément de « produit », peuvent quant à eux relever de NIS2.

Combien de temps devons-nous fournir des mises à jour de sécurité ?

expand_more

Pour la période de support déclarée correspondant au produit, vous devez la communiquer aux utilisateurs et en conserver une trace auditable.

Les applications mobiles comptent-elles comme des « produits comportant des éléments numériques » ?

expand_more

Oui, lorsque le produit est mis sur le marché de l'UE (par exemple, via les app stores). Vous aurez besoin de contrôles secure-by-design, d'un VDP et de correctifs en temps utile.

Nous opérons uniquement au Royaume-Uni – avons-nous besoin du CRA ?

expand_more

Non. Mais une fois que votre produit est mis sur le marché de l'UE (directement ou via des partenaires), le CRA s'applique parallèlement à toute obligation PSTI.

Comment le CRA s'articule-t-il avec les autres lois ?

expand_more

CRA governs the security of the product itself. If you operate essential or important services, your organisation may also be subject to NIS2, which focuses on operational resilience and incident reporting for the service. If personal data is involved, GDPR obligations around breach notification and privacy-by-design still apply. For UK sales, PSTI adds consumer-IoT-specific duties. The most efficient approach is to set your product baseline to CRA; it aligns well with PSTI and reduces duplication in NIS2/GDPR controls.

Combien de temps devons-nous fournir des mises à jour ?

expand_more

Pour la période de support que vous déclarez appropriée pour le produit ; communiquez-la en amont et respectez-la.