The Cybersecurity Act created a framework before a label

A common route to cybersecurity certification could reduce repeated supplier assessments across Europe. Its commercial value depended on the scope of each scheme, supporting evidence and the continuing cost of security support.

Delegates occupy curved rows of desks in the European Parliament chamber in Strasbourg.
European Parliament plenary session, Strasbourg, 2014.David Iliff (opens in a new tab) · CC BY-SA 3.0 (opens in a new tab)

Selling a connected product across Europe could require a supplier to explain the same security controls repeatedly, through different customer reviews and national arrangements. The EU Cybersecurity Act addressed that fragmentation by establishing a European certification framework for information and communications technology products, services and processes. It entered into force on 27 June 2019.

The law also gave ENISA a permanent mandate and a central role in preparing certification schemes. Those were institutional changes with practical consequences for suppliers. They created a route towards common assurance, but the regulation was not itself a universal product certificate. A startup still needed to know which future scheme would cover its offering, what evidence it would require and whether customers would value that assurance.

Common recognition needed a common scheme

Article 46 established the framework to improve the internal market by raising cybersecurity and enabling a harmonised approach. Under Article 49, ENISA would prepare candidate schemes following the prescribed process, while the Commission could adopt schemes through implementing acts. An operational assessment programme therefore required further technical work and Commission approval.

The intended benefit was that certification under an adopted European scheme would be recognised throughout Member States. For an emerging supplier, that could reduce repeated evaluation and make an assurance investment useful across more customers. The potential saving depended on an applicable scheme existing, its scope matching the product and buyers accepting its evidence. An immediate security passport valid across Europe remained beyond what the framework offered.

Assurance was a graduated claim

Article 52 described three assurance levels: basic, substantial and high. Basic addressed known basic risks, with at least a technical documentation review or equivalent evaluation. Substantial added evaluation against known cybersecurity risks and attacks by actors with limited skills and resources. High concerned state-of-the-art attacks by actors with significant skills and resources, with more demanding assessment including resistance to skilled attackers.

A certificate and an EU statement have different routes

Scroll to view all columns

ComparisonEuropean cybersecurity certificateEU statement of conformity
Evaluation routeCertification under the applicable adopted schemeSupplier conformity self-assessment where the scheme permits it
Assurance scopeScheme may provide basic, substantial or high assuranceLimited to low-risk offerings corresponding to basic assurance
Supplier responsibilityMaintain the product and information required by the schemeAssume responsibility for compliance and retain supporting documentation

Routes described in Articles 52, 53 and 56 of the act. Neither route existed independently of an applicable certification scheme.

Source1

These levels were not a simple ranking of vendors. The relevant question was the combination of product, threat model, scheme requirements and evaluation depth. A small supplier serving a modest risk use case could rationally make different investments from a business selling into critical infrastructure. Buyers and investors needed to understand what an assessment covered before treating its level as a commercial advantage.

Voluntary did not mean commercially irrelevant

Article 56 made cybersecurity certification voluntary unless Union or Member State law specified otherwise. The act did not require every software business to obtain a certificate simply to sell in Europe. It also contemplated future assessment of whether particular schemes should become mandatory through relevant legislation. Those legal distinctions affected both market sizing and the timing of expenditure.

Procurement could create a separate incentive. A customer might prefer an independently evaluated component, or find its assessment useful in a broader supplier review. A founder needed evidence of that purchasing behaviour before building certification costs into the sales plan. Legal availability, a customer's contractual requirement and a useful marketing signal represented three different reasons to invest.

The support promise outlasted evaluation

Article 55 required supplementary information for certified offerings and those carrying an EU statement: secure configuration guidance, the period of security support, contact routes for vulnerability reports and references to disclosed vulnerabilities or advisories. Article 54 required schemes to address continued compliance and previously undetected vulnerabilities. The framework therefore connected assurance with the product's life after its first release.

For a device company, promising security updates could imply engineering capacity for products no longer generating meaningful sales. For a software service, dependency updates and configuration changes could affect the assessed boundary. These were operating costs to understand early. A security claim that excluded important components, or relied on support a supplier could not fund, would offer limited reassurance to a careful customer.

A Raspberry Pi 4 Model B circuit board showing its Broadcom processor, memory, connectors and USB and Ethernet ports.
Raspberry Pi 4 Model B with a Broadcom BCM2711 Arm processor, July 2019.Laserlicht (opens in a new tab) · CC BY-SA 4.0 (opens in a new tab)

A permanent agency gave the framework an owner

The act strengthened ENISA's role in cybersecurity cooperation as well as certification. Its permanent mandate replaced the agency's temporary arrangements. Preparing technical schemes, supporting Member States and sharing expertise gave the certification framework an institutional home rather than leaving each supplier to interpret the legislation alone.

That did not guarantee a particular scheme's timetable or immediate customer demand. The commercial opportunity for security tooling and advisory software lay in specific work: preserving evaluation evidence, managing vulnerabilities and keeping product information current. Suppliers that could show those activities becoming easier or more reliable had a clearer proposition than a general promise to make customers compliant.

Investment implications

  • The act established the framework for European certification; specific schemes still needed to be developed and adopted.
  • Assurance levels describe evaluation against a scheme's requirements and defined threats.
  • Security support, vulnerability handling and clear product boundaries affect the cost of maintaining customer trust.

Sources

  1. Regulation (EU) 2019/881, original adopted text (opens in a new tab)

    European Union, preserved by The National Archives

  2. EU Cybersecurity Act (opens in a new tab)

    European Commission

CIR Ventures Journal

Published

Browse the journal