CRA Full Application 11 December 2027: The CE-Marking and Conformity Path for Software

By 11 December 2027 a great deal of software sold into the EU will need a CE mark, and for teams that have never touched product conformity the mechanics are less obvious than they look.

CE marking is familiar ground for anyone who has ever shipped a physical product. For software it is new territory. The Cyber Resilience Act, Regulation (EU) 2024/2847, extends CE marking to “products with digital elements”, and that phrase explicitly reaches standalone software placed on the EU market. This is a reading of the conformity route for software specifically: which assessment module applies, where you can sign your own declaration and where an external body has to get involved, and what the CE mark actually attests once it is affixed. The legal text is available elsewhere; the question here is what the regime does to the way an engineering organisation has to work.

The dates that bind

The Regulation entered into force on 10 December 2024 and applies in stages. From 11 June 2026 the provisions on notified bodies apply, so the accreditation infrastructure exists before it is needed. From 11 September 2026 the reporting obligations in Article 14 are live: actively exploited vulnerabilities and severe incidents must be notified to ENISA and the relevant CSIRT within defined windows. The main obligations, including CE marking against the essential requirements, apply from 11 December 2027. That last date is the one that decides whether you may place a product on the market at all.

What the CE mark attests for software

For a machine, a CE mark says the physical thing meets its essential requirements. For software under the CRA it means something narrower and slightly stranger: that the product was designed and built against the essential cybersecurity requirements in Annex I, and that the manufacturer runs a vulnerability-handling process for the whole of the declared support period. Annex I has two parts. Part I covers product properties such as secure-by-default configuration and attack-surface minimisation. Part II covers vulnerability handling, including a software bill of materials, coordinated disclosure and the timely delivery of security updates. The mark is not a statement that the software is secure. It is a statement that a defined process produced it and continues to maintain it. Get that distinction wrong and you will document the wrong things, so it is worth being clear that Annex I is a risk assessment, not a checklist.

The four routes, and which is yours

Article 32, with the procedures set out in Annex VIII, gives four conformity routes:

• Module A, internal production control. Self-assessment. The manufacturer evaluates the product against the essential requirements, compiles the technical documentation and signs the declaration. No external party is involved.
• Module B plus Module C. EU-type examination by a notified body, followed by the manufacturer’s own declaration that production conforms to the examined type.
• Module H, full quality assurance. A notified body assesses and certifies the manufacturer’s quality system across design, production and support.
• A European cybersecurity certification scheme at the appropriate assurance level, where one exists, which can stand in for the notified-body route.

Which of these you may use is not a preference; it is decided by how your product classifies. This is the same internal-control-versus-external-body split that runs through the high-risk regime under the AI Act, and if you have already read internal control versus notified body under the AI Act, the logic transfers cleanly.

Where self-assessment stops

Most software is “default”: not on either important-products list, and free to self-assess under Module A. Mobile apps, most SaaS features, games. You compile the file and sign your own declaration.

The moment your product lands on Annex III, that changes. Annex III splits important products into class I and class II. Class I covers a long list of security-relevant software: password managers, standalone browsers, antivirus and malware-removal tools, VPN products, network management systems, SIEM systems, identity and privileged-access management, boot managers and general-purpose operating systems. For class I you may still self-assess under Module A, but only if you fully apply the relevant harmonised standards, common specifications or a cybersecurity certification scheme. Apply them only in part, or in an area where no harmonised standard yet exists, and you drop to a notified body under Module B plus C or Module H.

Class II is stricter. Server, desktop and mobile operating systems, hypervisors and container runtimes, public-key-infrastructure and certificate-issuance software, industrial firewalls and intrusion-detection systems: these cannot self-assess at all. A notified body, or a certification scheme at the substantial level, is mandatory whatever standards you apply. Critical products in Annex IV, such as secure elements, smartcards and smart-meter gateways, go further still, towards a required European certificate. Working out where your product sits is the decision that governs everything downstream, which is why the important-versus-critical class test deserves to be run before any conformity work begins.

The evidence each route demands

Whichever module applies, the artefact a market-surveillance authority will ask to see is the technical documentation in Annex VII, held for at least ten years or the support period, whichever is longer. That documentation has to describe the product, the essential-requirements assessment, the vulnerability-handling process and the SBOM, and it has to be kept current as the product changes. Under Module A you produce and hold it yourself. Under B plus C or H a notified body examines a version of it and issues a certificate you reference in your EU declaration of conformity under Annex V. The declaration is the legal act; the CE mark is its visible shorthand.

The trap for software teams is to treat all of this as a documentation exercise to be done at the end. Annex I is a design-time obligation. If secure-by-default configuration, attack-surface minimisation and signed updates were not built in from the start, no volume of late documentation will describe them into existence. You cannot evidence a property the product does not have.

Why the timing is tighter than it reads

The full-application date reads like a 2027 problem. For anything that needs a notified body, it is not, and the reasons that the Annex III reprieve is a trap apply directly here. Notified bodies begin operating from mid-2026, their capacity is finite, and every class II software product in the EU is chasing the same assessment slots against the same deadline. If your product is class I and you intend to self-assess on harmonised standards, several of those standards are still being drafted, and you cannot self-assess against a standard that does not yet exist. Either way, the binding constraint is not the December 2027 date. It is the eighteen months of design evidence, documentation and, for many products, external assessment that has to be finished before it.

The CE mark is small. The route to earning it, for software that has never been a “product” before, is not, and the firms that first discover which route they are on in 2027 will discover it too late to change course.