The EU Cyber Resilience Act is no longer a future obligation. Reporting requirements begin September 11, 2026. Full enforcement follows December 11, 2027. For manufacturers of connected products in Europe, the compliance clock is already running.
TLDR
The EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to document, test, and prove the security of their software throughout its entire lifecycle. Cyber Resilience Act testing is not optional. For engineering teams building connected industrial systems, automotive components, and embedded devices, the evidence of testing has to exist, and it has to be traceable.
What the Cyber Resilience Act Actually Requires
The CRA (Regulation EU 2024/2847) entered into force on December 10, 2024. It applies to any product with digital elements placed on the EU market, including hardware, software, embedded systems, industrial controllers, and connected components.
The key obligations manufacturers need to prepare for:
Vulnerability reporting (from September 11, 2026): Actively exploited vulnerabilities must be reported to the relevant CSIRT and ENISA with an early warning within 24 hours of discovery. A full notification follows within 72 hours. This is not a general "have a process" requirement. It is a clock.
Technical documentation: Manufacturers must produce a cybersecurity risk assessment, a Software Bill of Materials (SBOM), and documented vulnerability handling processes covering the expected product lifetime or a period of at least five years, whichever is shorter.
Conformity assessment: Depending on product risk class, this means either self-assessment or mandatory third-party audit. Products must carry CE marking to demonstrate compliance before being placed on the EU market.
Security testing evidence: The CRA requires regular testing and review of product security as part of vulnerability handling. This is not prescriptive about methodology, but it is explicit that documented evidence of testing must exist.
The penalty for non-compliance: fines up to €15 million or 2.5% of global annual turnover, whichever is higher. Regulators can also order product recalls or market withdrawal.
Who Is Affected
The CRA is horizontal. It applies across sectors, not just one industry.
Manufacturing and industrial automation: Every connected component in a production environment, from PLCs to industrial gateways, falls within scope. Legacy products already on the market are also subject to reporting obligations if they remain under support after September 2026.
Automotive suppliers: Vehicle type approval is governed by UN R155 and R156. The CRA adds a separate layer. Suppliers placing products on the EU market under their own name, such as standalone telematics units, aftermarket components, or mobile applications, face CRA obligations independently of OEM approval chains. The same engineering process can feed both regimes, but the evidence packages and accountability owners are different.
Industrial software and embedded systems: Connected HMI panels, SCADA interfaces, and industrial display systems that are sold as standalone products on the EU market fall within CRA scope. For large industrial manufacturers, this means every connected component in a production environment needs traceable test documentation.
MedTech: Products already regulated under MDR or IVDR are generally excluded from CRA requirements. Any connected software or device that does not fall strictly under those definitions may still be subject to CRA.
Why Manual Testing Cannot Meet the CRA Bar
The CRA does not prescribe specific testing tools or methods. What it does prescribe is outcomes: documented evidence that security properties were verified, vulnerabilities were handled, and testing was conducted throughout the product lifecycle.
For engineering teams that currently rely on manual testing, two specific problems emerge.
The reporting timeline. An early warning within 24 hours of discovering an actively exploited vulnerability, followed by a full notification within 72 hours, means the process of detecting, classifying, and escalating an incident must be automated. Manual workflows cannot reliably meet this deadline.
The evidence requirement. Conformity assessments require structured, verifiable documentation. Post-test report compilation that takes days is not a compliant process. The evidence needs to be generated as part of test execution, not assembled afterward.
For products with embedded displays or HMI panels, there are no selectors, no DOM, and no accessibility hooks. Traditional tools need these to operate. Without them, test execution and evidence generation both stop
How Agentic Testing Supports Cyber Resilience Act Testing Requirements
AskUI provides agentic testing infrastructure for connected and embedded environments. It operates at the interface level, using a hybrid execution model: selectors and DOM when available, and screen-based execution when they are not. This means it can run on locked-down production builds, industrial HMI panels, automotive digital clusters, and connected devices where traditional tools cannot reach.
The compliance-relevant capabilities:
Automated evidence generation. Every test run produces structured HTML reports with screenshots at each step, action traces, and verification results. This is the documentation that conformity assessments require, generated automatically as part of execution rather than assembled manually afterward.
On-premise deployment. AskUI runs inside customer infrastructure. Test data, screenshots, and session logs never leave the organization's network. For manufacturers with data residency requirements or pre-release IP to protect, this is not optional.
Audit trail by default. Every agent action is logged: what it saw, what it decided, what it did, and what the result was. In regulated industries, this is the difference between "we tested it" and "we can prove we tested it."
Cross-surface coverage. The same test logic runs across SIL and HIL environments, hardware variants, and configuration builds without rebuilding from scratch. Signal-to-UI verification confirming that the correct UI state renders after a signal fires, generates traceable evidence at each step across every variant.
ISO 27001 certified, GDPR compliant. Zero model training on customer data.
The Timeline That Matters
| Date | Obligation |
|---|---|
| December 10, 2024 | CRA entered into force |
| June 11, 2026 | Conformity assessment bodies framework established |
| September 11, 2026 | Mandatory vulnerability and incident reporting begins |
| December 11, 2027 | Full CRA enforcement: all requirements apply |
The September 2026 deadline is the one that requires immediate preparation. Manufacturers that wait for full enforcement in 2027 will not have enough time to build the processes, tooling, and documentation infrastructure that reporting obligations require.
FAQ
Does the CRA apply to software-only products?
Yes. The CRA covers both hardware and software products with digital elements. Standalone software distributed for use on end-user devices falls within scope. Pure SaaS delivered entirely in the cloud is excluded, but any downloadable component or client-side element brings the product into scope.
Are automotive products excluded because of UN R155/R156?
No. UN R155 and R156 govern vehicle type approval. The CRA applies to products placed on the EU market under a manufacturer's own name, independently of OEM approval chains. Automotive suppliers may face obligations under both regimes. The evidence packages are different.
What is the minimum support period under the CRA?
The CRA requires manufacturers to support their products for the expected product lifetime or at least five years, whichever is shorter. Vulnerability handling and security documentation must be maintained throughout this period.
Does the CRA require penetration testing specifically?
No. The CRA is technology-neutral. It requires documented evidence of security testing and vulnerability handling, but does not mandate specific methodologies. Penetration testing may be used as part of a broader security validation strategy.
How does AskUI help with CRA compliance specifically?
AskUI generates audit-ready test artifacts automatically during execution: structured reports, action traces, and screenshots at every step. Combined with on-premise deployment and ISO 27001 certification, it provides the documentation infrastructure that conformity assessments and vulnerability reporting require. For connected products with embedded displays or HMI interfaces, it also solves the access problem: running functional tests on environments where traditional tools cannot operate.
Where can I learn more about AskUI's compliance capabilities?
See The Audit Trail: Verifiable Evidence for Automotive Compliance for a detailed walkthrough of how AskUI generates traceable test evidence in SIL environments.
Sources
- Cyber Resilience Act - Reporting Obligations — European Commission
- Regulation (EU) 2024/2847 - Full Legal Text — EUR-Lex, Official Journal of the EU