Annex III, Class I ยท Regulation (EU) 2024/2847

Is PKI or certificate issuance software an important product under the CRA?

Verified against the Official Journal text on

Important product, Class I (Annex III Class I (9), Art. 7(1))

Yes, most likely. The CRA lists "public key infrastructure and digital certificate issuance software" as important products (Annex III, Class I, item 9). Software whose core functionality is running a certificate authority or issuing digital certificates carries the full manufacturer obligations and a restricted conformity route: self-assessment stays available only where harmonised standards, common specifications, or eligible certification are applied in full. This reaches internal CA tooling and ACME issuance servers you supply as a product, not only public CAs.

Basis: Annex III Class I (9), Art. 7(1), Art. 32(1)-(2)

Judgment call: Whether a product "has the core functionality of" PKI or certificate issuance software is a classification judgment the technical descriptions in Implementing Regulation (EU) 2025/2392 control.

What the category reaches Annex III Class I (9), Art. 7(1), Art. 7(2), Art. 7(4)

Item 9 of Class I names "public key infrastructure and digital certificate issuance software". The focus is on the software that mints, signs, and manages digital certificates and the keys behind them: a certificate authority application, a registration authority, a certificate lifecycle manager, and an issuance server that answers enrolment requests.

It sits in Class I for the Article 7(2) reason: PKI primarily performs a function critical to the cybersecurity of other products, since trust in every certificate it issues rests on it. The binding scope is the technical description in the implementing act, so assess your product against that, not against the plain label.

Internal CA tooling and ACME servers Art. 7(1), Art. 7(4)

A common assumption is that only public, trusted certificate authorities are in view. That is too narrow. Software you supply that issues certificates for an internal or private PKI, and an ACME server that automates issuance, are certificate issuance software by function, whatever the trust anchor, where you place them on the market as a product.

The distinction to keep is between issuing certificates and merely consuming them. A product that requests, stores, or validates certificates is not itself PKI issuance software, and Article 7(1) confirms that integrating an issuance component does not, on its own, reclassify the surrounding product. Resolve close calls against Implementing Regulation (EU) 2025/2392, record the outcome, and until then treat the stricter Class I route as your working assumption.

Judgment call: Whether tooling that automates certificate issuance for a private PKI is "certificate issuance software" for item 9 is a judgment the implementing act settles; issuing differs from consuming.

What Class I changes: your conformity route Art. 32(1), Art. 32(2), Annex VIII

For a default-category product a manufacturer may self-assess under internal control (module A). For a Class I important product that choice narrows: internal control remains available only where you apply harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least "substantial", in full, to the relevant essential requirements.

Where you do not, or where no such standard yet exists, the product must go through EU-type examination plus conformity to type (modules B and C) or full quality assurance (module H), both involving a notified body. Plan for that lead time well before 11 December 2027.

Everything else is the ordinary manufacturer programme Art. 13, Art. 14, Annex I

Class I status changes the conformity route, not the substance. The essential cybersecurity requirements, vulnerability handling including a coordinated vulnerability disclosure policy, technical documentation, CE marking, and the reporting duties for actively exploited vulnerabilities and severe incidents apply to PKI software as they do to any product in scope. Protection of signing keys and issuance integrity carries particular weight here.

What you must do

  • Design, develop, and produce the product in line with the essential cybersecurity requirements. (Art. 13(1), Annex I Part I)
  • Handle vulnerabilities during the support period, including putting in place and enforcing a coordinated vulnerability disclosure policy. (Art. 13(8), Annex I Part II (5))
  • Draw up technical documentation and carry out the Class I conformity assessment: internal control only with harmonised standards, common specifications, or eligible certification applied in full, otherwise modules B and C or module H via a notified body. Then affix the CE marking. (Art. 13(12), Art. 32(2), Annex VIII)
  • Report actively exploited vulnerabilities and severe incidents once reporting duties start. (Art. 14)

The dates that decide your planning

11 September 2026
Reporting duties start. Actively exploited vulnerabilities and severe incidents must be reported via the single reporting platform: early warning within 24 hours, notification within 72 hours, then a final report (within 14 days after a corrective measure is available for vulnerabilities, within one month after the notification for severe incidents). (Art. 14, Art. 16, Art. 71(2))
11 December 2027
The full obligations apply: essential cybersecurity requirements, technical documentation, conformity assessment, and CE marking. (Art. 71(2))

Frequently asked

Only public CAs are in scope, right?

Not necessarily. Item 9 reads as functional: software that issues digital certificates for a private or internal PKI, including an ACME issuance server, looks like certificate issuance software whatever the trust anchor, where you place it on the market as a product. The technical description in Implementing Regulation (EU) 2025/2392 settles the boundary. (Annex III Class I (9), Art. 7(4))

My product only consumes certificates. Is it PKI software?

Consuming, validating, or storing certificates is not the same as issuing them. A product that requests or verifies certificates does not fall in item 9, and integrating an issuance component does not, on its own, reclassify the surrounding product. (Art. 7(1))

Can I still self-assess as a Class I product?

Only where you apply harmonised standards, common specifications, or an eligible European cybersecurity certification scheme at assurance level at least "substantial" in full. Otherwise a notified body route applies (modules B and C, or module H). (Art. 32(2))

When does this start applying?

Reporting duties start 11 September 2026. The full obligations, including the Class I conformity route, apply from 11 December 2027. (Art. 71(2))

Check where your product lands, free

The Vexwatch Scope Checker walks the same cited decision tree in about three minutes: whether you are in scope, in which role, in which category, and which obligations hit on which date.

Check your scope, free See the Blueprint

This page is general information about Regulation (EU) 2024/2847, the EU Cyber Resilience Act. It is compliance tooling, not legal advice, and creates no client relationship. It may not reflect your specific circumstances or the most recent regulatory guidance. Verify conclusions against the regulation or qualified counsel before relying on them.