Frequently Asked
Questions

The Common Criteria (CC) is an international standard for evaluating the security properties of IT products and systems, formally published as ISO/IEC 15408. It defines a structured framework for specifying security requirements, outlines the methodology for assessing whether those requirements are met, and sets rules for the oversight of these evaluations.

Governments and organizations worldwide use the CC to assess and certify the security of information technology products. In many cases, compliance with the Common Criteria is a prerequisite for procurement.

For more information or to obtain the standard, visit: https://www.commoncriteriaportal.org.

The most widely adopted mutual recognition framework is the Common Criteria Recognition Arrangement (CCRA). As of this writing, signatory nations include: Australia, Austria, Canada, Czech Republic, Denmark, Ethiopia, Finland, France, Germany, Greece, Hungary, India, Indonesia, Israel, Italy, Japan, Republic of Korea, Malaysia, the Netherlands, New Zealand, Norway, Pakistan, Poland, Qatar, Singapore, Spain, Sweden, Turkey, the United Kingdom, and the United States.

The official and up-to-date list of CCRA participants is maintained at:

https://www.commoncriteriaportal.org/ccra/members/index.cfm.

‍

Other recognition frameworks also exist:

• SOG-IS Mutual Recognition Agreement – Within Europe, SOG-IS allows mutual recognition among its members, often supporting higher assurance levels than CCRA.
• EUCC – The European Union Cybersecurity Certification Scheme based on Common Criteria, developed under the EU Cybersecurity Act, will provide an EU-wide CC-based certification framework. Once fully operational, EUCC will harmonize and replace certain national arrangements within the EU, offering a standardized recognition path for CC-based evaluations across all EU Member States.
• Bilateral agreements – Some countries maintain one-to-one recognition agreements.
• Independent use – Certain nations (e.g., China) and organizations may adopt and apply the ISO/IEC 15408 standard without participating in formal recognition schemes.

There are three parties involved in the CC evaluation process:

1. Vendor or Sponsor. The vendor/developer engages an accredited laboratory and submits their product and associated evidence for evaluation.

2. Laboratory. The laboratory performs the evaluation and reports evaluation results to the scheme. Evaluation is iterative in nature and the vendor is able to address findings during the evaluation.

3. Scheme. Certificate authorizing schemes (also known as a certification body) issue CC certificates and perform certification/validation oversight of the laboratory. Each scheme has its own policies with regard to how the CC is used in that country and what products may be accepted into evaluation

The following provides a high-level overview of what gets evaluated:

‍

Documents defining the evaluation:

Security Target evaluation. Evaluation of the Security Target (ST) - a claims document that specifies the security functions under evaluation and the security assurance requirements being met.

Protection Profile evaluation. Evaluation of the Protection Profile (PP) - an implementation-independent statement of security needs for a technology type.

‍

The product (technically called a Target of Evaluation (TOE). These evaluations can include:

• Development Evaluation. Involves a thorough review of design, architecture, functional specification etc. documents, which can range from a simple interface specification to comprehensive layers of detailed design documentation and even source code examination, depending on the level of assurance required.
• Guidance evaluation. Examination of the product’s guidance materials, including any CC-specific documentation such as secure installation guides, to ensure users can correctly configure the evaluated version of the product..
• Life-cycle evaluation. Evaluation of configuration management practices, delivery procedures and vulnerability or flaw remediation processes. At higher assurance levels this can also cover development environment security and on-site security audits..
• Functional testing. Re-execution of a sample of the developer’s functional tests, coupled with independent tests designed by the evaluators to verify that the security functions operate as described in the ST.
• Vulnerability analysis / Penetration testing. Identification of potential vulnerabilities and active attempts to exploit them, to confirm the TOE meets the claimed assurance level.

‍

Whether each of these activities is performed, and to what extent, depends on the specific assurance requirements stated in the Security Target.

A Security Target is the document that defines the Target of Evaluation (TOE), that is, the product configuration version, and scope of security functionality to be assessed. The CC allows the TOE to be all or part of a product or system. The Security Target is put together using CC constructs and includes a threat model, environmental assumptions, security objectives, security functional requirements and security assurance requirements. The ST is prepared by the vendor and may optionally claim conformance to one or more Protection Profiles (PP). Unlike a PP—typically created from the consumer’s perspective—the ST describes in detail how the product meets the defined security requirements.

‍

Examples of publicly available Security Targets can be found at: https://www.commoncriteriaportal.org/products/index.cfm .

A Protection Profile is an implementation-independent statement of security requirements for a particular type of technology. PPs are defined using CC constructs and often published by governments or industry bodies to guide procurement. Each PP specifies both functional and assurance requirements, which products aiming for CC certification can address.

A single product may conform to multiple PPs if relevant.

‍

A central repository of PPs is available at:

https://www.commoncriteriaportal.org/pps/index.cfm

A Collaborative Protection Profile (cPP) is a type of Protection Profile developed jointly by international technical communities and endorsed by multiple national CC schemes. The collaborative approach ensures that security requirements for a given technology are consistent, mutually recognized, and reflect international consensus. This process is coordinated via the Common Criteria Working Groups, with participation from government, industry, and academic experts.

‍

More information and a list of current cPPs can be found at:https://www.commoncriteriaportal.org/pps/collaborativePP.cfm?cpp=1&CFID=50449855&CFTOKEN=128d3f224a6fcbd2-9042B106-155D-00D0-0AA2F31A79DB3F05

An Evaluation Assurance Level (EAL) is one of several predefined sets of assurance requirements ranging from EAL1 (Functionally Tested) to EAL7 (Formally Verified Design and Tested). A Protection Profile or Security Target may reference an Evaluation Assurance Level (EAL), or, alternatively, describe a custom assurance package tailored to their requirements rather than using a predefined EAL.

A CC evaluation project typically lasts several months, but actual duration depends on many factors such as product complexity assurance claims and completeness of product documentation. An evaluation project includes product preparation (including necessary configuration and testing), documentation preparation by the vendor, engagement with an accredited evaluation laboratory, laboratory evaluation activities and finally certification by the Certification Body.

CC certification only applies to the configurations and versions specified by the certified Security Target. For example, if a certified product is updated from version 1.0 to 1.0.1, the original certificate does not automatically apply to the new version. Some certification schemes may offer longer certificate validity with update provisions, provided the changes are assessed and approved. In most cases, product changes are handled through the Assurance Continuity process.

Assurance Continuity allows minor, non-security-impacting changes to be appended to the existing CC certificate without a full re-evaluation. In cases where changes are security-relevant (and are classified as ‘major’), Assurance Continuity allows these changes to be rapidly evaluated through ‘re-evaluation’, which utilizes results from the original evaluation.

Note: Policies and implementation details for Assurance Continuity vary across national schemes.

Further details about the Assurance Continuity program are included in the Common Criteria Recognition Arrangement (CCRA).

Supporting Documents at https://www.commoncriteriaportal.org/cc/index.cfm#supporting.

CC certified products have undergone a rigorous evaluation process performed by accredited third-party security labs in accordance with internationally accepted criteria and a government-managed framework. Specific advantages include:

• Product security functions have been verified and tested
• Independent evaluators have assessed the product for known vulnerabilities and attempted to exploit potential weaknesses.
• Development practices, configuration management, and vulnerability remediation processes have been reviewed for compliance.
• The product meets formal CC certification requirements often specified in government and regulated-industry procurement policies
• Certificates may be accepted internationally under agreements such as the Common Criteria Recognition Arrangement (CCRA) or, for EU markets, the EUCC scheme.

• EN 419 211-2 (Secure signature creation device - Part 2: Device with key generation)
• EN 419 211-3 (Secure signature creation device - Part 3: “Device with key import”)
• EN 419 211-4 (Secure signature creation device - Part 4: “Extension for device with key generation and trusted communication with certificate generation application”)
• EN 419 211-5 (Secure signature creation device - Part 5: “Cryptographic Module for Trust Services”)
• EN 419 211-6 (Secure signature creation device - Part 6: Extension for device with key import and trusted communication with signature creation application)
• EN 419 241-2 (Trustworthy Systems Supporting Server Signing Part 2: Protection Profile for QSCD for Server Signing)
• EN 419-221-5 (Protection profiles for TSP Cryptographic modules - Part 5 Cryptographic Module for Trust Services)
• Protection Profile For Application Software

Version 1.4, 2021-10-07

• Collaborative Protection Profile For Network Devices

Version 2.2e, 2020-03-23

• Functional Package For Transport Layer Security

Version 1.1, 2019-02-12

• Protection Profile for Certification Authorities

Version 2.1, 2018-12-01 (NIAP)

• Protection Profile Module For Stateful Traffic Filter Firewalls

Version 1.3, 2019-09-27

• Protection Profile For Mobile Device Fundamentals

Version 3.2, 2021-04-15

• CIMC PP

Certificate Issuing and Management Components Protection Profile, Version 1.5

• Protection Profile- Module For Private Network (VPN) Gateways,

Version 1.1, 2020-06-18

• General Purpose Operating Systems Protection Profile/ Mobile Device Fundamentals Protection Profile Extended Package (EP) Wireless Local Area Network (WLAN) Clients

Version 1.0, 2016-02-08

A Common Criteria (CC) certification provides independent assurance that an IT product meets defined security requirements at a specified Evaluation Assurance Level (EAL). Common Criteria certifications are one of the widely recognized, and internationally standardized information security solutions in the world. Thanks to the CCRA (Common Criteria Recognition Arrangement ) and further mutual agreements, the certified product owners are in the especial position, where marketing their product worldwide not only in compliance with expected information technology security requirements (which is a CC certification in the most cases when it comes to tenders), but the evidence of the product’s compliance of up to date international professional standards.

Such certifications are mainly requested by the developers. In case you are in the process of creating a new software or hardware product, you have probably come across the opportunity to secure your product to a certain level. Common Criteria evaluations are for those, who are already prepared for such IT security challenges or welcome the work which leads to a globally acceptable high-end security certification.

CCLab is accredited by the Italian OCSI (Organismo di Certificazione della Sicurezza Informatica) and also the Dutch TrustCB, which are part of the EUCC scheme.

• EN 419 211-2 (Secure signature creation device - Part 2: Device with key generation) / BSI-CC-PP-0059-2009-MA-01, Version 2.0.1

(Protection profiles for secure signature creation device – Part 2: “Device with Key Generation”)

‍

• EN 419 211-3 (Secure signature creation device - Part 3: “Device with key import”) / BSI-CC-PP-0075-2012, Version 2.0.1 (Protection profiles for secure signature creation device - Part 3: Device with key import)
• EN 419 211-4 (Secure signature creation device - Part 4: “Extension for device with key generation and trusted communication with certificate generation application”) / BSI-CC-PP-0071-2012, Version 2.0.1

(Protection profiles for secure signature creation device – Part 4: “Extension for device with key generation and trusted communication with certificate generation application”)

‍

• EN 419 211-5 (Secure signature creation device - Part 5: “Cryptographic Module for Trust Services”) / /BSI-CC-PP-0072-2012, Version 2.0.1
• (Protection profiles for secure signature creation device – Part 5: Extension for device with key generation and trusted communication with signature creation application)
• EN 419 211-6 (Secure signature creation device - Part 6: Extension for device with key import and trusted communication with signature creation application) / BSI-CC-PP-0076-2013, Version 2.0.1 (Protection profiles for secure signature creation device - Part 6: Extension for device with key import and trusted channel to signature creation application)
• EN 419 241-2 (Trustworthy Systems Supporting Server Signing Part 2: Protection Profile for QSCD for Server Signing)
• EN 419-221-5 (Protection profiles for TSP Cryptographic modules - Part 5 Cryptographic Module for Trust Services) 
• CIMC PP Certificate Issuing and Management Components Protection Profile, Version 1.5
• Protection Profile for Certification Authorities Version 2.1, 2018-12-01
• Collaborative Protection Profile For Network Devices, Version 2.2e, 2020-03-23
• Protection Profile Module For Stateful Traffic Filter Firewalls Version 1.3, 2019-09-27
• Protection Profile- Module For Private Network (VPN) Gateways, Version 1.1, 2020-06-18
• Protection Profile For Mobile Device Fundamentals, Version 3.2, 2021-04-15
• General Purpose Operating Systems Protection Profile/ Mobile Device Fundamentals Protection Profile Extended Package (EP) Wireless Local Area Network (WLAN) Clients, Version 1.0, 2016-02-08
• Protection Profile For Application Software, Version 1.4, 2021-10-07
• Functional Package For Transport Layer Security, Version 1.1, 2019-02-12

IEC 62443 is the standard series that applies to all stakeholders involved in protecting Industrial Automation and Control Systems (IACS), offering the most effective cybersecurity solution for Industry 4.0 worldwide. It addresses technical and process-related aspects of cybersecurity for all stakeholders involved in industrial automation, including asset owners, operators, maintenance service providers, integrators, and product suppliers (developers of control systems and their components). The standard is designated as “horizontal” by IEC. It provides an achievable model to create security focused processes, handle risks and mitigate cybersecurity threats. With increased connectivity of production assets (Industrial IoT devices - IIoT), new hazards emerge that must be treated in traditional risk management processes. An industrial automation control system and component manufacturer shall apply the security requirements under IEC 62443-4-1 and IEC 62443-4-2 from the very first stage of the product development.

The standards are divided into four parts:  

• GENERAL (62443-1) - Overview of the IEC 62443 security process.
• POLICIES AND PROCEDURES (62443-2) - Guidance for creating and maintaining a secure system. 
• SYSTEM (62443-3) – Includes cybersecurity technologies, risk assessment methods for system design along with the description of system security requirements and security levels 
• COMPONENT (62443-4) - Describes the technical functionality levels and development life cycle requirements for IACS components.

‍

The IEC 62443 describes 4 levels of security functionality:

• SL 1 – Protection against causal or coincidental violation
• SL 2 – Protection against intentional violation using simple means with low resources, generic skills and low motivation
• SL 3 – Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills and moderate motivation
• SL 4 – Protection against intentional violation using sophisticated means with extended resources, IACS specific skills and high motivation

• Gap analysis
• Consultation and support the preparations for certification
• Online and on-site workshops
• Documentation review
• Secure product development lifecycle requirements audit & certification (62443-4-1)
• Technical security requirements for IACS component evaluation & certification (62443-4-2)
• Certification services under the CB Scheme

SL1-  Protection against causal or coincidental violation

SL2- Protection against intentional violation using simple means with low resources, generic skills and low motivation

SL3- Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills and moderate motivation

SL4- Protection against intentional violation using sophisticated means with extended resources,IACS specific skills and high motivation 

‍

There are three organizational role, who have responsibility:

• Asset Owner / End-user: 

- Owns and operates one or more IACS

- Easy to define a target security level

- Offers a frame of reference to evaluate existing security

•  System Integrator/ Implementer

- Builds IACS for the Asset owner 

              - Clear understanding of security requirements 

              - Simple to define a system security capability 

•   Product Manufacturer/ Supplier 

- Designs and creates the components for the System Integrator to build IACS.

              - Simple to define a product security capability

              - Easy to differentiate from competitors 

The standard is divided into 4 parts: General, Policies and Procedures,System, Component, which are denoted by the suffixes from 1 to 4. 

• General (62443-1) - Overview of the ISA/IEC 62443 security process. 
• Policies and Procedures (62443-2) - Guidance for creating and maintaining a secure system. 
• System (62443-3) - Includes cybersecurity technologies, risk assessment methods for system design along with the description of system security requirements and security levels. 
• Component (62443-4) - Describes the technical functionality levels and development life cycle requirements for IACS components.

CCLab has expertise primarily in the following parts of the IEC 62443 series:

• IEC 62443-4-1: Secure product development lifecycle requirements
  
  
• IEC 62443-4-2: Technical security requirements for Industrial Automation and Control System (IACS) components

QIMA and CCLab are recognized in the IECEE CB Scheme, the world’s largest certification scheme for electrical and electronic products and components. Based on our evaluation results, we can issue CB certificates that are internationally accepted in several countries.

CCLab is ready to provide the following services to conform and comply with the desired standards and security levels:

• Gap analysis
• Consultation and support the preparations for certification
• Online and on-site workshops
• Documentation review
• Secure product development lifecycle requirements audit & certification (62443-4-1)
• Technical security requirements for IACS component evaluation & certification (62443-4-2)
• Certification services under the CB Scheme

For more information, please visit: https://www.cclab.com/service/cybersecurity-certification

The Cyber Resilience Act (CRA) is a European Union regulation that sets horizontal cybersecurity requirements for all products with digital elements — including connected hardware and software, from IoT devices to standalone software applications. Unlike sector-specific laws, the CRA ensures a unified minimum level of cybersecurity across the entire EU market.

It requires manufacturers to consider cybersecurity throughout the entire product lifecycle — from design and development to maintenance and vulnerability handling. This means security can no longer be treated as an afterthought but must be built into products by design (“security by design” and “security by default”).

Although the CRA formally entered into force on 10 December 2024, it will only become fully applicable on 11 December 2027. This three-year transition period allows manufacturers and other stakeholders to adjust their development, compliance, and support processes in line with the new requirements.

After this date, any product with digital elements that is not compliant with CRA requirements cannot be legally placed on the EU market. Companies should therefore already start preparing by identifying affected products and aligning existing standards and risk management processes with the CRA.

The RED Delegated Act (EU) 2022/30 — which currently defines cybersecurity requirements for certain radio-connected products — will be repealed on 11 December 2027, the same day the CRA becomes fully applicable.

From that point onward, the CRA will serve as the overarching legal framework for product cybersecurity, avoiding duplication of obligations. Until then, manufacturers must still comply with the RED-DA, and existing RED-DA compliance work will still support future CRA compliance.

Both the RED-DA and the CRA impose mandatory cybersecurity requirements enforceable via CE marking.

• RED-DA applies to internet-connected radio equipment.
• CRA applies to all digital products, including software-only products.

Many devices fall under both frameworks (e.g., smart home devices, routers, industrial gateways). Once the CRA applies, it will take precedence, creating a single streamlined cybersecurity framework.

“Module A” refers to the Internal Production Control conformity assessment procedure. Under the CRA, it allows manufacturers to self-declare conformity if they fully implement relevant harmonised standards.

Manufacturers using Module A must implement internal processes ensuring their product meets all essential cybersecurity requirements, then issue an EU Declaration of Conformity, taking full legal responsibility.

However, Module A can only be used if harmonised standards (hENs) fully apply. If no standards exist or only partially apply, additional justification or third-party involvement may be required.

Presumption of Conformity means that a product is presumed to meet CRA requirements if it complies with harmonised standards (hENs) published in the Official Journal of the European Union.

By following these standards, manufacturers can demonstrate compliance in a straightforward and recognised way. However, PoC only applies to the aspects covered by the standards; any uncovered risks must be handled separately.

Important: No harmonised standards have yet been published under the CRA. Therefore, full Presumption of Conformity is currently impossible, and manufacturers must rely on alternative assessment methods until standards are finalised.

No. Under the CRA, only Class I products listed in Annex III (“important products with digital elements”) can achieve full PoC by applying harmonised standards.

For other product classes, only partial PoC will be possible — especially because the complete set of CRA-related harmonised standards is still under development.

Currently, no harmonised standards exist, meaning even Class I products cannot yet claim full Presumption of Conformity.

Harmonised standards form the technical backbone for demonstrating CRA compliance. The EN 18031 series — originally used for RED-DA — is expected to form the basis for future CRA harmonised standards.

This continuity means current RED-DA alignment efforts will continue to be useful and will ease the transition to CRA compliance.

Once harmonised standards are published, they will provide manufacturers with clear, recognised methods to meet cybersecurity and vulnerability management requirements.

Important: Candidate standards (such as EN 18031-1/-2/-3) are in development, but none have yet been harmonised. Until published in the Official Journal, compliance must rely on custom technical documentation and risk assessments.

For several decades, the CB Scheme has garnered recognition in over 50 countries as an international product certification initiative. It plays a crucial role in facilitating global trade by offering international recognition of CB Certificates for national approvals. This streamlined approach provides manufacturers with a "one-stop" service, allowing them to undergo testing once and gain access to multiple markets.

In recent years, the importance of cybersecurity within the CB Scheme has grown significantly. Over the past five years, a staggering 583,533 certificates have been issued, highlighting the increasing awareness of cybersecurity risks. Notably, approximately 80% of product categories covered by the scheme may be susceptible to cybersecurity vulnerabilities. These categories include household appliances (25%), information technology and audio/video equipment (23%), office equipment (15%), lighting products (6%), electronic components and accessories (4%), medical devices (3%), measurement and test equipment (2%), among others.

With the proliferation of connected products, such as consumer IoT devices and industrial control systems, the need to address cybersecurity concerns has become paramount. Consequently, national legislators have begun to prioritize cybersecurity alongside traditional safety and electromagnetic compatibility (EMC) risks, reflecting the evolving landscape of product certification and regulation.

A CB certificate is accepted in over 50 countries that participate in the CB Scheme. This international product certification initiative facilitates international trade by enabling the recognition of CB Certificates for national approvals, providing manufacturers with streamlined access to multiple markets. More information: https://www.iecee.org/members/member-bodies

1. Consumer IoT devices, covered by ETSI 303 645 standards. These are internet-connected devices that any person can have at home nowadays. This standard covers consumer IoT devices that are connected to network infrastructure and their interactions with associated services, like smart tv’s, CCTV cameras, speakers, connected home automation devices, IoT gateways, base stations, HUBs, wearable health trackers, baby monitors, IoMT devices, connected home appliances like smart refrigerators and washing machines, or connected alarm systems, door locks, smoke detectors, among many others.
2. Industrial automation and control system components, covered by ISA/IEC 62443-4-1 and ISA/IEC 62443-4-2.  SA/IEC 62443-4-1 standard defines the safe development life cycle for products used for IACS. This includes, for example, industrial automation devices, controllers, sensors, and related software and systems. ISA/IEC 62443-4-2 standard specifies technical security requirements for IACS components, in particular for embedded devices, network components, host components, and software applications. This standard deals in detail with the challenges and requirements arising in the field of industrial control systems, industrial networks, and their protection.

The evaluation according to ETSI EN 303 645 takes up to 3 weeks, but this requires thorough preparation on the part of the manufacturer as well. To do this, we recommend that you download our free infographic, which presents the evaluation process according to ETSI standards. 

The length of the evaluation according to ISA/SAE 62440-4-1 and 4-2 may vary depending on the complexity of the product, the evaluation conditions, and other factors. However, these assessments can usually take several months to several years. The process includes the preparation of product documentation, evaluation activities, tests, possible risk assessment, and finalization. It is important to note that the duration of the evaluation can also be influenced by how prepared the manufacturers and developers are for the evaluation process, as well as how well the product documentation and test results meet the standards. Therefore, we recommend that you ask for a consultation from our colleague or view our service page to obtain more information.

After a successful evaluation, the certification procedure takes 1-2 weeks, the certificate will be published on the IECEE website.

ISO / SAE 21434 covers all parts of the vehicle lifecycle, from design to decommissioning of cyber security techniques.This concerns all electronic systems, components, and software in the vehicle, and any external connectivity.

ISO21434 is important, because the connectivity in vehicles and the development of autonomous cars increase the risks of cyberattack and subsequent damage too. The purpose of the standard is to provide a structured process to ensure that cybersecurity considerations are incorporated into automotive products during their lifetime. The standard requires automotive manufacturers and suppliers to demonstrate due diligence in the implementation of cybersecurity engineering and that cybersecurity management is applied throughout the supply chain to support it.

We offer “zero to hero” and integration services which help manufacturers/developers to achieve cybersecurity compliance.

Our comprehensive services help from planning through implementation. They provide a clear path to compliance through methodology based on internationally recognized standards.

Integration services build on customers’ already implemented management systems that comply with relevant industry standards. Integration services help customers to utilize their already implemented processes instead of creating new ones.

• Gap analysis
• Risk management
• Vulnerability testing (testing and training)
• Preparation for certification
• Technical advice & consultation,
• Checking & evaluating technical documentation,
• Preparatory audit
• Preparation of technical reports,
• Complete type-approval process management.

• We provide what we do best - we know all the requirements of the CBs, so our experiences are the guarantee for an efficient compliance project.
• We are familiar with the format and content a certification body requires, so we can minimize the risk and project time for our clients.
• Smooth transition to ISO/SAE 21434 is guaranteed in a “one-stop shop”.
• Dedicated professionals’ guidance will streamline the process and shorten project time.
• Real value provided for reasonable pricing.

Our Laboratory issues this Whitepaper as a brief summary. METAS provides a checklist and detailed information to the test process: https://www.metas.ch/metas/de/home/dl/datensicherheitspruefungen.html

Our Laboratory issues this Whitepaper as a brief summary. METAS provides a checklist and detailed information to the test process: https://www.metas.ch/metas/de/home/dl/datensicherheitspruefungen.html

Our Laboratory issues this Whitepaper as a brief summary. METAS provides a checklist and detailed information to the test process:

https://www.metas.ch/metas/de/home/dl/datensicherheitspruefungen.html

Sec. 2.1 Required documents describe which documents should you submit at the beginning of the test process.

The checklist is a requirement catalogue ("WHAT" column) that shall be fulfilled by the manufacturer ("HOW" and "WHERE") columns. "HOW"  is an ADV_FSP-like description while the "WHERE" is an ADV_ARC-like description. In each HOW cell of the checklist the relevant OT tuples (“x”) from the OT matrix must be referenced (if any).

The RL-DSP-CH_A2_1045 is the recommended process for operating a whole smart meter system. It includes among others a theoretical explanation for the “5.1 Test field IT security concept” part of the Manufacturer document.

The requirements from chap. 5 of Annex 1 and the Prüfmethodologie chap. 7 are identical. Other parts of Annex 1 and Annex 2 basically contain requirements for the main components of an iMS. 

The requirements are implemented by the architecture and functionality of the main components.

We will perform the testing procedure based on the requirements of the Prüfmethodologie from section 5.1 to 5.6. which refers to the OT matrix and the checklist.

Based on the Prüfmethodologie sec 5.2 which is about the checklist:

The Manufacturer:

• fills the checklist of the Prüfmethodologie chap.7 Prüflistenmodule (checklist)
• (HOW - secure functionality to satisfy the WHAT requirement, WHERE – localization of the functionality in the architecture, referencing the relevant OT tuples)
• delivers the sufficient documentation of the Components
• and performs functional tests 

The Evaluator:

• checks the HOW value of checklist to make sure that it gives a solution to the WHAT (correctness, efficiency, completeness, based on the filled checklist and the additional Manufacturer documents for meter system components)  (Prüfmethodologie chap.7 Prüflistenmodule, e.g 5.1.4 (b)
• looks at whether the functionalities linked in the WHERE can really deliver the functionality
• determines a verdict based on steps above
• performs vulnerability analysis and penetration test to confirm the compliance

The requirements of the Prüfmethodologie will also be examined during the documentation evaluation and the penetration test process according to the steps above.

DOES THE 5.1.4 (b) REQUIREMENT ONLY MEAN THAT DATA BETWEEN MAIN SYSTEM COMPONENTS (HAUPTKOMPONENTEN) NEED TO BE EXCHANGED IN ENCRYPTED WAY?

The requirement means that the assets need to be stored in encrypted format in the Smart Meter, furthermore the system must include a procedure for the secure, selective deletion of specific data. This procedure shall delete the data permanently, for example through overwriting with random data, therefore these specific data cannot be restored.

So, it is about secure storing and deleting, not exchanges.

The requirement means that the assets need to be stored in encrypted format in the Smart Meter, furthermore the system must include a procedure for the secure, selective deletion of specific data. This procedure shall delete the data permanently, for example through overwriting with random data, therefore these specific data cannot be restored.

So, it is about secure storing and deleting, not exchanges.

The “Vulnerable data” means the protected objects (assets or interfaces based on the SBA) in the test object that shall be protected (confidentiality, integrity and availability).

 In this case, the key is also vulnerable data.

Swissmig created a Risk analysis document [Studie «Schutzbedarfsanalyse Smart Metering in der Schweiz»; 062016], which contains risk scenarios. 

In this document, Swissmig determined the assets, the objects to be protected against threats. Prüfmethodologie's OT matrix summarizes this information.

This is a general requirement for all components, and it will be tested during the penetration test.

Usually, this process cannot be planned preliminary - a deep knowledge of the TOE is necessary.

‍

To choose CCLab as Test Laboratory please enter the CCLab specific data to METAS Application form (Antragsformular):

• Name: CCLab Ltd.
• Abteilung: -
• Strasse: Katona Jozsef 17. III.2.
• PLZ Ort: 1137 Budapest
• Land: Hungary
• Internetadresse: https://www.cclab.com
• Kontaktperson (des Prüflabors)
• Name: Mr. Ferenc Molnár
• Funktion: CEO
• Telefon/Mobiltelefon: +36 30 280 6524
• E-Mail: ferenc.molnar@cclab.hu

There is a possibility to set up the HES in our laboratory. We can also test the HES with remote access.

First of all you deliver the test samples to our laboratory. We are responsible for the secure management of the test samples within the physical boundaries of the Laboratory. After the test process, we store the samples for at most one year for easier re-evaluation. After the one-year retention period, we send back the samples to you or take care of the secure disposal. Our price list contains the conditions of back delivery or secure disposal.

This can be certified within one evaluation process, but all the security relevant parts need to be tested separately. This may result in additional costs compared to a simple TOE evaluation process. If a configuration is not security relevant (e.g. color of the enclosure) no further tests are necessary. In the final test report, all possible configurations will be listed.

The European Union Cybersecurity Certification Scheme (EUCC) is a Common Criteria-based certification system drafted by the European Union Agency for Cybersecurity (ENISA). It aims to harmonize the evaluation and certification of Information and Communication Technology (ICT) products across Europe, ensuring they meet consistent cybersecurity standards. The European Commission adopted the implementing regulation, named EUCC, in 2024 ((EU) 2024/482) within the framework of the EU Cybersecurity Act (CSA).

The EUCC is designed to replace the previous SOG-IS Mutual Recognition Agreement (MRA) and introduces a unified framework under the EU Cybersecurity Act (CSA). This new scheme standardizes the certification process across EU member states, reducing complexity and fostering mutual recognition of certified products.

Achieving EUCC certification demonstrates that your ICT product complies with rigorous cybersecurity standards, enhancing its credibility and marketability within the European market. It also facilitates easier access to multiple EU countries by eliminating the need for multiple national certifications.

The EUCC certification process involves several key steps:

1. Application: Apply to a designated certification body accredited under the EUCC scheme.
2. Preparation: Hire consultants, review documentation through training, and perform an internal audit to ensure readiness for evaluation.
3. Evaluation: An independent assessment of your product's security features and documentation is conducted.
4. Certification: Upon successful evaluation, a certificate is issued, confirming compliance with EUCC standards.

Engaging with experienced certification bodies and IT Security Evaluation Facilities (ITSEFs) can streamline this process.

CCLab offers professional assistance, i.e. consultancy services to guide you through the EUCC certification process. Our team provides support in preparing necessary documentation, conducting security evaluations, and ensuring your product meets all required standards, thereby facilitating a smoother and more efficient certification journey. 

For more detailed information and resources on EUCC certification, contact our team directly.

The EUCC scheme became fully effective on February 27th, 2025, replacing the former national Common Criteria (CC) certification schemes. Applications under the old national schemes were accepted until the end of January 2025, and any ongoing projects must be finalized by 27th February 2026.

CC certificates issued during the transition period will remain valid for five years, even after the EUCC took effect. This ensures continuity and recognition while organizations adapt to the new framework.

The EUCC not only harmonizes certification across the EU but also provides ICT suppliers with stronger market credibility, free movement of certified products across member states, and an expanded customer base.

‍

For the latest updates, consult with our experts.

The Radio Equipment Directive (RED) is a regulatory framework established by the European Union (EU) for the harmonization of radio equipment within the EU market. It is officially known as Directive 2014/53/EU. The RED replaced the previous EU legislation, the Radio and Telecommunications Terminal Equipment (R&TTE) Directive.

The purpose of the RED is to ensure that radio equipment placed on the EU market meets essential requirements related to health and safety, electromagnetic compatibility (EMC), and efficient use of the radio spectrum. It aims to facilitate the free movement of radio equipment across EU member states while ensuring a high level of protection for users and preventing interference between different radio equipment.

The RED applies to a wide range of radio equipment, including wireless devices, radio transmitters, receivers, telecommunications terminal equipment, and satellite communications equipment. It covers both professional and consumer products that use the radio frequency spectrum for communication or transmission purposes.

Under the RED, manufacturers are required to demonstrate compliance with the essential requirements and ensure that their products bear the CE marking, indicating conformity with applicable EU directives. The directive also sets out obligations for economic operators, including importers and distributors, to ensure that only compliant radio equipment is placed on the market.

The RED harmonizes the requirements for radio equipment across the EU and provides a framework for market surveillance and enforcement by member states to ensure ongoing compliance and safety of radio equipment.

‍

The purpose of the Radio Equipment Directive (RED) is to establish a regulatory framework that ensures the safety, electromagnetic compatibility (EMC), and efficient use of radio spectrum for radio equipment placed on the market within the European Union (EU). The directive aims to achieve the following objectives:

• Safety and Health Protection
• Electromagnetic Compatibility (EMC)
• Efficient Use of Radio Spectrum
• Cybersecurity and Data Protection
• Universal Charging Compatibility (Common Charger, Directive (EU) 2022/2380)
• Harmonization and Free Movement
• Protection of End Users

The Radio Equipment Directive (RED) applies to various economic operators involved in placing radio equipment on the market within the European Union (EU). The directive outlines the obligations and responsibilities of the following parties:

• Manufacturers: The RED applies directly to manufacturers of radio equipment. They are responsible for ensuring that their products comply with the essential requirements specified in the directive. Manufacturers must perform conformity assessment procedures, prepare technical documentation, affix the CE marking on compliant products, and fulfill other obligations defined by the directive.
• Authorized Representatives: Manufacturers based outside the EU must appoint an authorized representative within the EU. The authorized representative acts on behalf of the manufacturer to ensure compliance with the RED and represent the manufacturer's interests in regulatory authorities and market surveillance.
• Importers: Importers, who bring radio equipment from non-EU countries into the EU market, have specific obligations under the RED. They must verify that the equipment complies with the essential requirements, ensure proper documentation is available, and only place compliant products on the market. Importers are responsible for affixing their name, registered trade name, or registered trademark on the equipment and maintaining records of the manufacturer and the equipment's compliance.
• Distributors: Distributors, who supply radio equipment within the EU market, also have certain obligations. They must verify that the equipment bears the CE marking, is accompanied by required documentation, and meets the essential requirements. Distributors must not make any changes that may affect the compliance of the equipment, cooperate with market surveillance authorities, and provide information on product traceability.

It's important to note that the RED also applies to economic operators involved in making radio equipment available on the market under their name or trademark, those who modify equipment's compliance, or those who assemble equipment from components to form a new product.

The Radio Equipment Directive (RED) covers a wide range of products that utilize the radio frequency spectrum for communication or transmission purposes. The directive applies to various types of radio equipment, including

• Wireless Devices: E.g. smartphones, tablets, laptops, smartwatches, wireless headphones, wireless speakers, wireless keyboards, and other portable electronic devices that incorporate radio functionality for communication or data transmission.
• Radio Transmitters and Receivers: This includes radio transmitters used in broadcasting, amateur radio equipment, citizen band (CB) radios, two-way radios, walkie-talkies, and radio modules integrated into other devices.
• Telecommunications Terminal Equipment: Such as fixed-line telephones, cordless telephones, Voice over IP (VoIP) devices, and modems.
• Satellite Communications Equipment: The RED also includes radio equipment used for satellite communications, including satellite phones, satellite modems, satellite data terminals, and satellite receivers.
• Broadcasting Equipment: Equipment used for broadcast radio and television transmission, including radio and TV broadcast transmitters, studio equipment, audio and video broadcasting receivers, and satellite broadcasting receivers.
• Short-Range Devices: The directive covers short-range radio devices used for specific purposes, such as wireless LAN (Wi-Fi) equipment, Bluetooth devices, wireless microphones, RFID (Radio Frequency Identification) devices, remote control devices, and other similar short-range radio applications.
• Internet-Connected Radio Equipment: Devices capable of communicating over the internet (directly or via other equipment) are now subject to specific cybersecurity requirements (Article 3.3(d), (e), and (f)).

Compliance with the Radio Equipment Directive (RED) requires the preparation and availability of various documentation and technical documentation. Here are the key documents that manufacturers or their authorized representatives must have to demonstrate compliance with the RED:

Technical Documentation: Manufacturers are required to create and maintain technical documentation that demonstrates the conformity of the radio equipment with the essential requirements of the RED. This documentation should be readily available for inspection by relevant authorities and should contain sufficient information to assess the compliance of the equipment. It typically includes:

• General description of the equipment
• Design and manufacturing drawings and specifications
• List of applicable standards or other technical specifications followed
• Descriptions of solutions adopted to meet essential requirements
• Results of design calculations, risk assessments, and test reports
• User and installation manuals, if applicable
• Information on labeling and marking of the equipment

Manufacturers have the option to self-declare compliance with the Radio Equipment Directive (RED) for most categories of radio equipment. This means they can carry out the conformity assessment themselves and issue the Declaration of Conformity (DoC) without the involvement of a third-party organization.

The RED allows for self-declaration of conformity through the "Internal Production Control" (Module A) conformity assessment procedure. Under this module, manufacturers or their authorized representatives are responsible for ensuring that the radio equipment meets the essential requirements of the directive but for certain categories of radio equipment with higher risks or specific characteristics, the involvement of a notified body is mandatory for the conformity assessment process. In these cases, third-party involvement is necessary, and the manufacturer cannot solely rely on self-declaration. The specific categories that require notified body involvement are outlined in the RED.

Non-compliance with the Radio Equipment Directive (RED) can lead to various penalties and consequences depending on the regulations and enforcement practices of individual European Union (EU) member states. Potential penalties for non-compliance with the RED could be:

• Market Withdrawal or Recall
• Administrative Measures
• Fines and Financial Penalties
• Legal Proceedings
• Restricted Market Access
• Reputational Damage

Manufacturers, importers, and distributors need to ensure compliance with the RED to avoid potential penalties and consequences. Compliance with the directive's requirements helps protect consumers, ensure fair competition, and promote the availability of safe and reliable radio equipment in the EU market.

Penalties for non-compliance with the Radio Equipment Directive (RED) vary among the European Union (EU) member states. Each member state is responsible for implementing and enforcing the directive within its jurisdiction, including determining the penalties for non-compliance. Penalties and enforcement measures are typically determined by national legislation or regulations enacted by individual EU member states.

Manufacturers can market radio equipment that meets international standards but is not yet fully compliant with the Radio Equipment Directive (RED) under certain conditions. The RED allows for a transitional period during which equipment complying with certain previous standards can still be placed on the market, provided that it does not endanger the safety of people, property, or the environment.

During this transitional period, manufacturers can continue to place radio equipment on the market that meets the essential requirements of older standards recognized by the European Commission. However, they should make efforts to ensure compliance with the RED as soon as possible.

After the end of the transitional period, manufacturers must ensure that their radio equipment fully complies with the requirements of the RED to continue placing it on the market within the EU.

The specific procedure for conformity assessment depends on the category and characteristics of the radio equipment. Here is a general overview of the conformity assessment process under the RED

Determine the Appropriate Module: Identify the applicable conformity assessment module based on the category and characteristics of the radio equipment. The RED defines differences that outline specific procedures for conformity assessment.

• Module A - Internal Production Control
• Module B: EU-Type Examination
• Module C: Conformity to Type based on Internal Production Control plus Supervision of a Notified Body
• Module D: Conformity to Type based on Quality Assurance of the Production Process
• Module E: Conformity to Type based on Product Verification
• Module F: Conformity to Type based on Unit Verification

Prepare the Required Documentation: Regardless of the module used, prepare the necessary technical documentation, including design and manufacturing specifications, risk assessments, test reports, and descriptions of solutions adopted to meet the essential requirements.

Issue Declaration of Conformity (DoC): After a successful conformity assessment, issue a Declaration of Conformity (DoC) stating that your radio equipment meets the essential requirements of the RED.

CE Marking and Market Access: Apply the CE marking on your compliant radio equipment to indicate conformity with the RED. This marking allows for the legal placement of the equipment on the market within the European Union.

It's important to note that the specific requirements and procedures for conformity assessment may vary depending on the characteristics and intended use of the radio equipment. It is recommended to consult with an expert.

The European Commission has officially granted an extension to the transition period for the Delegated Act (2022/30) associated with the Radio Equipment Directive (2014/53/EU). As a result of this decision, compliance with the specified cybersecurity requirements will become obligatory starting from the 1st of August 2025. It means that any devices in the scope of the RED Delegated Act will need to be compliant when placed into the European market after August 1, 2025.

As of August 1, 2025, the RED mandates that radio equipment with internet connectivity or certain wireless functionalities must comply with enhanced cybersecurity requirements, per the Delegated Act (2022/30). This includes internet-connected devices, childcare radio equipment, and wearable radio equipment.

The European Commission established that compliance with the specified cybersecurity requirements became obligatory starting from the 1st of August 2025. It means that all devices in the scope of the RED Delegated Act (such as internet-connected devices, cameras, smart home tech, and wearables) must comply to be placed into the European market today. Non-compliant equipment can no longer be legally placed on the market.

Yes, if it is a small or medium-sized portable electronic device capable of being recharged via wired charging. As of December 28, 2024, the Common Charger Directive (Directive (EU) 2022/2380) mandates that mobile phones, tablets, digital cameras, headphones, handheld video game consoles, portable speakers, e-readers, keyboards, mice, portable navigation systems, and earbuds must be equipped with a USB-C receptacle. Note: For laptop computers, this requirement will become mandatory starting April 28, 2026

No, the CE mark is the mandatory compliance mark for RED, indicating conformity with EU standards. It is essential for gaining legal access to the EU market.

IoT devices are the nonstandard computing devices that connect wirelessly to a network and have the ability to collect, store and transmit data. Embedded with technology, these devices can communicate and interact over the internet. They can also be remotely monitored and controlled. 

As technology continues to advance, anything can be turned into part of the IoT. There are many different types of IoT devices, some examples include

• Computers: Desktop computers, laptops, tablets, and smartphones 
• Consumer Electronics: televisions, DVD players, and video game consoles
• Communication devices: telephones, cell phones, and radios.
• Smart Home appliances: washing machines, refrigerators, and air conditioners.
• IoMT devices: Electronic devices worn on the body, such as smartwatches, fitness trackers, and smart glasses.
• IIoT devices: some of the connected devices are used to control Industrial Automation and Control systems. These devices are devices used in factories and industrial settings to automate and control processes, such as programmable logic controllers (PLCs) and sensors.
• Automotive Electronics: Electronic devices used in vehicles, including navigation systems, engine control units, and collision avoidance systems.

‍

A large percentage of electrical and electronic devices that surround us are connected (IoT) devices. 

When the IoT technology is intended for individuals, rather than organizations, these devices are called consumer IoT products. 

A wide range of devices and systems can collect, store and transfer health-related data. They are called IoMT devices, which can either be used by individuals or organizations. 

IIoT devices refer to a wide range of devices and systems including products and machinery used for industrial or manufacturing environments.

‍

One of the key challenges in the IoT device market is cybersecurity. Because IoT devices are connected to a network, they are vulnerable to cyber attacks that can compromise the confidentiality, integrity, and availability of the device, and the information it processes. This can have serious consequences, especially for devices that handle sensitive information or are critical to the operation of a system.

To address these challenges, it is important for manufacturers and other stakeholders to implement robust cybersecurity measures and follow relevant regulations and standards. This can help to reduce the risk of cyber-attacks and ensure the security of IoT devices.

‍

ETSI EN 303 645 is a technical specification developed by the European Telecommunications Standards Institute (ETSI) that provides guidelines for the security of Internet of Things (IoT) devices. ETSI EN 303 645 is the first globally applicable Cybersecurity Standard for Consumer IoT Devices. 

This standard covers consumer IoT devices that are connected to network infrastructure and their interactions with associated services, like smart tv’s, CCTV cameras, speakers, connected home automation devices, IoT gateways, base stations, HUBs, wearable health trackers, baby monitors, IoMT devices, connected home appliances like smart refrigerators and washing machines, or connected alarm systems, door locks, smoke detectors, among many others. 

ETSI EN 303 645 contains a set of 13 cybersecurity categories and some provisions specifically focused on Data Protection.

In addition to providing guidelines for device security, ETSI EN 303 645 also includes recommendations for the management of security risks, including the identification and assessment of risks, the implementation of controls to mitigate those risks, and the ongoing monitoring of risks.

‍

CCLab provides consultation, testing, and certification services for Consumer IoT devices.

• Training/Consultancy: We offer workshops to guide developers on their journey to ETSI EN 303 645 compliance. We provide insights and document templates for preparing the ICS, IXIT, and additional documentation needed for an evaluation.
• GAP Analysis: We assess the products to determine the differences between the current security implementation and the provisions defined in ETSI EN 303 645.
• Product Evaluation: We evaluate the product based on the applicable provisions of the ETSI EN 303 645 and will issue a conformance evaluation report as well as the identified security gaps.
• Statement of Conformity: CCLab issues a Statement of Conformity when the evaluated product meets the requirements defined in ETSI EN 303 645.

‍

• Every relevant Object and Threat shall be cross-checked
• It is worth using the SDCM matrix to check the relevance (there is embedded macro logic)
• For every cross-check describe the security functionality (SF) shortly, detailed information shall be referenced in the related documentation
• The SF description should include the localisation (TOE, TOE environment or Organization Security PAC - OSP)
• It is a good solution to use the SDCM Excel sheet as a framework to create the manufacturer’s OT matrix

• For every row, describe shortly the implementation and localisation, use references if necessarymore detailed information shall be referenced in the related documentation
• The SDCM is consistent with the OT matrix control and checklist sheet, hence the rows should be consistent.

• TOE shall be pre-configured and as exactly described in the product documentation - security settings shall be double-checked before delivery
• The operability and correct configuration of TOE shall be tested by the manufacturer before delivery
• The tested and operable credentials of the TOE and a short step-by-step login guide shall be delivered with TOE too.
• The fulfillment of the previous 3 requirements can save a lot of time during evaluations

• Proper identification of the whole TOE and main parts of the TOE are required (ID, name, version)
• A well-structured OT matrix and checklist speeds up evaluations
• In the manufacturer’s OT matrix, mark the cells where SDCM indicate “not relevant” and please justify
• One sentence for a security functionality within the OT matrix is not enough evidence. Must be supported by detailed information - referenced in the related documentation
• Appropriate reference is a must in manufacturer docs: Doc name, version, date, relevant Chapter, or section/paragraph
• The consistent referencing between the documentations and OT matrix description, checklist, OT matrix and related checklist indicated by SDCM are required.
• The OT matrix and Checklist shall focus on mandatory contents.
• Do not refer to irrelevant documents
• Preliminary acceptance checks of manufacturer documentation can be useful. (Starting an evaluation with deficient or contradictory documentation is not recommended

• Missing or inexact TOE identification
• OT matrix is not consistent with the description of security functionalities (missing fields or descriptions)
• Inexact or missing references (missing chapter, section, therefore the relevant evidence cannot be identified)
• The Checklist’s „HOW” section doesn’t answer the „WHAT” requirement
• „HOW” or „WHERE” cannot be verified (no reference to detailed documentation)
• The content of HOW and WHERE are inexact (TOE implementation differences)

• TOE is not pre-configured or tested by the manufacturer according to the product’s documentation - security settings shall be double-checked. In these cases, the laboratory has to focus and spend days on preliminary actions to set up an operable TOE.
• We recommend addressing any arising serious questions on the go, daily contact and quick reactions accelerate evaluations.

CCLab proposes a step-by-step approach to its clients during security evaluations, using Flaw Hypothesis Methodology based on our own Common Criteria experience.

The essence of the methodology is to set up the Flaw Hypothesis and then to test the hypothesis by analyzing the documentation in more depth and detail and finally by penetration testing.

Based on the errors found, we perform a “generalization” of the errors, eliminate or correct them and perform a re-check. 

The target security level can be reached on an increasing basis: first solving the most aching problems, then strengthening the security of the IT system gradually.

• Security by design
• Secure coding training
• Vulnerability assessment
• Penetration testing
• Hardening
• Security audit

For mobile applications CCLab proposes to follow the OWASP Mobile Application Security Verification Standard. The evaluation process is based on MASVS-L1 Standard Security level and additionally extended to MASVS-L2 Defense-in-Depth level.

‍

It depends on the product we test, and many factors such as product complexity and assurance claims. Usually a simple penetration task can take a few weeks, a complex vulnerability assessment project can take a few months, whilst a higher evaluation assurance level of Common Criteria evaluation could even take 6-12 months depending on the quality of manufacturer documents and the number of deficiencies found during the evaluation.

Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC (Text with EEA relevance. )

https://eur-lex.europa.eu/eli/reg/2017/745/oj

Regulation (EU) 2017/746 of the European Parliament and of the Council of 5 April 2017 on in vitro diagnostic medical devices and repealing Directive 98/79/EC and Commission Decision 2010/227/EU (Text with EEA relevance. )

https://eur-lex.europa.eu/eli/reg/2017/746/oj

As medical devices get smarter features providing more efficient and easy-to-use solutions to patients the used technologies can introduce additional risks for patient health and their personal data. These smart features are usually implemented with software, internet connection and other IT technologies. These technologies introduce cybersecurity risks in the medical device and based on the device’s features, functionality and the data it handles it can become a target for cybercriminals. Health data is considered sensitive personal information therefore in case of a cyberattack where the attackers steal patient data or harm patient safety the manufacturer/developer of the device can face serious fines.

EU regulations on medical devices have been adopted and entered into force on 25 May 2017. 

These are:

MDR 745/2017 - MDR Medical Devices Regulation; EU 2017/745

IVDR 746/2017 - IVDR In Vitro Diagnostic Medical Devices Regulation; EU 2017/746

Both regulations (MDR and IVDR) contain cybersecurity requirements. The goal of the policy makers was to create a regulation that ensures an industry standard security level without burdening market entities too much. The result is a risk-based approach where manufacturers/developers identify, analyze, and manage cybersecurity risks relevant to their product and create the necessary procedures and documentation to handle cybersecurity risks.

We offer “zero to hero” and integration services which help manufacturers/developers to achieve cybersecurity MDR compliance.

Our comprehensive services help from product design through development and MDR/IVDR certification. . They provide a clear path to compliance through methodology based on internationally recognized standards.

Integration services build on customers’ already implemented management systems that comply with relevant industry standards. Integration services help customers to utilize their already implemented processes instead of creating new ones.

Compliance to internationally recognized standards eliminates quality discrepancies. A manufacturer/developer might think that a freshly designed and planned cybersecurity activity will be compliant to regulatory requirements but during the certification process the notified body might reject the evidence because of insufficient quality. Standards are created by a group of experts on the relevant field and contain every pertinent aspect of the topic. Compliance to internationally recognized standards ensures that designed and implemented security procedures are secure. It creates a common language between the manufacturer/developer and the notified body.

As each project and product evaluation is different, there is no exact answer to this question. It depends on many factors such as product complexity and assurance claims. The certification time also depends on the selected certification body. Contact us @ info@cclab.com and we will help you put together a project plan and schedule.

Please contact our sales team, and they will help you. You can reach us by email:  info@cclab.com or mobile phone: +36 (20) 212 1664 . 

‍