EU Cyber Resilience Act — Guide for Penetration Tester & Red Team Lead
What the CRA means for your role, your team, and your day-to-day responsibilities.
Penetration Testing and Red Team Leads are a critical source of independent assurance that products with digital elements satisfy Annex I cybersecurity requirements. The CRA does not mandate specific testing frequency or methodology, but it requires manufacturers to demonstrate that products are free from exploitable vulnerabilities before market placement — a standard that is most credibly met with documented penetration testing evidence. This guide explains how pen testers produce, structure, and feed findings into the compliance and incident response programmes.
Your CRA responsibilities:
- ›Conduct structured penetration tests against products with digital elements and their supporting backend infrastructure
- ›Produce test reports formatted as conformity evidence suitable for the CRA technical file
- ›Define and maintain a product-class penetration testing scope that maps to Annex I Part I requirements
- ›Coordinate vulnerability findings with the PSIRT for triage, remediation tracking, and Article 14 assessment
- ›Advise the Security Architect on newly identified attack patterns and residual risk assessments
- ›Support notified body assessments by providing test evidence for Class I and Class II products
- ›Maintain a register of open findings with severity ratings and remediation deadlines
Penetration Testing as CRA Conformity Evidence
The CRA requires manufacturers to demonstrate that products satisfy Annex I requirements (Article 13(2)) and to retain this evidence in the technical file for 10 years (Article 23, Annex V). For Annex I obligations concerning absence of known exploitable vulnerabilities (§1), minimised attack surface (§2), and authentication controls (§6), penetration test reports are among the most credible and widely accepted forms of conformity evidence.
To be useful as conformity evidence, penetration test reports must:
- Clearly state the scope and version of the product tested — including firmware version, hardware revision, and API version
- Reference the specific Annex I requirements addressed by each test objective
- Document methodology: the testing approach, tools used (without relying solely on automated scans), and any scope limitations
- Record all findings with severity rating (CVSS 3.1 or 4.0 base score), reproduction steps, and affected component
- Include a remediation status section updated after each fix to demonstrate closure
- Be signed by the lead tester with their name, qualifications, and the date of test execution
Reports that satisfy these criteria can be cross-referenced in the technical file as evidence against specific Annex I requirements.
Scope and Frequency Requirements Under Annex I
Annex I does not prescribe penetration testing frequency, but the obligation to maintain products free from exploitable vulnerabilities throughout the support period (Article 13(8)) implies that testing cannot be a one-time pre-launch activity.
A CRA-aligned testing programme should define scope and cadence as follows:
- Pre-market placement: a full-scope penetration test covering all network interfaces, update mechanisms, authentication systems, and data-at-rest and in-transit protections — this is the minimum for technical file inclusion
- On significant architectural change: any change to the attack surface (new interface, new authentication mechanism, new cloud component) triggers a targeted test of the changed area
- Annual cadence: for products in active support, an annual test covering the full original scope plus any changes — retained in the technical file as ongoing conformity evidence
- On major CVE disclosure: when a critical vulnerability is disclosed in a component used by the product, a targeted test confirms whether the product is exploitable before the Article 14 assessment is made
Scope must explicitly include the update delivery mechanism — a compromised update channel is a critical attack vector specifically addressed by Annex I §12.
Documenting Findings for the Technical File
The technical file (Annex V) must contain sufficient information for a national market surveillance authority or notified body to verify conformity. Penetration test findings — including unresolved findings with accepted risk rationale — must be structured accordingly.
Finding documentation requirements for the technical file:
- Unique finding ID: for cross-referencing between test reports, remediation tickets, and risk acceptance records
- Annex I requirement mapping: which Annex I provision does the finding potentially violate? (e.g., an unauthenticated API endpoint maps to §6; a stack overflow maps to §1)
- CVSS score and vector: using CVSS 3.1 or 4.0 base score — notified bodies expect standardised severity ratings
- Reproduction steps: sufficient detail for the security team to reproduce and verify the fix without the original tester present
- Remediation record: the fix applied, the version in which it was shipped, and a retest result confirming closure
- Risk acceptance record (for accepted findings): signed by the CISO or delegated authority, with rationale and review date
All finding records should be version-controlled and linked to the specific product release in the technical file.
Coordinating with PSIRT on Discovered Vulnerabilities
When penetration testing discovers a vulnerability in a product already on the market, or when an externally reported vulnerability requires verification, the pen tester's role shifts to supporting the PSIRT's Article 14 obligations.
Article 14 imposes three sequential notification obligations on manufacturers:
- 24-hour early warning to ENISA and the relevant national CSIRT: confirm that an actively exploited vulnerability exists, product(s) affected, and any available mitigations
- 72-hour notification: full technical details of the vulnerability, its severity, and the remediation plan
- 14-day final report: complete incident analysis including the remediated version, deployment status, and lessons learned
Pen testers support this process by:
- Rapid severity rating: providing an authoritative CVSS score and exploitability assessment within hours of a finding being escalated to PSIRT
- Impact scoping: confirming which product versions, hardware revisions, and deployment configurations are affected
- Retest verification: confirming that the remediation is effective before the final report is submitted
- Technical narrative: contributing the vulnerability description and reproduction summary that forms the core of the ENISA notification
Pen testers should have a pre-established escalation path to the PSIRT Lead and be included in the incident response runbook.
Getting Started Checklist
Practical first steps for Penetration Testers building CRA compliance into their programme:
- Audit existing test reports for conformity-evidence quality — identify gaps in Annex I requirement mapping, missing CVSS scores, or absent scope declarations
- Create a CRA-aligned report template that captures all technical file requirements as mandatory fields, preventing omissions
- Map the product portfolio to establish which products require pre-market testing before the CRA application date and which need retrospective testing during the transition period
- Establish a finding lifecycle process covering severity rating, PSIRT notification, remediation verification, and risk acceptance — document this process and include it in the technical file
- Agree escalation thresholds with the PSIRT: which CVSS score or severity label triggers an Article 14 early warning assessment?
- Review the update mechanism of every in-scope product — update channel integrity is a frequent finding and an explicit Annex I requirement (§12)
- Run the CVD Portal CVSS Calculator to standardise severity ratings across the team before findings are submitted to the technical file
CVD Portal handles your CRA Article 13 obligations automatically.
Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation — built for Pen Testers and their teams.
Start your free portalFrequently asked by Pen Testers
Can automated vulnerability scanning substitute for penetration testing as CRA conformity evidence?+
Automated scanning can supplement but cannot replace manual penetration testing as CRA conformity evidence. Annex I §1 requires the absence of known exploitable vulnerabilities, and automated scanners have well-documented false-negative rates — particularly for business logic flaws, authentication bypass, and chained exploits. Notified bodies conducting conformity assessments for Class I and Class II products expect evidence of manual testing with human expertise, not scanner output alone. Automated scanning is valuable for continuous monitoring between manual test cycles.
Does the CRA require penetration testing by an accredited third party?+
For Class I products using the self-assessment route, internal penetration testing is acceptable provided the team is sufficiently independent from the development team and the methodology and qualifications are documented. For Class II products requiring a notified body assessment, the notified body may conduct its own testing or require evidence from a qualified third party. Organisations should document tester qualifications in the technical file regardless of whether internal or external testers are used.
What should a pen tester do if they discover a critical vulnerability in a product that is already on the market?+
A critical finding in a shipped product triggers the Article 14 notification obligation if the vulnerability is actively exploited or poses an immediate risk. The pen tester should immediately notify the PSIRT Lead with the full finding details, CVSS score, and affected versions. The PSIRT then has 24 hours from becoming aware to file an early warning with ENISA and the national CSIRT, and 72 hours to file a full notification. The pen tester should remain available to support the technical narrative and conduct retest verification within the 14-day final report window.
Key CRA articles for Pen Testers
Need a CVD policy template your team can deploy today?
Free CRA-compliant templates for every stage — from first CVD policy to full PSIRT programme.