EU Cyber Resilience Act Penetration Testing: 2026 Guide

EU Cyber Resilience Act penetration testing requirements do not exist, because the CRA never uses the phrase. Regulation (EU) 2024/2847 contains no testing mandate, no methodology and no cadence. What lands on 11 September 2026 is Article 14: a reporting obligation with a 24-hour clock, triggered by actively exploited vulnerabilities and severe incidents.

That matters because of a derogation most readers have never opened. Article 69(2) grandfathers products placed on the market before 11 December 2027 out of the CRA's substantive requirements. Article 69(3) carves Article 14 straight back in, so your entire shipped portfolio, including near-EOL products you will never re-certify, is in reporting scope from September.

So the honest answer to "does the CRA require a pentest" is no. The useful answer is that it creates an obligation measured in hours, applied to code you shipped years ago, backed by a €15 million penalty tier. Meeting it without improvising means already knowing what is in your products, and already looking.

The Deadline Everyone Is Preparing For Is the Wrong One

Two dates get conflated in almost every CRA briefing, and the conflation runs in the direction that costs you.

11 September 2026 is Article 14 only: manufacturer reporting obligations. Nothing else switches on.

11 December 2027 is the substantive regulation: Annex I essential requirements, CE marking, conformity assessment, technical documentation, and the Article 13 obligations covering risk assessment, secure-by-default configuration, SBOM and support periods.

11 June 2026 was the Chapter IV provision on notification of conformity assessment bodies. It has passed and creates no obligation for you now. It is worth one line of planning attention all the same: the rules for designating notified bodies are live, but no bodies had been designated as of mid-2026. If your product lands in Annex III Class II and needs a notified body by December 2027, the queue you will join does not exist yet.

The failure mode is a plan that treats September 2026 as a warm-up for December 2027. It is a live obligation with its own scope, trigger and top-tier penalty, arriving fifteen months earlier.

The Grandfathering Exception Nobody Read

Article 69(2) generated every "we're grandfathered" plan in the industry: products placed on the market before 11 December 2027 are subject to the Regulation's requirements only if, from that date, they undergo a substantial modification. Read alone, a genuine relief valve. Article 69(3) is the next paragraph:

By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.

No substantial-modification test. No carve-out for maintenance mode, no exemption for a version you stopped selling, no exit for a device with two years of support left.

For most manufacturers this inverts the programme. Annex I covers the products you are building now. Article 14 covers everything you have ever shipped: a larger population, less well documented, and in many organisations owned by nobody.

Are You Actually In Scope?

The CRA regulates a "manufacturer of a product with digital elements": broader than hardware, narrower than "all software". A product with digital elements is a software or hardware product plus its remote data processing solutions. Place software on the EU market under your own name or trademark and you are a manufacturer, physical device or not.

:::accordion{title="Quick scope test: five questions"}

1. Do we place a software or hardware product on the EU market under our own name or trademark?
2. Does the product connect, directly or indirectly, to another device or network?
3. Is there a remote component we built, or had built for us, that the product needs to function?
4. Do we rebrand or substantially modify anyone else's product before it reaches the customer?
5. Are we importing or distributing a third party's product into the EU?

Yes to 1–3 makes you a manufacturer. Yes to 4 makes you the manufacturer of someone else's product. Yes to 5 alone puts you in the lighter importer/distributor regime under Articles 19 and 20. :::

The SaaS Line

Here the regulation is genuinely ambiguous. A browser-only web application or informational website is not a product with digital elements on that basis alone. Pure SaaS, consumed over the internet with nothing installed and not marketed as a discrete product, sits on the services side of the line and is regulated by NIS2 instead.

The exception swallows much of the rule. Remote data processing solutions designed or developed by or for the manufacturer, whose absence would prevent the product performing one of its functions, are treated as part of the product. DLA Piper's February 2026 analysis of the SaaS boundary frames the test as three questions: is the remote functionality integral, does the product depend on it, and was it developed by or for the manufacturer.

In practice, an endpoint agent reporting to a vendor-operated backend is almost certainly in scope, backend included. A pure web dashboard with no distributed artefact is probably not.

The cost of the ambiguity is not the classification. It is that an undocumented one is worth nothing under scrutiny. A defensible "out of scope" determination is a document; an undocumented assumption is a guess a regulator gets to re-run.

Open-Source Stewards and Small-Enterprise Carve-Outs

Open-source software stewards, meaning legal persons other than a manufacturer that provide sustained support for OSS used commercially without monetising it, face a lighter regime under Article 24. Individual contributors and non-commercial projects fall outside the CRA.

Microenterprises and small enterprises get one narrow piece of relief. Article 64(10) disapplies administrative fines for micro and small manufacturers that miss the 24-hour early-warning deadline, on both the vulnerability track (Article 14(2), point (a)) and the severe-incident track (Article 14(4), point (a)). The reporting obligation itself still stands, and the 72-hour and final-report deadlines still carry fines. Relief on one clock, not an exemption from the programme.

What Article 14 Actually Demands

Article 14 runs on two tracks with separate triggers: any actively exploited vulnerability contained in a product you placed on the market, and any severe incident having an impact on the security of that product.

Both tracks follow a three-stage cascade:

Reports go simultaneously to the CSIRT designated as coordinator for your Member State and to ENISA, filed through the Single Reporting Platform. The European Commission's CRA reporting obligations page is the authoritative routing index.

The Platform You Are Supposed to Report Through

ENISA has committed to the SRP being operational on 11 September 2026. It published registration and notification submission guides across July 2026, both updated 3 August 2026, and a platform interface guide updated 14 August 2026. Filing is done by a named person using a free EU Login account, which you can create now at ecas.ec.europa.eu.

Article 14(8) and Telling Your Users

Article 14(8) turns a regulator filing into a disclosure event. Manufacturers must inform impacted users of the vulnerability or incident, and where appropriate all users, and where necessary must tell them the risk-mitigation and corrective measures they can deploy. Read the qualifiers carefully: "where appropriate" governs whether you widen the notice beyond impacted users, not whether you notify at all. Telling impacted users is the default, not the judgement call.

There is also a teeth clause most summaries omit. Where a manufacturer fails to inform users in a timely manner, the notified CSIRT coordinators may notify those users directly where they judge it proportionate and necessary. The realistic worst case is not a fine; it is your customers learning about your vulnerability from their national CSIRT rather than from you.

That makes this a customer-communications obligation running on the same clock as the regulatory filing, and it needs product, support, legal and comms in the room. Teams that prepared only the CSIRT filing discover this at hour 20.

"Exploitable" Is Not "Actively Exploited": Your Pentest Does Not Start the Clock

This distinction decides whether your Article 14 programme is workable or unbearable, and most security teams get it wrong in the cautious direction.

Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. Three elements must all be present: reliable evidence, a malicious actor, and absence of the owner's permission.

An authorised penetration test satisfies none of them. The tester is not a malicious actor, the exploitation happened with permission, and the report proves exploitability, not exploitation. A critical pentest finding starts no clock. Neither does a published proof of concept, a CVSS 9.8, or a lab demonstration. The CVD Portal's treatment of exploitable versus exploited is the clearest available reference for anyone who assumes severity equals reportability.

The hard cases are genuinely hard, and each deserves a named decision-maker rather than a blanket policy:

• Your product, or a component you ship, appears in CISA KEV. Strong evidence about the vulnerability class, not automatically about your product as shipped.
• A customer reports behaviour that looks like exploitation. The most common real-world path to an Article 14 report, and the one most likely to sit in a queue.
• A researcher's disclosure includes in-the-wild evidence. Disclosure alone does not trigger. Disclosure plus artefacts from a live compromise does.
• A component you ship has a CVE with confirmed exploitation. Code you bundle is code you are answerable for.

Decide who owns each of those calls before 11 September and write the names down. The hardest part of a 24-hour clock is not the filing. It is the twelve hours spent deciding whether the clock has started.

Where "Aware" Starts

Awareness is organisational, not individual. It does not begin when your CISO reads the ticket. It begins when the information reaches your organisation through a channel you hold out to the world. A support ticket sitting unread is awareness risk. A researcher email in a shared mailbox with no owner is the worst version, because you published the address.

This is the real operational change: your intake surface is now your compliance surface. Every channel through which someone could tell you about exploitation needs a named owner, a 24-hour triage SLA and an escalation path.

What This Changes About Your Testing Programme

Be exact here, because your board will ask. The CRA does not mandate penetration testing. Annex I Part II requires "effective and regular tests and reviews of the security of the product with digital elements", plus identifying and documenting components and vulnerabilities and remediating without delay. That names no methodology, provider or frequency. What the CRA changes is the shape of the problem, and that makes a testing programme the rational response.

Test the Product, Not Just the Estate

Most testing budgets point at the corporate estate: the perimeter, the cloud accounts, the internal network. The CRA points at the artefact you ship: the binary or image, the components inside it, the default configuration a customer receives, the update channel and its signing chain, and the remote data-processing solution it depends on. A test scoped to your corporate infrastructure covers almost none of that. The one part it does reach is the remote data-processing solution, which the regulation counts as part of the product, and which is worth scoping deliberately rather than by accident.

Components Are Your Biggest Reporting Exposure

Annex I Part II requires an SBOM covering at least the top-level dependencies, and Article 13(5) requires due diligence when integrating components sourced from third parties, free and open-source components included. A vulnerability in a component you ship is a vulnerability in your product, and most Article 14 reports in practice will originate in somebody else's code.

The exposure concentrates where nobody is looking: an upstream project that went end of life, a vendored library pinned three years ago, a base image with an unpatched package. You cannot report on what you did not know you shipped. Our CVE lookup tool is a free starting point; the discipline that matters is running it against a complete inventory.

Cadence: Annual Testing Does Not Survive a 24-Hour Clock

The CRA does not require continuous testing, and nobody should claim it does. The argument for cadence is arithmetic. A once-a-year test leaves an eleven-month window against an obligation measured in hours. The defensible shape is continuous monitoring of the shipped artefact and its components, plus independent testing on a regular cadence that produces a dated, signed result rather than a dashboard. This is the continuous threat exposure management model applied to a product rather than an estate. We have also written about when automated testing is sufficient for teams working out where the line falls.

Evidence, and What You Will Need in 2027 Anyway

Testing records, dated findings and remediation tracking all feed the Annex VII technical documentation you need for conformity assessment in December 2027, so work done now is not wasted. Be precise about what that means, though, because it is where vendors overreach. For the large majority of products with digital elements, conformity assessment is the internal control procedure in Annex VIII, which is self-assessment: you evaluate your own product, compile the technical documentation and sign the EU declaration of conformity yourself. Only important products in Annex III Class II, and Class I products that do not fully apply harmonised standards or hold the relevant certificates, must bring in a notified body. Test reports are an input to your technical file. They are not a conformity artefact, no third party's report confers conformity, and nobody's signature substitutes for your declaration.

Evidence also has a use inside an Article 14 investigation: when a regulator asks how you handled a finding, the answer that holds is an independently produced, dated, signed report showing what was tested, what was found and when it was fixed. An internal ticket closed by the person who wrote the code is weaker, because the party that produced the evidence is the party being assessed by it.

That independence is structural rather than a matter of effort. With CyberOrbit you set the targets, the platform scopes and runs the assessment against them, and the completed report you select is reviewed and signed by a certified security professional, with real HTTP evidence behind every finding. That covers the systematic 80%, the known risk classes regular testing exists to catch. Our pricing page sets out the tiers and what each deliverable contains.

Pre-September readiness checklist

The Fourth Clock: CRA Alongside NIS2, DORA and the AI Act

The same incident can start four clocks running to four recipients, and this is where well-run programmes fail.

Under NIS2 you report as an entity about your own operations; under the CRA, as a manufacturer about a product. DORA gives financial entities a separate major-incident channel to their supervisor, and the AI Act adds serious-incident reporting for high-risk AI systems.

A vendor selling into European hospitals can be a CRA manufacturer and a NIS2 important entity simultaneously. The realistic failure mode is not ignorance of any single regulation. It is an incident-response runbook that knows about one of them, with no branch for the others.

If you already have a NIS2 reporting runbook, add a CRA branch rather than build a parallel process. The objects being regulated differ (entity versus product), but many of the internal steps are the same: awareness triage, decision owner, notification template, stakeholder list.

The Digital Omnibus proposal of 19 November 2025 would eventually consolidate cyber incident reporting through a single ENISA entry point built on the SRP. It is a proposal, not law, and implementation is expected 18 to 24 months after entry into force. It does not help you in September 2026.

Your Readiness Plan

Whether you are weeks from the deadline or reading this after it has passed, the sequence is the same. None of it requires a SRP URL or budget approval.

Step 4 is where most teams stall, because inventorying what you actually ship is harder than it sounds, and it is work only you can do. There is one part of the CRA surface you can get an outside read on today, though. Where you operate a remote backend that you built, or had built for you, and your product cannot perform one of its functions without it, the regulation treats that backend as part of the product, which puts it in the same reporting scope as the code you ship. A backend your product works fine without does not meet that test. It is also the internet-facing part, and therefore the part a customer or a researcher is most likely to tell you about first, which is exactly what our free external security check looks at.

Frequently Asked Questions

This post is informational and does not constitute legal advice. Scope determinations under the CRA are fact-specific and should be confirmed with legal counsel. Primary sources: Regulation (EU) 2024/2847, Article 14, Article 69, Article 64.