My notes

  • CRA in a nutchell: Europe is only as strong as its weakest link. What ENISA wants is to create security throughout the world value chain: to ensure that all products with digital elements have an adequate level of cybersecurity.
  • Main elements of the law:
    • Cybersecurity rules for making available hardware and software on the market
    • Obligations for manufacturers, importers and distributors
    • Cybersecurity essential requirements across the lifecycle
    • Conformity assessment – differentiated by product category
    • Reporting obligations
    • Market surveillance and enforcement
    • Entry into application: 11December 2027, except for reporting obligations: 11 September 2026
  • CE marking: The CRA itself actually fits into a broader framework of EU legislation which is the new legislative framework: it is a product legislation which traditionally is focused on product safety. So this framework is no longer just about product safety, but also security. It’s not just for hardware products, but also software.
  • In scope: “products with digital elements” including their remote data processing solutions!
    • Hardware products (including components placed on the market): laptops, smart appliances, mobile phones, network equipment or CPUs…
    • Software products (including components placed on the market): operating systems, word processing, games or mobile apps, software libraries…
  • Outside the scope
    • Non-commercial products: hobby products
    • Services, in particular standalone SaaS (covered by NIS2): websites, purely web-based offerings…
    • Outright exclusions: cars, medical devices, in vitro, certified aeronautical equipment, marine equipment…
  • Obligations of manufacturers:
    • Design and development
      • Risk assessment
      • Product related essential requirements; Vulnerability handling essential requirements
      • Conformity assessment
    • Maintenance
      • Vulnerability handling throughout the product lifetime (for the period when the product is expected to be in use)
      • Obligation to report through a single reporting platform:
        • actively exploited vulnerabilities
        • severe incidents having an impact on the security of the products
    • Post maintenance
      • Reporting obligations to continue
  • Conformity assessment – product categorization
    • Default category – self assessment: memory chips, mobile apps, smart speakers, computer games…
    • Important products – application of standards / third party assessment: operating systems, anti-virus, routers, firewalls…
    • Critical products – in the future potentially certification: smart cards, secure elements, smart meter gateways…
    • FOSS – self-assessment (unless categorized as “critical products”): web development frameworks, operating systems, database management systems…
  • A simplified example of smartphones
    • As a rule, whoever places on the market a “final” product or a component is required to comply with the essential requirements, undergo conformity assessment and affix the CE marking
    • Developed by the manufacturer placing the smartphone on the market: OS, battery…
    • Developed by upstream manufacturers for integration into the “final” product: RAM, CPU, LTE…
  • Deliverables requested
    • Horizontal standards (1-15)
      • Risk-based approach (CRA Annex I)
      • Essential requirements (CRA Annex I part 1)
      • Vulnerability handling (CRA Annex I part 2)
    • Vertical standards (16-41)
      • Important products class 1 (CRA Annex III)
      • Important products class 2 (CRA Annex III)
      • Critical products (CRA Annex IV)
  • CRA standardization request in a nutshell cra
  • EUCC at a glance
    • Voluntary scheme under the EU CSA (Regulation (EU) 2019/881)
    • Certification of ICT products and Protection Profiles
    • Two assurance levels: Substantial (AVA_VAN.1-2) and High (AVA_VAN.3-5)
    • Private CABs (ITSEF and Cbs) requre accreditation for Substantial level
    • Both provate and public CABs also require authorization for High level
    • CABs are notified and listed on the Euopean Commission NANDO website
    • Certificate validity: 5 years
    • Mandatory monitoring and vulnerability management
    • CBs issuing High level certificates undergo Peer Assessment every 5 years
    • Recognition by the CCRA, subject to specific conditions
    • Ongoing maintenance of state-of-the-art and guidance documents
  • Presumption of conformity (Article 27 of CRA)
    • Products certified pursuant to a European cybersecurity certification scheme shall be presumed to be in conformity with cybersecurity requirements of the CRA.
    • European Commission empowered to adopt a delegated act to specify which schemes can be used to demonstrate conformity
    • Presumption of conformity via European harmonized standards also possible
  • Introduction to the study: Cyber Resilience Act implementation via EUCC and its appicable technical elements
    • July 2023: Request from the Commission to ENISA
    • November 2023: First strategy report linking CRA and EUCC, presented at ENISA Certification Week (Malaga, Spain)
    • July 2024: Revised to reflect CRA changes (March 2024) and EUCC Implementation Act; shared with ECCG/SCCG
    • September 2024: received and applied feedback from stakeholders
    • January 2024: final version published in ENISA websites
    • Purpose: Initial analysis to guide future use of EUCC to demonstrate CRA compliance
  • ENISA certification website: https://certification.enisa.europa.eu
  • EU Cyber Resilience Act (CRA) deadines
    • 27/02/2024: EUCC entry into force
    • 11/12/2024: CRA entry into force (20 days)
    • 27/02/2025: EUCC into application
    • 11/09/2026: Notification provisions to the CSIRT and ENISA (21 months)
    • 31/12/2027: End of use of CC 3.1 in EUCC
    • January 2028: CRA into application (36 months)
  • Use of protection profiles in CC industry cra
  • EUCC CABs alignment with NBs under CRA
    • Under the cybersecurity Act (CSA), EUCC CABs must be accredited and, for level High, authorized by national authorities (Art. 61 CSA), and notified to the Commission
    • Under the Cyber Resilience Act (CRA), notification does not require accreditation, but CABs must comply with Art. 39 CRA and demonstrate this to the notifying authority.
    • A comparison performed in the study shows string alignment between EUCC CAB requirements (CSA Annex) and CRA Art. 39, particularly regarding:
      • Legal status and independence
      • Impartiality and liability
      • Technical competence and procedures
      • Confidentiality and transparency
    • ISO/IEC 17065 supports both schemes; EUCC CABs already assessed under it are well positioned
    • Dual role possible: EUCC CABs could potentially act as CRA Notified Bodies – especially useful to assess overlaps, e.g., CC Protection Profiles vs CRA Essential Requirements
    • Conclusion: with minor adjustments, EUCC CABs could qualify as CRA Notified Bodies, fostering synergies across these EU cybersecurity frameworks
  • CRA ESRs mapping to EUCC Technical elements cra cra cra
  • Beyond Essential Security Requirements
    • CRA Essential Cybersecurity Requirements and other obligations apply to the scope of the full product with digital elements, including remote data processing solutions
    • CC TOE scope vs CRA scope
      • CC scope is often smaller than the full product
      • CRA compliance of TOE parts outside the EUCC scope?
      • Key: does the in-scope TOE protect the full product? Partial presumption of conformity?
    • On-cloud non-TOE components
      • EUCC can’t always deal and isn’t optimized with evaluation of on-cloud components
      • Key: demonstration of CRA compliance through other methods (i.e., harmonized standards)
    • Risk assessment
      • CRA article 13 requires a risk assessment leading to applicability of ESRs (Annex I P1)
      • Key: Security Problem Definition as simplified risk assessment + ASE_REQ + previous risk assessment (CC Part 1)
  • Closing Gaps Proposal
    • GAP1: EUCC certification doesn’t cover all CRA ESRs
      • Add SFRs/SARs to Security Target for applicable ESRs
      • Update Security Problem Definition to justify non-applicability of other ESRs
    • GAP2: Scope of the TOE smaller than scope of the product
      • Enlarge TOE scope (if impact is affordable), or
      • Update SPD to demonstrate that non-TOE parts of the product are sufficiently protected by the security functions in the TOE scope
    • GAP3: remote data processing solutions not included in certification
      • Update SPD to include assumptions on the remote data processing entities
      • Include SFRs protecting communications with relevant cloud entities
      • On-cloud entities CRA conformance to be demonstrated through other methods (i.e., harmonized standards)
  • PPs as vehicular tool for implementation
    • Strategy idea: undertaking gap closing through updating PPs rather than on individual certifications
      • Certification industry dominated by PPs
      • CRA-compliance analysis (risk assessment, SPD, TOE scope, SFRs/SAR) once and by expert technical communities, SDOs or NCCAs
      • Scenarios with exact conformance prevent gap closing without updating the PPs
    • Prioritizing the update of PPs of products that, for one or other reason, are required to obtain an EUCC certificate
      • Critical product PPs should be quick wins (high-priority)
      • EUCC is not cheap, fast or entry-level. It might not be a solution for all manufacturers that need to meet CRA.
    • When no PPs are used, functional and assurance packages, or modular PPs, tailored for CRA conformance can be developed. cra
  • Pilots
    • 10 pilots at least 2 of them for non PP certification
    • Engage with international community to collaborate in the update of the PP and cPP
    • Objectives
      • Update PP for CRA Compliance
      • Propose a generic PP for CRA compliance
      • Update the Study as a guidance for PP updates
  • Pilots roadmap cra
  • How to contact ENISA: https://certification.enisa.europa.eu/, and certification@enisa.europa.eu
  • Useful links