AI and LLM Penetration Testing Services
Web Penetration Testing Services
Mobile Penetration Testing Services
API Penetration Testing Services
Internal Network Penetration Testing Services
External Network Penetration Testing Services
PCI DSS Penetration Testing Services
Red Teaming Services & Operations
Threat-Led Penetration Testing Services (TLPT)
loT Penetration Testing Services
Embedded Systems Penetration Testing Services
Cloud Penetration Testing Services
Container Penetration Testing Services
Threat modeling for agile teams
Managed application security
DevSecOps consulting
Disclaimer: Article 14 reporting obligations take effect 11 September 2026. Full compliance is mandatory by 11 December 2027. This guide covers everything product manufacturers need to know — from classification and Annex I requirements to conformity assessment, technical documentation, and a practical compliance roadmap.
What Is the CRA and Who Does It Apply To?
The Cyber Resilience Act — Regulation (EU) 2024/2847 — is a horizontal EU regulation establishing mandatory cybersecurity requirements for all products with digital elements. In practice, this means hardware and software products that can connect, directly or indirectly, to another device or network.
Until the CRA, EU cybersecurity regulation remained fragmented. The NIS2 Directive addressed operators of essential services. The Radio Equipment Directive covered radio-connected products. Sector-specific frameworks applied to medical devices, aviation, and automotive systems. But a broad category of connected products — consumer IoT, industrial sensors, routers, firmware, software libraries, desktop applications — often fell into a regulatory gap, with no binding cybersecurity obligations.
The CRA closes that gap. It applies to:
- IoT devices: routers, smart cameras, sensors, wearables, home automation hubs
- Industrial products: PLCs, SCADA components, industrial gateways, robotics
- Software: operating systems, applications, libraries, firmware, SDKs, middleware
- General-purpose computing hardware: CPUs, network interface cards, storage controllers
The Cyber Resilience Act applies to manufacturers, importers, and distributors placing products on the EU market, regardless of where the company is headquartered. Limited exclusions apply to open-source software without a commercial purpose, products already covered by sector-specific regulation — such as MDR, EASA, or UNECE R155 — and national security applications.
This guide covers what product manufacturers need to know about the Cyber Resilience Act — from CRA product classification and Annex I requirements to CRA conformity assessment, technical documentation, Article 14 reporting, and a practical compliance roadmap.
Key CRA Compliance Deadlines
Most discussions around CRA compliance focus on the December 2027 full-compliance deadline. However, several earlier milestones matter, especially for organisations that need to build reporting workflows, technical documentation, and product-level security evidence.
| Attribute | Detail |
|---|---|
| The Requirement |
|
| Scope | Full Ecosystem: Device Firmware + Mobile App + Cloud API/Backend. |
| Frequency | Pre-Market (before launch) and post-market (continuous vulnerability management). |
| Methodology | Risk-based assessment focusing on Exploitable Vulnerabilities and Security by Design. |
| Iterasec Solution | Full Ecosystem Assessment. We test the firmware, API, and mobile app to ensure the entire product chain is secure before the Declaration of Conformity. In view of CRA, not only do you get an independent security assessment, but also a review of specific CRA-relevant security controls, processes and implementation resilience:
|
| External Required? | Often Mandatory. "Critical" class products require a Notified Body (Third Party). For others, an external report acts as crucial liability protection. |
Product Classification Under the CRA: Understanding the Four Tiers
The Cyber Resilience Act establishes four product classification tiers based on cybersecurity risk. Getting this classification right is critical, because it determines the conformity assessment path, the depth of testing and documentation required, and whether a notified body must be involved.
Default Category
The vast majority of products with digital elements fall into the default category. This includes personal computers, smartphones, smart TVs, most consumer IoT products, and general-purpose software.
For default-category products, manufacturers perform their own conformity assessment under Module A, apply CE marking, and maintain the required technical documentation.
Important Products: Class I
Class I covers products where a cybersecurity failure carries heightened downstream risk. Annex III lists these explicitly, including identity management systems, password managers, VPNs, network traffic management tools, browsers, operating systems for industrial use, firewalls, intrusion detection systems, and connected toys.
For Class I products, manufacturers can self-certify only if a harmonised standard covering all relevant CRA requirements has been published in the Official Journal of the European Union. As of April 2026, this is not the case for most Class I products, which makes the standards landscape especially important.
Important Products: Class II
Class II includes higher-criticality products where failures could cause serious harm at scale. Examples include hypervisors, container runtimes, PKI infrastructure, hardware security modules, smart meter gateways, industrial robots, and critical infrastructure components.
Class II products always require third-party conformity assessment by an accredited notified body. There is no self-certification option.
Critical Products
The critical category is smaller and more targeted. It covers products where compromise could have severe consequences for EU-wide critical infrastructure, such as smart grid components, certain automotive systems, and aviation electronics outside sector-specific regulation.
Critical products require the highest assurance level, including European Cybersecurity Certification under the EUCC scheme where available.
Cyber Resilience Act Requirements: Annex I Explained
The core technical obligations of the CRA are set out in Annex I. They are divided into two parts and define the 21 specific requirements against which every CRA-compliant product must be assessed.
For manufacturers, these Cyber Resilience Act requirements are not abstract controls. They define the security evidence that must be reflected in product design, vulnerability handling, testing, and technical documentation.
Part I: Security Properties for Design and Development
Products must be designed, developed, and produced to satisfy all 13 security properties below:
| Req. | Security Property |
|---|---|
| 2(a) | No known exploitable vulnerabilities at time of market placement |
| 2(b) | Secure by default — hardened defaults, minimal attack surface, no unnecessary open ports or services |
| 2(c) | Protection from unauthorised access — authentication, authorisation, access control including physical interfaces |
| 2(d) | Protection of data confidentiality — encryption in transit and at rest |
| 2(e) | Protection of data integrity — tamper detection and protection |
| 2(f) | Minimal data processing — only what is necessary for the intended function |
| 2(g) | Protection of availability — resilience against DoS and resource exhaustion attacks |
| 2(h) | Limited attack surface — ports, services, and components minimised |
| 2(i) | Reduced impact of incidents — logging, monitoring, and reset to known-good state |
| 2(j) | Security updates — timely, signed updates throughout the support period |
| 2(k) | Secure update mechanism — integrity verification, protection against rollback |
| 2(l) | Security event logging — authentication events, configuration changes, anomalies with timestamps |
| 2(m) | Data erasure — verifiable removal of personal and sensitive data on reset or disposal |
These requirements make cybersecurity-by-design a formal obligation rather than a best-practice recommendation. Manufacturers need to demonstrate that security was considered at the product design level, not added as a late-stage control.
Part II: Vulnerability Handling Obligations
Part II governs the post-market phase and is where many manufacturers are least prepared, especially when it comes to vulnerability handling, coordinated disclosure, and SBOM CRA requirements.
| Req. | Obligation |
|---|---|
| §1 | SBOM — maintain a Software Bill of Materials in machine-readable format (SPDX or CycloneDX) covering all top-level components and dependencies |
| §2 | Vulnerability identification and remediation — documented process for receiving, triaging, and fixing reported vulnerabilities |
| §3 | Regular security testing — including penetration testing and automated source code analysis (SAST/DAST) |
| §4 | Security updates — provided free of charge for the full duration of the support period |
| §5 | Coordinated vulnerability disclosure (CVD) — published policy with active contact address and researcher acknowledgement process |
| §6 | Coordinated disclosure to ENISA and CSIRTs — working through the single EU reporting platform at euvdb.europa.eu |
| §7 | Security update deployment — timely, with clear user communication on severity and urgency |
| §8 | Vulnerability information sharing — disclosure to other affected manufacturers and coordination through CSIRTs where relevant |
The support period — the duration for which a manufacturer must provide security updates — must be stated explicitly and must be appropriate to the product’s expected use lifetime. For consumer products with multi-year lifecycles, this creates long-tail obligations with real commercial implications.
Article 14: Incident and Vulnerability Reporting
Article 14 establishes a dual-track reporting regime with a three-stage notification timeline. It is one of the most operationally demanding parts of the CRA and the one that becomes applicable first, on 11 September 2026.
Track 1: Actively Exploited Vulnerabilities
This reporting track is triggered when a manufacturer becomes aware that a vulnerability in its product is being actively exploited in the wild.
| Stage | Deadline | Required Content |
|---|---|---|
| Early Warning | Within 24 hours of awareness | Indicate that exploitation is occurring; no full analysis required at this stage |
| Notification | Within 72 hours | Severity assessment, affected product versions, initial mitigation actions taken |
| Final Report | Within 14 days | Root cause analysis, full remediation plan, patch availability, estimated affected user count |
Track 2: Severe Incidents
This track is triggered when a cybersecurity incident affecting a product has a significant impact on the manufacturer or on users.
| Stage | Deadline | Required Content |
|---|---|---|
| Early Warning | Within 24 hours of awareness | Indicate that a severe incident has occurred |
| Notification | Within 72 hours | Impact assessment, affected products, actions taken to contain the incident |
| Final Report | Within 1 month | Detailed incident analysis, systemic fixes implemented, lessons learned |
Reports are submitted to ENISA and the relevant national CSIRT through the single EU reporting platform at euvdb.europa.eu. For incidents affecting users in multiple member states, the platform automatically routes notifications to the appropriate national authorities.
CRA Technical Documentation: Annex VII and the Technical File
Before placing a product on the EU market, manufacturers must compile and maintain a Technical File — the complete documentary record demonstrating Cyber Resilience Act compliance. This is a living document that must be updated after every substantial modification and retained for 10 years after the product is placed on the market.
The Technical File must cover:
- Product description: intended use, hardware and software configuration, product variants, supported interfaces
- Cybersecurity risk assessment: threat analysis using STRIDE, TARA, or an equivalent methodology; asset register with CIA impact ratings; threat scenarios mapped to Annex I requirements; risk treatment decisions with residual risk acceptance
- Annex I compliance evidence: for each of the 13 Part I properties and 8 Part II obligations — implementation status, supporting evidence, test results, and maturity score
- SBOM: complete list of software components with version, licence, and known CVEs
- Vulnerability handling documentation: CVD policy reference, patch release process, security testing programme
- Harmonised standards applied: which standards were used, version, scope, and any deviations noted
- Test reports: penetration test reports, fuzzing results, SAST/DAST outputs, and any standards-specific assessment results
- Draft EU Declaration of Conformity: the formal Annex V statement with full product scope and conformity module reference
CRA Conformity Assessment: Choosing the Right Path
The conformity module determines how a manufacturer formally demonstrates compliance. The correct path depends on product classification and the availability of relevant harmonised standards.
| Module | Description | Applicable To |
|---|---|---|
| Module A | Internal production control — manufacturer self-certifies, no external body | Default category; Class I where applicable harmonised standard exists |
| Module B+C | Type examination by notified body + production conformity declaration | Class I (no harmonised standard available); Class II |
| Module H | Full quality assurance system — notified body audits the QMS, not just the product | Class II alternative to Module B+C |
| EUCC | European Cybersecurity Certification Scheme — highest assurance level | Critical category; optional for Class II |
For manufacturers, this makes classification and standards monitoring more than a legal exercise. They directly affect budget, assessment timelines, technical documentation depth, and the need for third-party involvement.
The Harmonised Standards Landscape
Harmonised standards are the practical mechanism through which manufacturers demonstrate compliance with specific CRA requirements. A product manufactured according to a harmonised standard cited in the Official Journal of the European Union carries a presumption of conformity for the requirements that standard covers.
At the moment, the standards’ landscape is still complicated.
EN 18031 For Radio Equipment
EN 18031-1/2/3 covers cybersecurity requirements for radio-connected products within the scope of the Radio Equipment Directive. It covers 11 mechanism groups:
- Access Control Mechanism — ACM
- Authentication Mechanism — AUM
- Software Update Mechanism — SUM
- Security Services Mechanism — SSM
- Security Configuration Mechanism — SCM
- Resilience Mechanism — RLM
- Network Management Mechanism — NMM
- Traffic Control Mechanism — TCM
- Cryptographic Controls and Key Management — CCK
- General Controls — GEC
- Cryptographic Mechanisms — CRY
For products with Wi-Fi, Bluetooth, cellular, or Zigbee connectivity, EN 18031 provides a robust conformity path with a well-understood assessment methodology.
EN 40000 and the Current Standards Gap
Until EN 40000 is published in the OJEU, manufacturers of non-radio Class I products should:
- monitor CEN/CENELEC progress and OJEU publication timelines;
- proceed with notified body involvement rather than assuming self-certification will be available;
- document clearly which existing standards — such as IEC 62443, ISO 27001, or ETSI EN 303 645 — they are applying and how those standards map to Annex I requirements.
Where Organisations Are Currently Falling Short
Based on hands-on CRA readiness assessments across product manufacturers, we consistently see the same gaps.
- No SBOM process aligned with CRA requirements. Most organisations do not maintain a current, machine-readable SBOM. Open-source components accumulate without documentation, versions drift, and there is no systematic CVE monitoring. Building an SBOM retrospectively for a mature product can become a multi-month project.
- No published CVD policy. Fewer than a third of manufacturers we assess have a coordinated vulnerability disclosure policy. Without one, the CRA Part II §5 obligation is immediately unmet. Legal sign-off, intake channels, acknowledgement workflows, and researcher communication processes all take time to establish.
- Inadequate security event logging. Annex I §2(l) requires logging of authentication events, configuration changes, and anomalies. Many embedded and IoT products still rely on minimal logging, often stored locally and without tamper protection.
- No product-level risk assessment. Corporate ISO 27001 or SOC 2 programmes do not replace a product-specific threat model mapped to Annex I requirements. The CRA assessment must cover the product’s actual deployment threat landscape.
- No Article 14 workflow. Many organisations lack a defined process for detecting, classifying, and reporting CRA-reportable events. The 24-hour early warning clock requires detection-to-notification speed that typical enterprise security processes are not designed to support.
- Incomplete technical documentation. Manufacturers that have not specifically prepared for CRA often lack documentation that would satisfy Annex VII. Internal wikis, architecture diagrams, and scattered test reports are not a Technical File.
A Practical CRA Compliance Roadmap
Given the September 2026 and December 2027 deadlines, a realistic sequencing for a typical manufacturer should look like this:
Now — Q3 2026: Prepare Before Article 14 Applies
Before Article 14 becomes applicable, manufacturers should focus on the processes that are hardest to build under pressure:
- Conduct a gap assessment against the full Annex I checklist and Annex VII requirements
- Classify products accurately, and classify conservatively where uncertainty remains
- Establish the Article 14 reporting workflow and register with the relevant national CSIRT
- Draft and publish a coordinated vulnerability disclosure policy
- Begin building or formalising the SBOM process and CVE monitoring pipeline
Q3 2026 — Q2 2027: Remediation and Documentation
Once reporting readiness is in place, the next phase should focus on technical remediation and evidence-building:
- Commission penetration testing and security architecture reviews aligned to Annex I properties
- Remediate critical and high-severity findings from testing
- Begin drafting the Technical File for each product, including product description, risk assessment, and Annex I evidence tables
- Conduct product-level threat modelling using STRIDE, TARA, or an equivalent methodology
- Engage a notified body early if products are Class I without an applicable harmonised standard, or Class II
Q3 — Q4 2027: Final Compliance Push
The final phase should focus on formalisation, market access readiness, and ongoing maintenance:
- Complete and finalise the Technical File
- Sign and register the EU Declaration of Conformity under Annex V
- Apply CE marking and ensure product labelling meets CRA requirements
- Brief distribution and import channels on their downstream obligations
- Establish the ongoing maintenance programme: security testing cadence, SBOM update triggers, and patch release process
Start your CRA readiness assessment with Iterasec today.
How Iterasec Supports CRA Compliance
Iterasec is a specialist cybersecurity company focused on product security, CRA penetration testing, and compliance-ready technical evidence. Our CRA compliance services map directly to the obligations described above — from gap assessment and security testing to Technical File evidence and Article 14 readiness.
CRA Readiness Assessment and Gap Analysis
We evaluate products against all Annex I Part I and Part II controls across nine domains, from security by design and authentication to cryptography, logging, and update mechanisms.
The output is a scored worksheet with maturity ratings and prioritised remediation guidance. For most organisations, this is the natural starting point for a structured CRA compliance programme.
Penetration Testing for CRA Evidence
Annex I Part II §3 requires regular security testing, including penetration testing. Iterasec’s reports map findings directly to Annex I requirements, providing documentation that can be used both for remediation and as Technical File evidence.
Our testing covers embedded firmware, IoT hardware, APIs, cloud backends, mobile applications, and network protocols.
Security Architecture Review
We review product architecture against Annex I security properties and identify structural gaps before they become expensive to fix. This may include insufficient privilege separation, missing update signing, inadequate boot integrity, weak logging, or insecure trust boundaries.
A security architecture review helps teams align product design with CRA requirements before major engineering investment is committed.
Technical File Preparation
We provide a structured template and documentation process covering all Annex VII sections, including product description, risk assessment with threat scenarios, Annex I evidence tables, SBOM register, harmonised standards mapping, and a draft EU Declaration of Conformity ready for signature.
The goal is to create documentation that reflects the real security posture of the product, not a superficial compliance pack.
CVD Policy and SBOM Setup
We draft coordinated vulnerability disclosure policies aligned with CRA Part II §5–6 requirements, helping manufacturers establish a process that satisfies both operational and compliance expectations. This includes the contact channel, researcher acknowledgement workflow, safe harbour statement, and ENISA coordination procedure.
We also support SBOM tooling selection, initial SBOM generation for existing products, and CVE monitoring integration.
Article 14 Incident Response Readiness
We build the detection-to-notification workflow required under Article 14. This includes event classification criteria, escalation paths, notification templates for all three reporting stages, and tabletop exercises to stress-test the process before a real incident occurs.
Conclusion
The EU Cyber Resilience Act is one of the most significant product security regulations the technology industry has faced. It is not primarily about paperwork. It is a mandate to build more secure products, maintain them responsibly throughout their lifecycle, and communicate transparently when serious vulnerabilities or incidents occur.
The organisations best positioned for CRA compliance will be those that treat it as an engineering and operational discipline rather than a legal formality. That means investing in security architecture and testing, building real SBOM infrastructure, establishing coordinated vulnerability disclosure processes early, and commissioning independent security testing that can credibly support the Technical File.
The September 2026 Article 14 deadline is the immediate priority. If an organisation does not yet have a structured CRA programme underway, the time to start is now, not after months of internal planning.
Iterasec works with technology manufacturers across Europe to build CRA compliance programmes that are technically strong, commercially realistic, and capable of withstanding market surveillance scrutiny. Get in touch to discuss where your products stand and what a structured readiness programme could look like for your organisation.
