Understanding the European Cybersecurity Certification Framework

Understanding the European Cybersecurity Certification Framework

The European Union (EU) cybersecurity regulatory landscape is reminiscent of a medieval tapestry full of interwoven threads that complement one another to create the larger picture. Regulation (EU) 2019/881 created the foundation for information and communications technology (ICT) cybersecurity certification. Following this, the Commission Implementing Regulation (EU) 2024/482 (Implementing Regulation) specified the roles, rules, obligations, and structure of the European Common Criteria-based cybersecurity certification scheme (EUCC).

Since the initial publication, the European Commission has updated the Implementing Regulation twice, with amendments published in August and December of 2025. To achieve EUCC certification, vendors of information communications technology (ICT) should understand the mandatory process and assurance levels that certified products must meet.

 

What Is the Commission Implementing Regulation (EU) 2024/484?

According to Chapter 1, Article 1, the Commission Implementing Regulation (EU) 2024/484 establishes the European Common Criteria-based cybersecurity certification scheme (EUCC). It sets the rules and framework for evaluating and certifying ICT products under the EU Cybersecurity Act (Regulation EU 2019/881). The regulation outlines roles for:

  • Certification bodies who issue certificates.
  • Information Technology Security Evaluation Facility (ITSEFs) who perform the conformity assessments.

While the Implementing Regulation does not prescribe technical controls, it defines:

  • ITSEF evaluation
  • Assurance levels for products seeking certification.
  • ITSEFs and certification bodies that can conduct assessments.

 

Who Must Achieve EUCC Certification?

According to the Implementing Regulation, it applies to:

  • Information and communication technologies (ICT) products and their documentation.
  • Protection profiles submitted for specific ICT product categories

Some examples of these technologies might include, but are not limited to:

  • Operating systems.
  • Software managing sensitive data.
  • Internet of Things (IoT) devices with network connectivity functions.
  • Networking devices.
  • Embedded systems in critical sectors.

 

What Is a Target of Evaluation?

A target of evaluation (TOE) is the product, system, or component that must achieve certification, defining the ITSEF’s audit scope. The certification’s testing, documentation, and evaluation only apply to the TOE, not the rest of the organization’s environment.

 

What Is A Security Target?

A security target (ST) is a document that an ICT vendor prepares to define the TOE’s scope, including the following:

  • Threat analysis.
  • Security objectives.
  • Functional requirements
  • Assurance requirements.

The ST frames how the ITSEF will perform the evaluation.

 

What Is A Protection Profile?

A protection profile (PP) defines the security requirements based on product category. PPs allow consumer groups, governmental bodies, and communities to express security needs and facilitate writing STs.

Some examples of PPs include:

  • Smartcards, like the chips in ID cards, credit cards, or SIM cards.
  • Devices that create secure digital signatures, like e-signature hardware.
  • Digital tachographs, the devices in trucks that record driving hours and speed.
  • Embedded security hardware, chips or modules inside other devices that protect sensitive data.
  • Payment terminals, the card readers or point-of-sale machines you see in stores.

 

What Are the Evaluation Criteria and Methods for ICT Products?

When an ICT vendor submits a product for certification, Article 7 “Evaluation criteria and methods for ICT products,” outlines the following evaluation criteria that goes into formal effect after December 31, 2027:

  • The Common Criteria for Information Technology Security Evaluation published by the participants of the Arrangement on the Recognition of Common Criteria Certificates in the field of IT Security (CCRA).
  • Common Methodology for Information Technology Security Evaluation, version 3.1., revision 1 to 4, published by the participants of the Arrangement on the Recognition of Common Criteria Certificates in the field of IT Security.

Until December 31, 2027, organizations can use any of the following standards:

  • ISO/IEC 15408-1:2009, ISO/IEC 15408-2:2008 or ISO/IEC 15408-3:2008
  • CCRA version 3.1, revision 5
  • ISO/IEC 18045:2008
  • Common Methodology for Information Technology Security Evaluation, revision 5, version 3.1.

 

What Is the Arrangement on the Recognition of Common Criteria Certificates In the field of Information Technology Security?

The CCRA member organizations defined Security Functional Components (SFCs) and Security Assurance Components (SACs) that organizations seeking certification should understand.

Security Functional Requirements (SFRs)

Based on ISO/IEC 15408, the Common Criteria Security Functional requirements act as the building block that the Common Criteria uses to define the security functionality that a product or TOE must deliver, either in a PP or ST.

At a high level, the Common Criteria SFR categories are:

  • Communication Protection (FCO): Support for protecting the authenticity and non‑repudiation of messages or data exchanges.
  • Cryptographic Support (FCS): Cryptographic functions such as key management, random number generation, and encryption/decryption.
  • User Data Protection (FDP): Controls for accessing user data, like access control policies, data integrity, confidentiality, and flow control.
  • Identification & Authentication (FIA): Ways the product identifies users and verifies their credentials, including controls like passwords, multi‑factor authentication (MFA), and identification before actions.
  • Security Management (FMT): Functions for configuring and managing security roles, attributes, and functions.
  • Privacy (FPR): Privacy‑related features, like anonymity, pseudonymity, unlinkability, and unobservability.
  • Protection of the TOE Security Functions (FPT): Controls ensuring protection of the product’s security logic, like using secure initialization, fail‑secure behavior, or control of exported TSF data.
  • Trusted Path / Channel (FTP): Secure communication paths between users and the TOE or between TOEs..

These categories allow ICT vendors to choose the controls governing their product’s category.

Security Assurance Requirements (SARs)

Security Assurance Requirements (SARs) govern the processes around the activities that an evaluator assesses. A product’s Evaluation Assurance Level (EAL) or assurance packages consists of:

  • Security Target & Protection Profile Evaluation (ASE): Vendor documentation that defines the security claims (ST or PP), ensuring that they are clear, consistent, and measurable.
  • Development (ADV): Product’s internal design and implementation, like architecture, specifications, and completeness of security functions.
  • Guidance Documents (AGD): User, administrator, and developer guidance is sufficient and accurate for secure use and configuration.
  • Life‑Cycle Support (ALC): Secure processes around configuration management, delivery, flaw remediation, and tool use.
  • Tests (ATE): Functional and independent tests have been designed and executed to cover claimed security functions.
  • Vulnerability Assessment (AVA): Product resistance to known and potential vulnerabilities, including analysis and penetration testing evidence.
  • Composition (ACO): Components integrate and interact securely.

 

Best Practices for EUCC Certification Audit Readiness

Achieving EUCC certification means demonstrating that a technology’s security capabilities are operational, measurable, and defensible. Ultimately, readiness is about visibility, integrity, traceability, and control. By following these best practices, organizations can become audit ready faster and streamline the certification process.

Centralize and Normalize Security Logging (FAU, ATE, AVA)

Organizations need complete, consistent, reviewable audit evidence by consolidating logs across relevant systems, including the ones generated by:

  • Applications
  • Infrastructure
  • Identity services
  • Network devices

With all data in one location, organizations can correlate data from normalized, structured logs during evaluations to support independent testing.

Enforce Access Controls and Role Separation (FIA, FDP, FMT)

In a multi-cloud or hybrid cloud infrastructure, effective identification and authentication controls are critical security protections. Evaluators will look for evidence of role-based access management, like:

  • Limiting and documenting privileged access.
  • Logging administrative actions.
  • Restricting security configuration changes to authorized roles.

Clear role segmentation with audit trails strengthens documentation.

Protect Log Integrity and Retention (FPT, ALC)

Since audit data is critical security evidence, organizations need to ensure that it is:

  • Tamper resistant.
  • Time-synchronized.
  • Retained according to documented policy.

Secure storage, integrity verification mechanisms, and documented retention procedures demonstrate lifecycle maturity and process control.

Enable Continuous Monitoring and Alerting (FAU, AVA)

Certification requires organizations to prove that they have continuous monitoring to support vulnerability detection, anomaly identification, and incident response readiness. To meet these requirements and document adherence, organizations should implement real-time, high-fidelity alerting to prove their ongoing security posture.

Maintain Searchable, Reportable Evidence (ASE, AGD, ATE)

During evaluation, organizations should be able to quickly produce:

  • Audit trails
  • Configuration change histories
  • Access logs
  • Incident investigation records

When organizations have built-in reporting and dashboards, they can reduce the operational costs associated with gathering audit documentation and responding to additional document requests.

Align Operational Controls with Security Claims

The security target defines what a company claims its product does. Monitoring, logging, and operational controls prove that the claims are defensible. Aligning security telemetry, reporting, and management processes with the declared SFRs streamlines the evaluation process.

 

Graylog: Improving EEUC Certification Processes

Built on the Graylog Platform, Graylog Security gives you the features and functionality of a SIEM while eliminating the complexity and reducing costs. With our easy to deploy and use solution, you get the combined power of centralized log management, data enrichment and normalization, correlation, threat detection, incident investigation, anomaly detection, and reporting.

With Graylog prebuilt content, you don’t have to worry about choosing the server log data you want because we do it for you. Graylog Illuminate content packs automate the visualization, management, and correlation processes for you.

To see how Graylog can help you improve your audit readiness, contact us today.

Categories

Get the Monthly Tech Blog Roundup

Subscribe to the latest in log management, security, and all things Graylog blog delivered to your inbox once a month.